> Hi Tristan, > > I'm building the GCC backend with Debian sources for gcc-4.9.2. > My Ada compiler is GNAT 4.9.2 and my C compiler is GCC 4.9.2.
Could you try to use GNAT GPL as Ada compiler (unless this is too much pain) ? > The "range check" issue is only about 50% reproducible. When I > repeatedly run the command to compile memory_p.vhdl on my command > line, about 50% of the time it succeeds without messages and about > 50% of the time it crashes on "range check failed" at trans-rtis.adb > line 1633. Certainly not a good news :-( > When I run GHDL within GDB, it fails 0% of the time. > If the error occurs, GHDL itself prints a stack trace in hex codes. > But I don't understand what these codes represent. They apparently > don't exist as addresses in the program; addr2line does not return > anything and GDB says it can not access the addresses. I don't > understand this, but then again I don't understand Ada. > > I can build GHDL with the LLVM backend without problems. > However, if I use the LLVM-based GHDL binary to build memory_p.vhd > with the same command-line arguments as used during the GHDL-GCC > build process, it crashes 100% of the time. It appears that the "-g" > option to GHDL triggers the error. Without "-g" the command always > succeeds, with "-g" the command always fails on range check error. Interesting, but an error within trans-rtis should be independent of the back-end (llvm or gcc). Looks like an error due to interfacing between C and Ada. Valgrind could help here. > For example: > /data/tmp/ghdl/bin/ghdl -a --ieee=none --std=93 -P../std --work=ieee > ../../src/vital2000/memory_p.vhdl > (success) > > /data/tmp/ghdl/bin/ghdl -a --ieee=none -g --std=93 -P../std > --work=ieee ../../src/vital2000/memory_p.vhdl > Message: trans-rtis.adb:1633 range check failed > Call stack traceback locations: > 0x4fbddf 0x4fc8d1 0x4fceba 0x4fedbd 0x500171 0x501735 0x5a01c4 > 0x54bf99 0x5ae0bf 0x46d79f 0x4320c6 0x7f0b3b415b43 0x431510 > 0xfffffffffffffffe > > The hex addresses in the LLVM can be translated by addr2line: > ghdl-updates-code/src/vhdl/sem_names.adb:2835 (discriminator 4) > ghdl-updates-code/src/vhdl/sem_names.adb:2969 (discriminator 4) > ghdl-updates-code/src/vhdl/sem_names.adb:3049 > ghdl-updates-code/src/vhdl/sem_names.adb:3775 (discriminator 4) > ghdl-updates-code/src/vhdl/sem_assocs.adb:214 > ghdl-updates-code/src/vhdl/sem_assocs.adb:572 (discriminator 2) > ??:0 > ??:0 > ??:0 > ghdl-updates-code/./src/vhdl/scanner-scan_literal.adb:156 > (discriminator 6) > ghdl-updates-code/src/vhdl/iirs.adb:4921 > ??:0 > ghdl-updates-code/src/vhdl/iirs.adb:4753 (discriminator 1) > ??:0 > > I know this is confusing, I'm sorry. Yes, that looks completely bogus. I will try to investigate too. Thanks! Tristan. _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
