> And for this the starting point should be what has been requested,
> i.e. preprocessed source + gcc options + gcc version and some hints what
> actually misbehaves (with the , "+m" (*regs) change reverted)
> in gcc bugzilla.  Only with that we can actually look at what has been
> happening, see whether it is the tree optimizations or RTL and which one
> makes a difference.
> If I've missed a PR about this I apologize. 

I tried to file one, but I can't reproduce it currently
(I don't have hardware, so have to rely on code reading and the 32bit
code looks correct to me even without the additional +m)

The preprocessed source is at
http://halobates.de/tmp/i8k.i

Options I used:

 -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration 
-Wno-format-security -fno-delete-null-pointer-checks -O2 -m32 -msoft-float 
-mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 
-mtune=pentium3 -mtune=generic -maccumulate-outgoing-args -Wa,-mtune=generic32 
-ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 
-DCONFIG_AS_CFI_SECTIONS=1 -pipe -Wno-sign-compare 
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow 
-Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer 
-fno-optimize-sibling-calls -pg -Wdeclaration-after-statement -Wno-pointer-sign 
-fno-strict-overflow -fconserve-stack

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.

Reply via email to