> From: "Markus Mauhart" <[EMAIL PROTECTED]>
> 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.
_______________________________________________
Make-w32 mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/make-w32
