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.
Created attachment 56010 [details] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
the patch looks reasonable, please post it to gcc-patches@gcc.gnu.org
(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
Confirmed.
Is there any further action required to get this patch in? :)
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.
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)
(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.
(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?
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.
Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking bootstrap on x86_64-apple-darwin23
(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.
(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?
(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.
(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).
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.
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.
First patch pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a (forgot to add the PR number, silly me)
(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
This is fixed on trunk, but is needed on open release branches.
(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
(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.
(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.
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)
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)
NOTE: I adjusted the PR lines in the commit header so that the commits get reflected on the PR.
*** Bug 115006 has been marked as a duplicate of this bug. ***
(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?
(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?
(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?
(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,
(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.
> Yes, it was... Great, thank you.
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)
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)
The releases/gcc-11 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:378f50f4c32af5111893989bfc5a191d3aa27bb7 commit r11-11550-g378f50f4c32af5111893989bfc5a191d3aa27bb7 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> libcc1/ChangeLog: PR middle-end/111632 * libcc1plugin.cc: Fix include. * libcp1plugin.cc: Fix include. (cherry picked from commit 5213047b1d50af63dfabb5e5649821a6cb157e33)
fixed on open branches