[Bug lto/60404] New: wrong code by LTO on x86_64-linux-gnu

[Bug lto/60404] New: wrong code by LTO on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

            Bug ID: 60404
           Summary: wrong code by LTO on x86_64-linux-gnu
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The current gcc trunk miscompiles the following code when using LTO on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

This 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 --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140303 (experimental) [trunk revision 208268] (GCC) 
$ 
$ gcc-trunk -flto -O1 -c fn1.c
$ gcc-trunk -flto -O1 -c fn2.c
$ gcc-trunk -flto -O1 -c main.c
$ gcc-trunk -flto -O0 fn1.o fn2.o main.o           
$ a.out
1
$ 
$ gcc-4.8.2 -flto -O1 -c fn1.c
$ gcc-4.8.2 -flto -O1 -c fn2.c
$ gcc-4.8.2 -flto -O1 -c main.c
$ gcc-4.8.2 -flto -O0 fn1.o fn2.o main.o
$ a.out
0
$ 
$ gcc-trunk -O0 fn1.c fn2.c main.c
$ a.out
0
$ 
$ cat fn1.c 
void
fn1 (int p)
{
}
$ cat fn2.c
extern int b;

extern void fn1 (int);

void
fn2 (int p)
{
  b = p++;
  fn1 (p);
}
$ cat main.c
int printf (const char *, ...);

extern void fn2 (int);

int a[1];
int b;

int
main ()
{
  fn2 (0);
  printf ("%d\n", a[b]);
  return 0;
}
$

[Bug lto/60404] wrong code by LTO on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think r204742 broke this.
The assumption that you can coalesce all SSA_NAMEs of a particular PARM_DECL at
!optimize is only true without -flto, or if the function has been compiled with
-O0 before being streamed.
So, the quick hack would be to change all the optimize tests in r204742 to
optimize && !flag_ltrans, dunno if we have some way to query if a function has
been originally compiled with -O0.  That might mean we regress the param-4.c
testcase at -O0 -flto, but at least we don't generate wrong code.

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-03-04
   Target Milestone|---                         |4.9.0
            Summary|wrong code by LTO on        |[4.9 Regression] wrong code
                   |x86_64-linux-gnu            |by LTO on x86_64-linux-gnu
     Ever confirmed|0                           |1

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32257
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32257&action=edit
gcc49-pr60404.patch

Untested fix.

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Compiling with optimization and linking without it in LTO mode is one of the
most clever ideas I have seen recently so I agree that a kludge is good
enough...

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Mar  5 08:46:31 2014
New Revision: 208340

URL: http://gcc.gnu.org/viewcvs?rev=208340&root=gcc&view=rev
Log:
    PR lto/60404
    * cfgexpand.c (expand_used_vars): Do not assume all SSA_NAMEs
    of PARM/RESULT_DECLs must be coalesced with optimize && in_lto_p.
    * tree-ssa-coalesce.c (coalesce_ssa_name): Use MUST_COALESCE_COST - 1
    cost for in_lto_p.

    * gcc.dg/lto/pr60404_0.c: New test.
    * gcc.dg/lto/pr60404_1.c: New file.
    * gcc.dg/lto/pr60404_2.c: New file.

Added:
    trunk/gcc/testsuite/gcc.dg/lto/pr60404_0.c
    trunk/gcc/testsuite/gcc.dg/lto/pr60404_1.c
    trunk/gcc/testsuite/gcc.dg/lto/pr60404_2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-coalesce.c

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed, thanks for reporting this.

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #6 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jakub Jelinek from comment #5)
> Fixed, thanks for reporting this.

Jakub, thanks for the quick fix! 

I'm intrigued by Eric's earlier comment.  Is it one of the purposes of LTO so
that one could link object files (and shared libraries) compiled separately,
and possibly by others?  In that case, I could certainly imagine linking at
-O0, say for debugging, etc., correct?