[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed for 4.9.0.
[Bug lto/60319] wrong code (that hangs) by LTO at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 --- Comment #8 from Richard Biener --- 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 Richard Biener 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 --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-24 Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- (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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 --- Comment #5 from Zhendong Su --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319
--- Comment #4 from Richard Biener ---
(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 ()
{
:
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 --- Comment #3 from Zhendong Su --- (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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 --- Comment #2 from Richard Biener --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60319 Richard Biener changed: What|Removed |Added Keywords||lto Known to fail||4.5.4, 4.6.4, 4.7.3 --- Comment #1 from Richard Biener --- Hmm, I can't reproduce this with 4.8 or trunk but with 4.5, 4.6 and 4.7.
