>> Would anyone object to me committing the following change to
>> src/usr.bin/xlint?

> That is extrememly unlikely to be a real solution to any problem.

No, it's not, but I don't think there's anything wrong with making 
something work until someone does find the real solution.

> Likely possibilities:
>
> 1) There is an undefined variable somewhere, -O0 changes the code size
>   and makes it go away.

If that were the case, this problem would occur on all machines.

> 2) The compiler is generating an illegal sequence of instructions
>   (and maybe making use of a computed value too early).
>   This could easily affect any program.

I don't think there's any new (7447 or 7457) errata about instructions 
that cannot be run side by side, or at least any I can find in Motorola's 
/ FreeScale's documentation.

> 3) The cache hardware on the processor is broken.

Then this would either be isolated to one CPU (I've seen it on three), or 
it would apply to all 7447 / 7455 / 7457 CPUs, and the problem would be 
seen elsewhere.

> 4) The NetBSD cpu support isn't right

Certainly possible.

> If (1) then other architectures might be affected.
> If (2), (3) or (4) then other programs will be affected.
> So a lot of analysis needs to be done to determine the exact failure.

My guess is that there's a problem in lint specifically. I don't know much 
about the actual implementation, but lint basically plays with code and 
data structures in memory, so it's not unthinkable that something 
manipulated as data isn't getting flushed properly before it's executed. 
Or something like that.

I agree that this doesn't fix the problem per se, but the question 
remains: would anyone object to me fixing the symptom?

John