[Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[su at cs dot ucdavis.edu]

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

            Bug ID: 61969
           Summary: wrong code by LTO on x86_64-linux-gnu (affecting
                    trunk, 4.9.x, and 4.8.x)
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

Created attachment 33217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33217&action=edit
test files and compilation script

The current gcc trunk (as well as gcc 4.8.x and 4.9.x) miscompiles the attached
code when using LTO on x86_64-linux-gnu in 64-bit mode (but not in 32-bit
mode). 

This is a regression from 4.7.x.

Sorry that the test case is still pretty complex. It seems very difficult to be
reduced further --- any small changes to the code seem to hide the bug.

$ 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 20140730 (experimental) [trunk revision 213231] (GCC) 
$ 
$ compile.sh 
Usage: ./compile.sh <cc> <mode> <lto: 1 | 0>
$ compile.sh gcc-trunk 64 0; t
-25246
$ compile.sh gcc-trunk 64 1; t
-25246
$ compile.sh gcc-trunk 32 0; t
-25246
$ compile.sh gcc-trunk 32 1; t
0 
$ compile.sh gcc-4.9 32 1; t
0
$ compile.sh gcc-4.8 32 1; t
2052
$ compile.sh gcc-4.7 32 1; t
-25246
$

[Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i?86-*-*
   Target Milestone|---                         |4.8.4
            Summary|wrong code by LTO on        |[4.8/4.9/4.10 Regression]
                   |x86_64-linux-gnu (affecting |wrong code by LTO on
                   |trunk, 4.9.x, and 4.8.x)    |i?86-linux-gnu (affecting
                   |                            |trunk, 4.9.x, and 4.8.x)

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You mean in 32bit mode.  I can't reproduce it with trunk or 4.9 but only
with 4.8:

rguenther@murzim:/tmp> ./compile.sh gcc-4.8 32 1
rguenther@murzim:/tmp> ./t
2052

maybe it's sensitive to the linker used?  it works with both GNU ld and gold
for me with 4.9 and trunk.

[Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su <su at cs dot ucdavis.edu> ---
> You mean in 32bit mode.  

Richard, yes, I meant 32-bit mode. 

> I can't reproduce it with trunk or 4.9 but only
> with 4.8:
> 
> rguenther@murzim:/tmp> ./compile.sh gcc-4.8 32 1
> rguenther@murzim:/tmp> ./t
> 2052
> 
> maybe it's sensitive to the linker used?  it works with both GNU ld and gold
> for me with 4.9 and trunk.

I used the GNU gold linker: 

$ ld -v
GNU gold (GNU Binutils for Ubuntu 2.22) 1.11
$

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[andi-gcc at firstfloor dot org]

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

Andi Kleen <andi-gcc at firstfloor dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andi-gcc at firstfloor dot org

--- Comment #3 from Andi Kleen <andi-gcc at firstfloor dot org> ---
I did some experiments. I can reproduce it with trunk for 32bit.

The interesting part is that the printed value seems to be uninitialized on the
stack and changes on every run. a valgrind run gives


=23130== Use of uninitialised value of size 4
==23130==    at 0x40B102B: _itoa_word (in /lib/libc-2.18.so)
==23130==    by 0x40B474A: vfprintf (in /lib/libc-2.18.so)
==23130==    by 0x40BAFCE: printf (in /lib/libc-2.18.so)
==23130==    by 0x40879D2: (below main) (in /lib/libc-2.18.so)
==23130==  Uninitialised value was created by a stack allocation
==23130==    at 0x80482F4: main (in /home/andi/Downloads/pr61969/t)
==23130== 
... more warnings like this ...

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[andi-gcc at firstfloor dot org]

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

--- Comment #4 from Andi Kleen <andi-gcc at firstfloor dot org> ---

The problem is when returning a struct from func_52:

const struct S0 func_52 (uint32_t p_53)
{
  const struct S0 l_55 = { 4, 40290, 10, 4 };
  return l_55;
}

The main code stores the struct value from the stack into the global variable
and eventually prints it

 80482f4:       83 ec 38                sub    $0x38,%esp
 80482f7:       0f b6 15 4c da 04 08    movzbl 0x804da4c,%edx
 80482fe:       8b 1d 20 d1 04 08       mov    0x804d120,%ebx
 8048304:       0f b6 35 70 da 04 08    movzbl 0x804da70,%esi
 804830b:       e8 b0 0c 00 00          call   8048fc0 <func_52>
 8048310:       0f b7 45 d2             movzwl -0x2e(%ebp),%eax
 8048314:       ba 01 00 00 00          mov    $0x1,%edx
 8048319:       c7 05 20 d1 04 08 48    movl   $0x804da48,0x804d120
 8048320:       da 04 08 
 8048323:       66 a3 5c da 04 08       mov    %ax,0x804da5c


But func_52 has been completely optimized away and puts nothing onto the stack:


08048fc0 <func_52>:
 8048fc0:       f3 c3                   repz ret 
 8048fc2:       8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
 8048fc9:       8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi

So the value is random stack garbage.

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[andi-gcc at firstfloor dot org]

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

--- Comment #5 from Andi Kleen <andi-gcc at firstfloor dot org> ---
func_52 disappears during/after nrv:

in 173t.nrv:

;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)

func_52 (uint32_t p_53)
{
  extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4} [value-expr:
<retval>];

  <bb 2>:
  return <retval>;

}

in 174t.optimized

;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)

func_52 (uint32_t p_53)
{
  <bb 2>:
  return <retval>;

}

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[andi-gcc at firstfloor dot org]

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

--- Comment #6 from Andi Kleen <andi-gcc at firstfloor dot org> ---
I looked at this a bit more. It's definitely the nrv pass that causes the
problem.

When I disable it in the source code the 32bit version compiles correctly.
I also tried disabling the next pass (cfgcleanup), but that didn't make a
difference.

It converts the local variable to be a value-expr.

It's still not exactly clear who deletes the variable declaration though.

There are two possibilities:
- nrv shouldn't convert the variable in the first place
- someone who messes with the variables forgets to check for value-exprs.

;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)

NRV Replaced: l_55  with: <retval>
func_52 (uint32_t p_53)
{
  extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4} [value-expr:
<retval>];

  <bb 2>:
  return <retval>;

}

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andi Kleen from comment #6)
> I looked at this a bit more. It's definitely the nrv pass that causes the
> problem.
> 
> When I disable it in the source code the 32bit version compiles correctly.
> I also tried disabling the next pass (cfgcleanup), but that didn't make a
> difference.
> 
> It converts the local variable to be a value-expr.
> 
> It's still not exactly clear who deletes the variable declaration though.
> 
> There are two possibilities:
> - nrv shouldn't convert the variable in the first place
> - someone who messes with the variables forgets to check for value-exprs.
> 
> ;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
> symbol_order=1152)
> 
> NRV Replaced: l_55  with: <retval>
> func_52 (uint32_t p_53)
> {
>   extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4}
> [value-expr: <retval>];

only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.

What does func_52 look like before the NRV pass?  It must be sth like

 <retval> = l_55;

?

Looks like a bug in nrv to me:

              /* The returned value must be a local automatic variable of the
                 same type and alignment as the function's result.  */
              if (TREE_CODE (found) != VAR_DECL
                  || TREE_THIS_VOLATILE (found)
                  || DECL_CONTEXT (found) != current_function_decl
                  || TREE_STATIC (found)
                  || TREE_ADDRESSABLE (found)
                  || DECL_ALIGN (found) > DECL_ALIGN (result)
                  || !useless_type_conversion_p (result_type,
                                                 TREE_TYPE (found)))
                return 0;

should probably use auto_var_in_fn_p which checks for !DECL_EXTERNAL as well.

Index: gcc/tree-nrv.c
===================================================================
--- gcc/tree-nrv.c      (revision 215917)
+++ gcc/tree-nrv.c      (working copy)
@@ -216,8 +216,7 @@ pass_nrv::execute (function *fun)
                 same type and alignment as the function's result.  */
              if (TREE_CODE (found) != VAR_DECL
                  || TREE_THIS_VOLATILE (found)
-                 || DECL_CONTEXT (found) != current_function_decl
-                 || TREE_STATIC (found)
+                 || !auto_var_in_fn_p (found, current_function_decl)
                  || TREE_ADDRESSABLE (found)
                  || DECL_ALIGN (found) > DECL_ALIGN (result)
                  || !useless_type_conversion_p (result_type,


>   <bb 2>:
>   return <retval>;
> 
> }

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[andi at firstfloor dot org]

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

--- Comment #8 from andi at firstfloor dot org ---
> only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.

It's an initializer for an automatic var in the source

func_52() {
    struct S0 foo = { ... }
    ...
}


> 
> What does func_52 look like before the NRV pass?  It must be sth like
> 
>  <retval> = l_55;
> 
> ?

Yes it looks like that.

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[andi-gcc at firstfloor dot org]

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

--- Comment #9 from Andi Kleen <andi-gcc at firstfloor dot org> ---
Patch fixes the test case.

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-10-08
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Testing it.

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Oct  9 08:21:46 2014
New Revision: 216029

URL: https://gcc.gnu.org/viewcvs?rev=216029&root=gcc&view=rev
Log:
2014-10-09  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/61969
    * tree-nrv.c (pass_nrv::execute): Properly test for automatic
    variables.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-nrv.c

[Bug lto/61969] [4.8/4.9 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |5.0
            Summary|[4.8/4.9/5 Regression]      |[4.8/4.9 Regression] wrong
                   |wrong code by LTO on        |code by LTO on
                   |i?86-linux-gnu (affecting   |i?86-linux-gnu (affecting
                   |trunk, 4.9.x, and 4.8.x)    |trunk, 4.9.x, and 4.8.x)

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug lto/61969] [4.8 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug lto/61969] [4.8 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Nov 26 13:15:16 2014
New Revision: 218079

URL: https://gcc.gnu.org/viewcvs?rev=218079&root=gcc&view=rev
Log:
2014-11-26  Richard Biener  <rguenther@suse.de>

    Backport from mainline
    2014-10-08  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/61969
    * tree-nrv.c (pass_nrv::execute): Properly test for automatic
    variables.

    2014-08-15  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/62031
    * tree-data-ref.c (dr_analyze_indices): Do not set
    DR_UNCONSTRAINED_BASE.
    (dr_may_alias_p): All indirect accesses have to go the
    formerly DR_UNCONSTRAINED_BASE path.
    * tree-data-ref.h (struct indices): Remove
    unconstrained_base member.
    (DR_UNCONSTRAINED_BASE): Remove.

    * gcc.dg/torture/pr62031.c: New testcase.

    2014-10-10  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/63379
    * tree-vect-slp.c (vect_get_constant_vectors): Do not compute
    a neutral operand for min/max when it is not a reduction chain.

    * gcc.dg/vect/pr63379.c: New testcase.

    2014-11-07  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/63605
    * fold-const.c (fold_binary_loc): Properly use element_precision
    for types that may not be scalar.

    * gcc.dg/vect/pr63605.c: New testcase.

    2014-10-28  Richard Biener  <rguenther@suse.de>

    PR middle-end/63665
    * fold-const.c (fold_comparison): Properly guard simplifying
    against INT_MAX/INT_MIN with !TYPE_OVERFLOW_WRAPS.

    * gcc.dg/pr63665.c: New testcase.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr63665.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr62031.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63379.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63605.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/fold-const.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/tree-data-ref.c
    branches/gcc-4_8-branch/gcc/tree-data-ref.h
    branches/gcc-4_8-branch/gcc/tree-nrv.c
    branches/gcc-4_8-branch/gcc/tree-vect-slp.c