[Bug target/50588] New: gcc produce bad inlined code with -march=athlon -O2

[Bug target/50588] New: gcc produce bad inlined code with -march=athlon -O2

[newsgrp at duradsl dot dyndns.org]

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

             Bug #: 50588
           Summary: gcc produce bad inlined code with -march=athlon -O2
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: newsgrp@duradsl.dyndns.org


Created attachment 25394
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25394
Reduced example that trigger the bug

When the attached file (which is a reduced testcase from inetutils
traceroute.c) is compiled with -march=athlon -O2, the resulting binary
segfault:

gcc -march=athlon -O2 -o traceroute traceroute.c
./traceroute
Before
Segmentation fault

When inlining is disabled, no problem:
gcc -march=athlon -O2 -fno-inline -o traceroute traceroute.c
./traceroute
Before
After

The problem can be reproduced on athlon-xp and core2 machines with 32 bits
libs.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.1/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++ --disable-multilib
--disable-bootstrap --with-system-zlib
Thread model: posix
gcc version 4.6.1 (GCC)

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-02 11:58:09 UTC ---
Doesn't fail for me on Fedora 13 / i686 (C2Q6600) with gcc 4.7, 4.6, 4.5, or
4.4.

Please upload _preprocessed_ source.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[newsgrp at duradsl dot dyndns.org]

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

--- Comment #2 from newsgrp at duradsl dot dyndns.org 2011-10-02 11:58:39 UTC ---
Created attachment 25395
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25395
preprocessed result of traceroute.c

This seems to be a regression from gcc 4.5.x
Will try to make a git bisect in next few days

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-02 13:00:42 UTC ---
The preprocessed test case SEGVs for me with gcc-4.6-20110930, but works with
4.7-20111001, 4.5-20110929, and 4.4-20110927.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-02 18:55:45 UTC ---
The failure started with r164552:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00849.html

It's enough to pass -O2 -mtune=athlon to trigger the bug, you don't need
-march.

I don't see anything x86-specific in that revision so quite possibly it's just
triggering a latent x86 backend error.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-10-02 20:35:59 UTC ---
This could be a bug in FD_SET/FD_ZERO.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-02 20:45:07 UTC ---
So which libc was this originally compiled against?  Some things in
traceroute.i make me think it's glibc, but I don't see any indication of which
version it was.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[newsgrp at duradsl dot dyndns.org]

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

--- Comment #7 from newsgrp at duradsl dot dyndns.org 2011-10-02 22:00:15 UTC ---
Created attachment 25399
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25399
glibc-2.14 patches

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[newsgrp at duradsl dot dyndns.org]

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

--- Comment #8 from newsgrp at duradsl dot dyndns.org 2011-10-02 22:01:23 UTC ---
(In reply to comment #6)
> So which libc was this originally compiled against?  Some things in
> traceroute.i make me think it's glibc, but I don't see any indication of which
> version it was.

The glibc version is 2.14 and is compiled with the attached patches.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[newsgrp at duradsl dot dyndns.org]

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

--- Comment #9 from newsgrp at duradsl dot dyndns.org 2011-10-02 22:39:42 UTC ---
(In reply to comment #4)
> The failure started with r164552:
> http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00849.html
> 
> It's enough to pass -O2 -mtune=athlon to trigger the bug, you don't need
> -march.
> 
> I don't see anything x86-specific in that revision so quite possibly it's just
> triggering a latent x86 backend error.

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00849.html is the first bad commit
here too.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #10 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-03 08:35:31 UTC ---
(In reply to comment #8)
> (In reply to comment #6)
> > So which libc was this originally compiled against?  Some things in
> > traceroute.i make me think it's glibc, but I don't see any indication of which
> > version it was.
> 
> The glibc version is 2.14 and is compiled with the attached patches.

Using the non-preprocessed traceroute.c I can reproduce the segfault with
gcc-4.6.1 and glibc-2.13 (Fedora 14) but not with glibc-2.12.2 (Fedora 13).

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #11 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-03 11:46:28 UTC ---
The failure seems to have disappeared on trunk starting with r179284:
http://gcc.gnu.org/ml/gcc-cvs/2011-09/msg00903.html

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #12 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-03 12:56:10 UTC ---
Backporting r179284 to 4.6.1 (trivial except for the third ifcvt.c hunk which
required manual application due to a context diff) fixed the test case there
too.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #13 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-03 19:27:21 UTC ---
Created attachment 25404
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25404
reduced preprocessed test case

With this reduced test case I'm seeing gcc-4.6 ifcvt hoisting trapping insns
that depend on a NULL pointer check before that pointer check when
-mtune=athlon is in effect.

> cat pr50588.c
unsigned int __attribute__((noinline,noclone)) do_try(int *fd)
{
    unsigned int bits[32];

    bits[0] = 0;
    asm("" : "=m"(bits) : "r"(bits) : "memory");

    bits[(fd ? *fd : -1) / 32U] |= 1U << ((fd ? *fd : -1) % 32U);

    return bits[0];
}

int main(void)
{
    int fd = 3;
    if (do_try(&fd) != (1U << 3))
        __builtin_abort();
    return 0;
}
> /tmp/objdir46/gcc/xgcc -B/tmp/objdir46/gcc/ -O2 -S pr50588.c ; cat pr50588.s
        .file   "pr50588.c"
        .text
        .p2align 4,,15
        .globl  do_try
        .type   do_try, @function
do_try:
.LFB0:
        .cfi_startproc
        pushl   %ebx
        .cfi_def_cfa_offset 8
        .cfi_offset 3, -8
        addl    $-128, %esp
        .cfi_def_cfa_offset 136
        movl    136(%esp), %eax
        movl    $0, (%esp)
        testl   %eax, %eax
        je      .L2

## This is OK, we're testing fd (eax) before doing anything that depends on its
value.

        movl    (%eax), %ecx
        movl    $1, %eax
        movl    %ecx, %edx
        shrl    $5, %edx
        movl    (%esp,%edx,4), %ebx
        sall    %cl, %eax
        orl     %ebx, %eax
        movl    %eax, (%esp,%edx,4)
        movl    (%esp), %eax
        subl    $-128, %esp
        .cfi_remember_state
        .cfi_def_cfa_offset 8
        popl    %ebx
        .cfi_def_cfa_offset 4
        .cfi_restore 3
        ret
        .p2align 4,,7
        .p2align 3
.L2:
        .cfi_restore_state
        movl    536870908(%esp), %ebx

### This would obviously fail at runtime, but as fd != NULL it won't be
executed.

        movl    $-2147483648, %eax
        movl    $134217727, %edx
        orl     %ebx, %eax
        movl    %eax, (%esp,%edx,4)
        movl    (%esp), %eax
...
> /tmp/objdir46/gcc/xgcc -B/tmp/objdir46/gcc/ -mtune=athlon -O2 -S pr50588.c ; cat pr50588.s
        .file   "pr50588.c"
        .text
        .p2align 4,,15
        .globl  do_try
        .type   do_try, @function
do_try:
.LFB0:
        .cfi_startproc
        pushl   %ebx
        .cfi_def_cfa_offset 8
        .cfi_offset 3, -8
        movl    $134217727, %edx
        movl    $-2147483648, %eax
        addl    $-128, %esp
        .cfi_def_cfa_offset 136
        movl    136(%esp), %ecx
        movl    $0, (%esp)
        movl    536870908(%esp), %ebx

## This is broken.  Trapping insns from the fd == NULL case have been hoisted
above the fd == NULL check.  The movl above does segfault at runtime.

        testl   %ecx, %ecx
        je      .L3
        movl    (%ecx), %ecx
        movl    $1, %eax
        movl    %ecx, %edx
        sall    %cl, %eax
        shrl    $5, %edx
        movl    (%esp,%edx,4), %ebx
.L3:
        orl     %ebx, %eax
        movl    %eax, (%esp,%edx,4)
        movl    (%esp), %eax
        subl    $-128, %esp
        .cfi_def_cfa_offset 8
        popl    %ebx
        .cfi_def_cfa_offset 4
        .cfi_restore 3
        ret
        .cfi_endproc

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[bernds at gcc dot gnu.org]

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

--- Comment #14 from Bernd Schmidt <bernds at gcc dot gnu.org> 2011-10-06 13:30:31 UTC ---
It looks like ifcvt (or rather, can_move_insns_across_p) is doing the right
thing. The problem is that may_trap_or_fault_p returns false for the memory
reference with an out-of-range address based on the frame pointer.

I'll keep thinking about it; no good idea yet about how to fix it without
losing too many optimization opportunities.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[mikpe at it dot uu.se]

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

--- Comment #15 from Mikael Pettersson <mikpe at it dot uu.se> 2011-12-18 13:54:42 UTC ---
The problem appears to occur in rtx_addr_can_trap_p_1, case REG.  It returns
false for any address formed by the frame or stack pointer plus an offset,
regardless of the value of the offset.  In the test case it allows offsets in
the half GB range, which is bogus.  If I force it to return true for offsets
larger than, say, +/- 4KB, then the test case is unbroken.

Could rtx_addr_can_trap_p_1 find out what the ranges of safe offsets from the
stack and frame pointers are?

[Bug rtl-optimization/50588] gcc produce bad inlined code with -march=athlon -O2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-31
          Component|target                      |rtl-optimization
     Ever Confirmed|0                           |1

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-12-31 22:50:09 UTC ---
.

[Bug rtl-optimization/50588] gcc produce incorrect inlined code with -march=athlon -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
            Summary|gcc produce bad inlined     |gcc produce incorrect
                   |code with -march=athlon -O2 |inlined code with
                   |                            |-march=athlon -O2

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-01 09:24:56 UTC ---
Let's avoid bad, it's ambiguous, and use incorrect/wrong or inefficient/poor.

[Bug rtl-optimization/50588] gcc produce incorrect inlined code with -march=athlon -O2

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588

--- Comment #18 from Mikael Pettersson <mikpelinux at gmail dot com> ---
This is now fixed for 4.8+ by Eric's PR60452 patch.  Verified by backporting
that to 4.6.4 and seeing the bug on this PR's test case go away.