[Bug middle-end/58387] New: wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[Bug middle-end/58387] New: wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

            Bug ID: 58387
           Summary: wrong code at -Os and above on x86_64-linux-gnu (both
                    32-bit and 64-bit modes)
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The current gcc trunk produces wrong code for the attached testcase on
x86_64-linux-gnu when compiled at -Os and above in both 32-bit and 64-bit
modes. 

It is a regression from 4.8.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
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130910 (experimental) [trunk revision 202421] (GCC) 
$ gcc-trunk -O1 small.c
$ a.out
$ gcc-4.8 -O2 small.c
$ a.out
$ gcc-trunk -Os small.c
$ a.out
0
$ 


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

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

int a = -1; 

int main ()
{
  int b = a == 0 ? 0 : -a;
  if (b < 1)
    printf ("%d\n", 0);
  return 0;
}

[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't reproduce this, neither with 64-bit nor 32-bit.

[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce this, neither with 64-bit nor 32-bit.

Jakub, perhaps fixed in later revisions?  I tested it using 202421.

[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Not even with r202421.
Content of main with that revision for x86_64 -Os is:
    .cfi_startproc
    pushq    %rcx
    .cfi_def_cfa_offset 16
    movl    a(%rip), %esi
    testl    %esi, %esi
    je    .L4
    negl    %esi
    testl    %esi, %esi
    jg    .L3
    jmp    .L2
.L4:
    xorl    %esi, %esi
.L2:
    movl    $.LC0, %edi
    xorl    %eax, %eax
    call    printf
.L3:
    xorl    %eax, %eax
    popq    %rdx
    .cfi_def_cfa_offset 8
    ret

[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #4 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jakub Jelinek from comment #3)
> Not even with r202421.
> Content of main with that revision for x86_64 -Os is:
> 	.cfi_startproc
> 	pushq	%rcx
> 	.cfi_def_cfa_offset 16
> 	movl	a(%rip), %esi
> 	testl	%esi, %esi
> 	je	.L4
> 	negl	%esi
> 	testl	%esi, %esi
> 	jg	.L3
> 	jmp	.L2
> .L4:
> 	xorl	%esi, %esi
> .L2:
> 	movl	$.LC0, %edi
> 	xorl	%eax, %eax
> 	call	printf
> .L3:
> 	xorl	%eax, %eax
> 	popq	%rdx
> 	.cfi_def_cfa_offset 8
> 	ret


Here is what I have for x86_64 -Os: 

    .cfi_startproc
    pushq    %rax
    .cfi_def_cfa_offset 16
    xorl    %esi, %esi
    movl    $.LC0, %edi
    xorl    %eax, %eax
    call    printf
    xorl    %eax, %eax
    popq    %rdx
    .cfi_def_cfa_offset 8
    ret
    .cfi_endproc


Below is what I have for x86_64 -O1: 

    .cfi_startproc
    subq    $8, %rsp
    .cfi_def_cfa_offset 16
    movl    a(%rip), %eax
    testl    %eax, %eax
    je    .L2
    negl    %eax
    testl    %eax, %eax
    jg    .L3
.L2:
    movl    $0, %esi
    movl    $.LC0, %edi
    movl    $0, %eax
    call    printf
.L3:
    movl    $0, %eax
    addq    $8, %rsp
    .cfi_def_cfa_offset 8
    ret
    .cfi_endproc
>From gcc-bugs-return-429540-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 11 07:54:38 2013
Return-Path: <gcc-bugs-return-429540-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8035 invoked by alias); 11 Sep 2013 07:54:38 -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 7986 invoked by uid 48); 11 Sep 2013 07:54:34 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
Date: Wed, 11 Sep 2013 07:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
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:
Message-ID: <bug-58387-4-HsMOY1WR5P@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58387-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58387-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: 2013-09/txt/msg00780.txt.bz2
Content-length: 282

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Cannot reproduce either.

Maybe you got hit by Jeffs bus introducing random bits into your bootstrap?

So I wonder if it reproduces for you if you rebuild GCC ;)

[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #6 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Richard Biener from comment #5)
> Cannot reproduce either.
> 
> Maybe you got hit by Jeffs bus introducing random bits into your bootstrap?
> 
> So I wonder if it reproduces for you if you rebuild GCC ;)

Hi guys, I rebuilt GCC, but it still reproduces for me (see below).  

Did you configure with --enable-checking=release? 


$ 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
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130911 (experimental) [trunk revision 202489] (GCC) 
$ gcc-trunk -Os small.c
$ a.out
0
$ gcc-trunk -O1 small.c
$ a.out
$

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-11
   Target Milestone|---                         |4.9.0
            Summary|wrong code at -Os and above |[4.9 Regression] wrong code
                   |on x86_64-linux-gnu (both   |at -Os and above on
                   |32-bit and 64-bit modes)    |x86_64-linux-gnu (both
                   |                            |32-bit and 64-bit modes)
     Ever confirmed|0                           |1

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
stage2 and stage3 are miscompiled.  stage1 is OK.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
This is caused by r202345.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
           Assignee|unassigned at gcc dot gnu.org      |law at redhat dot com

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
Thanks.  Investigating.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
Looks like make_range_step is getting miscompiled.  Still trying to figure out
how/why.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
I know what's happening here.  It's obscure and quite nasty.

We have a jump threading opportunity which requires threading through a joiner
block.  The jump thread leaving one edge of the joiner eventually reaches the
same block as the joiner's other outgoing edge.

This is all fine and good as the threading code knows the conditions under
which it's still safe to thread that jump.  Specifically it has to look at the
PHI arguments for the two key edges and verify for each PHI that the values
associated with the two key edges are the same.  This condition is in place to
make the SSA graph updates easier to deal with.

At the time we discover and register the jump thread the condition holds and
we're good to go.  However a short time later we discover that we can propagate
a constant to one of those PHI arguments and do so.  Now the condition we
needed for updating the SSA graph was broken.  We update the SSA graph
incorrectly.

I'm going to have to review the SSA graph updating code a bit tomorrow AM.  In
the mean time I'm going to revert the patch.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #12 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jeffrey A. Law from comment #11)
> I know what's happening here.  It's obscure and quite nasty.
> 
> We have a jump threading opportunity which requires threading through a
> joiner block.  The jump thread leaving one edge of the joiner eventually
> reaches the same block as the joiner's other outgoing edge.
> 
> This is all fine and good as the threading code knows the conditions under
> which it's still safe to thread that jump.  Specifically it has to look at
> the PHI arguments for the two key edges and verify for each PHI that the
> values associated with the two key edges are the same.  This condition is in
> place to make the SSA graph updates easier to deal with.
> 
> At the time we discover and register the jump thread the condition holds and
> we're good to go.  However a short time later we discover that we can
> propagate a constant to one of those PHI arguments and do so.  Now the
> condition we needed for updating the SSA graph was broken.  We update the
> SSA graph incorrectly.
> 
> I'm going to have to review the SSA graph updating code a bit tomorrow AM. 
> In the mean time I'm going to revert the patch.

Jeff, I have another related testcase that only fails for the 32-bit mode (also
at -Os and above). It is a lot more complex, and the root cause is likely the
same as this one. In case it may be of some use to you (at least for testing
your fix), I'm including it below. The body of the conditional, which is not
executed, has an UB (accessing an initialized value: m[0]), which may explain
the difference in -m32 and -m64. 

Also btw everyone, does this mean that the whole testcase has UB (thus invalid)
even if the body of the if isn't executed at runtime at all?  I'm a bit unclear
on this, so any clarifications would be much appreciated.  


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


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

int a = -1, b = 1, f, **e;
static int c;
int *volatile d;

static void
foo (int p)
{
  int g, h, *i, *j = 0, k = g = a == 0 ? 0 : -a;
  if (p >= g)
    {
      int l, n = 0, s = 0, m[7], o[42];
      int ***p = 0, ****q = &p, *r = &l, *v = &h; 
      int **t[3] = { &i, &r, &j };
      int *u[3] = { &n, &k, &s };
      e = &v;
      i = &o[0];
      d && *q;
      f = m[0]; 
      b = 0;
    }
}

int main ()
{
  int x = 0, *y[1] = {&x};
  foo (c);
  printf ("%d\n", b);
  return 0;
}

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus at trippelsdorf dot de

--- Comment #13 from Markus Trippelsdorf <markus at trippelsdorf dot de> ---
*** Bug 58367 has been marked as a duplicate of this bug. ***

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law <law at redhat dot com> ---
It's the action of executing the code with undefined behaviour which is the
trigger.  ie, if you don't execute the code, then it has no effect on the
defined/undefined state of the program as a whole.

It's interesting that you mention undefined behaviour -- the primary motivation
behind the patch that's causing this problem is to better expose to the
analysis and optimization phases of GCC that certain paths, if executed, result
in undefined behaviour.

In particular, propagating NULL pointers into PHI nodes in non-dominated
successors exposes more opportunities to identify paths which, if executed,
would dereference a NULL pointer.  We want to then isolate those paths which
exhibit undefined behaviour from the rest of the code.  That allows the "real"
code paths to be better optimized and the undefined behaviour paths to be
pulled out of the main instruction stream.

The same can be done for out-of-bounds array accesses or uninitialized
variables.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #15 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jeffrey A. Law from comment #14)
> It's the action of executing the code with undefined behaviour which is the
> trigger.  ie, if you don't execute the code, then it has no effect on the
> defined/undefined state of the program as a whole.
> 

Thanks Jeff; that's what I thought. 

I noticed a stackoverflow discussion on this very topic: 

http://stackoverflow.com/questions/7961067/how-undefined-is-undefined-behavior 

Perhaps you folks could help inject some clarity to that discussion. 

> It's interesting that you mention undefined behaviour -- the primary
> motivation behind the patch that's causing this problem is to better expose
> to the analysis and optimization phases of GCC that certain paths, if
> executed, result in undefined behaviour.
> 

I see. But would it be better to inform the programmers instead? 

Please see this recent interesting work to appear at the upcoming SOSP
conference: 

http://css.csail.mit.edu/stack/

"Optimization-unstable code (unstable code for short) is an emerging class of
software bugs: code that is unexpectedly eliminated by compiler optimizations
due to undefined behavior in the program. Unstable code is present in many
systems, including the Linux kernel and the Postgres database server. The
consequences of unstable code range from incorrect functionality to missing
security checks.

STACK is a static checker that detects unstable code in C/C++ programs.
Applying STACK to widely used systems has uncovered 150+ new bugs that have
been confirmed and fixed by developers."

> In particular, propagating NULL pointers into PHI nodes in non-dominated
> successors exposes more opportunities to identify paths which, if executed,
> would dereference a NULL pointer.  We want to then isolate those paths which
> exhibit undefined behaviour from the rest of the code.  That allows the
> "real" code paths to be better optimized and the undefined behaviour paths
> to be pulled out of the main instruction stream.
> 
> The same can be done for out-of-bounds array accesses or uninitialized
> variables.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #16 from Jeffrey A. Law <law at redhat dot com> ---
The optimization came out of building additional warnings for GCC.  It's safe
to assume that there'll be an option to enable a warning that the compiler was
able to identify and isolate a path with undefined behaviour.

Sadly these paths are not uncommon and it is often exceedingly difficult to
prove if the path is truly unexecutable or not.  The net result is there's
going to be a fair amount of noise from this warning when tested on real world
code.

To give you a sense of scale, there's thousands of these paths in GCC itself. 
I analyzed many of them.  To date I haven't found a single one that was
actually executable at run time -- but to prove the paths are unexecutable we
have to have analysis that can span multiple compilation units and a much more
powerful mechanism to replace the jump threading code.

However, each of these instances certainly represents an opportunity to do some
real in depth analysis and potentially improve GCC's analysis/optimization
and/or restructure the source in such ways as to avoid the problematic paths. 
In both instances the resulting compiler is marginally faster.

And, yes, if you look at something like Coverity, these are precisely the kinds
of things it's warning about as well.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[joseph at codesourcery dot com]

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

--- Comment #17 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 13 Sep 2013, su at cs dot ucdavis.edu wrote:

> I noticed a stackoverflow discussion on this very topic: 
> 
> http://stackoverflow.com/questions/7961067/how-undefined-is-undefined-behavior 

That doesn't really seem to get into the distinction that in some cases 
where the C standard says something is undefined, what it says is 
undefined is a property of an execution of a program, while in some cases 
it's a property of the program itself.  In the case discussed there, the 
undefinedness is a property of an execution of the program, but in some 
cases (e.g. where one translation unit contains the declaration "extern 
int i;" and another contains "extern char i;") it's a property of the 
program.  You need to read the C standard carefully in each case to work 
out which it is.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #18 from Jeffrey A. Law <law at redhat dot com> ---
I'll also note that the plan for the isolated paths that exhibit undefined
behaviour is to have them trap/abort at the statement which triggers the
undefined behaviour.

The original patch from 2011 actually eliminated the undefined behaviour path
entirely, that's incorrect in that earlier code in the path might have
observable side effects (such as a printf call).  It would also make more
problems with "optimization unstable code".

By unconditionally trapping/aborting at the statement which triggered the
undefined behaviour (say a null pointer dereference), we still get any prior
observable side effects on the path and we halt the program at the point of
undefined behaviour, thus avoiding the multitude of problems around
"optimization unstable code".

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[glisse at gcc dot gnu.org]

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

--- Comment #19 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #18)
> I'll also note that the plan for the isolated paths that exhibit undefined
> behaviour is to have them trap/abort at the statement which triggers the
> undefined behaviour.

Not even a -fif-it-is-undefined-I-deserve-what-I-get option (or
-fmy-program-will-not-abort which turns __builtin_abort into
__builtin_unreachable)? I understand that if I try to debug a program by adding
printf to check that this branch is not taken and it is taken but nothing is
printed, I'll be confused. But don't we lose a large part of the benefit by
only propagating the detection of undefined behavior forward (abort) and not
also backward (unreachable)?

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #20 from Jeffrey A. Law <law at redhat dot com> ---
I think an option to eliminate the path entire like the first iteration of the
change did could be easily added later.  In fact it would be fairly easy to
add.

Basically we'd arrange to mark the isolated path with a flag on the block.  We
then have a pass which looks for those flags and eliminates the edge upon which
those blocks are control dependent.  That's really it.  That'll eliminate the
condition and expose the path as unreachable.

Are we leaving most of the benefit on the table without that option, maybe,
maybe not.  I was pleasantly surprised to see that just the isolation aspect of
this work does simplify things enough to allow the main path to optimize
better.

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[glisse at gcc dot gnu.org]

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

--- Comment #21 from Marc Glisse <glisse at gcc dot gnu.org> ---
Thanks Jeff, sounds great :-)

Even if we mark that a statement is not reachable, we probably won't eliminate
many functions with side-effects executed before, since (I guess) we must be
able to prove that they always return normally (no longjmp or throwing an
exception or going into an infinite loop or anything fancy that would avoid
coming back to execute the undefined-behavior statement), and I don't know if
we can prove that for more than a few builtins and inline functions (maybe more
with LTO).

PS: I secretly hope that one of your jump-threading improvements will magically
help with PR 55860 ;-)

[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

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

--- Comment #22 from Jeffrey A. Law <law at redhat dot com> ---
Fixed on trunk.