> 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.
