On Thursday, 22 August 2013 at 19:19:08 UTC, Timo Sintonen wrote:
On Thursday, 22 August 2013 at 15:11:15 UTC, Johannes Pfau
wrote:
Am Tue, 20 Aug 2013 18:40:09 +0200
schrieb "Timo Sintonen" <t.sinto...@luukku.com>:
I just updated my arm cross compiler to the latest head of
gdc and gcc. Now I get this every time when I try to compile
a file that has a class:
internal compiler error: Segmentation fault
0x99b39f crash_signal
../../gcc/gcc/toplev.c:335
0x8413ec tree_check
../../gcc/gcc/tree.h:3689
0x8413ec get_odr_type(tree_node*, bool)
../../gcc/gcc/ipa-devirt.c:263
0x841ac2 build_type_inheritance_graph()
../../gcc/gcc/ipa-devirt.c:360
0x6b6e21 analyze_functions
../../gcc/gcc/cgraphunit.c:854
0x6b8285 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2151
0x5fe5b4 d_write_global_declarations
../../gcc/gcc/d/d-lang.cc:619
This occurs every time in the last line of the last function
in a class, no matter what the line or the function contains.
Is this a bug in gdc or gcc or just in my system?
This is strange. I haven't built a cross compiler recently but
this
does not seem to be cross-compiler specific. I've built a
recent native
ARM compiler and can't reproduce this.
Yes, it seems not to be arm related. I tried to build a native
compiler for normal Intel/pc/64-bit with the same result. I can
compile both native and cross compiler with c and c++ only and
install them and use them. The D compiler compiles fine without
the library but as soon as there is a d class, I get this error.
The problem may be related to 64 bit linux. If I had something
wrong im my system or there would be a bug in gcc, I think I
could not be able to compile a c++ compiler.
I installed a totally new system (Slackware Linux 64 bit) and
took the latest heads of gcc and gdc. The problem is still the
same. Then I took 4.8.1 gcc and 4.8 gdc and everything is ok with
them. Then I tested mixing. It seems it is still possible to mix
gcc 4.8 with gdc 4.9 and gcc 4.9 with gdc 4.8. These will compile
fine but I have no idea how they would behave in real work.
Anyway in all cases gcc 4.8.1 works and gcc 4.9 does not, so this
may be a gcc issue. I just wonder if gcc has such kind of code
that only a d program triggers this error.
