[Bug rtl-optimization/61047] New: wrong code at -O1 on x86_64-linux

[Bug rtl-optimization/61047] New: wrong code at -O1 on x86_64-linux

[su at cs dot ucdavis.edu]

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

            Bug ID: 61047
           Summary: wrong code at -O1 on x86_64-linux
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The current gcc trunk and 4.9.0 mis-compile the following code on x86_64-linux
at -O1 in both 32-bit and 64-bit modes. 

This is a regression from 4.8.x and seems related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452. 

$ 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.10.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.10.0 20140503 (experimental) [trunk revision 210026] (GCC) 
$ 
$ gcc-trunk -O0 small.c; a.out
$ gcc-trunk -Os small.c; a.out
$ gcc-4.8.2 -O1 small.c; a.out
$ 
$ gcc-trunk -O1 small.c
$ a.out
Segmentation fault (core dumped)
$ gcc-4.9.0 -O1 small.c
$ a.out
Segmentation fault (core dumped)
$ 

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

int a, c, d;
short b;

int
main ()
{
  int e[1];
  for (; b < 2; b++)
    {
      a = 0;
      if (b == 2837)
        a = e[b];
      if (!(d || b))
        for (; c;)
          ;
    }
  return 0;
}

[Bug rtl-optimization/61047] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-05-03
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |law at gcc dot gnu.org
   Target Milestone|---                         |4.9.1
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r203895.

[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P2
            Summary|wrong code at -O1 on        |[4.9/4.10 Regression] wrong
                   |x86_64-linux                |code at -O1 on x86_64-linux

[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux

[ebotcazou at gcc dot gnu.org]

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

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

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

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Note how the load at insn 28 is guarded by comparing ax against #2837.  CE3
> transforms that into an unconditional load and we blow up reading the
> out-of-range stack slot.
> 
> This isn't a threading issue, but a latent bug in CE as far as I can tell.

Right, see PR rtl-optimization/60452 for an earlier example.  IMO a pretty
useless series of artificial testcases...

[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I tried a boot-strap with this patch, and there are almost no false positives,
except a few varargs functions.

Most interesting are these cases:

/home/ed/gnu/gcc-build/./prev-gcc/xg++ -B/home/ed/gnu/gcc-build/./prev-gcc/
-B/home/ed/gnu/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/home/ed/gnu/gcc-trunk/libstdc++-v3/libsupc++
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include
-I../../gcc-trunk/gcc/../libcpp/include -I/home/ed/gnu/gcc-build/./gmp
-I/home/ed/gnu/gcc-trunk/gmp -I/home/ed/gnu/gcc-build/./mpfr
-I/home/ed/gnu/gcc-trunk/mpfr -I/home/ed/gnu/gcc-trunk/mpc/src 
-I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/ed/gnu/gcc-build/./cloog/include -I/home/ed/gnu/gcc-trunk/cloog/include
-I../gcc-trunk/cloog/include  -I/home/ed/gnu/gcc-build/./isl/include
-I/home/ed/gnu/gcc-trunk/isl/include  -o expmed.o -MT expmed.o -MMD -MP -MF
./.deps/expmed.TPo ../../gcc-trunk/gcc/expmed.c
*** sp can trap: offset=34359738424, size=8, low_bound=-144, high_bound=272
*** sp can trap: offset=34359738456, size=8, low_bound=-144, high_bound=272
--
/home/ed/gnu/gcc-build/./prev-gcc/xg++ -B/home/ed/gnu/gcc-build/./prev-gcc/
-B/home/ed/gnu/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/home/ed/gnu/gcc-trunk/libstdc++-v3/libsupc++
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include
-I../../gcc-trunk/gcc/../libcpp/include -I/home/ed/gnu/gcc-build/./gmp
-I/home/ed/gnu/gcc-trunk/gmp -I/home/ed/gnu/gcc-build/./mpfr
-I/home/ed/gnu/gcc-trunk/mpfr -I/home/ed/gnu/gcc-trunk/mpc/src 
-I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/ed/gnu/gcc-build/./cloog/include -I/home/ed/gnu/gcc-trunk/cloog/include
-I../gcc-trunk/cloog/include  -I/home/ed/gnu/gcc-build/./isl/include
-I/home/ed/gnu/gcc-trunk/isl/include  -o fixed-value.o -MT fixed-value.o -MMD
-MP -MF ./.deps/fixed-value.TPo ../../gcc-trunk/gcc/fixed-value.c
*** sp can trap: offset=34359738472, size=8, low_bound=-144, high_bound=208
*** sp can trap: offset=34359738488, size=8, low_bound=-144, high_bound=240
/home/ed/gnu/gcc-build/./prev-gcc/xg++ -B/home/ed/gnu/gcc-build/./prev-gcc/
-B/home/ed/gnu/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/home/ed/gnu/gcc-trunk/libstdc++-v3/libsupc++
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/ed/gnu/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include
-I../../gcc-trunk/gcc/../libcpp/include -I/home/ed/gnu/gcc-build/./gmp
-I/home/ed/gnu/gcc-trunk/gmp -I/home/ed/gnu/gcc-build/./mpfr
-I/home/ed/gnu/gcc-trunk/mpfr -I/home/ed/gnu/gcc-trunk/mpc/src 
-I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/ed/gnu/gcc-build/./cloog/include -I/home/ed/gnu/gcc-trunk/cloog/include
-I../gcc-trunk/cloog/include  -I/home/ed/gnu/gcc-build/./isl/include
-I/home/ed/gnu/gcc-trunk/isl/include  -o fold-const.o -MT fold-const.o -MMD -MP
-MF ./.deps/fold-const.TPo ../../gcc-trunk/gcc/fold-const.c
*** hard_fp can trap: offset=34359738280, size=8, low_bound=-368, high_bound=32
--


they were not happening with the 4.9 branch.

[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
they only happen in stage3, not in stage2.

expmed.c.214r.reload:

;; Function long unsigned int choose_multiplier(long unsigned int, int, int,
long unsigned int*, int*, int*) (_Z17choose_multipliermiiPmPiS0_,
funcdef_no=1085, decl_uid=47659, symbol_order=801)

...
  557: r13:DI=0x7ffffff78
      REG_EQUIV 0x7ffffff78
...
  547: debug this => debug_implicit_ptr
  548: debug D#64 => debug_implicit_ptr
  549: debug D#37 => D#64
  550: debug this => D#37
  551: debug len => optimized away
  552: debug D#65 => debug_implicit_ptr
  553: debug D#39 => D#65
  554: debug this => D#39
  555: debug high => [sp:DI+0x800000038]
  556: debug res => 0
  560: NOTE_INSN_DELETED
 1334: NOTE_INSN_DELETED
 1367: ax:DI=[sp:DI+r13:DI+0xc0]

fixed-value.c.214r.reload:

;; Function void fixed_from_string(fixed_value*, const char*, machine_mode)
(_Z17fixed_from_stringP11fixed_valuePKc12machine_mode, funcdef_no=827,
decl_uid=38219, symbol_order=541)

...

   89: NOTE_INSN_BASIC_BLOCK 8
   90: debug this => sp:DI+0x70
   91: debug D#17 => sp:DI+0x70
   92: debug D#2 => D#17
   93: debug this => D#2
   94: debug len => optimized away
   95: debug D#18 => sp:DI+0x70
   96: debug this => D#18
   97: debug high => [sp:DI+0x800000068]
   98: dx:DI=0x7ffffffd8
      REG_EQUIV 0x7ffffffd8
  100: dx:DI=[sp:DI+dx:DI+0x90]
      REG_EQUAL [frame:DI+0x7ffffffd8]


unfortunately, gcc crashes when compiling fold-const.c
when I add -fdump-rtl-all-slim to the command line.

[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
xg++ [...] ../../gcc-trunk/gcc/fold-const.c -fdump-rtl-all-slim
*** fp can trap: offset=34359738280, size=8, low_bound=-368, high_bound=32
../../gcc-trunk/gcc/fold-const.c: In function 'tree_node*
fold_unary_loc(location_t, tree_code, tree, tree)':
../../gcc-trunk/gcc/fold-const.c:8475:1: internal compiler error: Segmentation
fault
 }
 ^
0xbeaf1f crash_signal
    ../../gcc-trunk/gcc/toplev.c:337
0x11a43c0 pp_string(pretty_printer*, char const*)
    ../../gcc-trunk/gcc/pretty-print.c:906
0xba02c2 print_exp
    ../../gcc-trunk/gcc/sched-vis.c:391
0xba0dfd print_value(pretty_printer*, rtx_def const*, int)
    ../../gcc-trunk/gcc/sched-vis.c:510
0xb9fe08 print_pattern(pretty_printer*, rtx_def const*, int)
    ../../gcc-trunk/gcc/sched-vis.c:620
0xb9fb3b print_insn(pretty_printer*, rtx_def const*, int)
    ../../gcc-trunk/gcc/sched-vis.c:743
0xb9fd17 print_insn_with_notes
    ../../gcc-trunk/gcc/sched-vis.c:764
0xba104e dump_insn_slim(_IO_FILE*, rtx_def const*)
    ../../gcc-trunk/gcc/sched-vis.c:801
0x8a09c7 print_rtl_with_bb(_IO_FILE*, rtx_def const*, int)
    ../../gcc-trunk/gcc/cfgrtl.c:2196
0xb32db3 execute_function_dump
    ../../gcc-trunk/gcc/passes.c:1569
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux

[bernd.edlinger at hotmail dot de]

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

--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
> expmed.c.214r.reload:
> 
> ;; Function long unsigned int choose_multiplier(long unsigned int, int, int,
> long unsigned int*, int*, int*) (_Z17choose_multipliermiiPmPiS0_,
> funcdef_no=1085, decl_uid=47659, symbol_order=801)
> 
> ...
>   557: r13:DI=0x7ffffff78
>       REG_EQUIV 0x7ffffff78
> ...
>   547: debug this => debug_implicit_ptr
>   548: debug D#64 => debug_implicit_ptr
>   549: debug D#37 => D#64
>   550: debug this => D#37
>   551: debug len => optimized away
>   552: debug D#65 => debug_implicit_ptr
>   553: debug D#39 => D#65
>   554: debug this => D#39
>   555: debug high => [sp:DI+0x800000038]
>   556: debug res => 0
>   560: NOTE_INSN_DELETED
>  1334: NOTE_INSN_DELETED
>  1367: ax:DI=[sp:DI+r13:DI+0xc0]
> 

OK. This is actually not reachable.

Only if wi::divmod_internal would return 0, which it does not.
But in this case get_len() would return 0, and then
generic_wide_int <storage>::uhigh () const
{
  return this->get_val ()[this->get_len () - 1];
}
would access exactly SP+32GB.

So this is actually one more case, where it would be incorrect
and potentially dangerous for rtx_addr_can_trap_p_1 to return 0.

The crash in -fdump-rtl-all-slim is actually a different bug,
PR61461 which has most likely nothing to do with this issue.

[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zsojka at seznam dot cz

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
*** Bug 63288 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Eric Botcazou from comment #9)
> Not worth fixing until we have a bug report for real-life software.

So it looks like this not fixed yet.

I checked that my patch is still working.

Should I post it again?

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Should I post it again?

No, PR 63288 is the reduced testcase of PR 60452 compiled with a random set of
RTL optimization options so nothing has changed since the suspension.

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[zsojka at seznam dot cz]

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

--- Comment #15 from Zdenek Sojka <zsojka at seznam dot cz> ---
(In reply to Eric Botcazou from comment #9)
> Not worth fixing until we have a bug report for real-life software.

So do you prefer leaving the bug in until it hits a real-life software?
Is this a common opinion among the GCC dev team, or does it apply only to this
particular case?

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[bernd.edlinger at hotmail dot de]

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

--- Comment #16 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Well, it is at least not my opinion.

I see this bug as a security risk.

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So do you prefer leaving the bug in until it hits a real-life software?
> Is this a common opinion among the GCC dev team, or does it apply only to
> this particular case?

Only this particular case of course...

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 64990 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 65383 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[bernhard.kaindl at thalesgroup dot com]

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

Bernhard Kaindl <bernhard.kaindl at thalesgroup dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernhard.kaindl@thalesgroup
                   |                            |.com

--- Comment #20 from Bernhard Kaindl <bernhard.kaindl at thalesgroup dot com> ---
For people reviewing this, I want to summarize:

Eric submitted a fix for this and explains it [required read]:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01200.html

The archive has no objections and Richard Biener said:
Looks reasonable to me.

The basic bug is that gcc does not eliminate the load of e[2837] (which is dead
code) right way - which may never be reached since b is limited to < 2:

  for (; b < 2; b++)
    {
      a = 0;
      if (b == 2837)
        a = e[b];

As written in Comment 3:
> Note how the load at insn 28 is guarded by comparing ax against #2837.  CE3
> transforms that into an unconditional load and we blow up reading the
> out-of-range stack slot.

As far as I understand: The patch fixes a bug in rtx_addr_can_trap_p_1() which
is called to check if an access can trap, where the bug is that
rtx_addr_can_trap_p_1() does not take the offset of the object (in this case
e[2837]) into account, and returns the info that the access is safe, which it
is not, because it is out of bounds (and out of the stack too)

The patch only fixes the wrong information returned by this function that the
access is safe by returning 1 when the offset causes the access to be outside
of the stack.

So this patch fixes a clear bug which leads to wrong code generated by gcc.

I think that the patch is clear in scope, only fixes a specific case unless
rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to
trunk, 5.1 and 4.9.

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I think that the patch is clear in scope, only fixes a specific case unless
> rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to
> trunk, 5.1 and 4.9.

No, the patch is way too risky and will very likely introduce more bugs than it
fixes, let alone performance regressions.  There are dozens of open PRs
reported for real-life software that need to be fixed, but this one is _not_
one of them.

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #21)
> > I think that the patch is clear in scope, only fixes a specific case unless
> > rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to
> > trunk, 5.1 and 4.9.
> 
> No, the patch is way too risky and will very likely introduce more bugs than
> it fixes, let alone performance regressions.  There are dozens of open PRs
> reported for real-life software that need to be fixed, but this one is _not_
> one of them.

I agree that this is too risky to backport, but I disagree with the decision
not to fix it on the trunk.  We have plenty of time to watch for performance
regressions and/or bugs it introduces there, and even if this bug is only hit
by machine generated code, it would be helpful to all the people that try to
report bugs against gcc if they wouldn't have to analyze and then ignore
similar cases every few days because we chose to never fix it on the gcc side.

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[bernd.edlinger at hotmail dot de]

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

--- Comment #23 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
sorry, which patch are we discussing here?

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I agree that this is too risky to backport, but I disagree with the decision
> not to fix it on the trunk.  We have plenty of time to watch for performance
> regressions and/or bugs it introduces there, and even if this bug is only
> hit by machine generated code, it would be helpful to all the people that
> try to report bugs against gcc if they wouldn't have to analyze and then
> ignore similar cases every few days because we chose to never fix it on the
> gcc side.

As far as I know "all the people" is just one guy submitting machine-generated
testcases and repeatedly running into the issue.  I suspended the PR because
nobody else reported it, in particular on real-life software.  IMO there are
far more pressing issues to be addressed than this one.

That being said, if you feel strongly about it, then go ahead, I won't oppose.

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

[edlinger at gcc dot gnu.org]

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

--- Comment #26 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
Author: edlinger
Date: Wed Jul  1 16:10:30 2015
New Revision: 225260

URL: https://gcc.gnu.org/viewcvs?rev=225260&root=gcc&view=rev
Log:
gcc/ChangeLog:
2015-07-01  Bernd Edlinger  <bernd.edlinger@hotmail.de>

        PR rtl-optimization/61047
        * rtlanal.c (get_initial_register_offset): New function.
        (rtx_addr_can_trap_p_1): Check offsets of stack references.

testsuite/ChangeLog:
2015-07-01  Bernd Edlinger  <bernd.edlinger@hotmail.de>

        PR rtl-optimization/61047
        * gcc.c-torture/execute/20150611-1.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/20150611-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/rtlanal.c
    trunk/gcc/testsuite/ChangeLog