From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14415 invoked by alias); 24 Jun 2013 15:27:36 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 14390 invoked by uid 48); 24 Jun 2013 15:27:33 -0000 From: "sqweek at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/57701] New: Incorrect optimisation of inlined function with inline assembly when cross-compiling Date: Mon, 24 Jun 2013 15:27:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sqweek at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg01399.txt.bz2 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.