[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto
      Known to fail|                            |4.5.4, 4.6.4, 4.7.3

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I can't reproduce this with 4.8 or trunk but with 4.5, 4.6 and 4.7.

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
4.7 and lower is expected to show this behavior due to the bug that c++ is
not properly implemented as c = (char)((int)c + 1) and thus we think that
overflow is undefined.

4.8 and above has that fixed and thus shows different, working behavior.

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #3 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Richard Biener from comment #1)
> Hmm, I can't reproduce this with 4.8 or trunk but with 4.5, 4.6 and 4.7.

Richard, it still fails for me. Did you use LTO?  

$ 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 20140223 (experimental) [trunk revision 208062] (GCC) 
$   
$ gcc-trunk -O0 -c foo.c
$ gcc-trunk -O0 -c main.c
$ gcc-trunk -Os foo.o main.o
$ a.out
$ 
$ gcc-trunk -flto -O0 -c foo.c
$ gcc-trunk -flto -O0 -c main.c
$ gcc-trunk -flto -Os foo.o main.o
$ a.out
^C
$ 
$ gcc-4.8 -flto -O0 -c foo.c
$ gcc-4.8 -flto -O0 -c main.c
$ gcc-4.8 -flto -Os foo.o main.o
$ a.out
^C
$

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Zhendong Su from comment #3)
> (In reply to Richard Biener from comment #1)
> > Hmm, I can't reproduce this with 4.8 or trunk but with 4.5, 4.6 and 4.7.
> 
> Richard, it still fails for me. Did you use LTO?  

Yes, I did.  For me -O[s23] -flto -v -save-temps -fdump-tree-all results
in a ccXYZ.ltrans0.o.169t.optimized file like


;; Function main (main, funcdef_no=2, decl_uid=2401, symbol_order=0) (executed
once)

main ()
{
  <bb 2>:
  return 0;

}

> $ 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 20140223 (experimental) [trunk revision 208062] (GCC) 
> $   
> $ gcc-trunk -O0 -c foo.c
> $ gcc-trunk -O0 -c main.c
> $ gcc-trunk -Os foo.o main.o
> $ a.out
> $ 
> $ gcc-trunk -flto -O0 -c foo.c
> $ gcc-trunk -flto -O0 -c main.c
> $ gcc-trunk -flto -Os foo.o main.o
> $ a.out
> ^C
> $ 
> $ gcc-4.8 -flto -O0 -c foo.c
> $ gcc-4.8 -flto -O0 -c main.c
> $ gcc-4.8 -flto -Os foo.o main.o
> $ a.out
> ^C
> $

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #5 from Zhendong Su <su at cs dot ucdavis.edu> ---
Did you separately compile the two files at -O0 and link at -Os, like below? 

> $ gcc-trunk -flto -O0 -c foo.c
> $ gcc-trunk -flto -O0 -c main.c
> $ gcc-trunk -flto -Os foo.o main.o

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Zhendong Su from comment #5)
> Did you separately compile the two files at -O0 and link at -Os, like below? 
> 
> > $ gcc-trunk -flto -O0 -c foo.c
> > $ gcc-trunk -flto -O0 -c main.c
> > $ gcc-trunk -flto -Os foo.o main.o

Ah, no.  The issue here is that the fix for that bug I mention triggers
on TYPE_OVERFLOW_UNDEFINED, but with -O[01] we have -fno-strict-overflow
enabled and thus we lower it in a bogus way while with -O[s23] we
have -fstrict-overflow.  This is a IL semantic change that is not actually
contained in the IL ...

Anyway, confirmed.

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that such bugs may occur generally when mixing -O[01] with -O[s23] ... for
a similar case, -f[no-]strict-aliasing we get away with streaming get_alias_set
() == 0.

Thus I think we have to "conservatively" merge -fstrict-overflow, similar
to how we treat -ffp-contract.

I have a patch.

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Feb 25 08:57:42 2014
New Revision: 208112

URL: http://gcc.gnu.org/viewcvs?rev=208112&root=gcc&view=rev
Log:
2014-02-25  Richard Biener  <rguenther@suse.de>

    PR lto/60319
    * lto-opts.c (lto_write_options): Output non-explicit conservative
    -fwrapv, -fno-trapv and -fno-strict-overflow.
    * lto-wrapper.c (merge_and_complain): Handle merging those options.
    (run_gcc): And pass them through.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto-opts.c
    trunk/gcc/lto-wrapper.c

[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

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

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