> -----Original Message----- > From: Eric Botcazou <ebotca...@adacore.com> > Sent: Tuesday, January 22, 2019 11:19 > To: Tamar Christina <tamar.christ...@arm.com> > Cc: Óscar Fuentes <o...@wanadoo.es>; gcc@gcc.gnu.org > Subject: Re: testsuite result updates for x86_64-w64-mingw32 > > > The gnat1 command that fails is > > > > mingw-w64-gcc/src/build-i686-w64-mingw32/gcc/gnat1.exe -gnatwa -quiet > > -nostdinc -dumpbase g-exptty.adb -auxbase-strip g-exptty.o -O2 -Wextra > > -Wall -g -gnatpg -mtune=generic -march=i686 -gnatO g-exptty.o > > g-exptty.adb -o E:\msys32-devel\tmp\ccAujHCD.s > > > > I attached gdb and set set env ADA_INCLUDE_PATH and it seems to not be > > able to find some file but segfaults when printing the error, so I'm > > guessing there's a heap corruption somewhere. > > > > The full stack trace is > > https://gist.github.com/Mistuke/a62d45337f7515f5f4725fcff1c93395 > > > > It seem to not be able to find s-reldel.ads? Any tips on how to debug this? > > The file is not in the source tree so the failure is expected. In this case, > Rtsfind.Load_Fail raises an exception which should be caught in the caller. > > The big difference between GCC 7 and GCC 8 here is documented on: > https://gcc.gnu.org/gcc-8/changes.html > > "For its internal exception handling used on the host for error recovery in > the > front-end, the compiler now relies on the native exception handling > mechanism of the host platform, which should be more efficient than the > former mechanism."
Ah, that makes sense since the 32-bit SEH is different from the 64-bit one, explains why the 64-bit builds work. > I presume that the problem occurs during stage #2, i.e. that the gnat1 at > stake has been built by the base compiler, right? Yeah, it's during stage2. Regards, Tamar. > -- > Eric Botcazou
