testsuite result updates for x86_64-w64-mingw32

testsuite result updates for x86_64-w64-mingw32

[Rainer Emrich]

[-- Attachment #1.1: Type: text/plain, Size: 504 bytes --]

There are new testsuite results for x86_64-w64-mingw32, for versions
6.4.1, 7.3.1, 8.2.1 and 9.0.0.

https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02309.html
https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02310.html
https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02312.html
https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02313.html

Complete build and test logs are available for download here:
https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W

Have fun

Rainer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: testsuite result updates for x86_64-w64-mingw32

[Eric Botcazou]

> There are new testsuite results for x86_64-w64-mingw32, for versions
> 6.4.1, 7.3.1, 8.2.1 and 9.0.0.
> 
> https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02309.html
> https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02310.html
> https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02312.html

So we have an additional ACATS failure (ce2104c) in 8.2.1 over the previous 
releases?  Feel free to open a PR about it if you have a couple of minutes.

Thanks for testing the Ada compiler!

-- 
Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

[Óscar Fuentes]

Eric Botcazou <ebotcazou@adacore.com> writes:

>> There are new testsuite results for x86_64-w64-mingw32, for versions
>> 6.4.1, 7.3.1, 8.2.1 and 9.0.0.
>> 
>> https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02309.html
>> https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02310.html
>> https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02312.html
>
> So we have an additional ACATS failure (ce2104c) in 8.2.1 over the previous 
> releases?  Feel free to open a PR about it if you have a couple of minutes.
>
> Thanks for testing the Ada compiler!

About the Ada compiler: it doesn't build on i686-w64-mingw32. It is
the reason why MSYS2 is stuck with 7.3 for 32 bits.

Rainer: testing the 32 bits builds would be very useful. On MinGW there
are enough differences among 32 bits vs 64 bits to consider them two
different beasts.

Thank you for your reports so far.

Re: testsuite result updates for x86_64-w64-mingw32

[Eric Botcazou]

> About the Ada compiler: it doesn't build on i686-w64-mingw32. It is
> the reason why MSYS2 is stuck with 7.3 for 32 bits.

Why doesn't it build?  Because of PR ada/81878?

-- 
Eric Botcazou

RE: testsuite result updates for x86_64-w64-mingw32

[Tamar Christina]

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org <gcc-owner@gcc.gnu.org> On Behalf Of Eric
> Botcazou
> Sent: Thursday, October 18, 2018 16:40
> To: Óscar Fuentes <ofv@wanadoo.es>
> Cc: gcc@gcc.gnu.org
> Subject: Re: testsuite result updates for x86_64-w64-mingw32
> 
> > About the Ada compiler: it doesn't build on i686-w64-mingw32. It is
> > the reason why MSYS2 is stuck with 7.3 for 32 bits.
> 
> Why doesn't it build?  Because of PR ada/81878?

I think so, but not sure, it currently ICEs. But in order to get it to compile at all the MINGW-Packages revert the
81878 patch, this seems work for the 64 bit build but ICEs the 32 bit one.  So I hadn't looked into it because I
think it may very well be an issue due to the revert.

Regards,
Tamar

> 
> --
> Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

[Óscar Fuentes]

Eric Botcazou <ebotcazou@adacore.com> writes:

>> About the Ada compiler: it doesn't build on i686-w64-mingw32. It is
>> the reason why MSYS2 is stuck with 7.3 for 32 bits.
>
> Why doesn't it build?  Because of PR ada/81878?

xgcc crashes.

https://github.com/Alexpux/MINGW-packages/issues/4125#issuecomment-425741895

This is all I know, sorry.

Re: testsuite result updates for x86_64-w64-mingw32

[Óscar Fuentes]

Eric Botcazou <ebotcazou@adacore.com> writes:

>> About the Ada compiler: it doesn't build on i686-w64-mingw32. It is
>> the reason why MSYS2 is stuck with 7.3 for 32 bits.
>
> Why doesn't it build?  Because of PR ada/81878?

More specifically:

xgcc.exe: internal compiler error: Aborted signal terminated program gnat1

If you are interested on analyzing this problem, ask and I'll try to
help as far as my time permits.

RE: testsuite result updates for x86_64-w64-mingw32

[Tamar Christina]

Forwarding to list as well.

> -----Original Message-----
> From: Tamar Christina
> Sent: Tuesday, January 22, 2019 11:02
> To: 'Óscar Fuentes' <ofv@wanadoo.es>; Eric Botcazou
> <ebotcazou@adacore.com>
> Cc: gcc@gcc.gnu.org
> Subject: RE: testsuite result updates for x86_64-w64-mingw32
> 
> Hi Eric,
> 
> This slipped my mind, but I was taking a look at it yesterday.
> 
> 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?
> 
> Regards,
> Tamar
> 
> > -----Original Message-----
> > From: gcc-owner@gcc.gnu.org <gcc-owner@gcc.gnu.org> On Behalf Of
> Óscar
> > Fuentes
> > Sent: Thursday, October 18, 2018 20:40
> > To: Eric Botcazou <ebotcazou@adacore.com>
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: testsuite result updates for x86_64-w64-mingw32
> >
> > Eric Botcazou <ebotcazou@adacore.com> writes:
> >
> > >> About the Ada compiler: it doesn't build on i686-w64-mingw32. It is
> > >> the reason why MSYS2 is stuck with 7.3 for 32 bits.
> > >
> > > Why doesn't it build?  Because of PR ada/81878?
> >
> > More specifically:
> >
> > xgcc.exe: internal compiler error: Aborted signal terminated program
> > gnat1
> >
> > If you are interested on analyzing this problem, ask and I'll try to
> > help as far as my time permits.

Re: testsuite result updates for x86_64-w64-mingw32

[Eric Botcazou]

> 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."

I presume that the problem occurs during stage #2, i.e. that the gnat1 at 
stake has been built by the base compiler, right?

-- 
Eric Botcazou

RE: testsuite result updates for x86_64-w64-mingw32

[Tamar Christina]

> -----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

Re: testsuite result updates for x86_64-w64-mingw32

[Eric Botcazou]

> Ah, that makes sense since the 32-bit SEH is different from the 64-bit one,
> explains why the 64-bit builds work.

Which EH mechanism does the base compiler use?  The default one?  We know that 
this works with the DWARF-2 mechanism (--disable-sjlj-exceptions).

-- 
Eric Botcazou

RE: testsuite result updates for x86_64-w64-mingw32

[Tamar Christina]

> > Ah, that makes sense since the 32-bit SEH is different from the 64-bit
> > one, explains why the 64-bit builds work.
> 
> Which EH mechanism does the base compiler use?  The default one?  We
> know that this works with the DWARF-2 mechanism (--disable-sjlj-
> exceptions).

It's built with --disable-sjlj-exceptions --with-dwarf2

https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD#L150

> 
> --
> Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

[Eric Botcazou]

> It's built with --disable-sjlj-exceptions --with-dwarf2
> 
> https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD
> #L150

Then, if both the base compiler and the compiler to be built are configured 
that way, there is no reason why this cannot work.

What's a little strange is that there is a .cold part in the backtrace:

#14 0x015fd511 in uw_init_context_1.cold ()
at ../../../gcc-8-20181214/libgcc/unwind-dw2.c:1386

and this shouldn't happen for the compiler built during stage #1.  Do you add 
-O2 to the STAGE1_CFLAGS or some such?  If so, can you lower it to -O1 or -O0?

-- 
Eric Botcazou

RE: testsuite result updates for x86_64-w64-mingw32

[Tamar Christina]

> 
> Then, if both the base compiler and the compiler to be built are configured
> that way, there is no reason why this cannot work.
> 
> What's a little strange is that there is a .cold part in the backtrace:
> 
> #14 0x015fd511 in uw_init_context_1.cold () at ../../../gcc-8-
> 20181214/libgcc/unwind-dw2.c:1386
> 
> and this shouldn't happen for the compiler built during stage #1.  Do you add
> -O2 to the STAGE1_CFLAGS or some such?  If so, can you lower it to -O1 or -
> O0?

I don't see it being set from the PKGBUILD but I'll double check when I get back tonight and reply.
I don't have the builddir available atm.

Thanks,
Tamar

> 
> --
> Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

[Tamar Christina]

Hi Eric,

So looking at it again, this seems to be happening during stage3.

And there aren't any special flags being set.

Regards,
Tamar
________________________________________
From: Eric Botcazou <ebotcazou@adacore.com>
Sent: Tuesday, January 22, 2019 12:23 PM
To: Tamar Christina
Cc: gcc@gcc.gnu.org; Óscar Fuentes; nd
Subject: Re: testsuite result updates for x86_64-w64-mingw32

> It's built with --disable-sjlj-exceptions --with-dwarf2
>
> https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD
> #L150

Then, if both the base compiler and the compiler to be built are configured
that way, there is no reason why this cannot work.

What's a little strange is that there is a .cold part in the backtrace:

#14 0x015fd511 in uw_init_context_1.cold ()
at ../../../gcc-8-20181214/libgcc/unwind-dw2.c:1386

and this shouldn't happen for the compiler built during stage #1.  Do you add
-O2 to the STAGE1_CFLAGS or some such?  If so, can you lower it to -O1 or -O0?

--
Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

[Eric Botcazou]

> So looking at it again, this seems to be happening during stage3.

Yes, I should have realized it a while ago, you don't compile g-exptty.adb for 
the compiler but only for the runtime...  The backtrace seems to show that the 
abort at libgcc/unwind-dw2.c:1386 is raised:

  int size = dwarf_reg_size_table[__builtin_dwarf_sp_column ()];

  if (size == sizeof(_Unwind_Ptr))
    tmp_sp->ptr = (_Unwind_Ptr) cfa;
  else
    {
      gcc_assert (size == sizeof(_Unwind_Word));
      tmp_sp->word = (_Unwind_Ptr) cfa;
    }

which is quite unexpected.

-- 
Eric Botcazou