[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Denis Excoffier <Denis.Excoffier at airbus dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.5.0                       |4.6.0

--- Comment #2 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-19 08:41:51 UTC ---
More or less the same applies for GCC 4.6.0 RC 20110314.

If i don't perform the modification indicated above in t-slibgcc-darwin (ie
force the build of libgcc_s_10.[45].dylib even when /usr/lib is not
$(shlib_slibdir), see line 31), the executable of my
(simple) C++ program gets stuck near its end (and never finishes).

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #3 from Mike Stump <mikestump at comcast dot net> 2011-03-19 09:49:35 UTC ---
> With an appropriate DYLD_LIBRARY_PATH, the problem disappears.

So, can you elaborate?  Which value makes the problem disappear?  I'd assume
you if you include $prefix/lib?

I fear this is going to be a hard bug...  If one wants any compatibility, the
routines in gcc_s from /usr/lib have to be used, in particular, the unwinder. 
But, that is exactly the thing that appears to be causing the problems.

I think we're going to need a test case, or if you could, could you try and
binary search the gcc trunk for the patch that caused this to break for you?

Also, you have this in bootstrap, does that mean that this doesn't bootstrap? 
If you could include the error messages from the bootstrap, or the name of the
gcc test case in the testsuite that is failing, that would help.

Thanks.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-19 15:00:14 UTC ---
Created attachment 23721
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23721
work in progress patch to suppress unwind epilogues on Darwin

There was a change in gcc unwinding during 4.5 which is incompatible with the
system unwinders on Darwin 9 (and incompatible with the unwind compacter on
Darwin 10).  Specifically we now emit function epilogues.

This is an unreviewed, unapproved,  "work in progress" patch ; ergo, it has a
health warning that it might not be acceptable to the maintainers, even if it
works (which I think it does).

If this solves your problem then I think we should alter the description &c.
accordingly.

If it doesn't then, as Mike says, we'll need a reduced test-case to work on.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-19 15:06:07 UTC ---

in addition to the attachment at c #4  - you'll also need this:

Index: gcc/toplev.c
===================================================================
--- gcc/toplev.c    (revision 171158)
+++ gcc/toplev.c    (working copy)
@@ -1338,9 +1338,10 @@ process_options (void)
   if (flag_rename_registers == AUTODETECT_VALUE)
     flag_rename_registers = flag_unroll_loops || flag_peel_loops;

-  if (flag_non_call_exceptions)
+  if (flag_non_call_exceptions 
+      && !global_options_set.x_flag_asynchronous_unwind_tables)
     flag_asynchronous_unwind_tables = 1;
-  if (flag_asynchronous_unwind_tables)
+  if (flag_asynchronous_unwind_tables || flag_non_call_exceptions)
     flag_unwind_tables = 1;

   if (flag_value_profile_transformations)

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-19 22:02:58 UTC ---
 Doesn't the darwin linker developer's comments on PR48097
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097#c8) imply that libjava's
Throw2 test case is expected to fail on the current Apple system unwinder? Thus
your epilogue patch should be fine as it only regressed Throw2 for me.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #7 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-20 08:12:49 UTC ---
1) In no configuration the bootstrap fails (as long as you take care of PR45381
and PR47016).

2) Indeed, the DYLD_LIBRARY_PATH that makes things to work properly is
DYLD_LIBRARY_PATH=$(prefix)/lib

3) I have built with the patch attached in #4 (together with the addition
included in #5), it seems
to work properly now (see configuration 'y' below).

4) I have now 3 configurations (all with 4.6.0 RC 20110314)
- 4.6.x: built with my modification (the change in t-slibgcc-darwin)
- 4.6.y: built with the 2 patches from yesterday
- 4.6.z: no change from the distribution
I have also built the Xerces-C library 3 times, xerces-c-3.1.1x,
xerces-c-3.1.1y and
xerces-c3.1.1.z.
The libxerces-c-3.1.dylib contains (iaw otool -L) a dependency towards
/usr/lib/libgcc_s.1.dylib
in the cases 'y' and 'z'. The libxerces-c-3.1.dylib contains a dependency
towards /usr/lib/libSystem.B.dylib in the three configurations. My C++ program
links with this library.

The sets 'x' and 'y' work properly. The set 'z' does not work (stuck between
throw and
catch, CPU running).

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.1

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-20 09:27:15 UTC ---
(In reply to comment #7)
> 1) In no configuration the bootstrap fails (as long as you take care of PR45381
> and PR47016).

PR45381 has been fixed in trunk and on the branch - I guess it will be fixed in
the release (I think there's another RC coming).  As already commented in
PR47016, this is a tool problem, not  a gcc bug (but, since I doubt any tool
fixes will be forthcoming for darwin < 11, we will endeavor to solve it somehow
;-) - patches welcome... )

> 2) Indeed, the DYLD_LIBRARY_PATH that makes things to work properly is
> DYLD_LIBRARY_PATH=$(prefix)/lib

If everything is linked correctly with proper rpaths, and the products are
installed - there should be no need for a DYLD_LIBRARY_PATH - it should only be
necessary for uninstalled testing.

> 3) I have built with the patch attached in #4 (together with the addition
> included in #5), it seems
> to work properly now (see configuration 'y' below).
> 
> 4) I have now 3 configurations (all with 4.6.0 RC 20110314)
> - 4.6.x: built with my modification (the change in t-slibgcc-darwin)
> - 4.6.y: built with the 2 patches from yesterday
> - 4.6.z: no change from the distribution
> I have also built the Xerces-C library 3 times, xerces-c-3.1.1x,
> xerces-c-3.1.1y and
> xerces-c3.1.1.z.
> The libxerces-c-3.1.dylib contains (iaw otool -L) a dependency towards
> /usr/lib/libgcc_s.1.dylib
> in the cases 'y' and 'z'. The libxerces-c-3.1.dylib contains a dependency
> towards /usr/lib/libSystem.B.dylib in the three configurations. My C++ program
> links with this library.
> 
> The sets 'x' and 'y' work properly. 

Hm, configuration 'x' is actually generically incorrect - it will _only_  work
providing you don't link with any library that is already linked with the
unwinder in /usr/lib/libgcc_s.1.dylib.   This is because there can only be
_one_ unwinder - the whole program must use the same one.

Some stand-alone programs are unaffected (including the gcc test-suite), but -
anything that uses stuff from gcc together with system frameworks is almost
certainly doomed...

set 'y' is correct (IMO) - and if the products are installed should work
without a DYLD_LIBRARY_PATH - assuming that everything has its correct paths...

The set 'z' does not work (stuck between
> throw and  catch, CPU running).

that, to me, confirms that the bug is in our emitting unwind that is
incompatible with the darwin 9 unwinder (a known issue, but without a specific
bug - it has been treated as part of PR41991 to date). 

I don't know when (or if) the patch will make it into gcc - but surely not for
4.6.0 it's too intrusive and the time has gone - for now, a local patch is
required - although it might be that fink/macports would decide to apply this
too.

hint: 
"DYLD_PRINT_LIBRARIES=1 ./myexe " 
is really useful for making sure that the libraries you think should be used
actually are ;-)

thanks for  testing!!

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-20 12:42:52 UTC ---
Test results for WIP patch  from Comment 4 and 5 against gcc-4_6-branch under
Xcode 4.0...

http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01968.html

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #10 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-20 20:34:37 UTC ---
(In reply to comment #8)
> "DYLD_PRINT_LIBRARIES=1 ./myexe " 
> is really useful for making sure that the libraries you think should be used
> actually are ;-)
This is great, thank you for the hint.

This shows that the sets 'y' (ie patched) and 'z' (ie unchanged) have a real
dependency towards /usr/lib/libgcc_s.1.dylib. The set 'x' (modif
t-slibgcc-darwin) does not have it. Perhaps (i don't know) it is inside anyway
(i mean statically) but i suppose that  if some libgcc_s.1.dylib must be
statically included, the one just-compiled will be chosen.

Now comes the question of the beginning (which is also included in the title of
this PR): why does my C++ program have (like in 'y' or 'z'+DYLD_LIBRARY_PATH)
to use a /usr/lib/libgcc_s.1.dylib (dated 2007-10-06, 264016 bytes on my Darwin
9.8.0), when we could take advantage of the one in $(prefix)/lib (newer and
only 89656 bytes), or none at all (like in 'x')?

Second question, why is /usr/lib hardwired into t-slibgcc-darwin (line 31)?
That fact, let it alone, is already suspicious for me...

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-20 20:54:09 UTC ---
(In reply to comment #10)
> (In reply to comment #8)

> 
> Now comes the question of the beginning (which is also included in the title of
> this PR): why does my C++ program have (like in 'y' or 'z'+DYLD_LIBRARY_PATH)
> to use a /usr/lib/libgcc_s.1.dylib (dated 2007-10-06, 264016 bytes on my Darwin
> 9.8.0), when we could take advantage of the one in $(prefix)/lib (newer and
> only 89656 bytes), or none at all (like in 'x')?

libgcc_s (/usr/lib/libgcc_s.1.dylib) contains the unwinder for the system
(which is what you need for your try/catch stuff). 

We are not at liberty to change that - it belongs to the distribution and is
part of the suite of things Apple would update in event of security matters
arising.

(of course, you can overwrite Apple's lib, but then you take personal
responsibility for any issues that creates - including security ones ;) ).

Now the technical reason;
Any system library that links with /usr/lib/libgcc_s.1.dylib - uses the
unwinder from that.

If you wish (and we do wish for gcc to be capable of this) to be able to make
use of system libraries and frameworks - then _everyone_ MUST link the unwinder
in  /usr/lib/libgcc_s.1.dylib ... it's that simple.  There can only be one
unwinder in a single application.

Now - we don't want to give up the newer capabilities of libgcc - so we made
the libgcc_ext which allows you to use some newer math (and things like
emulated thread local storage).

> Second question, why is /usr/lib hardwired into t-slibgcc-darwin (line 31)?
> That fact, let it alone, is already suspicious for me...

maybe it should not be - we are living in someone else's house ;) 
... we must comply with the existing infrastructure...

===

You can do a whole load of things that _might_ work for your particular case -
- stand alone code that makes NO use of system libraries or frameworks is free
to use the FSF libgcc_s ... (and you can force that with DYLD_LIBRARY_PATH).

- but the configuration for gcc is intended to work in the general case (for
example, people want to be able to link libobjc and pieces from CoreFoundation)
...

====

So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
(that tells us if we have a way forward)

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-20 21:06:30 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)

> So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
> (that tells us if we have a way forward)

duh ... make that version 'y'.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #13 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-21 06:46:26 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > (In reply to comment #8)
> > So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
> > (that tells us if we have a way forward)
> duh ... make that version 'y'.
If you take the pure distribution gcc-4.6.0-RC-20110314 and apply the two
patches (the patch attached in #4 and included in #5), then
- you can bootstrap without error (i can say for C and C++ for the time
  being)
- the xerces-c library compiles ok
- my C++ program compiles ok
- my C++ program executes ok with no DYLD_LIBRARY_PATH needed
- all the dylibs and executable around carry a dependency towards
  /usr/lib/libgcc_s.1.dylib

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-21 08:24:19 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > (In reply to comment #8)
> > > So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
> > > (that tells us if we have a way forward)
> > duh ... make that version 'y'.
> If you take the pure distribution gcc-4.6.0-RC-20110314 and apply the two
> patches (the patch attached in #4 and included in #5), then
> - you can bootstrap without error (i can say for C and C++ for the time
>   being)
> - the xerces-c library compiles ok
> - my C++ program compiles ok
> - my C++ program executes ok with no DYLD_LIBRARY_PATH needed

Thanks Denis, that is very helpful testing - and you have, indeed, identified a
serious bug.  However,  I think that this set of tests indicates that the bug
is that we "emit eh_frames that are incompatible with the darwin
{8,9}-unwinder,10-compacter". 

Accordingly, I suggest that either we close this bug and refer to PR41991 - or
we re-name this one to reflect its underlying cause and make it a target bug;

Mike - any preference?

> - all the dylibs and executable around carry a dependency towards
>   /usr/lib/libgcc_s.1.dylib

hopefully, I have explained both that this is an intention of the current
design and why that design must be as it is.

If you can think of a viable alternative, I'd be very glad to read it.

... remembering that there are some system libraries and frameworks that are
closed source and therefore cannot be re-compiled by an end User - to say
nothing of any 3rd party commercial applications the User has installed that
were linked against a 'standard' system.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #15 from Mike Stump <mikestump at comcast dot net> 2011-03-21 18:53:12 UTC ---
I'd trust the person doing the work.  :-)  They usually have more state on
exactly what problem they are fixing and if the work for any one bug covers the
problems in other bug reports completely or partially.  I prefer that as enough
work is put in to fix one bug report, that that bug report is then marked as
fixed, and other the other bug reports that are completely solved by it are
then marked as dup of that bug.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.1                       |---

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|powerpc-apple-darwin9.8.0   |*-apple-darwin{8,9,10}
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.06.26 17:37:00
          Component|bootstrap                   |target
                 CC|                            |dominiq at lps dot ens.fr
               Host|powerpc-apple-darwin9.8.0   |*-apple-darwin{8,9,10}
         AssignedTo|unassigned at gcc dot       |iains at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1
            Summary|libstdc++ (dylib) is built  |gcc emits frame (epilogue)
                   |with an erroneous           |info incompatible with the
                   |dependency towards /usr/lib |darwin
                   |                            |{8,9}-unwinder,10-compacter
              Build|powerpc-apple-darwin9.8.0   |*-apple-darwin{8,9,10}

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> 2011-06-26 17:37:00 UTC ---
This bug has been around since part way through 4.5.

Unfortunately, it is somewhat hidden in the test-suite since the latter
interposes the newly-built libgcc ahead of the system version (because
DYLD_LIBRARY_PATH is set to point to ./gcc, of necessity).

There are two steps needed to deal with this fully:

(a) fix things so we don't emit epilogue info in unwind frames for darwin 8,9
and 10 (compacter).

The patch currently attached is OK on 4.6.x - but the emitting of unwind frames
has been recently vec-ified which means it will need some re-work for trunk.

(b) fix the darwin libgcc build process so that we only export the _ext symbols
from newly-built libgcc when this is only supporting the ext.

* (b) will also solve the library ordering issues when -{force}_flat_namespace
is used.

I have another patch in progress that is a first attempt at (b) - (not yet
ready to post).

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Denis Excoffier <gcc@Denis-Excoffier.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.6.0                       |4.7.0

--- Comment #17 from Denis Excoffier <gcc@Denis-Excoffier.org> 2011-12-11 19:45:48 UTC ---
Hello,

Here comes gcc-4.7.20111203 with (not unexpectedly) exactly the same symptoms
(see Description above). I tried the patches provided in Comments #4 and #5
with no success:
11 out of 13 hunks FAILED -- saving rejects to file gcc/dwarf2out.c.rej
1 out of 3 hunks FAILED -- saving rejects to file gcc/config/darwin.c.rej
1 out of 1 hunk FAILED -- saving rejects to file gcc/config/darwin10.h.rej

The two patches have been working successfully for all 4.6.x versions. Can we
expect an update
of them for GCC 4.7?

You must know that i also tried the same as before:
sed -e 's|^ifeq (/usr/lib,|ifneq (/usr/lib,|g' libgcc/config/t-slibgcc-darwin
and of course it works.

Regards,

Denis Excoffier.

P.S.
Am i the only one needing this patch? As far as i am concerned, i can live with
the above workaround.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-11 20:01:37 UTC ---
(In reply to comment #17)
> Hello,
> 
> Here comes gcc-4.7.20111203 with (not unexpectedly) exactly the same symptoms
> (see Description above). I tried the patches provided in Comments #4 and #5
> with no success:
> 11 out of 13 hunks FAILED -- saving rejects to file gcc/dwarf2out.c.rej
> 1 out of 3 hunks FAILED -- saving rejects to file gcc/config/darwin.c.rej
> 1 out of 1 hunk FAILED -- saving rejects to file gcc/config/darwin10.h.rej

The mechanism in dwarf2out changed between 4.6 and 4.7 - so the code actually
needs changing.

> The two patches have been working successfully for all 4.6.x versions. Can we
> expect an update  of them for GCC 4.7?

I guess... the thing is that this is not really the 'ideal' solution -
 since by holding the unwinder of Darwin at the 4.4 flavor -  the behavior of
Darwin will start to diverge (more than usual) from that of other systems... 

... so...  I've been investigating other ways of resolving the problem (in
amongst all the other things to be done)...

> P.S.
> Am i the only one needing this patch? As far as i am concerned, i can live with
> the above workaround.

no - you are not - the compiler is essentially broken without a working
unwinder ...

However, Darwin10+ are not affected by this (unless you try to use the unwind
compacter) - so the screaming is not so loud as it might otherwise be ;)

...  I am considering a more radical Darwin-9-only solution (that allows us to
keep track of the current unwinder)
 - time is, as always, the killer ...

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
I have tried a number of ways to "fix" this - none of which are really
satisfactory.

1. we could keep hacking on the code gen to cater for legacy output (not a good
use of time with so many other darwin issues to deal with).

2. we could do some really hacky interposing of library code using undocumented
dyld entry points (which is quite fun, but probably not an acceptable
solution).

3. accept that the system is long out of security upgrade supports from the
vendor - and install an up-to-date libgcc_s.

4. something else (feel free to suggest).

I don't propose to investigate this further - but I am happy to provide a
pre-built FAT libgcc_s.1.dylib tested on x86-apple-darwin9 and
ppc-apple-darwin9.  However, I don't have anywhere suitable to host it.

NOTE: if you build/install your own libgcc_s.1.dylib on an x86 darwin9 you
*must* build it FAT including i386/x86_64 *and* at least ppc/7400 if you want
rosetta to function.

sorry, can't justify any more effort on this one - I've replaced the
libgcc_s.1.dylib in my Darwin9 systems with one built from 4.8 tip of branch.

The gcc-4.6 solution will continue to work for anyone who wants to use it as a
local patch.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #20 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Iain Sandoe from comment #19)

Yes. It might be a more profitable use of time to work on moving from the
compatibility  unwinder onto the newer compact unwinder for modern darwin.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #21 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 55956 has been marked as a duplicate of this bug. ***

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[fang at csl dot cornell.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #22 from David Fang <fang at csl dot cornell.edu> ---
Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's
bundled in libgcc_s in darwin8,9,10?

http://opensource.apple.com/tarballs/libunwind/

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #23 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
There should be a forward pointer to one of these from the OS release you're
interested in.  Later releases tend to be what the later OS would use.  Short
answer, yes.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #24 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to David Fang from comment #22)
> Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's
> bundled in libgcc_s in darwin8,9,10?
> 
> http://opensource.apple.com/tarballs/libunwind/

No. The libunwind sources are the replacement compact and compatibility
unwinders that Apple introduced in 10.7. You will see that the 0.30 release
first appears at http://www.opensource.apple.com/release/mac-os-x-107/. Note
that if you look at
http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c from 10.6.8, you
will see that the unwinder calls resided in libgcc_s up to 10.5 after which
they were subsumed into libSystem. I am unclear if the subsumed unwinder calls
in 10.6.x were based on the code from libgcc but these certainly aren't based
on libunwind. Since Apple never released the source code for theses files, it
is difficult to know their heritage in 10.6.x. Also see...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to David Fang from comment #22)
> Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's
> bundled in libgcc_s in darwin8,9,10?
> 
> http://opensource.apple.com/tarballs/libunwind/

To be clear,

For OSX 10.4 (Darwin8) and 10.5 (Darwin9) libgcc is derived from gcc sources
(4.0.1) which are incompatible/buggy when combined with unwinder changes made
during 4.5.  The compact unwinder is not present and there is no need to
consider it at all.  

For OSX 10.6 (Darwin 10), the libgcc functionality has been pulled into
libSystem.dylib (and, I assume, is derived from BSD or other  sources).  IIRC,
the 10.6 compact unwinder issues are to do with the library used by ld64 to
build such code.  FSF-gcc does not produce compact unwinder code on 10.6, and
the non-compact variant works (at least insomuch as the test-suite passes).

So the only places that we need to "fix" things in order to have a working
unwinder are 10.4 and 10.5:

What matters there is having a FAT libgcc_s.dylib that supports the corrected
'normal' unwinder.  This can be achieved by building libgcc_s from recent (say
4.8) sources.  The only consideration then is whether one is prepared to
replace the Apple-provided version of libgcc_s with one that you've built
yourself.

FWIW, I'd be happy to provide FAT library builds tested on 10.5 (I run three
PPC and an X86 box with 10.5).  I'd also be happy to provide a version for 10.4
- although that might take longer as I have to drag old hardware out of storage
to test it.  Personally, I have replaced the Apple-provided libgcc_s.dylib on
my Quad G5 and and 10.5 Xeon and Core2 boxen without issues - the FAT version
must include PPC(7400) on X86 if one wants to use rosetta.  I just build it
4-ways [i386, x86_64, ppc, ppc64] and use the same lib on x86 and ppc.

However I have nowhere appropriate to host the libraries - and the
responsibility for replacing the Apple-provided library absolutely needs to be
in the hands of the end user.

Note that 10.5 and 10.4 no longer get security updates, and it is possible to
arrange symbolic links to libgcc_s versions such that the Apple version could
be reinstated quickly if necessary - of course all of this requires sudo and
terminal work, but Id assume that anyone building GCC from source should be
able to cope with that.

It really doesn't seem productive to hold 10.5 (at least) at an older unwinder
- but if someone really wants to update the 4.6 patch on this thread to match
the scheme now used for 4.7/4.8/trunk, I'd be happy to review.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #26 from Iain Sandoe <iains at gcc dot gnu.org> ---
*** Bug 41991 has been marked as a duplicate of this bug. ***

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #27 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
I (OP) suppose we can WONTFIX that one. Thanks.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Denis Excoffier from comment #27)
> I (OP) suppose we can WONTFIX that one. Thanks.

Well, there is a fix - which is to update /usr/lib/libgcc_s.dylib to a
non-buggy version.

I can give you instructions on how to achieve that (and would be willing to
provide a ready-made suitable binary) - but don't have anywhere suitable to
host it.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #29 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
(In reply to Iain Sandoe from comment #28)
> Well, there is a fix - which is to update
> /usr/lib/libgcc_s.dylib to a non-buggy version.
I had understood that it was desirable not to replace libgcc_s.dylib.

Personally, i use the sed command (shown in comment #17) to create my own
libgcc_s.1.dylib, i install it with GCC in /usr/local (or equivalent) and try
to always link with it (and usually succeed since i don't use any libraries
that are already linked with /usr/lib/libgcc_s.dylib). For security matters,
that's like replacing, however.

In any case, that bug is not NEW any more.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #30 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Denis Excoffier from comment #29)
> (In reply to Iain Sandoe from comment #28)
> > Well, there is a fix - which is to update
> > /usr/lib/libgcc_s.dylib to a non-buggy version.
> I had understood that it was desirable not to replace libgcc_s.dylib.

so long as the system was maintained by the Vendor, then indeed it would be a
bad thing but… see below

(It's also somewhat like open-heart surgery - if you make a mistake doing the
exchange then you need to boot from a different disk to recover.  This makes it
unsuitable, without an installer, for casual users)

> Personally, i use the sed command (shown in comment #17) to create my own
> libgcc_s.1.dylib, i install it with GCC in /usr/local (or equivalent) and
> try to always link with it (and usually succeed since i don't use any
> libraries that are already linked with /usr/lib/libgcc_s.dylib). For
> security matters, that's like replacing, however.

I think replacing is the proper option in this case - the security issue is
moot for an unsupported EOL system.

> 
> In any case, that bug is not NEW any more.

Well, I think we should close as WONTFIX - because we don't have resources to
find a better solution - and replacing the library is an acceptable work-around
for EOL systems (I've now done this on both my i686 and ppc darwin9 boxes).

Note: that a replacement library MUST be built FAT if you want ppc64 to work
and FAT including ppc on i686-darwin9 if you want rosetta to work.
>From gcc-bugs-return-441238-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 22 19:53:27 2014
Return-Path: <gcc-bugs-return-441238-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26716 invoked by alias); 22 Jan 2014 19:53:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26300 invoked by uid 48); 22 Jan 2014 19:53:22 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error:=?UTF-8?Q? converting to ‘const std?=::vector<std::basic_string<char> >=?UTF-8?Q?’ from initializer list would use explicit constructor?Date: Wed, 22 Jan 2014 19:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58764-4-9oJ2bVJ141@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58764-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58764-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg02380.txt.bz2
Content-length: 336

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX764

--- Comment #10 from Marc Glisse <glisse at gcc dot gnu.org> ---
       vector() _GLIBCXX_NOEXCEPT : _Base() { }
       list() _GLIBCXX_NOEXCEPT

I think that's wrong, the default construction of the allocator may throw,
hence the conditional noexcept I was suggesting in comment #3.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fxcoudert at gcc dot gnu.org
         Resolution|---                         |WONTFIX

--- Comment #31 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
WONTFIX sounds reasonable

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[gcc@Denis-Excoffier.org]

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

--- Comment #32 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
(In reply to Francois-Xavier Coudert from comment #31)
> WONTFIX sounds reasonable
Okay.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2021-Februar
                   |                            |y/565950.html
           Keywords|                            |patch
         Resolution|WONTFIX                     |---
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #33 from Eric Gallager <egallager at gcc dot gnu.org> ---
Iain has a patch for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565950.html

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[cvs-commit at gcc dot gnu.org]

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

--- Comment #34 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b

commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Jan 18 20:09:10 2021 +0000

    dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097].

    This address one of the more long-standing and serious regressions
    for Darwin.  GCC emits unwind code by default on the assumption that
    the unwinder will be (of have the same capability) as the one in the
    current libgcc_s.  For Darwin platforms, this is not the case - some
    of them are based on the libgcc_s from GCC-4.2.1 and some are using
    the unwinder provided by libunwind (part of the LLVM project). The
    latter implementation has gradually adopted a section that deals with
    GNU unwind.

    The most serious problem for some of the platform versions is in
    handling DW_CFA_remember/restore_state pairs.  The DWARF description
    talks about these in terms of saving/restoring register rows; this is
    what GCC originally did (and is what the unwinders do for the Darwin
    versions based on libgcc_s).

    However, in r118068, this was changed so that not only the registers
    but also the current frame address expression were saved.  The unwind
    code assumes that the unwinder will do this; some of Darwin's unwinders
    do not, leading to lockups etc.  To date, the only solution has been
    to replace the system libgcc_s with a newer one which is not a viable
    solution for many end-users (since that means overwritting the one
    provided with the system installation).

    The fix here provides a target hook that allows the target to specify
    that the CFA should be reinstated after a DW_CFA_restore.  This fixes
    the issue (and also the closed WONTFIX of 44107).

    (As a matter of record, it also fixes reported Java issues if
     backported to GCC-5).

    gcc/ChangeLog:

            PR target/44107
            PR target/48097
            * config/darwin-protos.h (darwin_should_restore_cfa_state): New.
            * config/darwin.c (darwin_should_restore_cfa_state): New.
            * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New.
            * doc/tm.texi: Regenerated.
            * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE.
            * dwarf2cfi.c (connect_traces): If the target requests, restore
            the CFA expression after a DW_CFA_restore.
            * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[cvs-commit at gcc dot gnu.org]

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

--- Comment #35 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

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

commit r10-9502-gc3d51b2d2382d44b0463b7ebaf12f3b788c9027e
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Jan 18 20:09:10 2021 +0000

    dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097].

    This address one of the more long-standing and serious regressions
    for Darwin.  GCC emits unwind code by default on the assumption that
    the unwinder will be (of have the same capability) as the one in the
    current libgcc_s.  For Darwin platforms, this is not the case - some
    of them are based on the libgcc_s from GCC-4.2.1 and some are using
    the unwinder provided by libunwind (part of the LLVM project). The
    latter implementation has gradually adopted a section that deals with
    GNU unwind.

    The most serious problem for some of the platform versions is in
    handling DW_CFA_remember/restore_state pairs.  The DWARF description
    talks about these in terms of saving/restoring register rows; this is
    what GCC originally did (and is what the unwinders do for the Darwin
    versions based on libgcc_s).

    However, in r118068, this was changed so that not only the registers
    but also the current frame address expression were saved.  The unwind
    code assumes that the unwinder will do this; some of Darwin's unwinders
    do not, leading to lockups etc.  To date, the only solution has been
    to replace the system libgcc_s with a newer one which is not a viable
    solution for many end-users (since that means overwritting the one
    provided with the system installation).

    The fix here provides a target hook that allows the target to specify
    that the CFA should be reinstated after a DW_CFA_restore.  This fixes
    the issue (and also the closed WONTFIX of 44107).

    (As a matter of record, it also fixes reported Java issues if
     backported to GCC-5).

    gcc/ChangeLog:

            PR target/44107
            PR target/48097
            * config/darwin-protos.h (darwin_should_restore_cfa_state): New.
            * config/darwin.c (darwin_should_restore_cfa_state): New.
            * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New.
            * doc/tm.texi: Regenerated.
            * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE.
            * dwarf2cfi.c (connect_traces): If the target requests, restore
            the CFA expression after a DW_CFA_restore.
            * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.

    (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[cvs-commit at gcc dot gnu.org]

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

--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4

commit r9-9492-g6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Jan 18 20:09:10 2021 +0000

    dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097].

    This address one of the more long-standing and serious regressions
    for Darwin.  GCC emits unwind code by default on the assumption that
    the unwinder will be (of have the same capability) as the one in the
    current libgcc_s.  For Darwin platforms, this is not the case - some
    of them are based on the libgcc_s from GCC-4.2.1 and some are using
    the unwinder provided by libunwind (part of the LLVM project). The
    latter implementation has gradually adopted a section that deals with
    GNU unwind.

    The most serious problem for some of the platform versions is in
    handling DW_CFA_remember/restore_state pairs.  The DWARF description
    talks about these in terms of saving/restoring register rows; this is
    what GCC originally did (and is what the unwinders do for the Darwin
    versions based on libgcc_s).

    However, in r118068, this was changed so that not only the registers
    but also the current frame address expression were saved.  The unwind
    code assumes that the unwinder will do this; some of Darwin's unwinders
    do not, leading to lockups etc.  To date, the only solution has been
    to replace the system libgcc_s with a newer one which is not a viable
    solution for many end-users (since that means overwritting the one
    provided with the system installation).

    The fix here provides a target hook that allows the target to specify
    that the CFA should be reinstated after a DW_CFA_restore.  This fixes
    the issue (and also the closed WONTFIX of 44107).

    (As a matter of record, it also fixes reported Java issues if
     backported to GCC-5).

    gcc/ChangeLog:

            PR target/44107
            PR target/48097
            * config/darwin-protos.h (darwin_should_restore_cfa_state): New.
            * config/darwin.c (darwin_should_restore_cfa_state): New.
            * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New.
            * doc/tm.texi: Regenerated.
            * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE.
            * dwarf2cfi.c (connect_traces): If the target requests, restore
            the CFA expression after a DW_CFA_restore.
            * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.

    (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #37 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed on open branches, but is relevant on any older maintained outside of the
GCC  repo.