http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701
Bug ID: 57701 Summary: Incorrect optimisation of inlined function with inline assembly when cross-compiling Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sqweek at gmail dot com Created attachment 30354 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30354&action=edit Standalone source file for reproducing gcc version 4.8.1 (GCC) My system is x86_64-unknown-linux-gnu, but I'm cross-compiling to x86 (-m32) Configured with: /build/gcc-multilib/src/gcc-4.8.1/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --enable-multilib --disable-libssp --disable-werror --enable-checking=release I'm running the gcc-multilib binary from archlinux, which slightly modifies the stock gcc build - it doesn't run fixinc.sh and adds -O2 to some configure tests. I suspect they are not important, but in the interest of full disclosure the details available in the prepare() function at https://projects.archlinux.org/svntogit/community.git/tree/repos/multilib-x86_64/PKGBUILD?h=packages/gcc-multilib The problem: I've attached a program (which I've tried to make smaller but failed to reproduce the problem) that runs fine when compiled with no flags, but fails when compiled with -O. -O2 also fails, but -O3 works again *shrug*. Build commands: gcc -m32 fpe.c -o fpe #produces a working binary gcc -m32 -O fpe.c -o fpe-O #produces the failing binary Anyway, the code uses inline assembly to setup the floating point unit, then calculates 0./0. The expected result is a NaN, but when compiled with -O the FPU gets setup differently and we get a SIGFPE instead. I'm pretty new at assembler, but I *think* I've ruled that out as the cause, I've been stepping through the instructions in gdb and the results from the inline assembly sections appear to be the same. The value returned from getFPcontrol() seems to be where the differences begun.