From Bugzilla Helper:
User-Agent: Mozilla/4.75 [ja] (WinNT; U)
Description of problem:
Just see gcc-bug ml, #2246, this issue is reported.
called NaT comsamption fault.
But this has not been fixed yet.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.use ide-floppy module.
2.do benchmark test.
Actual Results: It could be kernel panic, segmentation fault or core dump.
Expected Results: Nothing'll be occured.
We encounted this issue when testing ide-floppy interrupt handler.
And this isn't ocurred everytime, but certainly. In ide-floppy.o
e0000000046626bc: dep r40=r14,r40,8,8 // r40.nat=r40.nat | r14.nat ...(2)
e00000000466271c: dep r40=r14,r40,0,8 // r40.nat=r40.nat | r14.nat
e000000004662966: zxt2 r34=r40 // r34.nat=r40.nat
e000000004662a96: mov r15=r34 // r15.nat=r34.nat
e000000004662aa0: add r14=r14,r15 // r14.nat=r15.nat
e000000004662ab6: st4 [r37]=r14 ...(1)
r40's nat bit isn't initialized on this sequence, because
r40 register hasn't been initialized before this.
We can do something to avoid this.
1) Edit kernel binary directry and swap the line(2) into
e0000000046626bc: dep r40=r14,r0,8,8
This is not good because we could fix only this bug.
2) Fix kernel source not to use the spaculative load.
__strlen_user() and strlen() functions use this spaculative
load. However gcc doesn't produce spaculative load if all
sources are in C,
Both are needed to avoid this issue.
The compiler is wrong to assume anything about the NAT state of registers it
doesn't fully set... -> assigning to gcc
Jim was looking at this at some point; Jakub, I can send you the discussion.
I know about it, have read the discussion. But as Jim is looking into this,
I'll leave it on him.
Oh, forgot to close this.
This has been fixed in gcc-2.96-101.