Created attachment 55 [details] printed stacktrace I tried to compile with -flto and got an internal compiler error, even for a very simple example: file app.d: import bar; void main(string[] args){ foo(); } file bar.d: module bar; int foo() { return 0; } gdc -flto app.d bar.d (see Attachment for the stacktrace) The stacktrace in http://forum.dlang.org/thread/mailman.277.1362743197.14496.d.gnu@puremagic.com seemed to be similar... If gdc 4.8 does not support LTO or it's a bug in GCC, it may be possible to print a warning or error message instead of the stacktrace when -flto is passed to gdc. I guess all given options are read to find the D-specific ones like -frelease, so perhaps it's not much work to implement a check for -flto (?) OS: Ubuntu 12.04 Compiler Version: gdc -v Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=gdc COLLECT_LTO_WRAPPER=/opt/gdc/libexec/gcc/i686-pc-linux-gnu/4.8.2/lto-wrapper Ziel: i686-pc-linux-gnu Konfiguriert mit: ../gcc-4.8.2/configure --enable-languages=d --enable-checking=release --prefix=/opt/gdc --with-bugurl=http://gdcproject.org/bugzilla Thread-Modell: posix gcc-Version 4.8.2 (GCC) PS: in the README.md and on github the link to the wiki is still http://gdcproject.org/wiki. Could you update it to http://wiki.dlang.org/GDC ? The old link is not found anymore...
I tried to compile the example given in bug 61 and got the same error with a very similar stacktrace, so it's probably related. lto1: interner Compiler-Fehler: in streamer_get_pickled_tree, bei tree-streamer-in.c:1050 0x84dfc1f streamer_get_pickled_tree(lto_input_block*, data_in*) ../../gcc-4.8.2/gcc/tree-streamer-in.c:1049 0x84df6e4 lto_input_ts_type_common_tree_pointers ../../gcc-4.8.2/gcc/tree-streamer-in.c:768 0x84df6e4 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*) ../../gcc-4.8.2/gcc/tree-streamer-in.c:997 0x82f7ce5 lto_read_tree ../../gcc-4.8.2/gcc/lto-streamer-in.c:1015 0x82f7ce5 lto_input_tree(lto_input_block*, data_in*) ../../gcc-4.8.2/gcc/lto-streamer-in.c:1082 0x84df2bb lto_input_ts_common_tree_pointers ../../gcc-4.8.2/gcc/tree-streamer-in.c:599 0x84df2bb streamer_read_tree_body(lto_input_block*, data_in*, tree_node*) ../../gcc-4.8.2/gcc/tree-streamer-in.c:970 0x82f7ce5 lto_read_tree ../../gcc-4.8.2/gcc/lto-streamer-in.c:1015 0x82f7ce5 lto_input_tree(lto_input_block*, data_in*) ../../gcc-4.8.2/gcc/lto-streamer-in.c:1082 0x81166d6 lto_read_decls ../../gcc-4.8.2/gcc/lto/lto.c:2086 0x81166d6 lto_file_finalize ../../gcc-4.8.2/gcc/lto/lto.c:2339 0x81166d6 lto_create_files_from_ids ../../gcc-4.8.2/gcc/lto/lto.c:2349 0x81166d6 lto_file_read ../../gcc-4.8.2/gcc/lto/lto.c:2389 0x81166d6 read_cgraph_and_symbols ../../gcc-4.8.2/gcc/lto/lto.c:2964 0x81166d6 lto_main() ../../gcc-4.8.2/gcc/lto/lto.c:3375
It is indeed related. It's not immediately obvious why the LTO frontend ICE 's, but a start would be to get the library built using -flto and see if the same problem occurs.
https://github.com/D-Programming-GDC/GDC/commit/28d98308d02942984ead0cba03ff043eed26a8ad