[Bug lto/41932] New: LTO ICE when compiling ocaml trunk (incompatible type)

When trying to compile ocaml-trunk (svn revision 9408 of ocaml trunk) with
gcc-trunk rev 153839, gcc LTO make an ICE.

Step by step instructions to reproduce the bug (on a Linux AMD64 system, eg
Debian/Sid or Ubuntu/Karmic etc...)

0. You should have gcc-trunk already built; ensure (perhaps with some PATH
trick that your gcc-trunk is indeed invoked as gcc-trunk, or replace gcc-trunk
by what is appropriate for you
 % gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/src/Lang/gcc-trunk-bstarynk/configure
--program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk
--libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-languages=c,c++ --enable-lto --enable-plugins --enable-maintainer-mode
: (reconfigured) /usr/src/Lang/gcc-trunk-bstarynk/configure
--program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk
--libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-languages=c,c++ --enable-lto --enable-plugins --enable-maintainer-mode
: (reconfigured) /usr/src/Lang/gcc-trunk-bstarynk/configure
--program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk
--libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-lto --enable-plugins --enable-maintainer-mode
--enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured)
/usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk
--libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-lto --enable-plugins --enable-maintainer-mode
--enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured)
/usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk
--libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-lto --enable-plugins --enable-maintainer-mode
--enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20091103 (experimental) (GCC)


1. Retrieve ocaml-trunk rev 9408 with
  svn co -r 9408 http://caml.inria.fr/svn/ocaml/trunk ocaml-trunk-r9408

2. Go into that directory
  cd ocaml-trunk-r9408

3. Configure Ocaml to be compiled with gcc-trunk -flto -O2
  ./configure -cc 'gcc-trunk -flto -O2'
Note that ocaml does not use autoconf. Its configure script is handcrafted.

4. Build the bytecode variant of ocaml. This should crash gcc-trunk.
   make -w world
gcc-trunk -flto -O2 -c -DCAML_NAME_SPACE -O -fno-defer-pop -Wall
-D_FILE_OFFSET_BITS=64 -D_REENTRANT  -fPIC finalise.c
mv finalise.o finalise.pic.o
gcc-trunk -flto -O2 -c -DCAML_NAME_SPACE -O -fno-defer-pop -Wall
-D_FILE_OFFSET_BITS=64 -D_REENTRANT  -fPIC custom.c
mv custom.o custom.pic.o
gcc-trunk -flto -O2 -c -DCAML_NAME_SPACE -O -fno-defer-pop -Wall
-D_FILE_OFFSET_BITS=64 -D_REENTRANT  -fPIC dynlink.c
mv dynlink.o dynlink.pic.o
gcc-trunk -flto -O2 -c -DCAML_NAME_SPACE -O -fno-defer-pop -Wall
-D_FILE_OFFSET_BITS=64 -D_REENTRANT  -fPIC unix.c
mv unix.o unix.pic.o
gcc-trunk -flto -O2 -c -DCAML_NAME_SPACE -O -fno-defer-pop -Wall
-D_FILE_OFFSET_BITS=64 -D_REENTRANT  -fPIC main.c
mv main.o main.pic.o
gcc-trunk -flto -O2 -shared -o libcamlrun_shared.so interp.pic.o misc.pic.o
stacks.pic.o fix_code.pic.o startup.pic.o freelist.pic.o major_gc.pic.o
minor_gc.pic.o memory.pic.o alloc.pic.o roots.pic.o globroots.pic.o fail.pic.o
signals.pic.o signals_byt.pic.o printexc.pic.o backtrace.pic.o compare.pic.o
ints.pic.o floats.pic.o str.pic.o array.pic.o io.pic.o extern.pic.o
intern.pic.o hash.pic.o sys.pic.o meta.pic.o parsing.pic.o gc_ctrl.pic.o
terminfo.pic.o md5.pic.o obj.pic.o lexing.pic.o callback.pic.o debugger.pic.o
weak.pic.o compact.pic.o finalise.pic.o custom.pic.o dynlink.pic.o unix.pic.o
main.pic.o -lm  -ldl -lcurses -lpthread
gc_ctrl.c:44:16: warning: type of 'caml_major_heap_increment' does not match
original declaration
major_gc.c:33:8: note: previously declared here
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: /usr/local/bin/gcc-trunk returned 1 exit status
collect2: lto-wrapper returned 1 exit status
make[2]: *** [libcamlrun_shared.so] Error 1
make[2]: Leaving directory `/usr/src/Lang/ocaml-trunk-r9408/byterun'
make[1]: *** [coldstart] Error 2
make[1]: Leaving directory `/usr/src/Lang/ocaml-trunk-r9408'
make: *** [world] Error 2
make: Leaving directory `/usr/src/Lang/ocaml-trunk-r9408'


The diagnostic is right:

in gc_ctrl.c:
extern asize_t caml_major_heap_increment;  /* bytes; see major_gc.c */

in major_gc.c:
intnat caml_major_heap_increment;

But the GCC crash is wrong.

I was not able to reproduce the crash with two small files (a.c & b.c)
containing almost only the above suspicious lines.


I am sorry for such a big bug report.


--
           Summary: LTO ICE when compiling ocaml trunk (incompatible type)
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: lto
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bstarynk at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-04 10:32 -------
Reduce this line:

gcc-trunk -flto -O2 -shared -o libcamlrun_shared.so interp.pic.o misc.pic.o
stacks.pic.o fix_code.pic.o startup.pic.o freelist.pic.o major_gc.pic.o
minor_gc.pic.o memory.pic.o alloc.pic.o roots.pic.o globroots.pic.o fail.pic.o
signals.pic.o signals_byt.pic.o printexc.pic.o backtrace.pic.o compare.pic.o
ints.pic.o floats.pic.o str.pic.o array.pic.o io.pic.o extern.pic.o
intern.pic.o hash.pic.o sys.pic.o meta.pic.o parsing.pic.o gc_ctrl.pic.o
terminfo.pic.o md5.pic.o obj.pic.o lexing.pic.o callback.pic.o debugger.pic.o
weak.pic.o compact.pic.o finalise.pic.o custom.pic.o dynlink.pic.o unix.pic.o
main.pic.o -lm  -ldl -lcurses -lpthread

by removing as many .o files from it as possible (and of course the crash
still persists).  Then attach preprocessed source for the files that remain
needed.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
            Summary|LTO ICE when compiling ocaml|LTO ICE when compiling ocaml
                   |trunk (incompatible type)   |trunk (incompatible type)


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

------- Comment #2 from simon_baldwin at yahoo dot com  2009-11-04 12:17 -------
I have a minimal failing case for this, I think.  I'm using trunk 153803, for
what it's worth.

$ cat demo.c
  typedef long intnat;
  typedef intnat value;
  void caml_darken (value v, value *p) { }

$ .../gcc -flto -O2 -c -O -fPIC demo.c
$ .../gcc -flto -O2 -shared -o /dev/null demo.o
  lto1: internal compiler error: Segmentation fault

Though it looks to be related to the ICE, the warning

  gc_ctrl.c:44:16: warning: type of 'caml_major_heap_increment' does not match
original declaration
  major_gc.c:33:8: note: previously declared here

seems genuine and unrelated to me.  gc_ctrl.c declares this as extern asize_t
(size_t, long unsigned), major_gc.c defines it as intnat (long).


--


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

------- Comment #3 from simon_baldwin at yahoo dot com  2009-11-04 12:57 -------
A bit more info from a gdb trace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000b798ce in ipa_populate_param_decls (node=0x2aaaab453300,
    info=0x15eb768) at ../../gcc/gcc/ipa-prop.c:141
141           info->params[param_num].decl = parm;
(gdb) bt
#0  0x0000000000b798ce in ipa_populate_param_decls (node=0x2aaaab453300,
    info=0x15eb768) at ../../gcc/gcc/ipa-prop.c:141
#1  0x0000000000b8192a in ipa_update_after_lto_read ()
    at ../../gcc/gcc/ipa-prop.c:2165
#2  0x0000000000b7224d in ipcp_iterate_stage () at ../../gcc/gcc/ipa-cp.c:736
#3  0x0000000000b73beb in ipcp_driver () at ../../gcc/gcc/ipa-cp.c:1258
#4  0x00000000007ceae5 in execute_one_pass (pass=0x1515960)
    at ../../gcc/gcc/passes.c:1518
#5  0x00000000007cf191 in execute_ipa_pass_list (pass=0x1515960)
    at ../../gcc/gcc/passes.c:1730
#6  0x0000000000b6e03a in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1387
#7  0x0000000000b6e111 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1421
#8  0x00000000004b3278 in lto_main (debug_p=0) at ../../gcc/gcc/lto/lto.c:2008
#9  0x00000000008c5751 in compile_file () at ../../gcc/gcc/toplev.c:1049
#10 0x00000000008c7a4c in do_compile () at ../../gcc/gcc/toplev.c:2408
#11 0x00000000008c7afd in toplev_main (argc=12, argv=0x7fffffffd458)
    at ../../gcc/gcc/toplev.c:2450
#12 0x00000000004b5c93 in main (argc=12, argv=0x7fffffffd458)
    at ../../gcc/gcc/main.c:35
(gdb) p param_num
$1 = 0
(gdb) p info->params
$2 = (struct ipa_param_descriptor *) 0x0
(gdb) p info
$3 = (struct ipa_node_params *) 0x15eb768
(gdb) p *info
$4 = {param_count = 0, params = 0x0, param_calls = 0x0, ipcp_orig_node = 0x0,
  count_scale = 0, called_with_var_arguments = 0,
  modification_analysis_done = 0, uses_analysis_done = 0, node_enqueued = 0}


--


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

------- Comment #4 from rguenth at gcc dot gnu dot org  2009-11-04 14:00 -------
This is -O vs. -O2 ICE because different IPA passes are selected then.  I think
we have a dup for this - Martin, is it somehow easy to avoid the ICE?


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjambor at suse dot cz
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-11-04 14:00:43
               date|                            |


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

------- Comment #5 from rguenth at gcc dot gnu dot org  2009-11-04 14:01 -------
Note that I wonder why we write/read summaries (do we?) with -flto at all.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


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

------- Comment #6 from jamborm at gcc dot gnu dot org  2009-11-04 16:10 -------
(In reply to comment #4)
> This is -O vs. -O2 ICE because different IPA passes are selected
> then.  I think we have a dup for this - Martin, is it somehow easy
> to avoid the ICE?
>

Well, it seems that calling ipa_initialize_node_params() rather than
ipa_populate_param_decls() in ipa_update_after_lto_read() should avoid
it.

Moreover, if things can get this much out of sync, I'd also call
ipa_check_create_node_params() and ipa_check_create_edge_args() at the
beginning of ipa_update_after_lto_read() too, just to be sure.

I have not tried any of the above but can prepare a patch along these
lines... unless someone else is faster :-)


--


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

------- Comment #7 from bstarynk at gcc dot gnu dot org  2009-11-04 18:37 -------
With gcc trunk rev 153897 Simon Baldwin's demo.c file
  typedef long intnat;
  typedef intnat value;
  void caml_darken (value v, value *p) { }
is passing ok.

But ocaml-trunk is still crashing the gcc-trunk. And it is not related to the
incompatible type warning. This has been fixed in ocaml trunk rev 9410, and
gcc-trunk still crashes when compiling it.

It is indeed related to passing both -flto -O2 & -O to the compiler.


--


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

------- Comment #8 from bstarynk at gcc dot gnu dot org  2009-11-04 18:45 -------
(In reply to comment #7)
> With gcc trunk rev 153897 Simon Baldwin's demo.c file
>   typedef long intnat;
>   typedef intnat value;
>   void caml_darken (value v, value *p) { }
> is passing ok.
>

No I was wrong. It crashes also. It is important to run
  gcc-trunk -flto -O2 -c -O -fPIC PR41932-demo.c
and then
  gcc-trunk -flto -O2 -shared -o /dev/null PR41932-demo.o


--


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

------- Comment #9 from jamborm at gcc dot gnu dot org  2009-11-10 16:20 -------
Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00501.html


--

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|mjambor at suse dot cz      |jamborm at gcc dot gnu dot
                   |                            |org


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

------- Comment #10 from jamborm at gcc dot gnu dot org  2009-11-11 15:07 -------
Subject: Bug 41932

Author: jamborm
Date: Wed Nov 11 15:07:18 2009
New Revision: 154095

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154095
Log:
2009-11-11  Martin Jambor  <mjambor@...>

        PR lto/41932
        * ipa-prop.c (ipa_update_after_lto_read): Call
        ipa_check_create_node_params and ipa_check_create_edge_args.  Also
        call ipa_initialize_node_params instead of ipa_populate_param_decls.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-prop.c


--


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

------- Comment #11 from jamborm at gcc dot gnu dot org  2009-11-11 15:10 -------
Basile, can you please confirm that this is now fixed?  Thanks.


--


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

------- Comment #12 from hubicka at gcc dot gnu dot org  2009-11-12 23:52 -------
When we use summaries at LTO as well as on WHOPR, we get better testing
coverage for the summary streaming code, somewhat faster linktime (avoiding
need to produce them) and we should make it possible for LTO to drag in
function bodies on demand avoiding the problems with peak memory usage.
At LTO it should be possible for IPA pass to compute missing summaries when
needed, but we will need bit of infrastructure for it.

Honza


--


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

------- Comment #13 from rguenth at gcc dot gnu dot org  2009-12-10 16:03 -------
No answer, so fixed.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


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