Re: GNU make 3.81beta4 released

[Eli Zaretskii]

> From: "Markus Mauhart" <address@hidden>
> Date: Thu, 19 Jan 2006 00:55:46 +0100
> 
> Now I continued with your suggestion "-j 64" -- it run AFAICS allmost
> 1m without errors until I got ...
>     Assertion failed: a == g->changed, file .\remake.c, line 169
> ... this comes from an assertion I had inserted around this bug:
>     g->changed += commands_started - ocommands_started;
> (g->changed is only 8 bits wide).

What is the value of commands_started and ocommands_started at that
point, and what is the value of g->changed?

> Today before my 1st test I thought this bug could cause this infinite
> loop, hence the assertion.

What exactly is that assertion testing?  I mean, what is `a' to which
it compares the value of g->changed?

Anyway, it looks like g->changed is just a boolean flag, its value is
tested in remake.c to be either zero or non-zero.  So, unless I'm
missing something, the offending line can be modified to say:

           g->changed = commands_started - ocommands_started;

(and maybe insert an assertion that the expression on the left of the
assignment is either 0 or 1).  Can you see if this change removes the
problem?

> Fixing this one is not so easy, cause this byte is also used as a flag
> and sometimes binary combined with some pseudo-bools

remake.c uses this flag as TRUE/FALSE only, the bit-map use is
elsewhere (in main.c), and it's unrelated to what remake.c does,
AFAICS (Paul, could you please confirm that I didn't miss anything?).
The most telltale sign that remake.c doesn't treat g->changed as a bit
map is that remake.c doesn't use bitwise operators with it (in the
function we are discussing).

So I think the change I suggest above should be safe.