>> I've done some investigating into the elink3 (ep driver) related crashes,
>> and found the following:
>> 
>>       - Removing the do { } while around mbuf macros did not result
>>         in different code for elink3.o. Perhaps it avoided the problem
>>         by changing code in other places slightly.


>This directly contradicts my experience, by the way.
>
>adding the do {} while (0)'s DID change the generated code, in all of
>the builds with optimization that _I_ ran.


Sometime last month I mailed Christos .s output from chris' patch,
both pwith and without -D_LOSING_COMPILER.  It definitely changed the
.s output for me.  Christos has the .s files.  Apparently the impact
of this bug depends on what the register-allocation bug trashes; some
people apparenlty have no ill effects at all.

[fvdl's -fno-force-mem workaround]


Please don't advocate this as a workaround.  

If it works, it works by changing gcc's register allocation (by not
forcing memory values into registers to make them potentially more
exploitable by CSE).  I haven't looke dbut I guess It's almost
certainly working by changing the allocation of %eax from something
that spans a bus_space_XXX_multi() method call, to something that
doesn't.

That works for the current source, but its' inherently fragile, and in
fact may not help other mysterious crashes at all.  It could quite
plausibly _create_ them.

The right way to fix this bug is to fix the compiler, or failing that,
in specific cases, to kludge the source code to avoid the problem.


I haven't been a gcc maintainer for yonks, if someone has more
up-to-date info on gcc internals I'd be glad to be corrected.