[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-08 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org ---
too bad :/  As this doesn't reproduce with a cross it's impossible to debug for
me as well (are there instructions somewhere how to install
x86_64-w64-mingw32 using wine ...?  would that even work and reproduce the
issue?)

I'll leave this for Kai to debug.


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-08 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #15 from Kai Tietz ktietz at gcc dot gnu.org ---
That is my issue too.  I try to reproduce this issue with cross and native.
But I see some issues only in combination with upstream binutils, and here only
in native case, which is the curious part ...
I am still on to find the underlying issue ...


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-07 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
3
fprintf.o 2
195 905fe68a PREVAILING_DEF_IRONLY main_test
233 905fe68a RESOLVED_EXEC __iob_func
fprintf-lib.o 1
263 905f8622 RESOLVED_IR inside_main
main.o 3
172 905f8490 PREVAILING_DEF main
179 905f8490 PREVAILING_DEF_IRONLY inside_main
175 905f8490 RESOLVED_IR main_test

but we have only

fprintf.o
main.o

as inputs (from ccm7oRxV).  That file is generated from lto-wrapper which
already gets fprintf-lib.o stripped somehow (cc8SwjwK).  collect2.c still
sees all inputs.

Unfortunately -Wl,-debug is missing ;)

It would be interesting to see the lto-wrapper invocation (is there sth like
strace on mingw?) and to eventually attach to lto-wrapper with a debugger...

We seem to use a linker plugin, so the error may even start there.


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-07 Thread rai...@emrich-ebersheim.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #9 from Rainer Emrich rai...@emrich-ebersheim.de ---
Created attachment 35244
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35244action=edit
reproducer with temporaries and verbose gcc output including -Wl,-debug


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-07 Thread rai...@emrich-ebersheim.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #10 from Rainer Emrich rai...@emrich-ebersheim.de ---
(In reply to Richard Biener from comment #8)
 Unfortunately -Wl,-debug is missing ;)
Ok, I uploaded a version including -Wl,-debug

 
 It would be interesting to see the lto-wrapper invocation (is there sth like
 strace on mingw?) and to eventually attach to lto-wrapper with a debugger...
I can't tell how to do this. Kai can you have a look?


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-07 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, the ld invocation still looks correct.  For some reason we don't see the
debug output from lto-wrapper or the linker plugin.  Ah - it looks for '-v',
so can you try with -Wl,-debug -Wl,-v?

Debugging the linker-plugin should work by debugging the ld.exe invocation.
From that gdb should be able to follow forks(?)


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-07 Thread rai...@emrich-ebersheim.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #13 from Rainer Emrich rai...@emrich-ebersheim.de ---
(In reply to Richard Biener from comment #11)
 Ok, the ld invocation still looks correct.  For some reason we don't see the
 debug output from lto-wrapper or the linker plugin.  Ah - it looks for '-v',
 so can you try with -Wl,-debug -Wl,-v?
The real trick is -Wl,--verbose=2.

I'm really sorry, for the next few days I don't have the time to debug this.
For me it's really time consuming, because I don't know what to look for and
even can't really operate gdb.


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-07 Thread rai...@emrich-ebersheim.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #12 from Rainer Emrich rai...@emrich-ebersheim.de ---
Created attachment 35245
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35245action=edit
yet another more verbose reproducer


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-06 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #6 from Jan Hubicka hubicka at ucw dot cz ---
Can you please compile with --verbose --save-temps and attach the output +
temporary files produced?
(in particular I wonder about resolution file that should be named *.res)


Re: [Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-06 Thread Jan Hubicka
Can you please compile with --verbose --save-temps and attach the output + 
temporary files produced?
(in particular I wonder about resolution file that should be named *.res)


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-06 Thread rai...@emrich-ebersheim.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #5 from Rainer Emrich rai...@emrich-ebersheim.de ---
Created attachment 35237
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35237action=edit
reproducer with temporaries

$ gcc fprintf.c fprintf-lib.c main.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -w -O2 -flto -flto-partition=none
-fno-tree-loop-distribute-patterns --save-temps -Wl,--allow-multiple-definition
-lm -o fprintf.x7
lto1.exe: internal compiler error: in read_cgraph_and_symbols, at
lto/lto.c:2960
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper.exe: fatal error:
D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\gcc.exe
returned 1 exit status
compilation terminated.
d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/../lib/gcc/x86_64-w64-mingw32/5.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

$ gcc -v
Using built-in specs.
COLLECT_GCC=D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/../libexec/gcc/x86_64-w64-mingw32/5.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/configure
--prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0
--with-gnu-as
--with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/as
--with-gnu-ld
--with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/ld
--build=x86_64-w64-mingw32 --enable-threads=posix
--enable-languages=c,c++,fortran,java,lto,objc,obj-c++
--with-gmp-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-gmp-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-mpfr-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-mpfr-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-mpc-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-mpc-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-isl-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-isl-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0
--enable-libgomp --enable-fully-dynamic-string --disable-multilib
--enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk
Thread model: posix
gcc version 5.0.0 20150403 (experimental) [trunk revision 221852] (GCC)


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-06 Thread rai...@emrich-ebersheim.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #7 from Rainer Emrich rai...@emrich-ebersheim.de ---
Created attachment 35239
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35239action=edit
reproducer with temporaries and verbose gcc output


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-03-31 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Needs more analysis from folks that can reproduce - see Honzas comment.


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-03-26 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.0


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
Yeah, I noticed such failures too.
AFAI researched them, they are related to out-of-stack issues.

The problem seems to be that within lto a lot of vec-s are passed on stack and
lead for stack-limited targets easily to out-of-stack issues.

Not sure if this is here really the reason, but my gut feeling would say so.

Nevertheless I can confirm this ice


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-03-25 Thread rai...@emrich-ebersheim.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #2 from Rainer Emrich rai...@emrich-ebersheim.de ---
(In reply to Kai Tietz from comment #1)
 Yeah, I noticed such failures too.
 AFAI researched them, they are related to out-of-stack issues.
 
 The problem seems to be that within lto a lot of vec-s are passed on stack
 and lead for stack-limited targets easily to out-of-stack issues.
 
 Not sure if this is here really the reason, but my gut feeling would say so.
 
 Nevertheless I can confirm this ice
This issue is new, last time I ran the whole testsuite, end of october last
year, I didn't get such ICEs. And they are present in the g++ testsuite too.
And there are a lot of them.


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-03-25 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org ---
lto1.exe: internal compiler error: in read_cgraph_and_symbols, at
lto/lto.c:2947
does not seem like stack limit issue.

  /* True, since the plugin splits the archives.  */
  gcc_assert (num_objects == nfiles);   

so it seems there is some confussion in handling the object files.  num_objects
is the number of objects stored by linker to resolution file, while nfiles is
number of objects seen by GCC.  How they differ?

This may be either linker or simple-object bug I guess.
with --save-temps you can check the .res file and see if it looks sane.