Bug 111632 - gcc fails to bootstrap when using libc++
Summary: gcc fails to bootstrap when using libc++
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: https://gcc.gnu.org/pipermail/gcc-pat...
Keywords: build, patch
: 115006 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-09-28 16:26 UTC by Dimitry Andric
Modified: 2024-06-11 18:07 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-10-05 00:00:00


Attachments
Include safe-ctype.h after C++ standard headers, to avoid over-poisoning (1.66 KB, patch)
2023-09-28 16:26 UTC, Dimitry Andric
Details | Diff
Fix identifier poisoning in libcc1plugin and libc1plugin (495 bytes, patch)
2024-03-06 22:51 UTC, Dimitry Andric
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric 2023-09-28 16:26:01 UTC
As reported in https://bugs.freebsd.org/274041 and a number of related PRs, when building gcc's C++ sources against recent libc++ (>= 17), the poisoning of the ctype macros due to including safe-ctype.h before including C++ standard headers such as <list>, <map>, etc, causes many compilation errors, similar to:

  In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
  In file included from /home/dim/src/gcc/master/gcc/system.h:233:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from /usr/include/c++/v1/__format/formatter_integral.h:32:
  In file included from /usr/include/c++/v1/locale:202:
  /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces
    546 |     _LIBCPP_INLINE_VISIBILITY
        |     ^
  /usr/include/c++/v1/__config:813:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY'
    813 | #  define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
        |                                     ^
  /usr/include/c++/v1/__config:792:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI'
    792 |           __attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_VERSIONED_IDENTIFIER))))
        |                          ^
  In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
  In file included from /home/dim/src/gcc/master/gcc/system.h:233:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from /usr/include/c++/v1/__format/formatter_integral.h:32:
  In file included from /usr/include/c++/v1/locale:202:
  /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of declaration list
    547 |     char_type toupper(char_type __c) const
        |                                     ^
  /usr/include/c++/v1/__locale:553:48: error: too many arguments provided to function-like macro invocation
    553 |     const char_type* toupper(char_type* __low, const char_type* __high) const
        |                                                ^
  /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note: macro 'toupper' defined here
    146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
        |         ^

This is because libc++ uses different transitive includes than libstdc++, and some of those transitive includes pull in various ctype declarations (typically via <locale>).

There was already a special case for including <string> before safe-ctype.h, so move the rest of the C++ standard header includes to the same location, to fix the problem.
Comment 1 Dimitry Andric 2023-09-28 16:26:35 UTC
Created attachment 56010 [details]
Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
Comment 2 Richard Biener 2023-09-29 08:37:52 UTC
the patch looks reasonable, please post it to gcc-patches@gcc.gnu.org
Comment 3 Dimitry Andric 2023-09-29 08:49:00 UTC
(In reply to Richard Biener from comment #2)
> the patch looks reasonable, please post it to gcc-patches@gcc.gnu.org

https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631611.html
Comment 4 Andrew Pinski 2023-10-05 23:44:56 UTC
Confirmed.
Comment 5 Dimitry Andric 2023-10-26 16:46:57 UTC
Is there any further action required to get this patch in? :)
Comment 6 Sam James 2023-10-26 16:52:58 UTC
Try replying to the patch with 'ping'. I'm not a reviewer, but it both LGTM and we're using it in Gentoo with no reported problems.
Comment 7 Arsen Arsenović 2024-02-08 10:56:47 UTC
hm, somewhat unrelated to the patch, but is there any reason why stage 1 needs to have poisoning?  AFAIK future stages won't use libcxx anyway, and nobody 'works' on stage 1, so I see no reason to poison the symbols there (unless bootstrap is disabled, I guess)
Comment 8 Jakub Jelinek 2024-02-08 11:00:32 UTC
(In reply to Arsen Arsenović from comment #7)
> hm, somewhat unrelated to the patch, but is there any reason why stage 1
> needs to have poisoning?  AFAIK future stages won't use libcxx anyway, and
> nobody 'works' on stage 1, so I see no reason to poison the symbols there
> (unless bootstrap is disabled, I guess)

I certainly work on stage 1 all the time, that is where I develop everything I do
(of course once something is written, I test it with full bootstrap, but discovering issues there is too late).
Non-bootstrapped compiler has the added bonus that it defaults to -O0 -g building of objects when they are rebuilt when doing make inside of the gcc directory.
Comment 9 Arsen Arsenović 2024-02-08 12:34:21 UTC
(In reply to Jakub Jelinek from comment #8)
> I certainly work on stage 1 all the time, that is where I develop everything
> I do
> (of course once something is written, I test it with full bootstrap, but
> discovering issues there is too late).
> Non-bootstrapped compiler has the added bonus that it defaults to -O0 -g
> building of objects when they are rebuilt when doing make inside of the gcc
> directory.

right, I do the same, but that can be guarded by checking whether bootstrap is enabled, no?
Comment 10 Dimitry Andric 2024-02-29 15:10:41 UTC
Note there are other issues with poisoned identifiers, so I'll ask again: is a non-bootstrapped build even supposed to work, and officially supported, or not?

Or more qualified, is a non-bootstrapped build only officially supported when building on a host with gcc and libstdc++?

Otherwise, keeping this bug open makes no real sense, as there seems to be no movement at all on committing this patch. And it would make no sense to post any follow-up patches either.
Comment 11 Francois-Xavier Coudert 2024-03-06 13:38:30 UTC
Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking bootstrap on x86_64-apple-darwin23
Comment 12 Jonathan Wakely 2024-03-06 13:48:13 UTC
(In reply to Dimitry Andric from comment #10)
> Note there are other issues with poisoned identifiers, so I'll ask again: is
> a non-bootstrapped build even supposed to work, and officially supported, or
> not?

Yes.

> Or more qualified, is a non-bootstrapped build only officially supported
> when building on a host with gcc and libstdc++?

No.

But just because something is officially supported doesn't mean it's a high priority for everybody involved. Some things just take longer to resolve.
Comment 13 Iain Sandoe 2024-03-06 20:05:00 UTC
(In reply to Francois-Xavier Coudert from comment #11)
> Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking
> bootstrap on x86_64-apple-darwin23

confirmed the bootstrap fail and that the proposed patch fixes it (on x86_64-darwin23).  Now testing more widely on other Darwin versions.

For Darwin, this is a regression (caused by changes in the system SDK headers) - what is the situation with freeBSD?
Comment 14 Dimitry Andric 2024-03-06 20:15:52 UTC
(In reply to Iain Sandoe from comment #13)
> (In reply to Francois-Xavier Coudert from comment #11)
> > Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking
> > bootstrap on x86_64-apple-darwin23
> 
> confirmed the bootstrap fail and that the proposed patch fixes it (on
> x86_64-darwin23).  Now testing more widely on other Darwin versions.
> 
> For Darwin, this is a regression (caused by changes in the system SDK
> headers) - what is the situation with freeBSD?

The situation is that the FreeBSD port maintainer disabled the option to build the gcc ports without bootstrap, to work around the problem. :-)

I built the ports locally, but there are seem to have been some recent introductions of poisoned identifiers in plugins, which also have be fixed by adding #define INCLUDE_xxx statements at the top of the sources, before including system.h.

I will update the patches to build with gcc master, and re-attach/send them.
Comment 15 Iain Sandoe 2024-03-06 20:18:08 UTC
(In reply to Dimitry Andric from comment #14)
> (In reply to Iain Sandoe from comment #13)
> > (In reply to Francois-Xavier Coudert from comment #11)
> > > Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking
> > > bootstrap on x86_64-apple-darwin23
> > 
> > confirmed the bootstrap fail and that the proposed patch fixes it (on
> > x86_64-darwin23).  Now testing more widely on other Darwin versions.
> > 
> > For Darwin, this is a regression (caused by changes in the system SDK
> > headers) - what is the situation with freeBSD?
> 
> The situation is that the FreeBSD port maintainer disabled the option to
> build the gcc ports without bootstrap, to work around the problem. :-)
> 
> I built the ports locally, but there are seem to have been some recent
> introductions of poisoned identifiers in plugins, which also have be fixed
> by adding #define INCLUDE_xxx statements at the top of the sources, before
> including system.h.
> 
> I will update the patches to build with gcc master, and re-attach/send them.

FAOD, in the Darwin case this is a failure in the regular bootstrap at stage-1 (not an attempt to build --disable-bootstrap or a cross).
Comment 16 Dimitry Andric 2024-03-06 22:51:18 UTC
Created attachment 57639 [details]
Fix identifier poisoning in libcc1plugin and libc1plugin

Here is another patch that can be committed separately. It fixes the direct inclusion of <vector> in libcc1plugin.cc and libcp1plugin.cc, and replaces it with INCLUDE_VECTOR before system.h.
Comment 17 Dimitry Andric 2024-03-06 22:52:46 UTC
With both attached patches, I can build gcc master (gcc-14-9347-g790e0b478ea) with --disable-bootstrap, against libc++ 18 on FreeBSD 15-CURRENT, using clang 18 as host compiler.
Comment 18 Francois-Xavier Coudert 2024-03-07 13:41:01 UTC
First patch pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a
(forgot to add the PR number, silly me)
Comment 19 Dimitry Andric 2024-03-07 18:55:34 UTC
(In reply to Francois-Xavier Coudert from comment #18)
> First patch pushed as
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=9970b576b7e4ae337af1268395ff221348c4b34a
> (forgot to add the PR number, silly me)

Thank you. The next patch has been posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647394.html
Comment 20 Iain Sandoe 2024-03-29 19:41:05 UTC
This is fixed on trunk, but is needed on open release branches.
Comment 21 Dimitry Andric 2024-03-29 20:18:11 UTC
(In reply to Iain Sandoe from comment #20)
> This is fixed on trunk, but is needed on open release branches.

Indeed, please merge both commits:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5213047b1d50af63dfabb5e5649821a6cb157e33
Comment 22 Gerald Pfeifer 2024-03-29 23:30:18 UTC
(In reply to Dimitry Andric from comment #21)
> Indeed, please merge both commits:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=9970b576b7e4ae337af1268395ff221348c4b34a
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=5213047b1d50af63dfabb5e5649821a6cb157e33

Jakub, Ian, if you approve I volunteer to gradually push this to
open release branches.
Comment 23 Iain Sandoe 2024-03-30 06:14:02 UTC
(In reply to Gerald Pfeifer from comment #22)
> (In reply to Dimitry Andric from comment #21)
> > Indeed, please merge both commits:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=9970b576b7e4ae337af1268395ff221348c4b34a
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=5213047b1d50af63dfabb5e5649821a6cb157e33
> 
> Jakub, Ian, if you approve I volunteer to gradually push this to
> open release branches.

Geral, thanks for the offer:
 I have locally back ported and tested for GCC-13, so (assuming that this is approved) please start with gcc-12.
Comment 24 GCC Commits 2024-04-03 14:48:10 UTC
The releases/gcc-13 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:68057560ff1fc0fb2df38c2f9627a20c9a8da5c5

commit r13-8571-g68057560ff1fc0fb2df38c2f9627a20c9a8da5c5
Author: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Date:   Thu Mar 7 14:36:03 2024 +0100

    Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
    
    When building gcc's C++ sources against recent libc++, the poisoning of
    the ctype macros due to including safe-ctype.h before including C++
    standard headers such as <list>, <map>, etc, causes many compilation
    errors, similar to:
    
      In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
      In file included from /home/dim/src/gcc/master/gcc/system.h:233:
      In file included from /usr/include/c++/v1/vector:321:
      In file included from
      /usr/include/c++/v1/__format/formatter_bool.h:20:
      In file included from
      /usr/include/c++/v1/__format/formatter_integral.h:32:
      In file included from /usr/include/c++/v1/locale:202:
      /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute
      only applies to structs, variables, functions, and namespaces
        546 |     _LIBCPP_INLINE_VISIBILITY
            |     ^
      /usr/include/c++/v1/__config:813:37: note: expanded from macro
      '_LIBCPP_INLINE_VISIBILITY'
        813 | #  define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
            |                                     ^
      /usr/include/c++/v1/__config:792:26: note: expanded from macro
      '_LIBCPP_HIDE_FROM_ABI'
        792 |
        __attribute__((__abi_tag__(_LIBCPP_TOSTRING(
      _LIBCPP_VERSIONED_IDENTIFIER))))
            |                          ^
      In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
      In file included from /home/dim/src/gcc/master/gcc/system.h:233:
      In file included from /usr/include/c++/v1/vector:321:
      In file included from
      /usr/include/c++/v1/__format/formatter_bool.h:20:
      In file included from
      /usr/include/c++/v1/__format/formatter_integral.h:32:
      In file included from /usr/include/c++/v1/locale:202:
      /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of
      declaration list
        547 |     char_type toupper(char_type __c) const
            |                                     ^
      /usr/include/c++/v1/__locale:553:48: error: too many arguments
      provided to function-like macro invocation
        553 |     const char_type* toupper(char_type* __low, const
        char_type* __high) const
            |                                                ^
      /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note:
      macro 'toupper' defined here
        146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
            |         ^
    
    This is because libc++ uses different transitive includes than
    libstdc++, and some of those transitive includes pull in various ctype
    declarations (typically via <locale>).
    
    There was already a special case for including <string> before
    safe-ctype.h, so move the rest of the C++ standard header includes to
    the same location, to fix the problem.
    
            PR middle-end/111632
    
    gcc/ChangeLog:
    
            * system.h: Include safe-ctype.h after C++ standard headers.
    
    Signed-off-by: Dimitry Andric <dimitry@andric.com>
    (cherry picked from commit 9970b576b7e4ae337af1268395ff221348c4b34a)
Comment 25 GCC Commits 2024-04-03 14:49:51 UTC
The releases/gcc-13 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

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

commit r13-8572-ge95ab9e60ce1d9aa7751d79291133fd5af9209d7
Author: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Date:   Sat Mar 16 09:50:00 2024 +0100

    libcc1: fix <vector> include
    
    Use INCLUDE_VECTOR before including system.h, instead of directly
    including <vector>, to avoid running into poisoned identifiers.
    
    Signed-off-by: Dimitry Andric <dimitry@andric.com>
    
            PR middle-end/111632
    
    libcc1/ChangeLog:
    
            * libcc1plugin.cc: Fix include.
            * libcp1plugin.cc: Fix include.
    
    (cherry picked from commit 5213047b1d50af63dfabb5e5649821a6cb157e33)
Comment 26 Iain Sandoe 2024-04-03 14:50:50 UTC
NOTE: I adjusted the PR lines in the commit header so that the commits get reflected on the PR.
Comment 27 Francois-Xavier Coudert 2024-05-09 11:17:45 UTC
*** Bug 115006 has been marked as a duplicate of this bug. ***
Comment 28 Liviu Ionescu 2024-05-09 11:30:06 UTC
(In reply to Francois-Xavier Coudert from comment #27)
> *** Bug 115006 has been marked as a duplicate of this bug. ***

11506 is related to gcov.cc, does the existing fixes also apply to this file?
Comment 29 Dimitry Andric 2024-05-09 11:47:27 UTC
(In reply to Liviu Ionescu from comment #28)
> (In reply to Francois-Xavier Coudert from comment #27)
> > *** Bug 115006 has been marked as a duplicate of this bug. ***
> 
> 11506 is related to gcov.cc, does the existing fixes also apply to this file?

https://gcc.gnu.org/g:9970b576b7e4ae337af1268395ff221348c4b34a fixes system.h which is also included by gcov.cc, so I would expect that to work. Which version of gcc were you building?
Comment 30 Liviu Ionescu 2024-05-09 12:07:14 UTC
(In reply to Dimitry Andric from comment #29)
> ... fixes system.h which is also included by gcov.cc

ok, great.

> Which version of gcc were you building?

in the reported bug I was building 13.2.

was the fix backported to older versions?
Comment 31 Iain Sandoe 2024-05-09 12:12:05 UTC
(In reply to Liviu Ionescu from comment #30)
> (In reply to Dimitry Andric from comment #29)
> > ... fixes system.h which is also included by gcov.cc
> 
> ok, great.
> 
> > Which version of gcc were you building?
> 
> in the reported bug I was building 13.2.
> 
> was the fix backported to older versions?

so far, the fix has baeen back ported for 13.3 .. it is on the list to be back ported for 12.4 and 11.5,
Comment 32 Jakub Jelinek 2024-05-09 12:12:43 UTC
(In reply to Liviu Ionescu from comment #30)
> in the reported bug I was building 13.2.
> 
> was the fix backported to older versions?

Yes, it was, as can be seen above.  Though only in March 2024, so it couldn't have affected gcc 13.2 which was released more than 9 months ago.  It is fixed on gcc 13.2.1 snapshots after those commits and will be in gcc 13.3, right now planned for release in less than 2 weeks from now.
Comment 33 Liviu Ionescu 2024-05-09 12:34:49 UTC
> Yes, it was...

Great, thank you.
Comment 34 GCC Commits 2024-06-11 18:07:44 UTC
The releases/gcc-12 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:8f11ed1c58e14421ba4be1652764fc47fdce8dc7

commit r12-10547-g8f11ed1c58e14421ba4be1652764fc47fdce8dc7
Author: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Date:   Sat Mar 16 09:50:00 2024 +0100

    libcc1: fix <vector> include
    
    Use INCLUDE_VECTOR before including system.h, instead of directly
    including <vector>, to avoid running into poisoned identifiers.
    
    Signed-off-by: Dimitry Andric <dimitry@andric.com>
    
            PR middle-end/111632
    
    libcc1/ChangeLog:
    
            * libcc1plugin.cc: Fix include.
            * libcp1plugin.cc: Fix include.
    
    (cherry picked from commit 5213047b1d50af63dfabb5e5649821a6cb157e33)
Comment 35 GCC Commits 2024-06-11 18:07:49 UTC
The releases/gcc-12 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

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

commit r12-10548-ga995fded34fe488153b06bb41e026277f01efded
Author: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Date:   Thu Mar 7 14:36:03 2024 +0100

    Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
    
    When building gcc's C++ sources against recent libc++, the poisoning of
    the ctype macros due to including safe-ctype.h before including C++
    standard headers such as <list>, <map>, etc, causes many compilation
    errors, similar to:
    
      In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
      In file included from /home/dim/src/gcc/master/gcc/system.h:233:
      In file included from /usr/include/c++/v1/vector:321:
      In file included from
      /usr/include/c++/v1/__format/formatter_bool.h:20:
      In file included from
      /usr/include/c++/v1/__format/formatter_integral.h:32:
      In file included from /usr/include/c++/v1/locale:202:
      /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute
      only applies to structs, variables, functions, and namespaces
        546 |     _LIBCPP_INLINE_VISIBILITY
            |     ^
      /usr/include/c++/v1/__config:813:37: note: expanded from macro
      '_LIBCPP_INLINE_VISIBILITY'
        813 | #  define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
            |                                     ^
      /usr/include/c++/v1/__config:792:26: note: expanded from macro
      '_LIBCPP_HIDE_FROM_ABI'
        792 |
        __attribute__((__abi_tag__(_LIBCPP_TOSTRING(
      _LIBCPP_VERSIONED_IDENTIFIER))))
            |                          ^
      In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
      In file included from /home/dim/src/gcc/master/gcc/system.h:233:
      In file included from /usr/include/c++/v1/vector:321:
      In file included from
      /usr/include/c++/v1/__format/formatter_bool.h:20:
      In file included from
      /usr/include/c++/v1/__format/formatter_integral.h:32:
      In file included from /usr/include/c++/v1/locale:202:
      /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of
      declaration list
        547 |     char_type toupper(char_type __c) const
            |                                     ^
      /usr/include/c++/v1/__locale:553:48: error: too many arguments
      provided to function-like macro invocation
        553 |     const char_type* toupper(char_type* __low, const
        char_type* __high) const
            |                                                ^
      /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note:
      macro 'toupper' defined here
        146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
            |         ^
    
    This is because libc++ uses different transitive includes than
    libstdc++, and some of those transitive includes pull in various ctype
    declarations (typically via <locale>).
    
    There was already a special case for including <string> before
    safe-ctype.h, so move the rest of the C++ standard header includes to
    the same location, to fix the problem.
    
            PR middle-end/111632
    
    gcc/ChangeLog:
    
            * system.h: Include safe-ctype.h after C++ standard headers.
    
    Signed-off-by: Dimitry Andric <dimitry@andric.com>
    (cherry picked from commit 9970b576b7e4ae337af1268395ff221348c4b34a)