[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Iain Sandoe  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #67 from Iain Sandoe  ---
so fixed on open branches, needed on at least 8.x / 9.x for vendor branches.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #66 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:bf41b26f5891c6ce3b1ffe41d3736a566db02390

commit r10-10795-gbf41b26f5891c6ce3b1ffe41d3736a566db02390
Author: Iain Sandoe 
Date:   Sat Sep 18 23:38:53 2021 +0100

Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality.  The patch
replaces
several work-arounds with a fix for PR80556 and a work-around for PR88590.

* The fix for PR80556 requires a bump to the SO name for libgcc_s, since we
need to remove the unwinder symbols from it.  This would trigger PR88590
hence the work-around for that.

* We weaken the symbols for emulated TLS support so that it is possible
for a DSO linked with static-libgcc to interoperate with a DSO linked with
libgcc_s.  Likewise main exes.

* We remove all the gcc-4.2.1 era stubs machinery and workarounds.

* libgcc is always now linked ahead of libc, which avoids fails where the
libc (libSystem) builtins implementations are not up to date.

* The unwinder now always comes from the system
 - for Darwin9 from /usr/lib/libgcc_s.1.dylib
 - for Darwin10 from /usr/lib/libSystem.dylib
 - for Darwin11+ from /usr/lib/system/libunwind.dylib.

 We still insert a shim on Darwin10 to fix an omitted unwind function, but
 the underlying unwinder remains the system one.

* The work-around for PR88590 has two parts (1) we always link libgcc from
its convenience lib on affected system versions (avoiding the need to find
the DSO path); (2) we add and export the emutls functions from DSOs - this
makes a relatively small (20k) addition to a DSO.  These can be backed out
when a proper fix for PR88590 is committed.

For distributions that wish to install a libgcc_s.1.dylib to satisfy
linkage
from exes that linked against the stubs can use a reexported libgcc_s.1.1
(since that contains all the symbols that were previously exported via the
 stubs).

The replacement libgcc_s.1 forwards the symbols from the new SO.
In order to support DYLD_LIBRARY_PATH on systems (where it works)
we forward the libSystem unwinder symbols from 10.7+ and a
compiler-local version of the libgcc unwinder on earlier.

For macOS 10.4 to 10.6 this is 'bug-compatible' with existing uses.
For 10.7+ the behaviour will now actually be correct.

Backported from commits d4943ce939d9654932624b9ece24c3a474ae4157,
7add7f7bb3d35726a0c45322ffdbbab2bbf6a348,
b504917e43b9a559c9ac779e08784ad412125f2e,
32731fa5b0abf092029b8e2be64319b978bda514,
574c09da48a5a0ff4c32dd4577eaf65bac8c94a0 and
c18ddb05b0391a397f8882fc6a12a1bab7e0df52

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

PR target/80556
* config/darwin-driver.c (darwin_driver_init): Handle exported
symbols and symbol lists (suppress automatic export of the TLS
symbols).
* config/darwin.c (darwin_rename_builtins): Remove workaround.
* config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise.
(REAL_LIBGCC_SPEC): Handle revised library uses.
* config/darwin.opt (nodefaultexport): New.
* config/i386/darwin.h (PR80556_WORKAROUND): Remove.
* config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise.
* config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise.

libgcc/ChangeLog:

* config.host: Add weak emutls crt to the extra_parts.
(*-*-darwin*): Add logic to build a shared unwinder library for
Darwin8-10.  Add shim declaration header to powerpc*-darwin builds.
* config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove
workaround.
* config/libgcc-libsystem.ver: Add exclude list for the system-
provided unwinder.
* config/t-slibgcc-darwin: Bump SO version, remove stubs code.
Build a legacy libgcc_s.1 and the supporting pieces (all FAT libs).
* config/t-darwin-ehs: Add dependencies to the shared unwinder
objects.  Add dependency on unwind.h.
* config/t-darwin: Reorganise the EH fragments to place them for
inclusion in a shared EH lib.  Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-enc-func.
* config/i386/libgcc-darwin.10.4.ver: Removed.
* config/i386/libgcc-darwin.10.5.ver: Removed.
* config/rs6000/libgcc-darwin.10.4.ver: Removed.
* config/rs6000/libgcc-darwin.10.5.ver: Removed.
* config/i386/t-darwin: Build legacy libgcc_s.1.
* config/rs6000/t-darwin: Likewise.
* config/rs6000/t-darwin-ehs: Remove dependency on 

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #65 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:94c9c6acdc14de186abe4ea59c54920fbfb60beb

commit r11-9878-g94c9c6acdc14de186abe4ea59c54920fbfb60beb
Author: Iain Sandoe 
Date:   Sat Sep 18 23:38:53 2021 +0100

Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality.  The patch
replaces
several work-arounds with a fix for PR80556 and a work-around for PR88590.

* The fix for PR80556 requires a bump to the SO name for libgcc_s, since we
need to remove the unwinder symbols from it.  This would trigger PR88590
hence the work-around for that.

* We weaken the symbols for emulated TLS support so that it is possible
for a DSO linked with static-libgcc to interoperate with a DSO linked with
libgcc_s.  Likewise main exes.

* We remove all the gcc-4.2.1 era stubs machinery and workarounds.

* libgcc is always now linked ahead of libc, which avoids fails where the
libc (libSystem) builtins implementations are not up to date.

* The unwinder now always comes from the system
 - for Darwin9 from /usr/lib/libgcc_s.1.dylib
 - for Darwin10 from /usr/lib/libSystem.dylib
 - for Darwin11+ from /usr/lib/system/libunwind.dylib.

 We still insert a shim on Darwin10 to fix an omitted unwind function, but
 the underlying unwinder remains the system one.

* The work-around for PR88590 has two parts (1) we always link libgcc from
its convenience lib on affected system versions (avoiding the need to find
the DSO path); (2) we add and export the emutls functions from DSOs - this
makes a relatively small (20k) addition to a DSO.  These can be backed out
when a proper fix for PR88590 is committed.

For distributions that wish to install a libgcc_s.1.dylib to satisfy
linkage
from exes that linked against the stubs can use a reexported libgcc_s.1.1
(since that contains all the symbols that were previously exported via the
 stubs).

The replacement libgcc_s.1 forwards the symbols from the new SO.
In order to support DYLD_LIBRARY_PATH on systems (where it works)
we forward the libSystem unwinder symbols from 10.7+ and a
compiler-local version of the libgcc unwinder on earlier.

For macOS 10.4 to 10.6 this is 'bug-compatible' with existing uses.
For 10.7+ the behaviour will now actually be correct.

Backported from commits d4943ce939d9654932624b9ece24c3a474ae4157,
7add7f7bb3d35726a0c45322ffdbbab2bbf6a348,
b504917e43b9a559c9ac779e08784ad412125f2e,
32731fa5b0abf092029b8e2be64319b978bda514,
574c09da48a5a0ff4c32dd4577eaf65bac8c94a0 and
c18ddb05b0391a397f8882fc6a12a1bab7e0df52

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

PR target/80556
* config/darwin-driver.c (darwin_driver_init): Handle exported
symbols and symbol lists (suppress automatic export of the TLS
symbols).
* config/darwin.c (darwin_rename_builtins): Remove workaround.
* config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise.
(REAL_LIBGCC_SPEC): Handle revised library uses.
* config/darwin.opt (nodefaultexport): New.
* config/i386/darwin.h (PR80556_WORKAROUND): Remove.
* config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise.
* config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise.

libgcc/ChangeLog:

* config.host: Add weak emutls crt to the extra_parts.
(*-*-darwin*): Add logic to build a shared unwinder library for
Darwin8-10.  Add shim declaration header to powerpc*-darwin builds.
* config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove
workaround.
* config/libgcc-libsystem.ver: Add exclude list for the system-
provided unwinder.
* config/t-slibgcc-darwin: Bump SO version, remove stubs code.
Build a legacy libgcc_s.1 and the supporting pieces (all FAT libs).
* config/t-darwin-ehs: Add dependencies to the shared unwinder
objects.  Add dependency on unwind.h.
* config/t-darwin: Reorganise the EH fragments to place them for
inclusion in a shared EH lib.  Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-enc-func.
* config/i386/libgcc-darwin.10.4.ver: Removed.
* config/i386/libgcc-darwin.10.5.ver: Removed.
* config/rs6000/libgcc-darwin.10.4.ver: Removed.
* config/rs6000/libgcc-darwin.10.5.ver: Removed.
* config/i386/t-darwin: Build legacy libgcc_s.1.
* config/rs6000/t-darwin: Likewise.
* config/rs6000/t-darwin-ehs: Remove dependency on 

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #64 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:d4943ce939d9654932624b9ece24c3a474ae4157

commit r12-5418-gd4943ce939d9654932624b9ece24c3a474ae4157
Author: Iain Sandoe 
Date:   Mon Sep 20 18:41:56 2021 +0100

Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality.  The patch
replaces
several work-arounds with a fix for PR80556 and a work-around for PR88590.

* The fix for PR80556 requires a bump to the SO name for libgcc_s, since we
need to remove the unwinder symbols from it.  This would trigger PR88590
hence the work-around for that.

* We weaken the symbols for emulated TLS support so that it is possible
for a DSO linked with static-libgcc to interoperate with a DSO linked with
libgcc_s.  Likewise main exes.

* We remove all the gcc-4.2.1 era stubs machinery and workarounds.

* libgcc is always now linked ahead of libc, which avoids fails where the
libc (libSystem) builtins implementations are not up to date.

* The unwinder now always comes from the system
 - for Darwin9 from /usr/lib/libgcc_s.1.dylib
 - for Darwin10 from /usr/lib/libSystem.dylib
 - for Darwin11+ from /usr/lib/system/libunwind.dylib.

 We still insert a shim on Darwin10 to fix an omitted unwind function, but
 the underlying unwinder remains the system one.

* The work-around for PR88590 has two parts (1) we always link libgcc from
its convenience lib on affected system versions (avoiding the need to find
the DSO path); (2) we add and export the emutls functions from DSOs - this
makes a relatively small (20k) addition to a DSO.  These can be backed out
when a proper fix for PR88590 is committed.

For distributions that wish to install a libgcc_s.1.dylib to satisfy
linkage
from exes that linked against the stubs can use a reexported libgcc_s.1.1
(since that contains all the symbols that were previously exported via the
 stubs).

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

PR target/80556
* config/darwin-driver.c (darwin_driver_init): Handle exported
symbols and symbol lists (suppress automatic export of the TLS
symbols).
* config/darwin.c (darwin_rename_builtins): Remove workaround.
* config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise.
(REAL_LIBGCC_SPEC): Handle revised library uses.
* config/darwin.opt (nodefaultexport): New.
* config/i386/darwin.h (PR80556_WORKAROUND): Remove.
* config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise.
* config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise.

libgcc/ChangeLog:

* config.host: Add weak emutls crt to the extra_parts.
* config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove
workaround.
* config/libgcc-libsystem.ver: Add exclude list for the system-
provided unwinder.
* config/t-slibgcc-darwin: Bump SO version, remove stubs code.
* config/i386/libgcc-darwin.10.4.ver: Removed.
* config/i386/libgcc-darwin.10.5.ver: Removed.
* config/rs6000/libgcc-darwin.10.4.ver: Removed.
* config/rs6000/libgcc-darwin.10.5.ver: Removed.
* config/t-darwin-noeh: New file.

gcc/testsuite/ChangeLog:

* gcc.dg/torture/fp-int-convert-timode-3.c: Remove XFAIL.
* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Iain Sandoe  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #63 from Iain Sandoe  ---
I'm reopening this because
(a) the fix applied was a work-around and it's time to fix the Darwin unwinder
hassles properly
(b) it regresses gcc.dg/torture/fp-int-convert-timode-3.c  to place libSystem()
in front of libgcc.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #62 from Iain Sandoe  ---
Author: iains
Date: Sun May 19 16:03:17 2019
New Revision: 271381

URL: https://gcc.gnu.org/viewcvs?rev=271381=gcc=rev
Log:
darwin - fix PR86215 by backporting 80556.

The backport had been missed.

2019-01-03  Iain Sandoe  

PR target/86215
Backport from mainline
2017-09-25  Iain Sandoe  

PR target/80556
* config/i386/darwin.h (REAL_LIB_SPEC): New; put libSystem ahead
of libgcc_eh for m64.
* config/i386/darwin64.h: Likewise.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/darwin.h
branches/gcc-7-branch/gcc/config/i386/darwin64.h

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #61 from Eric Botcazou  ---
Nice work, thanks!  But I'm sure the next Darwin crisis is already looming. ;-)

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Iain Sandoe  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #60 from Iain Sandoe  ---
so fixed

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #59 from Iain Sandoe  ---
Author: iains
Date: Mon Sep 25 08:47:41 2017
New Revision: 253137

URL: https://gcc.gnu.org/viewcvs?rev=253137=gcc=rev
Log:
[Patch, Darwin] Fix PR80556 by linking the system unwinder ahead of libgcc_eh.

PR target/80556
* config/i386/darwin.h (REAL_LIB_SPEC): New; put libSystem ahead
of libgcc_eh for m64.
* config/i386/darwin64.h: Likewise.

/* WORKAROUND pr80556:
   For x86_64 Darwin10 and later, the unwinder is in libunwind (redirected
   from libSystem).  This doesn't use the keymgr (see keymgr.c) and therefore
   the calls that libgcc makes to obtain the KEYMGR_GCC3_DW2_OBJ_LIST are not
   updated to include new images, and might not even be valid for a single
   image.
   Therefore, for 64b exes at least, we must use the libunwind implementation,
   even when static-libgcc is specified.  We put libSystem first so that
   unwinder symbols are satisfied from there. 



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h
trunk/gcc/config/i386/darwin64.h

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #58 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #57 from Iain Sandoe  ---
[...]
>> Now running an i386-apple-darwin11.4.2 bootstrap, which will take
>> another day.

> Dominique reported OK on Darwin16 and Darwin10 on irc, so I think if the i386
> bootstrap is successful - this should be good to go (for now)

It just did complete successfully, so the patch is good to go, I believe.

Thanks.
Rainer

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #57 from Iain Sandoe  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #56)
> > --- Comment #55 from simon at pushface dot org ---
> > (In reply to Iain Sandoe from comment #54)
> >
> >> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if
> >> folks could check it out.
> >
> > bootstrapped r252935 on 10.11.6:
> [...]
> 
> Same here on x86_64-apple-darwin11.4.2 (all languages), where I replaced
> Simon's previous workaround with your patch.
> 
> Now running an i386-apple-darwin11.4.2 bootstrap, which will take
> another day.

thanks all!

Dominique reported OK on Darwin16 and Darwin10 on irc, so I think if the i386
bootstrap is successful - this should be good to go (for now)

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #56 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #55 from simon at pushface dot org ---
> (In reply to Iain Sandoe from comment #54)
>
>> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if
>> folks could check it out.
>
> bootstrapped r252935 on 10.11.6:
[...]

Same here on x86_64-apple-darwin11.4.2 (all languages), where I replaced
Simon's previous workaround with your patch.

Now running an i386-apple-darwin11.4.2 bootstrap, which will take
another day.

Rainer

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #55 from simon at pushface dot org ---
(In reply to Iain Sandoe from comment #54)

> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if
> folks could check it out.

bootstrapped r252935 on 10.11.6:

=== gnat Summary ===

# of expected passes2604
# of unexpected failures1
# of expected failures  24
# of unsupported tests  7

=== acats Summary ===
# of expected passes2320
# of unexpected failures0

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #41651|0   |1
is obsolete||

--- Comment #54 from Iain Sandoe  ---
Created attachment 42198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42198=edit
workaround patch

This is a workaround, to avoid Ada bootstrap breakage.

what should happen:

 - for x86-64 (m64) Darwin we should get -lSystem -lgcc_eh -lgcc -lSystem (thus
picking up the unwinder from libSystem=>libunwind.

 - for x86 (m32) we should get -lgcc_eh -lgcc -lSystem which links the unwinder
from libgcc_eh (as before).

So, the first case works around the unusable unwinder in m64 libgcc and the
second case preserves the status quo for m32.

you should be able to confirm this with some trivial code using the unwinder,
linked -static-libgcc:

(m32)

$ DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./t 2>&1 |grep _Un


(m64)

$ DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./t 2>&1 |grep _Un
dyld: lazy bind: t:0x1044D1080 = libunwind.dylib:__Unwind_RaiseException,
*0x1044D1080 = 0x7FFF8F975918
dyld: lazy bind: t:0x1044D1068 =
libunwind.dylib:__Unwind_GetLanguageSpecificData, *0x1044D1068 = 0x7FFF8F9763D0
dyld: lazy bind: t:0x1044D1070 = libunwind.dylib:__Unwind_GetRegionStart,
*0x1044D1070 = 0x7FFF8F9763F3
dyld: lazy bind: t:0x1044D1060 = libunwind.dylib:__Unwind_GetIPInfo,
*0x1044D1060 = 0x7FFF8F97A266
dyld: lazy bind: t:0x1044D1098 = libunwind.dylib:__Unwind_SetGR, *0x1044D1098 =
0x7FFF8F9765A0
dyld: lazy bind: t:0x1044D10A0 = libunwind.dylib:__Unwind_SetIP, *0x1044D10A0 =
0x7FFF8F976760
dyld: lazy bind: t:0x1044D1050 = libunwind.dylib:__Unwind_DeleteException,
*0x1044D1050 = 0x7FFF8F9767F1

===

I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if
folks could check it out.

Haven't tried an i386 bootstrap.

===

As per comment #20, we really need to rationalise our libgcc/crts to suit the
range of use-cases.  I've started rebasing the patches for this...

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #53 from Iain Sandoe  ---
(In reply to Eric Botcazou from comment #52)
> > Yes, that's expected at present.
> > a. there's evidently some more EH breakage caused by the
> > reorder-and-partition (see 81733)
> > b. the libgcc unwinder seems to have some issues even on systems that should
> > support it
> > c. we need to do some checking on the availability of the kernel call to
> > fetch the FDEs and setup the specs accordingly.
> 
> IMO a. and b. are not top priority, we should first restore Ada bootstrap on
> recent Darwins with the system unwinder.

it would seem that the partitioning is still part of the issue (81733 isn't
completely fixed by the patch for 81361).  We just don't know what other ways
it might manifest.

> >  -static-libstdc++ is a workaround (actually, all it's really doing is
> > overriding the -static-libgcc).
> 
> Yes, -static-libgcc is the problem on Darwin.

So, we can hack around the problems with;
1) temporarily disable the partitioning
2) force libSystem ahead of libgcc_eh for Darwin >= 10
 - this second one would ideally be for m64 only.

 will experiment with some specs fixes later.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #52 from Eric Botcazou  ---
> Yes, that's expected at present.
> a. there's evidently some more EH breakage caused by the
> reorder-and-partition (see 81733)
> b. the libgcc unwinder seems to have some issues even on systems that should
> support it
> c. we need to do some checking on the availability of the kernel call to
> fetch the FDEs and setup the specs accordingly.

IMO a. and b. are not top priority, we should first restore Ada bootstrap on
recent Darwins with the system unwinder.

>  -static-libstdc++ is a workaround (actually, all it's really doing is
> overriding the -static-libgcc).

Yes, -static-libgcc is the problem on Darwin.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #51 from Iain Sandoe  ---
(In reply to Rainer Orth from comment #10)
> Interestingly, a i386-apple-darwin16 bootstrap *does* work fine.

That's because the keymgr does work for m32 binaries.
It's never kept track of images for x86_64 (from 10.6+, anyway) I'm not sure if
/ when last I ever tried a static linked libgcc on m64.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #50 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #49)
> The patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html is
> still needed after revision r252914 (fix for pr81361).

Yes, that's expected at present.
a. there's evidently some more EH breakage caused by the reorder-and-partition
(see 81733)
b. the libgcc unwinder seems to have some issues even on systems that should
support it
c. we need to do some checking on the availability of the kernel call to fetch
the FDEs and setup the specs accordingly.

 -static-libstdc++ is a workaround (actually, all it's really doing is
overriding the -static-libgcc).

IMO we need to get to the bottom of the various breakages, and preferably fix
them properly - rather than applying a band-aid patch to place libSystem ahead
of libgcc_eh.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #49 from Dominique d'Humieres  ---
The patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html is still
needed after revision r252914 (fix for pr81361).

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #48 from Iain Sandoe  ---
(In reply to simon from comment #46)
> I posted my darwin.h patch at
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html on 1 September -
> hasn’t attracted any notice yet.

Thanks for the patch Simon, and apologies that no-one has reviewed it yet.

I am trying to catch up on the state of this (and other pending Darwin issues).

As it is, the patch needs some more work, since the unwinder needs to come from
different places in different versions of Darwin.  As I read it, you've made
the change unconditional which will most likely break earlier Darwin versions.

Currently, I'm trying to reproduce the various issues, and will have some
suggestions for amendment of the patch once I can get Ada to bootstrap.  Once
that's happening, I'll reply to the @patches post.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #47 from Dominique d'Humieres  ---
This PR is "fixed" by applying the patch at
  https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html
on top of revision r251529. However it does not fix pr82141.

> I posted my darwin.h patch at
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html
> on 1 September - hasn’t attracted any notice yet.

May be PING for it.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #46 from simon at pushface dot org ---
I posted my darwin.h patch at
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html on 1 September -
hasn’t attracted any notice yet.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #45 from Eric Botcazou  ---
*** Bug 82141 has been marked as a duplicate of this bug. ***

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #44 from Jeffrey A. Law  ---
So coming back to this.  Thanks for outlining the key specs.

So link_gcc_c_sequence doesn't pull in -lSystem because of -static-libgcc, but
it does appear (after -lgcc_eh -lgcc) because of of the %lib spec which only
avoids -lSystem if -static was specified, but not -static-libgcc.


Fixing the specs seems preferable to me over the original patch. 

It'd be ideal if we could get someone with Darwin expertise to chime in on your
patch to REAL_LIBGCC_SPEC as a second opinion -- I'm just not qualified enough
in any aspects of Darwin to give a final ACK here.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #43 from simon at pushface dot org ---
Created attachment 41651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41651=edit
Patch to gcc/config/darwin.h

Following up on a comment from Jeff Law on gcc-patches@, I replied as
follows (it didn't appear on the archive, so I've re-sent)

> I'm a bit confused here.  Isn't -lSystem included in darwin's
> LIB_SPEC in which case the right things ought to already be
> happening, shouldn't it?

The specs that involve -lSystem are

*link_gcc_c_sequence:
%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind)   
%{!static:%{!static-libgcc:   %:version-compare(>= 10.6
mmacosx-version-min= -lSystem) } }   
%{fno-pic|fno-PIC|fno-pie|fno-PIE|fapple-kext|mkernel|static|mdynamic-no-pic:  
%:version-compare(>= 10.7 mmacosx-version-min= -no_pie) } %G %L

*lib:
%{!static:-lSystem}

but I also see

*libgcc:
%{static-libgcc|static: -lgcc_eh -lgcc; 

which might be the root of the problem?

In comment 39, I report that

   $ gnatmake raiser -largs -static-libgcc -static-libstdc++

resulted in the link command

   /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0
   -weak_reference_mismatches non-weak -o raiser -L./
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o
   ./raiser.o -v
   /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a
   -no_compact_unwind -lgcc_eh -lgcc -lSystem

i.e. -lSystem is *after* -lgcc, so that its exception handling won't
be invoked.

I don't know what -lgcc_eh does, but my patch would be pretty much
equivalent to changing the libgcc spec above to

*libgcc:
%{static-libgcc|static: -lSystem -lgcc_eh -lgcc; 

and if that would be OK it would obviously be much better.

I've rebuilt gcc-8-20170528 with this, successfully; the last line of
the raiser.adb link command above becomes

   -no_compact_unwind -lSystem -lgcc_eh -lgcc -lSystem

and the exception is properly handled.

Patch attached.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Just for the record: at r249012 (i.e. before the patches causing PR
bootstrap/81033), I managed to successfully bootstrap
x86_64-apple-darwin16.6.0, x86_64-apple-darwin11.4.2, and
i386-apple-darwin11.4.2.

Thanks.
Rainer

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

simon at pushface dot org changed:

   What|Removed |Added

  Attachment #41520|0   |1
is obsolete||

--- Comment #41 from simon at pushface dot org ---
Created attachment 41531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41531=edit
Patch (3) to top-level configure.ac, configure

(In reply to r...@cebitec.uni-bielefeld.de from comment #40)
> > --- Comment #39 from simon at pushface dot org ---
> [...]
> > Updated patch posted here; working on gcc-patches@ submission.
> 
> Thanks for the analysis and the patch.  I'll give it a whirl once PR
> bootstrap/81033 is resolved.
> 
> One nit for actual submission: your current patch contains lots of
> unrelated changes, removing trailing whitespace.  While that is fine in
> itself, please move it to a separate patch.

Oops, sorry about that.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #39 from simon at pushface dot org ---
[...]
> Updated patch posted here; working on gcc-patches@ submission.

Thanks for the analysis and the patch.  I'll give it a whirl once PR
bootstrap/81033 is resolved.

One nit for actual submission: your current patch contains lots of
unrelated changes, removing trailing whitespace.  While that is fine in
itself, please move it to a separate patch.

Thanks.
Rainer

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

simon at pushface dot org changed:

   What|Removed |Added

  Attachment #41474|0   |1
is obsolete||

--- Comment #39 from simon at pushface dot org ---
Created attachment 41520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41520=edit
Patch (2) to top-level configure.ac, configure

The notes on -shared-libgcc at
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html say

   However, if a library or main executable is supposed to throw or
   catch exceptions, you must link it using the G++ driver, as
   appropriate for the languages used in the program, or using the
   option -shared-libgcc, such that it is linked with the shared
   libgcc.

This seems not to be true for Linux (Debian Jessie) but is definitely
true for Darwin. If, using GCC 7.1.0, we build

   with Ada.Text_IO; use Ada.Text_IO;
   procedure Raiser is
   begin
  begin
 raise Program_Error;
  exception
 when others =>
Put_Line ("caught it");
  end;
   end Raiser;

with

   $ gnatmake raiser -largs -static-libgcc -static-libstdc++

then

   $ ./raiser
   Illegal instruction: 4

The actual ld invocation was

   /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0
   -weak_reference_mismatches non-weak -o raiser -L./
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o
   ./raiser.o -v
   /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a
   -no_compact_unwind -lgcc_eh -lgcc -lSystem

This PR was raised because of a mishandled exception raised by
Rtsfind.Load_Fail while processing g-exptty.adb. g-exptty.adb had been
updated on 2017-04-25 (but so had a lot of other parts of GNAT). Since
a lot of other compilations had been performed successfully by this
point, one may assume that this was the first that actually caused an
exception.

Comment 14 works because --with-boot-ldflags=-static-libstdc++ means
that the default boot-ldflags (-static-libgcc -static-libstdc++) is
overridden, so that libgcc defaults to being shared (and
-static-libstdc++ is ignored, as per comment 25, resulting in the
stage 2 problems in comment 5, comment 24).

Following the suggestion on comment 22 (put -lSystem before -lgcc),
I've tried gcc-8-20170528 with

   --with-stage1-ldflags='-lSystem -static-libgcc -static-libstdc++'
   --with-boot-ldflags='-lSystem -static-libgcc -static-libstdc++'

AND IT WORKS (on macOS Sierra, Debian jessie).

Changing the command line above to the equivalent

   $ gnatmake raiser -largs -lSystem -static-libgcc -static-libstdc++

results in the ld invocation

   /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0
   -weak_reference_mismatches non-weak -o raiser -L./
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o
   ./raiser.o -lSystem -v
   /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a
   -no_compact_unwind -lgcc_eh -lgcc -lSystem

and

   $ ./raiser
   caught it

Updated patch posted here; working on gcc-patches@ submission.



I'd like to point out that even if gnat1 hadn't failed, building GNAT
tools without shared libgcc results in failures as in PR61027; but
they only affect users of the tools, not the bootstrap.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #38 from Eric Botcazou  ---
> I’ve worked out a patch and bootstrapped (see attachment). The patch is 
> against the gcc-8-20170558 snapshot, would that be OK?

I'm no Darwin specialist so I cannot really comment, but my understanding is
that it cannot make things worse...  Please post it on gcc-patches@ if you
don't mind.

In any case, thanks for stepping in here.

> One thing I’m not sure of is what versions of Darwin this applies to. I’ve
> tested for *-apple-darwin*.

The Darwin maintainers will probably enlighten once they see the patch.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #37 from simon at pushface dot org ---
Created attachment 41474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41474=edit
Patch to top-level configure.ac, configure

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #36 from simon at pushface dot org ---
(In reply to Eric Botcazou from comment #35)

> The workaround is to filter out -static-libgcc in configure.ac on Darwin but
> to leave -static-libstdc++, so why is it still looking for the shared
> libstdc++?

Because (as in comment 25) g++ linking on Darwin silently ignores 
-static-libstdc++ (if it sees -shared-libgcc). I've verified this 
with a C++ "hello world".

This PR is labelled 'target', is that right?

I’ve worked out a patch and bootstrapped (see attachment). The patch is 
against the gcc-8-20170558 snapshot, would that be OK?

One thing I’m not sure of is what versions of Darwin this applies to. I’ve
tested for *-apple-darwin*.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #35 from Eric Botcazou  ---
> When I tried the workaround, I got
> 
> /var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc
> -B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/
> -B/vol/gcc/x86_64-apple-darwin11.4.2/bin/
> -B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem
> /vol/gcc/x86_64-apple-darwin11.4.2/include -isystem
> /vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W
> -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o
> dyld: Symbol not found: __ZdaPvm
>   Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
>   Expected in: /usr/lib/libstdc++.6.dylib
>  in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
> xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1)

The workaround is to filter out -static-libgcc in configure.ac on Darwin but to
leave -static-libstdc++, so why is it still looking for the shared libstdc++?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #34 from simon at pushface dot org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #31)
> When I tried the workaround, I got
> 
> /var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc
> -B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/
> -B/vol/gcc/x86_64-apple-darwin11.4.2/bin/
> -B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem
> /vol/gcc/x86_64-apple-darwin11.4.2/include -isystem
> /vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W
> -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o
> dyld: Symbol not found: __ZdaPvm
>   Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
>   Expected in: /usr/lib/libstdc++.6.dylib
>  in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
> xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1)

From previous experience building *with* shared libraries (because of 
pr61027 comment 4), when dyld loads the tools (code generators, gnat1, 
gnatbind) it looks for libstdc++ under $prefix, doesn't find it because 
it's not installed yet, tries the system libstdc++, fails because of 
that missing symbol.
libgcc_s doesn’t appear to have the same issue.

e.g.
build/genmddeps ../../gcc-8-20170528/gcc/common.md
../../gcc-8-20170528/gcc/config/i386/i386.md > tmp-mddeps
build/genmodes -h > tmp-modes.h
dyld: Symbol not found: __ZdlPvm
  Referenced from:
/Volumes/Miscellaneous/tmp/gcc-8-20170528-build/gcc/build/genmddeps (which was
built for Mac OS X 10.12)
  Expected in: /usr/lib/libstdc++.6.dylib
 in /Volumes/Miscellaneous/tmp/gcc-8-20170528-build/gcc/build/genmddeps

I temporarily install the just-built libraries under $prefix/lib and
reconfigure, rebuild. Might be possible to work some DYLD_LIBRARY_PATH
magic

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---
   Severity|blocker |major

--- Comment #33 from Eric Botcazou  ---
> I have wasted enough of my time with Ada. If its maintainers are unable to
> clean the mess caused by revision r247391, I could I?

Well, I only suggested to try the workaround, nothing more.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Oh, I forgot: does anyone have an explanation why
i386-apple-darwin16.7.0 and i386-apple-darwin11.4.2 bootstraps *with*
Ada still work fine while their x86_64 counterparts fail?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #29 from Dominique d'Humieres  ---
>> Did you try what I suggested in comment #16 as a stopgap measure? 
>> No GNAT developer builds the mainline compiler on Darwin regularly
>> so this may take a while to sort out otherwise.
>
> I have wasted enough of my time with Ada. If its maintainers are unable to
> clean the mess caused by revision r247391, I could I?
>
> Closing as WONTFIX. Please do not reopen this PS and don't CC me for any
> further change in Ada.

Then please keep the PR open, but set the `Ignore Bug Mail' flag so you
won't see any further mails.  The fact that you're no longer interested
doesn't make the bug go away.

When I tried the workaround, I got

/var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc
-B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/
-B/vol/gcc/x86_64-apple-darwin11.4.2/bin/
-B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem
/vol/gcc/x86_64-apple-darwin11.4.2/include -isystem
/vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W -Wall
-gnatpg -nostdinc g-exptty.adb -o g-exptty.o
dyld: Symbol not found: __ZdaPvm
  Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
  Expected in: /usr/lib/libstdc++.6.dylib
 in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1)

Rainer

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #30 from Dominique d'Humieres  ---
s/I could I/how could I/

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #29 from Dominique d'Humieres  ---
> Did you try what I suggested in comment #16 as a stopgap measure? 
> No GNAT developer builds the mainline compiler on Darwin regularly
> so this may take a while to sort out otherwise.

I have wasted enough of my time with Ada. If its maintainers are unable to
clean the mess caused by revision r247391, I could I?

Closing as WONTFIX. Please do not reopen this PS and don't CC me for any
further change in Ada.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

simon at pushface dot org changed:

   What|Removed |Added

 CC||simon at pushface dot org

--- Comment #28 from simon at pushface dot org ---
(In reply to Iain Sandoe from comment #25)

> NOTE: AFAIR clang doesn't support that option anyway, so it would not be
> available at stage 1 where clang is the bootstrap compiler.

clang doesn’t support Ada, so the stage 1 compiler has to be a (fairly 
recent, AFAICR) GCC.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #27 from Eric Botcazou  ---
> Still present at revision r248811. Any chance to get this fixed?

Did you try what I suggested in comment #16 as a stopgap measure?  No GNAT
developer builds the mainline compiler on Darwin regularly so this may take a
while to sort out otherwise.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #26 from Dominique d'Humieres  ---
Still present at revision r248811. Any chance to get this fixed?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #25 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #24)
> > Le 11 mai 2017 à 09:06, gingold at adacore dot com 
> >  a écrit :


> 
> Note that
> 
> --with-stage1-ldflags=-static-libstdc++ 
> --with-boot-ldflags=-static-libstdc++
> 
> does not work if the install directory is empty:

That's actually a different problem, what you're seeing there is that
-static-libstdc++ is ignored on Darwin (dropped silently)...

... I.e.  -static-libstdc++ only works on Darwin with a patch which I got fed
up with pinging after 4 or so times.

NOTE: AFAIR clang doesn't support that option anyway, so it would not be
available at stage 1 where clang is the bootstrap compiler.

However, the existing compiler build process points explicitly to the
just-built libstdc++ convenience lib IIRC (the built tools are statically
linked with the lib). So that info ought to be available to the Ada build (I'm
pretty sure all the -B etc. is passed through).

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #24 from Dominique d'Humieres  ---
> Le 11 mai 2017 à 09:06, gingold at adacore dot com  
> a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
> 
> --- Comment #19 from Tristan Gingold  ---
> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
> 
>> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
>> 
>> --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 
>> 247300
>> +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 
>> 247301
>> @@ -99,6 +99,8 @@
>> ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
>> # Unresolved warnings in specific files.
>> ada/adaint.o-warn = -Wno-error
>> +# For unwind-pe.h
>> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
>> 
>> ada/%.o: ada/gcc-interface/%.c
>>$(COMPILE) $<
>> 
>> Isn't this wrong for darwin?
> 
> Why ?

I cannot distinguish -I (for include) and -l (for libs) on my browser, hence
the mistake.

Note that

--with-stage1-ldflags=-static-libstdc++ 
--with-boot-ldflags=-static-libstdc++

does not work if the install directory is empty:

dyld: Symbol not found: __ZdlPvm
  Referenced from: /opt/gcc/p_build/gcc/build/genmddeps (which was built for
Mac OS X 10.12)
  Expected in: /usr/lib/libstdc++.6.dylib
 in /opt/gcc/p_build/gcc/build/genmddeps

Dominique

> 
> The header unwind-pe.h is needed for the personality routine.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #23 from Tristan Gingold  ---
On 11/05/2017 10:11, iains at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>
> --- Comment #22 from Iain Sandoe  ---
> (In reply to Tristan Gingold from comment #21)
>> On 11/05/2017 09:44, iains at gcc dot gnu.org wrote:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>>>
>>> --- Comment #20 from Iain Sandoe  ---
>>> (In reply to Tristan Gingold from comment #19)
 On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
>
> --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 
> 247300
> +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 
> 247301
> @@ -99,6 +99,8 @@
>  ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
>  # Unresolved warnings in specific files.
>  ada/adaint.o-warn = -Wno-error
> +# For unwind-pe.h
> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
>
>  ada/%.o: ada/gcc-interface/%.c
> $(COMPILE) $<
>
> Isn't this wrong for darwin?

 Why ?

 The header unwind-pe.h is needed for the personality routine.
>>>
>>> What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh
>>> (static-libgcc) for Darwin > 10, since the unwinder is now in
>>> usr/lib/system/libunwind.dylib.
>>>
>>> Needs two chunks (1) move the content for TLS emulation somewhere else, 
>>> since
>>> that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 
>>> 10
>>> to not include libgcc_eh for -static-libgcc.  I have some patches for gcc-5 
>>> and
>>> 6 that do this, will forward-port them.
>>
>> Great!
>
> .. but might not be 'this week' ;-)
>
>
>>> I'm a little surprised that we need explicit -static-libstdc++ for gnat, the
>>> rest of the compiler already handles this?
>>
>> We just need to remove -static-libgcc but keep -static-libstdc++
>
> OK. So looking at the breaking rev. (and to check I've understood correctly) -
> the change switches gnat from using setjmp/longjmp to using DWARF unwinding
> (and thus exposes the incompatibility)?

Yes.

> In the short-term, what ought to work is to ensure that -lSystem appears 
> before
> any -lgcc on the link line (so that the correct unwinder is used), and to
> remove -static-libgcc.

Might work too.

> TBH static-libgcc should actually work unless gnat is now pulling in any other
> system libraries which cause two unwinders to be present - I guess it might 
> be?

No, I think static-libgcc cannot work because it is not able to get the 
address of the unwind tables (on recent Darwin versions).

> (probably, as an aside, we ought to look at putting libstdc++ on top of
> libc++abi instead of libsupc++ - but that's on the TODO, no patches yet).

Hum, yes.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #22 from Iain Sandoe  ---
(In reply to Tristan Gingold from comment #21)
> On 11/05/2017 09:44, iains at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
> >
> > --- Comment #20 from Iain Sandoe  ---
> > (In reply to Tristan Gingold from comment #19)
> >> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
> >>
> >>> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
> >>>
> >>> --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 
> >>> 247300
> >>> +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 
> >>> 247301
> >>> @@ -99,6 +99,8 @@
> >>>  ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
> >>>  # Unresolved warnings in specific files.
> >>>  ada/adaint.o-warn = -Wno-error
> >>> +# For unwind-pe.h
> >>> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
> >>>
> >>>  ada/%.o: ada/gcc-interface/%.c
> >>> $(COMPILE) $<
> >>>
> >>> Isn't this wrong for darwin?
> >>
> >> Why ?
> >>
> >> The header unwind-pe.h is needed for the personality routine.
> >
> > What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh
> > (static-libgcc) for Darwin > 10, since the unwinder is now in
> > usr/lib/system/libunwind.dylib.
> >
> > Needs two chunks (1) move the content for TLS emulation somewhere else, 
> > since
> > that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 
> > 10
> > to not include libgcc_eh for -static-libgcc.  I have some patches for gcc-5 
> > and
> > 6 that do this, will forward-port them.
> 
> Great!

.. but might not be 'this week' ;-)


> > I'm a little surprised that we need explicit -static-libstdc++ for gnat, the
> > rest of the compiler already handles this?
> 
> We just need to remove -static-libgcc but keep -static-libstdc++

OK. So looking at the breaking rev. (and to check I've understood correctly) -
the change switches gnat from using setjmp/longjmp to using DWARF unwinding
(and thus exposes the incompatibility)?

In the short-term, what ought to work is to ensure that -lSystem appears before
any -lgcc on the link line (so that the correct unwinder is used), and to
remove -static-libgcc.

TBH static-libgcc should actually work unless gnat is now pulling in any other
system libraries which cause two unwinders to be present - I guess it might be?

(probably, as an aside, we ought to look at putting libstdc++ on top of
libc++abi instead of libsupc++ - but that's on the TODO, no patches yet).

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #21 from Tristan Gingold  ---
On 11/05/2017 09:44, iains at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>
> --- Comment #20 from Iain Sandoe  ---
> (In reply to Tristan Gingold from comment #19)
>> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>>
>>> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
>>>
>>> --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 
>>> 247300
>>> +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 
>>> 247301
>>> @@ -99,6 +99,8 @@
>>>  ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
>>>  # Unresolved warnings in specific files.
>>>  ada/adaint.o-warn = -Wno-error
>>> +# For unwind-pe.h
>>> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
>>>
>>>  ada/%.o: ada/gcc-interface/%.c
>>> $(COMPILE) $<
>>>
>>> Isn't this wrong for darwin?
>>
>> Why ?
>>
>> The header unwind-pe.h is needed for the personality routine.
>
> What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh
> (static-libgcc) for Darwin > 10, since the unwinder is now in
> usr/lib/system/libunwind.dylib.
>
> Needs two chunks (1) move the content for TLS emulation somewhere else, since
> that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 10
> to not include libgcc_eh for -static-libgcc.  I have some patches for gcc-5 
> and
> 6 that do this, will forward-port them.

Great!

> I'm a little surprised that we need explicit -static-libstdc++ for gnat, the
> rest of the compiler already handles this?

We just need to remove -static-libgcc but keep -static-libstdc++

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #20 from Iain Sandoe  ---
(In reply to Tristan Gingold from comment #19)
> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
> 
> > In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
> >
> > --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 
> > 247300
> > +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 
> > 247301
> > @@ -99,6 +99,8 @@
> >  ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
> >  # Unresolved warnings in specific files.
> >  ada/adaint.o-warn = -Wno-error
> > +# For unwind-pe.h
> > +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
> >
> >  ada/%.o: ada/gcc-interface/%.c
> > $(COMPILE) $<
> >
> > Isn't this wrong for darwin?
> 
> Why ?
> 
> The header unwind-pe.h is needed for the personality routine.

What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh
(static-libgcc) for Darwin > 10, since the unwinder is now in
usr/lib/system/libunwind.dylib.

Needs two chunks (1) move the content for TLS emulation somewhere else, since
that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 10
to not include libgcc_eh for -static-libgcc.  I have some patches for gcc-5 and
6 that do this, will forward-port them.

I'm a little surprised that we need explicit -static-libstdc++ for gnat, the
rest of the compiler already handles this?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #19 from Tristan Gingold  ---
On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
>
> --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 247300
> +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 247301
> @@ -99,6 +99,8 @@
>  ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
>  # Unresolved warnings in specific files.
>  ada/adaint.o-warn = -Wno-error
> +# For unwind-pe.h
> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
>
>  ada/%.o: ada/gcc-interface/%.c
> $(COMPILE) $<
>
> Isn't this wrong for darwin?

Why ?

The header unwind-pe.h is needed for the personality routine.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #18 from Dominique d'Humieres  ---
> This failure is simply a consequence of broken libgcc on Darwin: this 
> libgcc is not able to get exception table addresses and therefore cannot 
> propagate exceptions.
>
> Any program (that uses exceptions) and linked with -static-libgcc on 
> Darwin will also fail.

In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in

--- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 247300
+++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 247301
@@ -99,6 +99,8 @@
 ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
 # Unresolved warnings in specific files.
 ada/adaint.o-warn = -Wno-error
+# For unwind-pe.h
+CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude

 ada/%.o: ada/gcc-interface/%.c
$(COMPILE) $<

Isn't this wrong for darwin?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #17 from Tristan Gingold  ---
On 09/05/2017 17:41, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>
> --- Comment #15 from Dominique d'Humieres  ---
>> You should add:
>>
>> --with-stage1-ldflags=-static-libstdc++
>> --with-boot-ldflags=-static-libstdc++
>>
>> to your configure line.
>
> With these lines added to my configure line I have been able to bootstrap
> revision r247792. However this addition was not necessary before and I don't
> think it is the end user responsibility to do the addition.

This failure is simply a consequence of broken libgcc on Darwin: this 
libgcc is not able to get exception table addresses and therefore cannot 
propagate exceptions.

Any program (that uses exceptions) and linked with -static-libgcc on 
Darwin will also fail.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #16 from Eric Botcazou  ---
> With these lines added to my configure line I have been able to bootstrap
> revision r247792. However this addition was not necessary before and I don't
> think it is the end user responsibility to do the addition.

Right.  Can you make the necessary modifications to the toplevel configure.ac
for Darwin (grep for -static-libgcc) and post them on gcc-patches@?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #15 from Dominique d'Humieres  ---
> You should add:
>
> --with-stage1-ldflags=-static-libstdc++ 
> --with-boot-ldflags=-static-libstdc++
>
> to your configure line.

With these lines added to my configure line I have been able to bootstrap
revision r247792. However this addition was not necessary before and I don't
think it is the end user responsibility to do the addition.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #14 from Tristan Gingold  ---
On 09/05/2017 15:14, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>
> --- Comment #13 from Dominique d'Humieres  ---
>> Did you try to get gnat1 built without -static-libgcc ?
>
> How am I supposed to do that? I have used the same clean configure
>
> ../p_work/configure --prefix=/opt/gcc/gcc8p-247298p1
> --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp-new
> --with-system-zlib --enable-checking=release --with-isl=/opt/mp-new
> --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7
>
> and bootstrap for r247298 (bootstraps) and r247302 (fails).
>
> The bootstrap compiler is
>
> gcc version 8.0.0 20170425 (experimental) [trunk revision 247256]
>
> configured with
>
> ../_clean/configure --prefix=/opt/gcc/gcc8a
> --enable-languages=c,c++,fortran,ada,lto --with-gmp=/opt/mp-new
> --with-system-zlib --enable-checking=release --with-isl=/opt/mp-new
> --enable-lto --enable-plugin

You should add:

--with-stage1-ldflags=-static-libstdc++ 
--with-boot-ldflags=-static-libstdc++

to your configure line.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #13 from Dominique d'Humieres  ---
> Did you try to get gnat1 built without -static-libgcc ?

How am I supposed to do that? I have used the same clean configure 

../p_work/configure --prefix=/opt/gcc/gcc8p-247298p1
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp-new
--with-system-zlib --enable-checking=release --with-isl=/opt/mp-new
--enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7

and bootstrap for r247298 (bootstraps) and r247302 (fails).

The bootstrap compiler is 

gcc version 8.0.0 20170425 (experimental) [trunk revision 247256]

configured with

../_clean/configure --prefix=/opt/gcc/gcc8a
--enable-languages=c,c++,fortran,ada,lto --with-gmp=/opt/mp-new
--with-system-zlib --enable-checking=release --with-isl=/opt/mp-new
--enable-lto --enable-plugin

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #12 from Tristan Gingold  ---
On 09/05/2017 14:43, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>
> --- Comment #11 from Dominique d'Humieres  ---
> Any chance to see this PR fixed soon?

Did you try to get gnat1 built without -static-libgcc ?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #11 from Dominique d'Humieres  ---
Any chance to see this PR fixed soon?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #10 from Rainer Orth  ---
Interestingly, a i386-apple-darwin16 bootstrap *does* work fine.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #9 from Tom de Vries  ---
PR80590 could be a non-darwin duplicate.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #8 from Dominique d'Humieres  ---
> It looks like gnat1 was compiled with libgcc, which is not able to 
> handle unwinding on Darwin.
> I suppose it must be linked without -static-libgcc

This was handled properly on darwin up to r247298. The changes in r247301
should be updated to work properly on darwin.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #7 from Eric Botcazou  ---
> It looks like gnat1 was compiled with libgcc, which is not able to 
> handle unwinding on Darwin.
> I suppose it must be linked without -static-libgcc

Is there a specific change intended to do it and which doesn't work here?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #6 from Tristan Gingold  ---
On 29/04/2017 21:11, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>
> Eric Botcazou  changed:
>
>What|Removed |Added
> 
>  Status|WAITING |NEW
>  CC||gingold at gcc dot gnu.org
>
> --- Comment #4 from Eric Botcazou  ---
>> a bunch of similar errors
>> ...
>> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
>>   * frame #0: 0x7fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10
>> frame #1: 0x7fffa7f7d5bf libsystem_pthread.dylib`pthread_kill + 90
>> frame #2: 0x7fffa7df5420 libsystem_c.dylib`abort + 129
>> frame #3: 0x000100ff88c1
>> gnat1`uw_init_context_1(context=, outer_cfa=,
>> outer_ra=) at unwind-dw2.c:1579
>> frame #4: 0x000100ff8f2e
>> gnat1`_Unwind_RaiseException(exc=0x000144a022a0) at unwind.inc:88
>> frame #5: 0x00010006663f
>> gnat1`ada__exceptions__exception_propagation__propagate_gcc_exceptionXn(gcc_e
>> xception=0x000144a022a0) at a-exexpr.adb:322
>> frame #6: 0x000100066683
>> gnat1`ada__exceptions__exception_propagation__propagate_exceptionXn(excep=> available>) at a-exexpr.adb:354
>> frame #7: 0x000100066af9
>> gnat1`ada__exceptions__complete_and_propagate_occurrence(x=) at
>> a-except.adb:937
>> frame #8: 0x000100066b2e
>> gnat1`__gnat_raise_exception(e=, message=) at
>> a-except.adb:978
>> frame #9: 0x0001001fbf9a gnat1`rtsfind__load_fail(s=const
>> string___XUP @ 0x7fe1c0cf6f50, u_id=, id=) at
>> rtsfind.adb:851
>
> OK, thanks, there is a problem in exception propagation on the Darwin host.
> I'm not exactly a specialist here, so CCing Tristan.

It looks like gnat1 was compiled with libgcc, which is not able to 
handle unwinding on Darwin.
I suppose it must be linked without -static-libgcc

>

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #5 from Dominique d'Humieres  ---
The last successful bootstrap is r247298; r247301 fails as reported in comment
0; r247299 fails for a different reason:

/opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/
-B/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/bin/
-B/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/lib/ -isystem
/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/include -isystem
/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/sys-include-c -g -O2 
-fno-common  -W -Wall -gnatpg -nostdinc   s-excmac.ads -o s-excmac.o
cannot generate code for file s-excmac.ads (package spec)

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||gingold at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
> a bunch of similar errors
> ...
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
>   * frame #0: 0x7fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fffa7f7d5bf libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fffa7df5420 libsystem_c.dylib`abort + 129
> frame #3: 0x000100ff88c1
> gnat1`uw_init_context_1(context=, outer_cfa=,
> outer_ra=) at unwind-dw2.c:1579
> frame #4: 0x000100ff8f2e
> gnat1`_Unwind_RaiseException(exc=0x000144a022a0) at unwind.inc:88
> frame #5: 0x00010006663f
> gnat1`ada__exceptions__exception_propagation__propagate_gcc_exceptionXn(gcc_e
> xception=0x000144a022a0) at a-exexpr.adb:322
> frame #6: 0x000100066683
> gnat1`ada__exceptions__exception_propagation__propagate_exceptionXn(excep= available>) at a-exexpr.adb:354
> frame #7: 0x000100066af9
> gnat1`ada__exceptions__complete_and_propagate_occurrence(x=) at
> a-except.adb:937
> frame #8: 0x000100066b2e
> gnat1`__gnat_raise_exception(e=, message=) at
> a-except.adb:978
> frame #9: 0x0001001fbf9a gnat1`rtsfind__load_fail(s=const
> string___XUP @ 0x7fe1c0cf6f50, u_id=, id=) at
> rtsfind.adb:851

OK, thanks, there is a problem in exception propagation on the Darwin host.
I'm not exactly a specialist here, so CCing Tristan.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #3 from Dominique d'Humieres  ---
> Other native platforms seem fine, so please post a backtrace.

The best I can do without further directives:

[Book15] ada/rts% lldb /opt/gcc/build_a/gcc/gnat1
(lldb) run -O2 g-exptty.adb
Process 95815 launched: '/opt/gcc/build_a/gcc/gnat1' (x86_64)
Process 95815 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x7fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fffa7e8fd42 <+10>: jae0x7fffa7e8fd4c; <+20>
0x7fffa7e8fd44 <+12>: movq   %rax, %rdi
0x7fffa7e8fd47 <+15>: jmp0x7fffa7e88caf; cerror_nocancel
0x7fffa7e8fd4c <+20>: retq   
(lldb) bt
error: gnat1 {0x00179120}: unhandled type tag 0x0021 (DW_TAG_subrange_type),
please file a bug and attach the file at the start of this error message
...
a bunch of similar errors
...
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x7fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fffa7f7d5bf libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fffa7df5420 libsystem_c.dylib`abort + 129
frame #3: 0x000100ff88c1 gnat1`uw_init_context_1(context=,
outer_cfa=, outer_ra=) at unwind-dw2.c:1579
frame #4: 0x000100ff8f2e
gnat1`_Unwind_RaiseException(exc=0x000144a022a0) at unwind.inc:88
frame #5: 0x00010006663f
gnat1`ada__exceptions__exception_propagation__propagate_gcc_exceptionXn(gcc_exception=0x000144a022a0)
at a-exexpr.adb:322
frame #6: 0x000100066683
gnat1`ada__exceptions__exception_propagation__propagate_exceptionXn(excep=)
at a-exexpr.adb:354
frame #7: 0x000100066af9
gnat1`ada__exceptions__complete_and_propagate_occurrence(x=) at
a-except.adb:937
frame #8: 0x000100066b2e gnat1`__gnat_raise_exception(e=,
message=) at a-except.adb:978
frame #9: 0x0001001fbf9a gnat1`rtsfind__load_fail(s=const string___XUP
@ 0x7fe1c0cf6f50, u_id=, id=) at rtsfind.adb:851
frame #10: 0x0001001fc316 gnat1`rtsfind__load_rtu(u_id=,
id=, use_setting=) at rtsfind.adb:987
frame #11: 0x0001001fc74e gnat1`rtsfind__rte at rtsfind.adb:1380
frame #12: 0x0001001fcab8 gnat1`rtsfind__rte_available(e=)
at rtsfind.adb:1462
frame #13: 0x00010011d4ad
gnat1`exp_ch9__expand_n_delay_relative_statement(n=) at
exp_ch9.adb:8068
frame #14: 0x00010017078f gnat1`expander__expand(n=) at expander.adb:214
frame #15: 0x0001002124d8 gnat1`sem__analyze(n=)
at sem.adb:753
frame #16: 0x00010029d347 gnat1`sem_ch5__analyze_statements(l=) at sem_ch5.adb:3613
frame #17: 0x00010029f06e gnat1`sem_ch5__analyze_if_statement(n=) at sem_ch5.adb:1665
frame #18: 0x000100212bf0 gnat1`sem__analyze(n=)
at sem.adb:306
frame #19: 0x00010029d347 gnat1`sem_ch5__analyze_statements(l=) at sem_ch5.adb:3613
frame #20: 0x0001002396ee
gnat1`sem_ch11__analyze_handled_statements(n=) at
sem_ch11.adb:426
frame #21: 0x000100212882 gnat1`sem__analyze(n=)
at sem.adb:297
frame #22: 0x0001002ad694
gnat1`sem_ch6__analyze_subprogram_body(n=) at sem_ch6.adb:4245
frame #23: 0x000100212ace gnat1`sem__analyze(n=)
at sem.adb:547
frame #24: 0x00010027767b gnat1`sem_ch3__analyze_declarations(l=) at sem_ch3.adb:2608
frame #25: 0x0001002b2dbe gnat1`sem_ch7__analyze_package_body(n=) at sem_ch7.adb:786
frame #26: 0x000100212ada gnat1`sem__analyze(n=)
at sem.adb:444
frame #27: 0x000100236c22
gnat1`sem_ch10__analyze_compilation_unit(n=) at
sem_ch10.adb:897
frame #28: 0x000100212713 gnat1`sem__analyze(n=)
at sem.adb:180
frame #29: 0x000100213863 gnat1`sem__semantics at sem.adb:1338
frame #30: 0x0001002137e6 gnat1`sem__semantics
frame #31: 0x000100182fd4 gnat1`_ada_frontend at frontend.adb:407
frame #32: 0x00010037a6b1 gnat1`_ada_gnat1drv at gnat1drv.adb:1127
frame #33: 0x00010001daff gnat1`::gnat_parse_file() at misc.c:122
frame #34: 0x000100c583ca gnat1`::compile_file() at toplev.c:467
frame #35: 0x000100ffd717 gnat1`toplev::main(int, char**) at
toplev.c:2003
frame #36: 0x000100ffd227 gnat1`toplev::main(this=0x7fff5fbff2fe,
argc=, argv=)
frame #37: 0x000100fff2fe gnat1`main(argc=3, argv=0x7fff5fbff330)
at main.c:39
frame #38: 0x7fffa7d61235 libdyld.dylib`start + 1

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Eric Botcazou  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin16
 Status|NEW |WAITING
 CC||ebotcazou at gcc dot gnu.org
  Component|ada |target
   Host||x86_64-apple-darwin16
Summary|[8 Regression] Ada breaks   |[8 Regression] bootstrap
   |bootstrap on|failure for Ada compiler
   |x86_64-apple-darwin16   |
  Build||x86_64-apple-darwin16

--- Comment #2 from Eric Botcazou  ---
Other native platforms seem fine, so please post a backtrace.