[Bug tree-optimization/57701] New: Incorrect optimisation of inlined function with inline assembly when cross-compiling

[Bug tree-optimization/57701] New: Incorrect optimisation of inlined function with inline assembly when cross-compiling

[sqweek at gmail dot com]

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.

[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You do not properly specify the side-effects of the asms so the compiler
assumes it can freely re-order things as it likes.

[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling

[sqweek at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701

--- Comment #2 from sqweek <sqweek at gmail dot com> ---
Sorry! The constraints were actually the first place I looked for a problem,
apparently my inexperience with assembly made me blind to the mistake :(

Thanks for your time.

[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling

[rennis at gmx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701

rennis at gmx dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rennis at gmx dot com

--- Comment #3 from rennis at gmx dot com ---
Richard, do you have any information on how to specify the side-effects?  Any
tips or guesses on how you would go about it in this situation?  I'm having the
same problem as sqweek (we're both trying to build inferno-os, a 32-bit
application, on archlinux 64-bit).  I'm far out of my realm here.  I've played
with assembly before, but never done much with inline assembly.

Thanks,
Rob

[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling

[hp at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu.org

--- Comment #4 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to rennis from comment #3)
> Richard, do you have any information on how to specify the side-effects? 
> Any tips or guesses on how you would go about it in this situation?  I'm
> having the same problem as sqweek (we're both trying to build inferno-os, a
> 32-bit application, on archlinux 64-bit).  I'm far out of my realm here. 
> I've played with assembly before, but never done much with inline assembly.

I'm not Richard but...
For effects other than the output operands, use "asm volatile" (which you don't
want to use if you *can* express the effect in terms of output operands).

Note also that your asm input constraints in fpe.c are totally wrong; input
constraints don't take register names, they're collections of "magic letters"
found in the gcc info pages in an arch-specific section.  That you managed to
group them to make valid register names unfortunately means nothing except
possibly to expose an opportunity for warnings improvement.

[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling

[sqweek at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701

--- Comment #5 from sqweek <sqweek at gmail dot com> ---
Hahaha, that amuses me probably more than it should! Thanks for chiming in
Hans, it would have taken me forever to figure that out :)