RE: testsuite result updates for x86_64-w64-mingw32

[Tamar Christina <Tamar dot Christina at arm dot com>]

> -----Original Message-----
> From: Eric Botcazou <ebotcazou@adacore.com>
> Sent: Tuesday, January 22, 2019 11:19
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: Óscar Fuentes <ofv@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