[Bug tree-optimization/60116] New: wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[Bug tree-optimization/60116] New: wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[su at cs dot ucdavis.edu]

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

            Bug ID: 60116
           Summary: wrong code at -Os on x86_64-linux-gnu in 32-bit mode
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The current gcc trunk and 4.8.x mis-compile the following code on x86_64-linux
at -Os in 32-bit mode (but not 64-bit).

This is a regression from 4.7.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140207 (experimental) [trunk revision 207610] (GCC) 
$ 
$ gcc-trunk -m32 -O1 small.c; a.out
1
$ gcc-trunk -m64 -Os small.c; a.out
1
$ gcc-4.7.3 -m32 -Os small.c; a.out
1
$ 
$ gcc-trunk -m32 -Os small.c; a.out
0
$ gcc-4.8.2 -m32 -Os small.c; a.out
0
$ 


-------------------------------------


int printf (const char *, ...);

int a, b, c, d = 1, e, f = 1, h, i, k;
char g, j;

int
fn1 ()
{
  int l;
  e = 0;
  c = 0;
  for (;;)
    {
      k = a && b;
      j = k * 54;
      g = j * 147;
      l = ~g + (long long) e && 1;
      if (d)
    c = l;
      else
    h = i = l * 9UL;
      if (f)
    return 0;
    }
}

int
main ()
{
  fn1 ();
  printf ("%d\n", c);
  return 0;
}

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org
          Component|rtl-optimization            |target

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Yeah, it's target.  Started with r184891.

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 32086
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32086&action=edit
assembly dump from trunk revision 207643

I'm not able to trigger this problem with trunk revision 207643:

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -Os -m32 pr60116.c;
./a.out
1
>From gcc-bugs-return-443135-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 09 18:06:50 2014
Return-Path: <gcc-bugs-return-443135-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6842 invoked by alias); 9 Feb 2014 18:06:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6780 invoked by uid 48); 9 Feb 2014 18:06:46 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60122] Unexpected warning for uninitialised character variable
Date: Sun, 09 Feb 2014 18:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
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_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-60122-4-WUSk9VhYMH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60122-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60122-4@http.gcc.gnu.org/bugzilla/>
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: 2014-02/txt/msg00892.txt.bz2
Content-length: 522

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`122

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-02-09
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed for 4.7, 4.8, and trunk (4.9).

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, I haven't been able to reproduce it with any cc1 at -Os -m32 I've tried
(including r184900, current trunk etc., even with different -march= options.

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 32088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32088&action=edit
asm that prints 0

Strange, I can reproduce it easily with r207643 on Debian testing:

stedding /tmp $ /tmp/gcc-mult/inst/bin/gcc -Os -m32 u.c && ./a.out
0
stedding /tmp $ /tmp/gcc-mult/inst/bin/gcc -O3 -m32 u.c && ./a.out
1

Target: x86_64-unknown-linux-gnu
Configured with: /data/repos/gcc/trunk/configure --prefix=/tmp/gcc-mult/inst
--enable-languages=c,c++ --with-system-zlib --disable-nls
--enable-libstdcxx-time=yes --disable-bootstrap

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I can reproduce 0 even with the assembly by Uros:
$ ./xgcc -B./ -m32 -xassembler Uok.s; ./a.out 
0

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Marc Glisse from comment #5)
> Created attachment 32088 [details]
> asm that prints 0

Well,

$ gcc -m32 u.s && ./a.out
1

as --version
GNU assembler version 2.23.2
Copyright 2012 Free Software Foundation, Inc.

This is F20, with:

binutils.x86_64 2.23.88.0.1-13.fc20 installed
>From gcc-bugs-return-443146-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 09 21:27:54 2014
Return-Path: <gcc-bugs-return-443146-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3615 invoked by alias); 9 Feb 2014 21:27:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3084 invoked by uid 48); 9 Feb 2014 21:27:48 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
Date: Sun, 09 Feb 2014 21:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60116-4-BCxeos2xcT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60116-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60116-4@http.gcc.gnu.org/bugzilla/>
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: 2014-02/txt/msg00903.txt.bz2
Content-length: 416

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`116

--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
Er, right, my attachment is useless, it is the same as Uros' (but I can't see
how to remove it). If it matters:

GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.24
GNU C Library (Debian EGLIBC 2.17-97) stable release version 2.17, by Roland
McGrath et al.

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> ---
Extract from a gdb session, showing 2 wrong branches taken:

(gdb) p f
$15 = 1
(gdb) step
15          j = k * 54;
(gdb) 
16          g = j * 147;
(gdb) 
18          if (d)
(gdb) p d
$16 = 1
(gdb) step
21        h = i = l * 9UL;
(gdb) 
22          if (f)
(gdb) p f
$17 = 1
(gdb) step
25    }

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32088|0                           |1
        is obsolete|                            |

--- Comment #10 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 32089
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32089&action=edit
.o that prints 0

objdump -d doesn't seem suspicious.

[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
OK, confirmed using "-Os -m32" with

gcc version 4.9.0 20140207 (experimental) [trunk revision 207597] (GCC) 

on CentOS 5.10.

It looks like a fault in the combine pass.

Before combine, we have:

...
(insn 14 11 15 2 (set (reg:SI 101 [ D.1782 ])
        (mem/c:SI (symbol_ref:SI ("d") [flags 0x2]  <var_decl 0x2b47ff9e1ed8d>)
[2 d+0 S4 A32])) t.c:18 90 {*movsi_internal}
     (nil))
...

(insn 33 32 34 5 (set (reg:SI 113 [ D.1782 ])
        (sign_extend:SI (reg:QI 91 [ D.1785 ]))) t.c:17 148 {extendqisi2}
     (nil))
(insn 34 33 35 5 (set (reg:SI 114 [ D.1782 ])
        (not:SI (reg:SI 113 [ D.1782 ]))) t.c:17 510 {*one_cmplsi2_1}
     (expr_list:REG_DEAD (reg:SI 113 [ D.1782 ])
        (nil)))
(insn 35 34 37 5 (parallel [
            (set (reg:DI 115 [ D.1786 ])
                (sign_extend:DI (reg:SI 114 [ D.1782 ])))
            (clobber (reg:CC 17 flags))
            (clobber (scratch:SI))
        ]) t.c:17 143 {extendsidi2_1}
     (expr_list:REG_DEAD (reg:SI 114 [ D.1782 ])
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))
(insn 37 35 38 5 (parallel [
            (set (reg:SI 117)
                (ior:SI (subreg:SI (reg:DI 115 [ D.1786 ]) 0)
                    (subreg:SI (reg:DI 115 [ D.1786 ]) 4)))
            (clobber (reg:CC 17 flags))
        ]) t.c:17 420 {*iorsi_1}
     (expr_list:REG_DEAD (reg:DI 115 [ D.1786 ])
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))
(insn 38 37 39 5 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:SI 117)
            (const_int 0 [0]))) t.c:17 3 {*cmpsi_ccno_1}
     (expr_list:REG_DEAD (reg:SI 117)
        (nil)))
(insn 39 38 41 5 (set (reg:QI 119)
        (ne:QI (reg:CCZ 17 flags)
            (const_int 0 [0]))) t.c:17 624 {*setcc_qi}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (nil)))
(insn 41 39 83 5 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:SI 101 [ D.1782 ])
            (const_int 0 [0]))) t.c:18 3 {*cmpsi_ccno_1}
     (nil))
(insn 83 41 42 5 (set (reg:SI 122 [ D.1787 ])
        (zero_extend:SI (reg:QI 119))) 138 {*zero_extendqisi2}
     (expr_list:REG_DEAD (reg:QI 119)
        (nil)))
(jump_insn 42 83 43 5 (set (pc)
        (if_then_else (eq (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref 47)
            (pc))) t.c:18 628 {*jcc_1}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (int_list:REG_BR_PROB 5000 (nil)))
 -> 47)

Please note (insn 41) that sets flags for (jump_insn 42), comparing (reg:SI
101) a.k.a "d" with zero.

Later, combine mass-deletes everything from (insn 33) to (insn 83) to
substitute (insn 83) with constant load:

...
(insn 14 11 15 2 (set (reg:SI 101 [ D.1782 ])
        (mem/c:SI (symbol_ref:SI ("d") [flags 0x2]  <var_decl 0x2b47ff9e1ed8d>)
[2 d+0 S4 A32])) t.c:18 90 {*movsi_internal}
     (nil))
...
(note 33 32 34 5 NOTE_INSN_DELETED)
(note 34 33 35 5 NOTE_INSN_DELETED)
(note 35 34 37 5 NOTE_INSN_DELETED)
(note 37 35 39 5 NOTE_INSN_DELETED)
(note 39 37 41 5 NOTE_INSN_DELETED)
(note 41 39 83 5 NOTE_INSN_DELETED)
(insn 83 41 42 5 (set (reg:SI 122 [ D.1787 ])
        (const_int 1 [0x1])) 90 {*movsi_internal}
     (nil))
(jump_insn 42 83 43 5 (set (pc)
        (if_then_else (eq (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref 47)
            (pc))) t.c:18 628 {*jcc_1}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (int_list:REG_BR_PROB 5000 (nil)))
 -> 47)

Unfortunately unrelated (insn 41) is also killed, so flags are taken from
unrelated operation (that happens to be insn 32, just above insn 33).

Things go downhill from there.
>From gcc-bugs-return-443175-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 10 09:21:32 2014
Return-Path: <gcc-bugs-return-443175-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25386 invoked by alias); 10 Feb 2014 09:21:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25326 invoked by uid 48); 10 Feb 2014 09:21:29 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
Date: Mon, 10 Feb 2014 09:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: component
Message-ID: <bug-60116-4-IZpfqheIyD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60116-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60116-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00932.txt.bz2
Content-length: 417

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
Re-confirmed as rtl-optimization problem.
>From gcc-bugs-return-443176-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 10 09:29:17 2014
Return-Path: <gcc-bugs-return-443176-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28973 invoked by alias); 10 Feb 2014 09:29:17 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28941 invoked by uid 48); 10 Feb 2014 09:29:12 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
Date: Mon, 10 Feb 2014 09:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords: build, ice-on-valid-code
X-Bugzilla-Severity: critical
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-49847-4-opiIPX8ysL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-49847-4@http.gcc.gnu.org/bugzilla/>
References: <bug-49847-4@http.gcc.gnu.org/bugzilla/>
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: 2014-02/txt/msg00933.txt.bz2
Content-length: 2278

http://gcc.gnu.org/bugzilla/show_bug.cgi?idI847

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #24)
> This is a mess.
>
> As noted in the other comments, we're considering a cc0-setter as a
> potentially trapping insn.  As a result the cc0-setter and cc0-consumer end
> up in different blocks.
>
> That's bad on so many levels and "fixing" it by hacking up fold_rtx like
> this just papers over the fundamental problem (though I must admit from a
> pragmatic standpoint, it's pretty effective).
>
> One could argue that the CFG building code could be tweaked so that a
> cc0-setter is never considered the end of a block.  The downside of that is
> we're lying to the compiler about the true nature of the CFG.  But that
> little white lie may be acceptable.  I haven't looked into how ugly that
> would be to implement.

Well, it re-exposes the original problem of not properly handling EH
with -fnon-call-exception and trapping FP comparisons?  I don't recall
all the issues with the original case I installed the change (at least
we do consider GIMPLE_CONDs as possibly trapping, just we don't allow
a possibly throwing condition in a GIMPLE_COND).

One fix for backends where cc0 setter and consumer
may not be separated is to duplicate the comparison like

 <bb>
   ...
   g >= 0.0;     // stmt ending BB with EH edges

 <bb>
   if (g >= 0.0) // redundant compare, but with NOTHROW set
     ...

Or to revert the original change and think of a better fix.

But certainly you can't rely on the IL being

  if (g >= 0.0)

instead of (what gimplification forces now)

  bool tem = g >= 0.0;

  <bb>
    if (tem != 0)

because with -fnon-call-exceptions writing that literally in C++ and
compiling with -O0 will yield exactly the same issue as you hit it
now (separated cc0 setter / consumer).

So reverting wouldn't be a "real" fix.  Testcase:

int foo (double x)
{
  try {
      bool cond = x >= 0.0;
      if (cond)
        return 1;
      return 0;
  }
  catch (...)
    {
      return -1;
    }
}

Where we shouldn't ICE when reverting the original fix and which at -O0
produces exactly the same "issue" you face now.

Best it into a runtime testcase that properly catches a trapping compare.

Richard.

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P2

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |law at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, what happens is that we have:
(insn 39 38 41 5 (set (reg:QI 119)
        (const_int 1 [0x1])) pr60116.c:17 93 {*movqi_internal}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (nil)))

(insn 41 39 83 5 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:SI 101 [ D.1460 ])
            (const_int 0 [0]))) pr60116.c:18 3 {*cmpsi_ccno_1}
     (nil))

(insn 83 41 42 5 (set (reg:SI 122 [ D.1465 ])
        (zero_extend:SI (reg:QI 119))) 138 {*zero_extendqisi2}
     (expr_list:REG_DEAD (reg:QI 119)
        (nil)))

(the REG_DEAD on flags on the first insn supposedly comes from earlier
combining.
try_combine is then called on i3=insn83 and i2=insn39 and manages to combine
insn 83 into (set (reg:SI 122) (const_int 1 [0x1])).
The problem is when distribute_notes attempts to distribute the REG_DEAD
(reg:CCZ 17 flags) note from elim_i2=insn39 to i3=insn83.

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And the place where we first change insn 39 is when simplifying the comparison
that feeds it, in simplify_set:
  /* If we are setting CC0 or if the source is a COMPARE, look for the use of
     the comparison result and try to simplify it unless we already have used
     undobuf.other_insn.  */
...
6292          rtx pat = PATTERN (other_insn);
6293          undobuf.other_insn = other_insn;
6294          SUBST (*cc_use, tmp);

So, is it a bug that we've kept REG_DEAD flags there in this case, or just
distribute_notes shouldn't perform:
                  /* If the register is being set at TEM, see if that is all
                     TEM is doing.  If so, delete TEM.  Otherwise, make this
                     into a REG_UNUSED note instead. Don't delete sets to
                     global register vars.  */
                  if ((REGNO (XEXP (note, 0)) >= FIRST_PSEUDO_REGISTER
                       || !global_regs[REGNO (XEXP (note, 0))])
                      && reg_set_p (XEXP (note, 0), PATTERN (tem)))
...
                          SET_INSN_DELETED (tem);
Dunno how that could ever be safe if from_insn is the former i2 and i3 is a
different insn and tem has bigger luid than from_insn.  This code seems to be
in there even in 3.2.  Anyway, can somebody more familiar with this have a
look?

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Will do.

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Wed Feb 12 08:49:55 2014
New Revision: 207713

URL: http://gcc.gnu.org/viewcvs?rev=207713&root=gcc&view=rev
Log:
    PR rtl-optimization/60116
    * combine.c (try_combine): Also remove dangling REG_DEAD notes on the
    other_insn once the combination has been validated.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/20140212-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/combine.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Wed Feb 12 08:51:57 2014
New Revision: 207714

URL: http://gcc.gnu.org/viewcvs?rev=207714&root=gcc&view=rev
Log:
    PR rtl-optimization/60116
    * combine.c (try_combine): Also remove dangling REG_DEAD notes on the
    other_insn once the combination has been validated.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/20140212-1.c
      - copied unchanged from r207713,
trunk/gcc/testsuite/gcc.c-torture/execute/20140212-1.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/combine.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Thanks for reporting the problem.

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #20 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Wed Feb 12 10:17:08 2014
New Revision: 207717

URL: http://gcc.gnu.org/viewcvs?rev=207717&root=gcc&view=rev
Log:
    PR rtl-optimization/60116
    * combine.c (try_combine): Fix oversight in previous change.

Modified:
    branches/gcc-4_8-branch/gcc/combine.c

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Wed Feb 12 10:16:34 2014
New Revision: 207716

URL: http://gcc.gnu.org/viewcvs?rev=207716&root=gcc&view=rev
Log:
    PR rtl-optimization/60116
    * combine.c (try_combine): Fix oversight in previous change.

Modified:
    trunk/gcc/combine.c