libstdc++ -> libiconv depenedncy: implications on in-tree libiconv
Evening! While working on https://inbox.sourceware.org/20240414001113.1698685-1-ar...@aarsen.me/ I had noticed that libstdc++ currently does not get linked against an in-tree libiconv, as the in-tree libiconv is only a host library. Should it also be a target one? With a quick hack of copying libiconv in the build dir as arm64-apple-darwin21.6.0/libiconv, I had managed to get libstdc++ not to link system libiconv. This implies that simply enabling building iconv as a target library also would suffice. There are considerations with this, though: naturally, this implies that libstdc++ now contains a copy of libiconv as it gets linked in as a '.a'. It appears not to cause a copy of the symbols to be emitted on this platform: cfarm104:gcc-build arsen$ objdump --syms ./aarch64-apple-darwin21.6.0/libstdc++-v3/src/.libs/libstdc++.6.dylib | grep iconv cfarm104:gcc-build arsen$ ... however, even in that case, the symbols are renamed AFAICT: cfarm104:gcc-build arsen$ objdump --syms ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a | grep iconv ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(iconv.o): file format mach-o arm64 000dbbe0 g O __DATA,__data __libiconv_version 00013730 g F __TEXT,__text _iconv_canonicalize 00013080 g F __TEXT,__text _libiconv 000130c0 g F __TEXT,__text _libiconv_close 00012ca0 g F __TEXT,__text _libiconv_open 000130e0 g F __TEXT,__text _libiconv_open_into 00013468 g F __TEXT,__text _libiconvctl 000135ac g F __TEXT,__text _libiconvlist ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(localcharset.o): file format mach-o arm64 ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(relocatable.o): file format mach-o arm64 00e4 g F __TEXT,__text _libiconv_relocate 01e0 g F __TEXT,__text _libiconv_relocate2 g F __TEXT,__text _libiconv_set_relocation_prefix ... so, that might be okay? What do you think? Should be build a libiconv as a target lib for libstdc++ use? TIA, have a lovely night! -- Arsen Arsenović signature.asc Description: PGP signature
Re: Scaling -fmacro-prefix-map= to thousands entries
Hi,
Sergei Trofimovich via Gcc writes:
> Sounds good. Do you have any preference over specific syntax? My
> suggestions would be:
>
> 1. `-fmacro-prefix-map=file-name`: if `file-name` there is not in `key=val`
>format then treat it as file
> 2. `-fmacro-prefix-map=@file-name`: use @ as a signal to use file
> 3. `fmacro-prefix-map-file=file-name`: use a new option
>
>> Btw, I thought we have response files to deal with command-line limits,
>> why doesn't that work here? I see the driver expands response files
>> but IIRC it also builds those when the command-line gets too large
>> and uses it for the environment and the cc1 invocation? If it doesn't
>> do the latter why not fix it that way?
>
> Yeah, in theory response files would extend the limit. In practice `gcc`
> always extends response files internally into a single
> `COLLECT_GCC_OPTIONS` option and hits the environment variable limit
> very early:
>
> https://gcc.gnu.org/PR111527
Doesn't it make more sense to fix this? The issue is more general than
just this option (even if manifesting like so today).
Can the COLLECT_GCC_OPTIONS consumers deal with argfiles?
> Example reproducer:
>
> $ for i in `seq 1 1000`; do printf -- "-fmacro-prefix-map=%0*d=%0*d\n"
> 200 1 200 2; done > a.rsp
> $ touch a.c; gcc @a.rsp -c a.c
> gcc: fatal error: cannot execute 'cc1': execv: Argument list too long
> compilation terminated.
>
> And if you want to look at the gory details:
>
> $ strace -f -etrace=execve -s 100 -v -v -v gcc @a.rsp -c a.c
> ...
> [pid78] execve("cc1", ["cc1", "-quiet", "a.c", "-quiet", "-dumpbase",
> "a.c", "-dumpbase-ext", ".c", "-mtune=generic", "-march=x86-64",
> "-fmacro-prefix-map=...=...",
> "-fmacro-prefix-map=...=...",
> ...],
> [...,
> "COLLECT_GCC=gcc",
> "COLLECT_GCC_OPTIONS='-fmacro-prefix-map=...=...'
> '-fmacro-prefix-map=...=...' ... '-c' '-mtune=generic' '-march=x86-64'"]) =
> -1 E2BIG (Argument list too long)
>
> Note how `gcc` not only expands response file into an argument list
> (that is not too bad) but also duplicates the whole list as a single
> `COLLECT_GCC_OPTIONS=...` environment variable with added quoting on
> top.
>
> Would be nice if `gcc` just passed response files around as is :)
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: Report from the additional type errors for GCC 14 BoF at Cauldron
Sam James via Gcc writes: > Florian Weimer via Gcc writes: > >> My understanding of the consensus goes as follows: >> >> * We want to make some changes in this area for GCC 14. >> * We should do the same thing that Clang does: default to the relevant >> -Werror= options. >> * Unlike regular warnings, these warnings-as-errors should also apply >> to system headers. >> * At least implict-int and implicit-function-declaration should be >> upgraded to errors in this way. >> * It's too early to make the () changes and bool-as-keyword from C2X >> for GCC 14. >> * We should fix the missing scope of the int-conversion warnings >> (PR109827). Likweise for incompatible-pointer-types (PR109826). >> >> Is this summary accurate? >> > > I wasn't there, but this reflects my understanding & what I would've > said if I could've attended. > >> I think the open issues are: >> >> * Do we want to implement something else beside implicit-int and >> implicit-function-declaration? (Candidates are int-conversion and >> incompatible-pointer-types, and the void vs non-void part of >> return-type, maybe others as previously discussed on the list.) > > Ideally, I'd like both int-conversion + incompatible-pointer-types in > this cycle, but if we have to defer one, I'd say to keep int-conversion. +1, this seems reasonable. I'm not sure I can imagine any even half-legitimate use for falling off the end of functions and similar, so perhaps we should also take return-type? Is that part of C23? > A lot of the low hanging fruit is already fixed there, with the only > big remaining blocker being Vala (which is a > compiler/transpiler). They've indicated they're not that fussed > unless/until GCC changes. > > Putting it another way: I don't think waiting a year or two > would actually help the situation much. Yes, at best it helps with the schedule. >> * How do we divide up the test suite cleanup work? > > Once there's some patches to work with, I'm happy to do a good > chunk (obviously). > > IIRC Jakub and others indicated that the priority is to preserve > the test cases (and hence pass appropriate flags) rather than fix them > up, to avoid inadvertently testing the wrong thing. We could possibly even automate that, by checking what new errors appeared per testcase and inverting them. >> >> Thanks, >> Florian -- Arsen Arsenović signature.asc Description: PGP signature
Re: Question on -fwrapv and -fwrapv-pointer
Qing Zhao writes: > Even though unsigned integer overflow is well defined, it might be > unintentional, shall we warn user about this? This would be better addressed by providing operators or functions that do overflow checking in the language, so that they can be explicitly used where overflow is unexpected. One could easily imagine a scenario where overflow is not expected in some region of code but is in the larger application. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists
Tobias Burnus writes: > Attached an old patch. See attached patch for the current one. > > Difference is one line: the warning that is shown in the example output > below. Python-wise, the changes seem fine. Unsure if it does the right thing, though, since I'm not familiar with the full script. -- Arsen Arsenović signature.asc Description: PGP signature
Re: Request for Software Usage License
孟祥龙 writes: > Dear Teacher, > > > I hope this email finds you well. I am writing to kindly request a software > usage license for the GCC for our research and development activities. We > believe that this software would greatly contribute to our work and enable us > to achieve our research goals more effectively. > > > Given the nature of our projects and our commitment to advancing knowledge, > we are excited about the potential of incorporating this software into our > workflow. > > > We assure you that the software will be used strictly for non-commercial > research purposes. We are prepared to comply with any terms and conditions > outlined by the software provider regarding its usage and dissemination of > results. > > > If possible, we kindly request information about the licensing process, any > associated costs, and the steps required to acquire the license. We > appreciate your consideration of our request and would be grateful for any > guidance you can provide in this matter. > > > Thank you for your attention to this request. We look forward to your > response. Hi, GCC is Free Software, as such you can use it for any purpose, commercial or otherwise. See https://www.gnu.org/philosophy/free-sw.html for a description of what free software is. In particular, GCC is licensed under the GNU GPL version 3, or any later version[1], with some bits of code also being under the GCC Runtime Libraries Exception[2] or the GNU Lesser GPL version 3, or any later version[3]. I must personally ask that you consider also releasing your work as free software, and to support free software development and free systems, but you're not under obligation to do so. Please see the license texts for a description of your rights and obligations. [1] https://www.gnu.org/licenses/gpl-3.0.html [2] https://www.gnu.org/licenses/gcc-exception-3.1.html [3] https://www.gnu.org/licenses/lgpl-3.0.html Hope that helps, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH] libstdc++ Add cstdarg to freestanding
Jonathan Wakely writes: > On Fri, 21 Jul 2023 at 22:23, Paul M. Bendixen via Libstdc++ > wrote: >> >> P1642 includes the header cstdarg to the freestanding implementation. >> This was probably left out by accident, this patch puts it in. >> Since this is one of the headers that go in whole cloth, there should be no >> further actions needed. > > Thanks for the patch. I agree that should be freestanding, > but I think and were also missed from the > change. Arsen? Indeed, we should include all three, and according to [compliance], there's a couple more headers that we should provide (cwchar, cstring, cerrno, and cmath, but these are probably significantly more involved, so we can handle them separately). As guessed, the omission was not intentional. If you could, add those two to the patch as well, edit Makefile.am and regenerate using automake 1.15.1, and see https://gcc.gnu.org/contribute.html wrt. changelogs in commit messages. Thank you! Have a lovely day :-) [compliance]: https://eel.is/c++draft/compliance > Also, the patch should change include/Makefile.am as well (the .in > file is autogenerated from that one). > > >> This might be related to PR106953, but since that one touches the partial >> headers I'm not sure The headers mentioned in this PR are provided in freestanding, partially, in 13 already, indeed. >> /Paul M. Bendixen >> >> -- >> • − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− >> •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −// -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH v2 2/2] libstdc++: Replace all manual FTM definitions and use
Jonathan Wakely writes: > [..snip..] > Thanks for adding the comments like "// C++ < 20". > > I think in the comment on the #endif can be just __cpp_lib_any > rather than defined(__cpp_lib_any). Similarly for > __cpp_lib_atomic_float in . Oh, and __cpp_lib_atomic_ref. And > in , and several others. I think I'd like those to be > consistent, and usually we just name the macro in the #endif comment, > sometimes abbreviated for clarity, without the explicit defined(...). ACK. Fixed all of those. > For this error in please add <> around "version" and remove > the question mark: > +# error "libstdc++ bug: no lock-free atomics but they were emitted in > version?" > > Similarly, please remove the question marks from the two #errors in > : > +# error "libstdc++ bug: is_corresponding_member and > is_layout_compatible are provided but their FTM is not set?" > +# error "libstdc++ bug: is_pointer_interconvertible available but FTM > unset?" > > In you have: > +# error "libstdc++ bug: string_contents not defined when it should be" > That should be contains, not contents. > > OK for trunk with the #error changes. The #endif cleanup can be > fixed in a follow-up. > > It seems like there's some inconsistency (probably some preexisting) > about whether you use: > #if __cpp_lib_xxx > or > #ifdef __cpp_lib_xxx > That can be tidied up later. > > Currently we define many of the macros in the "bits" headers, e.g. in > bits/stl_iterator.h > > +#define __glibcxx_want_constexpr_iterator > +#define __glibcxx_want_array_constexpr > +#define __glibcxx_want_make_reverse_iterator > +#define __glibcxx_want_move_iterator_concept > +#include > > We should consider only defining those in itself. So that > when other parts of the lib include bits/stl_iterator.h they don't > define the macros. That would mean that > __cpp_lib_make_reverse_iterator is not defined by and > , for example. Even though they do actually provide the > features, the macro would only be defined by and . > This might encourage users to include the right headers, instead of > relying on transitive includes. > If we do that, our own internal checks for features would all need to use: > #if __glibcxx_make_reverse_iterator > because they wouldn't have the __cpp_lib_xxx macro, because they only > include the internal bits header not . > > That's for another day though. Yes, that sounds quite reasonable. I like the idea that headers should export narrower FTMs. Pushed. Thanks :-) -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH v2 1/2] libstdc++: Implement more maintainable header
Arsen Arsenović writes:
> This commit replaces the ad-hoc logic in with an AutoGen
> database that (mostly) declaratively generates a version.h bit which
> combines all of the FTM logic across all headers together.
>
> This generated header defines macros of the form __glibcxx_foo,
> equivalent to their __cpp_lib_foo variants, according to rules specified
> in version.def and, optionally, if __glibcxx_want_foo or
> __glibcxx_want_all are defined, also defines __cpp_lib_foo forms with
> the same definition.
>
> libstdc++-v3/ChangeLog:
>
> * include/Makefile.am (bits_freestanding): Add version.h.
> (allcreated): Add version.h.
> (${bits_srcdir}/version.h): New rule. Regenerates
> version.h out of version.{def,tpl}.
> * include/Makefile.in: Regenerate.
> * include/bits/version.def: New file. Declares a list of
> all feature test macros, their values and their preconditions.
> * include/bits/version.tpl: New file. Turns version.def
> into a sequence of #if blocks.
> * include/bits/version.h: New file. Generated from
> version.def.
> * include/std/version: Replace with a __glibcxx_want_all define
> and bits/version.h include.
> ---
> This patchset is a rebase of
> https://inbox.sourceware.org/libstdc++/20230429101640.1697750-1-ar...@aarsen.me/
>
> ... passing the same two checks (difall / vercmp) I wrote for the first
> pass. Testsuite runs are still pending.
>
> Changes in this revision:
> - Replace the ${bits_srcdir}/version.h rule with a update-version phony,
> - Add the new __cpp_lib_chrono value,
> - Add __cpp_lib_{ranges_{contains,find_last,fold,iota}},
> - Add comments to various replaced conditions which summarize their
> condition,
> - Correct a few minor errors spotted in review
>
> OK for trunk (if those testsuite runs end up clean)?
Same tests as the first time around passed on x86_64-pc-linux-gnu (that
is, regression testing + a large libstdc++ harness).
--
Arsen Arsenović
signature.asc
Description: PGP signature
[PATCH v2 1/2] libstdc++: Implement more maintainable header
This commit replaces the ad-hoc logic in with an AutoGen
database that (mostly) declaratively generates a version.h bit which
combines all of the FTM logic across all headers together.
This generated header defines macros of the form __glibcxx_foo,
equivalent to their __cpp_lib_foo variants, according to rules specified
in version.def and, optionally, if __glibcxx_want_foo or
__glibcxx_want_all are defined, also defines __cpp_lib_foo forms with
the same definition.
libstdc++-v3/ChangeLog:
* include/Makefile.am (bits_freestanding): Add version.h.
(allcreated): Add version.h.
(${bits_srcdir}/version.h): New rule. Regenerates
version.h out of version.{def,tpl}.
* include/Makefile.in: Regenerate.
* include/bits/version.def: New file. Declares a list of
all feature test macros, their values and their preconditions.
* include/bits/version.tpl: New file. Turns version.def
into a sequence of #if blocks.
* include/bits/version.h: New file. Generated from
version.def.
* include/std/version: Replace with a __glibcxx_want_all define
and bits/version.h include.
---
This patchset is a rebase of
https://inbox.sourceware.org/libstdc++/20230429101640.1697750-1-ar...@aarsen.me/
... passing the same two checks (difall / vercmp) I wrote for the first
pass. Testsuite runs are still pending.
Changes in this revision:
- Replace the ${bits_srcdir}/version.h rule with a update-version phony,
- Add the new __cpp_lib_chrono value,
- Add __cpp_lib_{ranges_{contains,find_last,fold,iota}},
- Add comments to various replaced conditions which summarize their
condition,
- Correct a few minor errors spotted in review
OK for trunk (if those testsuite runs end up clean)?
libstdc++-v3/include/Makefile.am | 10 +-
libstdc++-v3/include/Makefile.in | 10 +-
libstdc++-v3/include/bits/version.def | 1597
libstdc++-v3/include/bits/version.h | 1942 +
libstdc++-v3/include/bits/version.tpl | 210 +++
libstdc++-v3/include/std/version | 350 +
6 files changed, 3770 insertions(+), 349 deletions(-)
create mode 100644 libstdc++-v3/include/bits/version.def
create mode 100644 libstdc++-v3/include/bits/version.h
create mode 100644 libstdc++-v3/include/bits/version.tpl
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index a880e8ee227..9c71c75393a 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -154,6 +154,7 @@ bits_freestanding = \
${bits_srcdir}/stl_raw_storage_iter.h \
${bits_srcdir}/stl_relops.h \
${bits_srcdir}/stl_uninitialized.h \
+ ${bits_srcdir}/version.h \
${bits_srcdir}/string_view.tcc \
${bits_srcdir}/uniform_int_dist.h \
${bits_srcdir}/unique_ptr.h \
@@ -1113,7 +1114,8 @@ allcreated = \
${host_builddir}/c++config.h \
${host_builddir}/largefile-config.h \
${thread_host_headers} \
- ${pch_build}
+ ${pch_build} \
+ ${bits_srcdir}/version.h
# Here are the rules for building the headers
all-local: ${allstamped} ${allcreated}
@@ -1463,6 +1465,12 @@ ${pch3_output}: ${pch3_source} ${pch2_output}
-mkdir -p ${pch3_output_builddir}
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) -O2 -g ${pch3_source} -o $@
+# AutoGen .
+.PHONY: update-version
+update-version:
+ cd ${bits_srcdir} && \
+ autogen version.def
+
# The real deal.
install-data-local: install-headers
install-headers:
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 0ff875b280b..f5b04d3fe8a 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -509,6 +509,7 @@ bits_freestanding = \
${bits_srcdir}/stl_raw_storage_iter.h \
${bits_srcdir}/stl_relops.h \
${bits_srcdir}/stl_uninitialized.h \
+ ${bits_srcdir}/version.h \
${bits_srcdir}/string_view.tcc \
${bits_srcdir}/uniform_int_dist.h \
${bits_srcdir}/unique_ptr.h \
@@ -1441,7 +1442,8 @@ allcreated = \
${host_builddir}/c++config.h \
${host_builddir}/largefile-config.h \
${thread_host_headers} \
- ${pch_build}
+ ${pch_build} \
+ ${bits_srcdir}/version.h
# Host includes for threads
@@ -1937,6 +1939,12 @@ ${pch3_output}: ${pch3_source} ${pch2_output}
-mkdir -p ${pch3_output_builddir}
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) -O2 -g ${pch3_source} -o $@
+# AutoGen .
+${bits_srcdir}/version.h: ${bits_srcdir}/version.def \
+ ${bits_srcdir}/version.tpl
+ cd $(@D) && \
+ autogen version.def
+
# The real deal.
install-data-local: install-headers
install-headers:
diff --git a/libstdc++-v3/include/bits/version.def
b/libstdc++-v3/include/bits/version.def
new file mode 100644
index 000..e63715e17e7
--- /dev/null
+++
Re: [PATCHv2] Use toplevel configure for GMP and MPFR for gdb
Matthias Klose via Gcc-patches writes: > On 10.11.22 20:05, apinski--- via Binutils wrote: >> From: Andrew Pinski >> This patch uses the toplevel configure parts for GMP/MPFR for >> gdb. The only thing is that gdb now requires MPFR for building. >> Before it was a recommended but not required library. >> Also this allows building of GMP and MPFR with the toplevel >> directory just like how it is done for GCC. >> We now error out in the toplevel configure of the version >> of GMP and MPFR that is wrong. >> OK after GDB 13 branches? Build gdb 3 ways: >> with GMP and MPFR in the toplevel (static library used at that point for >> both) >> With only MPFR in the toplevel (GMP distro library used and MPFR built from >> source) >> With neither GMP and MPFR in the toplevel (distro libraries used) > > this still seems to be broken for a gdb trunk build, using GMP and MPFR system > libraries: > > linking gdb: > > [...] > ../gnulib/import/libgnu.a -Lyes/lib -lmpfr -lgmp -lsource-highlight > -lboost_regex -lxxhash -ldebuginfod -ldl > -Wl,--dynamic-list=/<>/gdb/proc-service.list > ./libtool: line 5209: cd: yes/lib: No such file or directory > libtool: link: cannot determine absolute directory name of `yes/lib' > make[3]: *** [Makefile:2174: gdb] Error 1 > make[3]: Leaving directory '/<>/build/default/gdb' > > full build log at > https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/15065515/+listing-archive-extra > > > the toplevel config.log has: > > configure:8183: checking for the correct version of gmp.h > configure:8202: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 > configure:8202: $? = 0 > configure:8220: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 > configure:8220: $? = 0 > configure:8221: result: yes > configure:8237: checking for the correct version of mpfr.h > configure:8255: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 > configure:8255: $? = 0 > configure:8272: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 > configure:8272: $? = 0 > configure:8273: result: yes > configure:8342: checking for the correct version of the gmp/mpfr libraries > configure:8366: x86_64-linux-gnu-gcc -o conftest -Iyes/include -fPIC > conftest.c -Lyes/lib -lmpfr -lgmp >&5 > configure:8366: $? = 0 > configure:8367: result: yes > configure:8615: checking for isl 0.15 or later > configure:8628: x86_64-linux-gnu-gcc -o conftest -Iyes/include -fPIC > -lisl > -Lyes/lib -lmpfr -lgmp conftest.c -lisl -lgmp >&5 > configure:8628: $? = 0 Seems that you're passing simply --with-mpfr, however: AC_ARG_WITH(mpfr, [AS_HELP_STRING([--with-mpfr=PATH], [specify prefix directory for installed MPFR package. Equivalent to --with-mpfr-include=PATH/include plus --with-mpfr-lib=PATH/lib])]) ... so it is interpreted to mean that the prefix MPFR is installed in is yes/include (perhaps we should warn for the 'yes' case - that'd be less confusing). I think you should be able to get away without passing --with-mpfr at all if your toolchain has mpfr available (and there's no mpfr in the toplevel, to inhibit the toplevel trying to build its own copy). Hope that helps, have a lovely night. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb
Joseph Myers writes: > On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote: > >> Yes. Libtool was forked over a decade ago. My next project is syncing >> upstream and us back up. Unsure about pkg.m4. > > Note as per previous discussions that libtool commit > 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting in GCC when > updating libtool because of incompatible usage of --with-sysroot. I wanted to, somehow, coalesce the two back together, so that both are available. Presumably, this means adding an option to libtool to accept host-sysroot or such, but I haven't done too much looking into this. Is my interpretation of the issue correct? (i.e. GCC uses sysroot to mean *target* sysroot rather than host sysroot) > Reportedly libtool is based on upstream commit > 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622 (with *many* local changes, some > of which may not be present upstream). Thanks, sharing that base will save me a good amount of time. Have a lovely night. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb
Eric Gallager writes: > Hi, with the updates to libtool.m4 and pkg.m4, those files originally > come from upstream libtool and pkg-config, correct? Won't patching > GCC's local copies make re-syncing them with upstream > libtool/pkg-config more difficult, or have these patches already been > sent there, too? Also, when updating .m4 files, aren't you supposed to > increment the serial number that they have near the top, too? Yes. Libtool was forked over a decade ago. My next project is syncing upstream and us back up. Unsure about pkg.m4. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH 24/24] toplevel: Makefile.def: add install-strip dependency on libsframe
Jeff Law writes: > OK. > > I know I skipped over a few. I'll try to get those wrapped up shortly. Thanks, I've pushed all of those (since I received all the reviews). > While I strongly dislike git submodules, this may be one of those occasions > where their use might be justified. Something to ponder because these shared > toplevel files are painful to keep sync'd. I'm not sure how viable this is in the toplevel directory. The inverse is quite possible: the shared build system contains all the other directories as modules, but that's undesirable for other reasons, I presume. I'll see if there's some solution. > jeff -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH 2/2] libstdc++: Replace all manual FTM definitions and use
Jonathan Wakely writes: > On Sat, 29 Apr 2023 at 11:24, Arsen Arsenović via Libstdc++ < > libstd...@gcc.gnu.org> wrote: > >> libstdc++-v3/ChangeLog: >> >> * libsupc++/typeinfo: Switch to bits/version.h for >> __cpp_lib_constexpr_typeinfo. >> >> > Does this change have an impact on compilation speed? > With this change we'll be re-including bits/version.h multiple times in > most compilations, and unlike other headers the preprocessor can't optimize > away the second and subsequent times its' included, because the header > isn't idempotent. > It will only affect the preprocessing phase, which is a fraction of the > time taken by template instantiation and middle end optimizations, but I'd > like to know it's not *too* expensive before committing to this approach. > Whoops, I forgot to provide these measurements. ~/gcc/build$ time for x in $(seq 1 100); do _pfx/bin/g++ -x c++ - \ -S -o /dev/null <<< '#include '; done real 3m4.104s user 2m53.394s sys 0m10.132s ~/gcc/pristine-bld$ time for x in $(seq 1 100); do _pfx/bin/g++ \ -x c++ - -S -o /dev/null \ <<< '#include '; done real 2m56.430s user 2m46.898s sys 0m8.967s The top is a build of gcc with (a rebase of) this patchset, and the bottom is the merge base. The configuration for both was: ../configure --enable-languages=c++ \ --disable-libsanitizers \ --prefix="$(pwd)/_pfx" This should imply that the difference is minor compared to compilation time. Of course, for preprocessing, the difference is far more significant (same testcase, but with -E): 0m17.248s vs 0m28.382s. This seems okay to me. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH 2/2] libstdc++: Replace all manual FTM definitions and use
Jonathan Wakely writes:
> On Sat, 29 Apr 2023 at 11:24, Arsen Arsenović via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> libstdc++-v3/ChangeLog:
>>
>> * libsupc++/typeinfo: Switch to bits/version.h for
>> __cpp_lib_constexpr_typeinfo.
>>
>>
> Does this change have an impact on compilation speed?
> With this change we'll be re-including bits/version.h multiple times in
> most compilations, and unlike other headers the preprocessor can't optimize
> away the second and subsequent times its' included, because the header
> isn't idempotent.
> It will only affect the preprocessing phase, which is a fraction of the
> time taken by template instantiation and middle end optimizations, but I'd
> like to know it's not *too* expensive before committing to this approach.
>
>> @@ -234,9 +234,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>return __atomic_test_and_set (&_M_i, int(__m));
>> }
>>
>> -#if __cplusplus > 201703L
>> -#define __cpp_lib_atomic_flag_test 201907L
>> -
>> +#ifdef __cpp_lib_atomic_flag_test
>> _GLIBCXX_ALWAYS_INLINE bool
>> test(memory_order __m = memory_order_seq_cst) const noexcept
>> {
>>
>
> This is more "structured" and maintainable than the current ad-hoc way we
> deal with FTMs, but this seems like a readability/usability regression in
> terms of being able to open the header and see "ah this feature is only
> available for C++20 and up". Instead you can see it's available for the
> specified FTM, but now you have to go and find where that's defined, and
> that's not even defined in C++, it's in the version.def file. It's also
> defined in bits/version.h, but that's a generated file and so is very
> verbose and long.
>
>
> diff --git a/libstdc++-v3/include/bits/move_only_function.h
>> b/libstdc++-v3/include/bits/move_only_function.h
>> index 71d52074978..81d7d9f7c0a 100644
>> --- a/libstdc++-v3/include/bits/move_only_function.h
>> +++ b/libstdc++-v3/include/bits/move_only_function.h
>> @@ -32,7 +32,10 @@
>>
>> #pragma GCC system_header
>>
>> -#if __cplusplus > 202002L
>> +#define __glibcxx_want_move_only_function
>> +#include
>> +
>> +#ifdef __cpp_lib_move_only_function
>>
>
> Here's another case where I think the __cplusplus > 202002L is more
> discoverable.
>
> Although maybe I'm biased, because I look at that and immediately see
> "C++23 and up". Maybe the average user finds that less clear. Maybe the
> average user doesn't need to look at this anyway, but I know *I* do it
> fairly often.
>
> I wonder if it would help if we kept a comment there with a (possibly
> imprecise) hint about the conditions under which the feature is defined. So
> in this case:
>
> // Only defined for C++23
> #ifdef __cpp_lib_move_only_function
>
> That retains the info that's currently there, and is even more readable
> than the __cplusplus check.
>
> There's a risk that those comments would get out of step with reality,
> which is one of the things this patch set aims to solve. But I think in
> practice that's unlikely. std::move_only_function isn't suddenly going to
> become available in C++20, or stop being available in C++23 and move to
> C++26.
>
> What do you think?
I think that's reasonable. And, yes, I doubt these conditions change
much. I'll go over the conditions and insert a hint.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [PATCH 1/2] libstdc++: Implement more maintainable header
Jonathan Wakely writes: > [...snip...] > It looks like this will regenerate the bits/version.h file if it's older > than the definitions or the autogen template, right? > > Generally we don't want to touch anything in the source tree as part of a > normal build. It's OK to do that when configured with > --enable-maintainer-mode (which nobody working on libstdc++ actually uses, > because it causes problems IME) or via a dedicated target which is not > built by default (e.g. doc/Makefile.am has the doc-html-docbook-regenerate > target, which is isn't a prereq of any other targets so it's only run if > you explicitly request it). > > The problem with modifying the source tree as part of a normal build is > that it might be on read-only media, and so the build will fail if this > target can't be updated. We would also want to add the version.h header to > the contrib/gcc_update script that updates the timestamps of generated > files, so that they are always newer than their prereqs. > > Maybe the best option here is to assume that version.h is always up to > date, and add a custom target to regen it manually, which we can run after > editing the .def or .tpl files. What do you think? Ah, I wasn't aware of this concern. I'll make it a phony target, yeah. > My only other concern with this patch is that I don't speak lisp so the > Guile code in version.tpl is opaque and unmaintainable for me. That is > fixable though. The algorithm the code implements is quite simple, it just verifies that the three numeric fields associated with each FTM are in a non-ascending order (which ensures that the most broad option comes last in the #if/#elif chain). It's a sanity check that's caught a couple of transcription errors I made during the initial conversion. -- Arsen Arsenović signature.asc Description: PGP signature
[PATCH 22/24] libtool.m4: augment symcode for Solaris 11
From: Nick Alcock This reports common symbols like GNU nm, via a type code of 'C'. ChangeLog: * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for Solaris 11. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate. --- gcc/configure | 2 +- libatomic/configure| 2 +- libbacktrace/configure | 2 +- libcc1/configure | 2 +- libffi/configure | 2 +- libgfortran/configure | 2 +- libgm2/configure | 2 +- libgomp/configure | 2 +- libitm/configure | 2 +- libobjc/configure | 2 +- libphobos/configure| 2 +- libquadmath/configure | 2 +- libsanitizer/configure | 2 +- libssp/configure | 2 +- libstdc++-v3/configure | 2 +- libtool.m4 | 2 +- libvtv/configure | 2 +- lto-plugin/configure | 2 +- zlib/configure | 2 +- 19 files changed, 19 insertions(+), 19 deletions(-) diff --git a/gcc/configure b/gcc/configure index e5e95e7c1c8..ea1ad6606a6 100755 --- a/gcc/configure +++ b/gcc/configure @@ -15346,7 +15346,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libatomic/configure b/libatomic/configure index 75096735c61..57f320753e1 100755 --- a/libatomic/configure +++ b/libatomic/configure @@ -6593,7 +6593,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libbacktrace/configure b/libbacktrace/configure index f3ef3fc3f23..c3e7b884e36 100755 --- a/libbacktrace/configure +++ b/libbacktrace/configure @@ -7038,7 +7038,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libcc1/configure b/libcc1/configure index edf03334f30..1a63a0e4e1a 100755 --- a/libcc1/configure +++ b/libcc1/configure @@ -6299,7 +6299,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libffi/configure b/libffi/configure index a1ded4f617b..9eac9c907bf 100755 --- a/libffi/configure +++ b/libffi/configure @@ -6825,7 +6825,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libgfortran/configure b/libgfortran/configure index 7b408515498..cd176b04a14 100755 --- a/libgfortran/configure +++ b/libgfortran/configure @@ -8227,7 +8227,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libgm2/configure b/libgm2/configure index 2d54302129c..f576681098f 100755 --- a/libgm2/configure +++ b/libgm2/configure @@ -8129,7 +8129,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libgomp/configure b/libgomp/configure index 6d4b6e3850e..a12b30f1b0f 100755 --- a/libgomp/configure +++ b/libgomp/configure @@ -6607,7 +6607,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libitm/configure b/libitm/configure index 83ff24b73e8..02e8de7896b 100755 --- a/libitm/configure +++ b/libitm/configure @@ -7268,7 +7268,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libobjc/configure b/libobjc/configure index fd590e628ab..752f6fdfebd 100755 --- a/libobjc/configure +++ b/libobjc/configure @@ -5995,7 +5995,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libphobos/configure b/libphobos/configure index 814cacc1120..b7276d95010 100755 --- a/libphobos/configure +++ b/libphobos/configure @@ -7272,7 +7272,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git
[PATCH 19/24] Deprecate a.out support for NetBSD targets.
From: John Ericson
As discussed previously, a.out support is now quite deprecated, and in
some cases removed, in both Binutils itself and NetBSD, so this legacy
default makes little sense. `netbsdelf*` and `netbsdaout*` still work
allowing the user to be explicit about there choice. Additionally, the
configure script warns about the change as Nick Clifton requested.
One possible concern was the status of NetBSD on NS32K, where only a.out
was supported. But per [1] NetBSD has removed support, and if it were to
come back, it would be with ELF. The binutils implementation is
therefore marked obsolete, per the instructions in the last message.
With that patch and this one applied, I have confirmed the following:
--target=i686-unknown-netbsd
--target=i686-unknown-netbsdelf
builds completely
--target=i686-unknown-netbsdaout
properly fails because target is deprecated.
--target=vax-unknown-netbsdaout builds completely except for gas, where
the target is deprecated.
[1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html
config/ChangeLog:
* picflag.m4: Simplify SHmedia NetBSD match by presuming ELF.
gcc/ChangeLog:
* configure: Regenerate.
libada/ChangeLog:
* configure: Regenerate.
libgcc/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
---
config/picflag.m4 | 4 +---
gcc/configure | 8 +++-
libada/configure| 4 +---
libgcc/configure| 4 +---
libiberty/configure | 4 +---
5 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/config/picflag.m4 b/config/picflag.m4
index 0aefcf619bf..3f3ac744c96 100644
--- a/config/picflag.m4
+++ b/config/picflag.m4
@@ -63,9 +63,7 @@ case "${$2}" in
sh-*-linux* | sh[[2346lbe]]*-*-linux*)
$1=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
$1=-fpic
;;
# Default to -fPIC unless specified otherwise.
diff --git a/gcc/configure b/gcc/configure
index cd9919e858d..e5e95e7c1c8 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -5480,9 +5480,7 @@ case "${target}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG_FOR_TARGET=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG_FOR_TARGET=-fpic
;;
# Default to -fPIC unless specified otherwise.
@@ -19888,7 +19886,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 19891 "configure"
+#line 19889 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -19994,7 +19992,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 19997 "configure"
+#line 19995 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
diff --git a/libada/configure b/libada/configure
index 9c8b133d817..ac4dad3ad3b 100755
--- a/libada/configure
+++ b/libada/configure
@@ -3231,9 +3231,7 @@ case "${host}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG=-fpic
;;
# Default to -fPIC unless specified otherwise.
diff --git a/libgcc/configure b/libgcc/configure
index 1e727367ba3..cf149209652 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -2422,9 +2422,7 @@ case "${host}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG=-fpic
;;
# Default to -fPIC unless specified otherwise.
diff --git a/libiberty/configure b/libiberty/configure
index bdc860f1623..dd896270dc6 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5368,9 +5368,7 @@ case "${host}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG=-fpic
;;
# Default to -fPIC unless specified otherwise.
--
2.41.0
[PATCH 14/24] libtool.m4: fix nm BSD flag detection
From: Nick Alcock Libtool needs to get BSD-format (or MS-format) output out of the system nm, so that it can scan generated object files for symbol names for -export-symbols-regex support. Some nms need specific flags to turn on BSD-formatted output, so libtool checks for this in its AC_PATH_NM. Unfortunately the code to do this has a pair of interlocking flaws: - it runs the test by doing an nm of /dev/null. Some platforms reasonably refuse to do an nm on a device file, but before now this has only been worked around by assuming that the error message has a specific textual form emitted by Tru64 nm, and that getting this error means this is Tru64 nm and that nm -B would work to produce BSD-format output, even though the test never actually got anything but an error message out of nm -B. This is fixable by nm'ing *nm itself* (since we necessarily have a path to it). - the test is entirely skipped if NM is set in the environment, on the grounds that the user has overridden the test: but the user cannot reasonably be expected to know that libtool wants not only nm but also flags forcing BSD-format output. Worse yet, one such "user" is the top-level Cygnus configure script, which neither tests for nor specifies any BSD-format flags. So platforms needing BSD-format flags always fail to set them when run in a Cygnus tree, breaking -export-symbols-regex on such platforms. Libtool also needs to augment $LD on some platforms, but this is done unconditionally, augmenting whatever the user specified: the nm check should do the same. One wrinkle: if the user has overridden $NM, a path might have been provided: so we use the user-specified path if there was one, and otherwise do the path search as usual. (If the nm specified doesn't work, this might lead to a few extra pointless path searches -- but the test is going to fail anyway, so that's not a problem.) (Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where *that* is a symlink to /usr/bin/nm.) ChangeLog: * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided NM, if there is one. Run nm on itself, not on /dev/null, to avoid errors from nms that refuse to work on non-regular files. Remove other workarounds for this problem. Strip out blank lines from the nm output. fixincludes/ChangeLog: * configure: Regenerate. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate. --- fixincludes/configure | 3 +- gcc/configure | 89 ++-- libatomic/configure| 89 ++-- libbacktrace/configure | 89 ++-- libcc1/configure | 89 ++-- libffi/configure | 89 ++-- libgfortran/configure | 89 ++-- libgm2/configure | 89 ++-- libgomp/configure | 89 ++-- libitm/configure | 89 ++-- libobjc/configure | 89 ++-- libphobos/configure| 89 ++-- libquadmath/configure | 89 ++-- libsanitizer/configure | 89 ++-- libssp/configure | 89 ++-- libstdc++-v3/configure | 101 + libtool.m4 | 88 +-- libvtv/configure | 89 ++-- lto-plugin/configure | 89 ++-- zlib/configure | 89 ++-- 20 files changed, 863 insertions(+), 842 deletions(-) diff --git a/fixincludes/configure b/fixincludes/configure index f1748ebef74..b9770489adc 100755 ---
[PATCH 24/24] toplevel: Makefile.def: add install-strip dependency on libsframe
From: Indu Bhagat
As noted in PR libsframe/30014 - FTBFS: install-strip fails because
bfdlib relinks and fails to find libsframe, the install time
dependencies of libbfd need to be updated.
ChangeLog:
* Makefile.def: Reflect that libsframe needs to installed before
libbfd. Reorder a bit to better track libsframe dependencies.
* Makefile.in: Regenerate.
---
Makefile.def | 5 -
Makefile.in | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Makefile.def b/Makefile.def
index 0c6784b6da1..870150183b9 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -492,7 +492,6 @@ dependencies = { module=install-binutils;
on=install-opcodes; };
dependencies = { module=install-strip-binutils; on=install-strip-opcodes; };
// Likewise for ld, libctf, and bfd.
-dependencies = { module=install-bfd; on=install-libsframe; };
dependencies = { module=install-libctf; on=install-bfd; };
dependencies = { module=install-ld; on=install-bfd; };
dependencies = { module=install-ld; on=install-libctf; };
@@ -500,6 +499,10 @@ dependencies = { module=install-strip-libctf;
on=install-strip-bfd; };
dependencies = { module=install-strip-ld; on=install-strip-bfd; };
dependencies = { module=install-strip-ld; on=install-strip-libctf; };
+// libbfd depends on libsframe
+dependencies = { module=install-bfd; on=install-libsframe; };
+dependencies = { module=install-strip-bfd; on=install-strip-libsframe; };
+
// libopcodes depends on libbfd
dependencies = { module=configure-opcodes; on=configure-bfd; hard=true; };
dependencies = { module=install-opcodes; on=install-bfd; };
diff --git a/Makefile.in b/Makefile.in
index 35a5d8c575d..c97130a2338 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -66496,13 +66496,14 @@ all-stageautoprofile-binutils:
maybe-all-stageautoprofile-libsframe
all-stageautofeedback-binutils: maybe-all-stageautofeedback-libsframe
install-binutils: maybe-install-opcodes
install-strip-binutils: maybe-install-strip-opcodes
-install-bfd: maybe-install-libsframe
install-libctf: maybe-install-bfd
install-ld: maybe-install-bfd
install-ld: maybe-install-libctf
install-strip-libctf: maybe-install-strip-bfd
install-strip-ld: maybe-install-strip-bfd
install-strip-ld: maybe-install-strip-libctf
+install-bfd: maybe-install-libsframe
+install-strip-bfd: maybe-install-strip-libsframe
configure-opcodes: configure-bfd
configure-stage1-opcodes: configure-stage1-bfd
configure-stage2-opcodes: configure-stage2-bfd
--
2.41.0
[PATCH 23/24] bfd: linker: merge .sframe sections
From: Indu Bhagat
The linker merges all the input .sframe sections. When merging, the
linker verifies that all the input .sframe sections have the same
abi/arch.
The linker uses libsframe library to perform key actions on the
.sframe sections - decode, read, and create output data. This
implies buildsystem changes to make and install libsframe before
libbfd.
The linker places the output .sframe section in a new segment of its
own: PT_GNU_SFRAME. A new segment is not added, however, if the
generated .sframe section is empty.
When a section is discarded from the final link, the corresponding
entries in the .sframe section for those functions are also deleted.
The linker sorts the SFrame FDEs on start address by default and sets
the SFRAME_F_FDE_SORTED flag in the .sframe section.
This patch also adds support for generation of SFrame unwind
information for the .plt* sections on x86_64. SFrame unwind info is
generated for IBT enabled PLT, lazy/non-lazy PLT.
The existing linker option --no-ld-generated-unwind-info has been
adapted to include the control of whether .sframe unwind information
will be generated for the linker generated sections like PLT.
Changes to the linker script have been made as necessary.
ChangeLog:
* Makefile.def: Add install dependency on libsframe for libbfd.
* Makefile.in: Regenerated.
---
Makefile.def | 4
Makefile.in | 11 +++
2 files changed, 15 insertions(+)
diff --git a/Makefile.def b/Makefile.def
index 86d25f43762..0c6784b6da1 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -459,11 +459,14 @@ dependencies = { module=all-gdbsupport; on=all-gnulib; };
dependencies = { module=all-gdbsupport; on=all-intl; };
// Host modules specific to binutils.
+// build libsframe before bfd for encoder/decoder support for linking
+// SFrame sections
dependencies = { module=configure-bfd; on=configure-libiberty; hard=true; };
dependencies = { module=configure-bfd; on=configure-intl; };
dependencies = { module=all-bfd; on=all-libiberty; };
dependencies = { module=all-bfd; on=all-intl; };
dependencies = { module=all-bfd; on=all-zlib; };
+dependencies = { module=all-bfd; on=all-libsframe; };
dependencies = { module=configure-opcodes; on=configure-libiberty; hard=true;
};
dependencies = { module=all-opcodes; on=all-libiberty; };
@@ -489,6 +492,7 @@ dependencies = { module=install-binutils;
on=install-opcodes; };
dependencies = { module=install-strip-binutils; on=install-strip-opcodes; };
// Likewise for ld, libctf, and bfd.
+dependencies = { module=install-bfd; on=install-libsframe; };
dependencies = { module=install-libctf; on=install-bfd; };
dependencies = { module=install-ld; on=install-bfd; };
dependencies = { module=install-ld; on=install-libctf; };
diff --git a/Makefile.in b/Makefile.in
index 214a2a15544..35a5d8c575d 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -66354,6 +66354,16 @@ all-stagetrain-bfd: maybe-all-stagetrain-zlib
all-stagefeedback-bfd: maybe-all-stagefeedback-zlib
all-stageautoprofile-bfd: maybe-all-stageautoprofile-zlib
all-stageautofeedback-bfd: maybe-all-stageautofeedback-zlib
+all-bfd: maybe-all-libsframe
+all-stage1-bfd: maybe-all-stage1-libsframe
+all-stage2-bfd: maybe-all-stage2-libsframe
+all-stage3-bfd: maybe-all-stage3-libsframe
+all-stage4-bfd: maybe-all-stage4-libsframe
+all-stageprofile-bfd: maybe-all-stageprofile-libsframe
+all-stagetrain-bfd: maybe-all-stagetrain-libsframe
+all-stagefeedback-bfd: maybe-all-stagefeedback-libsframe
+all-stageautoprofile-bfd: maybe-all-stageautoprofile-libsframe
+all-stageautofeedback-bfd: maybe-all-stageautofeedback-libsframe
configure-opcodes: configure-libiberty
configure-stage1-opcodes: configure-stage1-libiberty
configure-stage2-opcodes: configure-stage2-libiberty
@@ -66486,6 +66496,7 @@ all-stageautoprofile-binutils:
maybe-all-stageautoprofile-libsframe
all-stageautofeedback-binutils: maybe-all-stageautofeedback-libsframe
install-binutils: maybe-install-opcodes
install-strip-binutils: maybe-install-strip-opcodes
+install-bfd: maybe-install-libsframe
install-libctf: maybe-install-bfd
install-ld: maybe-install-bfd
install-ld: maybe-install-libctf
--
2.41.0
[PATCH 16/24] Add support for the haiku operating system
From: Alexander von Gluck IV
These are the os support patches we have been grooming and maintaining
for quite a few years over on git.haiku-os.org. All of these
architectures are working and most have been stable for quite some time.
ChangeLog:
* configure: Regenerate.
* configure.ac: Add Haiku to list of ELF OSes
* libtool.m4: Update sys_lib_dlsearch_path_spec on Haiku.
gcc/ChangeLog:
* configure: Regenerate.
libatomic/ChangeLog:
* configure: Regenerate.
libbacktrace/ChangeLog:
* configure: Regenerate.
libcc1/ChangeLog:
* configure: Regenerate.
libffi/ChangeLog:
* configure: Regenerate.
libgfortran/ChangeLog:
* configure: Regenerate.
libgm2/ChangeLog:
* configure: Regenerate.
libgomp/ChangeLog:
* configure: Regenerate.
libitm/ChangeLog:
* configure: Regenerate.
libobjc/ChangeLog:
* configure: Regenerate.
libphobos/ChangeLog:
* configure: Regenerate.
libquadmath/ChangeLog:
* configure: Regenerate.
libsanitizer/ChangeLog:
* configure: Regenerate.
libssp/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
libvtv/ChangeLog:
* configure: Regenerate.
lto-plugin/ChangeLog:
* configure: Regenerate.
zlib/ChangeLog:
* configure: Regenerate.
---
configure | 2 +-
configure.ac | 2 +-
gcc/configure | 4 ++--
libatomic/configure| 2 +-
libbacktrace/configure | 2 +-
libcc1/configure | 4 ++--
libffi/configure | 4 ++--
libgfortran/configure | 4 ++--
libgm2/configure | 4 ++--
libgomp/configure | 4 ++--
libitm/configure | 4 ++--
libobjc/configure | 2 +-
libphobos/configure| 2 +-
libquadmath/configure | 2 +-
libsanitizer/configure | 4 ++--
libssp/configure | 2 +-
libstdc++-v3/configure | 4 ++--
libtool.m4 | 2 +-
libvtv/configure | 4 ++--
lto-plugin/configure | 2 +-
zlib/configure | 2 +-
21 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/configure b/configure
index 907ebe71777..28f0913bdd4 100755
--- a/configure
+++ b/configure
@@ -3077,7 +3077,7 @@ case "${ENABLE_GOLD}" in
*-*-elf* | *-*-sysv4* | *-*-unixware* | *-*-eabi* | hppa*64*-*-hpux* \
| *-*-linux* | *-*-gnu* | frv-*-uclinux* | *-*-irix5* | *-*-irix6* \
| *-*-netbsd* | *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* \
- | *-*-solaris2* | *-*-nto* | *-*-nacl*)
+ | *-*-solaris2* | *-*-nto* | *-*-nacl* | *-*-haiku*)
case "${target}" in
*-*-linux*aout* | *-*-linux*oldld*)
;;
diff --git a/configure.ac b/configure.ac
index 6a2e585a39a..5d25dc864c3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -349,7 +349,7 @@ case "${ENABLE_GOLD}" in
*-*-elf* | *-*-sysv4* | *-*-unixware* | *-*-eabi* | hppa*64*-*-hpux* \
| *-*-linux* | *-*-gnu* | frv-*-uclinux* | *-*-irix5* | *-*-irix6* \
| *-*-netbsd* | *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* \
- | *-*-solaris2* | *-*-nto* | *-*-nacl*)
+ | *-*-solaris2* | *-*-nto* | *-*-nacl* | *-*-haiku*)
case "${target}" in
*-*-linux*aout* | *-*-linux*oldld*)
;;
diff --git a/gcc/configure b/gcc/configure
index c58a99f5d40..e97433d8743 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -19068,7 +19068,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
- sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/beos/system/lib'
+ sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/system/lib'
hardcode_into_libs=yes
;;
@@ -22743,7 +22743,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
- sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/beos/system/lib'
+ sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/system/lib'
hardcode_into_libs=yes
;;
diff --git a/libatomic/configure b/libatomic/configure
index 648f0dd7e52..75096735c61 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -10582,7 +10582,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
- sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/beos/system/lib'
+ sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/system/lib'
hardcode_into_libs=yes
;;
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 73611a3b994..f3ef3fc3f23 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -10759,7 +10759,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
-
[PATCH 13/24] configure: reinstate 32b PA-RISC HP-UX target in toplevel
The Binutils still support this target.
ChangeLog:
* configure.ac: Reinstate 32b PA-RISC HP-UX targets
* configure: Regenerate.
---
configure| 10 ++
configure.ac | 10 ++
2 files changed, 20 insertions(+)
diff --git a/configure b/configure
index b6b7487f834..907ebe71777 100755
--- a/configure
+++ b/configure
@@ -3572,6 +3572,11 @@ case "${target}" in
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs target-libffi"
;;
+ hppa*-hp-hpux11*)
+;;
+ hppa*-*-hpux*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
ia64*-*-*vms*)
noconfigdirs="$noconfigdirs target-libffi"
;;
@@ -3878,9 +3883,14 @@ case "${target}" in
h8500-*-*)
noconfigdirs="$noconfigdirs target-libgloss"
;;
+ hppa1.1-*-osf* | hppa1.1-*-bsd* )
+;;
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs gdb"
;;
+ hppa*-*-hpux11*)
+noconfigdirs="$noconfigdirs gdb ld"
+;;
hppa*64*-*-linux*)
;;
hppa*-*-linux*)
diff --git a/configure.ac b/configure.ac
index 39e5649f360..6a2e585a39a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -802,6 +802,11 @@ case "${target}" in
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs target-libffi"
;;
+ hppa*-hp-hpux11*)
+;;
+ hppa*-*-hpux*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
ia64*-*-*vms*)
noconfigdirs="$noconfigdirs target-libffi"
;;
@@ -1105,9 +1110,14 @@ case "${target}" in
h8500-*-*)
noconfigdirs="$noconfigdirs target-libgloss"
;;
+ hppa1.1-*-osf* | hppa1.1-*-bsd* )
+;;
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs gdb"
;;
+ hppa*-*-hpux11*)
+noconfigdirs="$noconfigdirs gdb ld"
+;;
hppa*64*-*-linux*)
;;
hppa*-*-linux*)
--
2.41.0
[PATCH 15/24] libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
From: Nick Alcock My previous nm patch handled all cases but one -- if the user set NM in the environment to a path which contained an option, libtool's nm detection tries to run nm against a copy of nm with the options in it: e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle". This is unlikely to be desirable: in this case we should run "/usr/bin/nm --blargle /usr/bin/nm". Furthermore, as part of this nm has to detect when the passed-in $NM contains a path, and in that case avoid doing a path search itself. This too was thrown off if an option contained something that looked like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run "nm -B../prev-gcc nm" which rarely works well (and indeed it looks to see whether that nm exists, finds it doesn't, and wrongly concludes that nm -p or whatever does not work). Fix all of these by clipping all options (defined as everything including and after the first " -") before deciding whether nm contains a path (but not using the clipped value for anything else), and then removing all options from the path-modified nm before looking to see whether that nm existed. NM=my-nm now does a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM=/usr/bin/my-nm now avoids a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM="my-nm -p../wombat" now does a path search and runs e.g. /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search: ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm This seems to be all combinations, including those used by GCC bootstrap (which, before this commit, fails to bootstrap when configured --with-build-config=bootstrap-lto, because the lto plugin is now using --export-symbols-regex, which requires libtool to find a working nm, while also using -B../prev-gcc to point at the lto plugin associated with the GCC just built.) Regenerate all affected configure scripts. ChangeLog: * libtool.m4 (LT_PATH_NM): Handle user-specified NM with options, including options containing paths. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate. --- gcc/configure | 20 +--- libatomic/configure| 20 +--- libbacktrace/configure | 20 +--- libcc1/configure | 20 +--- libffi/configure | 20 +--- libgfortran/configure | 20 +--- libgm2/configure | 20 +--- libgomp/configure | 20 +--- libitm/configure | 20 +--- libobjc/configure | 20 +--- libphobos/configure| 20 +--- libquadmath/configure | 20 +--- libsanitizer/configure | 20 +--- libssp/configure | 20 +--- libstdc++-v3/configure | 32 +++- libtool.m4 | 16 +++- libvtv/configure | 20 +--- lto-plugin/configure | 20 +--- zlib/configure | 20 +--- 19 files changed, 251 insertions(+), 137 deletions(-) diff --git a/gcc/configure b/gcc/configure index 81b93c1b599..c58a99f5d40 100755 --- a/gcc/configure +++ b/gcc/configure @@ -14144,25 +14144,31 @@ else lt_nm_to_check="$lt_nm_to_check nm" fi fi - for lt_tmp_nm in $lt_nm_to_check; do + for lt_tmp_nm in "$lt_nm_to_check"; do lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do IFS="$lt_save_ifs" test -z "$ac_dir" && ac_dir=. - case "$lt_tmp_nm" in + # Strip out any user-provided options from the nm to test twice, + # the first time to test to see if nm (rather than its options) has + # an explicit path, the second time to yield a file which can be + # nm'ed itself. + tmp_nm_path="`$ECHO "$lt_tmp_nm" | sed 's, -.*$,,'`" + case
[PATCH 10/24] gprofng: a new GNU profiler
From: Vladimir Mezentsev
ChangeLog:
* Makefile.def: Add gprofng module.
* configure.ac: Add --enable-gprofng option.
* Makefile.in: Regenerate.
* configure: Regenerate.
include/ChangeLog:
* collectorAPI.h: New file.
* libcollector.h: New file.
* libfcollector.h: New file.
---
Makefile.def| 11 +
Makefile.in | 497
configure | 18 ++
configure.ac| 14 ++
include/collectorAPI.h | 73 ++
include/libcollector.h | 89 +++
include/libfcollector.h | 42
7 files changed, 744 insertions(+)
create mode 100644 include/collectorAPI.h
create mode 100644 include/libcollector.h
create mode 100644 include/libfcollector.h
diff --git a/Makefile.def b/Makefile.def
index 9b4a8a2bf7a..86d25f43762 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -73,6 +73,7 @@ host_modules= { module= isl; lib_path=.libs; bootstrap=true;
no_install= true; };
host_modules= { module= gold; bootstrap=true; };
host_modules= { module= gprof; };
+host_modules= { module= gprofng; };
// intl acts on 'host_shared' directly, and does not support --with-pic.
host_modules= { module= intl; bootstrap=true; };
host_modules= { module= tcl;
@@ -511,6 +512,16 @@ dependencies = { module=all-gprof; on=all-bfd; };
dependencies = { module=all-gprof; on=all-opcodes; };
dependencies = { module=all-gprof; on=all-intl; };
dependencies = { module=all-gprof; on=all-gas; };
+
+dependencies = { module=configure-gprofng; on=configure-intl; };
+dependencies = { module=all-gprofng; on=all-libiberty; };
+dependencies = { module=all-gprofng; on=all-bfd; };
+dependencies = { module=all-gprofng; on=all-opcodes; };
+dependencies = { module=all-gprofng; on=all-intl; };
+dependencies = { module=all-gprofng; on=all-gas; };
+dependencies = { module=install-gprofng; on=install-opcodes; };
+dependencies = { module=install-gprofng; on=install-bfd; };
+
dependencies = { module=configure-ld; on=configure-intl; };
dependencies = { module=all-ld; on=all-libiberty; };
dependencies = { module=all-ld; on=all-bfd; };
diff --git a/Makefile.in b/Makefile.in
index 6539fb201dc..f177ce176fb 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1089,6 +1089,7 @@ configure-host: \
maybe-configure-isl \
maybe-configure-gold \
maybe-configure-gprof \
+maybe-configure-gprofng \
maybe-configure-intl \
maybe-configure-tcl \
maybe-configure-itcl \
@@ -1242,6 +1243,7 @@ all-host: maybe-all-isl
all-host: maybe-all-gold
@endif gold-no-bootstrap
all-host: maybe-all-gprof
+all-host: maybe-all-gprofng
@if intl-no-bootstrap
all-host: maybe-all-intl
@endif intl-no-bootstrap
@@ -1381,6 +1383,7 @@ info-host: maybe-info-mpc
info-host: maybe-info-isl
info-host: maybe-info-gold
info-host: maybe-info-gprof
+info-host: maybe-info-gprofng
info-host: maybe-info-intl
info-host: maybe-info-tcl
info-host: maybe-info-itcl
@@ -1471,6 +1474,7 @@ dvi-host: maybe-dvi-mpc
dvi-host: maybe-dvi-isl
dvi-host: maybe-dvi-gold
dvi-host: maybe-dvi-gprof
+dvi-host: maybe-dvi-gprofng
dvi-host: maybe-dvi-intl
dvi-host: maybe-dvi-tcl
dvi-host: maybe-dvi-itcl
@@ -1561,6 +1565,7 @@ pdf-host: maybe-pdf-mpc
pdf-host: maybe-pdf-isl
pdf-host: maybe-pdf-gold
pdf-host: maybe-pdf-gprof
+pdf-host: maybe-pdf-gprofng
pdf-host: maybe-pdf-intl
pdf-host: maybe-pdf-tcl
pdf-host: maybe-pdf-itcl
@@ -1651,6 +1656,7 @@ html-host: maybe-html-mpc
html-host: maybe-html-isl
html-host: maybe-html-gold
html-host: maybe-html-gprof
+html-host: maybe-html-gprofng
html-host: maybe-html-intl
html-host: maybe-html-tcl
html-host: maybe-html-itcl
@@ -1741,6 +1747,7 @@ TAGS-host: maybe-TAGS-mpc
TAGS-host: maybe-TAGS-isl
TAGS-host: maybe-TAGS-gold
TAGS-host: maybe-TAGS-gprof
+TAGS-host: maybe-TAGS-gprofng
TAGS-host: maybe-TAGS-intl
TAGS-host: maybe-TAGS-tcl
TAGS-host: maybe-TAGS-itcl
@@ -1831,6 +1838,7 @@ install-info-host: maybe-install-info-mpc
install-info-host: maybe-install-info-isl
install-info-host: maybe-install-info-gold
install-info-host: maybe-install-info-gprof
+install-info-host: maybe-install-info-gprofng
install-info-host: maybe-install-info-intl
install-info-host: maybe-install-info-tcl
install-info-host: maybe-install-info-itcl
@@ -1921,6 +1929,7 @@ install-dvi-host: maybe-install-dvi-mpc
install-dvi-host: maybe-install-dvi-isl
install-dvi-host: maybe-install-dvi-gold
install-dvi-host: maybe-install-dvi-gprof
+install-dvi-host: maybe-install-dvi-gprofng
install-dvi-host: maybe-install-dvi-intl
install-dvi-host: maybe-install-dvi-tcl
install-dvi-host: maybe-install-dvi-itcl
@@ -2011,6 +2020,7 @@ install-pdf-host: maybe-install-pdf-mpc
install-pdf-host: maybe-install-pdf-isl
install-pdf-host: maybe-install-pdf-gold
install-pdf-host: maybe-install-pdf-gprof
+install-pdf-host: maybe-install-pdf-gprofng
install-pdf-host: maybe-install-pdf-intl
install-pdf-host: maybe-install-pdf-tcl
[PATCH 17/24] egrep in binutils
From: Alan Modra
Apparently some distros have a nagging egrep that helpfully tells you
egrep is deprecated and to use "grep -E". The nag message causes a ld
testsuite failure. What's more the advice isn't that good. The "-E"
flag may not be available with older versions of grep.
This patch fixes bare invocation of egrep within binutils, replacing
it with the autoconf $EGREP or with grep.
config/ChangeLog:
* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Require AC_PROG_EGREP and
invoke $EGREP.
(AC_LIB_PROG_LD): Likewise.
gcc/ChangeLog:
* configure: Regenerate.
intl/ChangeLog:
* configure: Regenerate.
libcpp/ChangeLog:
* configure: Regenerate.
libgcc/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
---
config/lib-ld.m4 | 8 +---
gcc/configure | 4 ++--
intl/configure | 4 ++--
libcpp/configure | 4 ++--
libgcc/configure | 2 +-
libstdc++-v3/configure | 4 ++--
6 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/config/lib-ld.m4 b/config/lib-ld.m4
index 11d0ce77342..73cf9571b57 100644
--- a/config/lib-ld.m4
+++ b/config/lib-ld.m4
@@ -12,9 +12,10 @@ dnl with libtool.m4.
dnl From libtool-1.4. Sets the variable with_gnu_ld to yes or no.
AC_DEFUN([AC_LIB_PROG_LD_GNU],
-[AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
+[AC_REQUIRE([AC_PROG_EGREP])dnl
+AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
[# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+if $LD -v 2>&1 &5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
@@ -29,6 +30,7 @@ AC_DEFUN([AC_LIB_PROG_LD],
test "$withval" = no || with_gnu_ld=yes, with_gnu_ld=no)
AC_REQUIRE([AC_PROG_CC])dnl
AC_REQUIRE([AC_CANONICAL_HOST])dnl
+AC_REQUIRE([AC_PROG_EGREP])dnl
# Prepare PATH_SEPARATOR.
# The user is always right.
if test "${PATH_SEPARATOR+set}" != set; then
@@ -88,7 +90,7 @@ AC_CACHE_VAL(acl_cv_path_LD,
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
diff --git a/gcc/configure b/gcc/configure
index e97433d8743..cd9919e858d 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -11299,7 +11299,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -11327,7 +11327,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+if $LD -v 2>&1 &5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
diff --git a/intl/configure b/intl/configure
index 79bb5831a47..42b2a26b5bf 100755
--- a/intl/configure
+++ b/intl/configure
@@ -5094,7 +5094,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -5122,7 +5122,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+if $LD -v 2>&1 &5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
diff --git a/libcpp/configure b/libcpp/configure
index 1389ddab544..ed98f40a1c1 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -6811,7 +6811,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
[PATCH 20/24] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
From: "H.J. Lu" It is quite normal to have headers without library on multilib OSes. Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS works. config/ChangeLog: * pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if $pkg_cv_[]$1[]_LIBS works. --- config/pkg.m4 | 6 ++ 1 file changed, 6 insertions(+) diff --git a/config/pkg.m4 b/config/pkg.m4 index 13a88901786..45587e97c8b 100644 --- a/config/pkg.m4 +++ b/config/pkg.m4 @@ -147,6 +147,12 @@ AC_MSG_CHECKING([for $2]) _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) _PKG_CONFIG([$1][_LIBS], [libs], [$2]) +dnl Check whether $pkg_cv_[]$1[]_LIBS works. +pkg_save_LDFLAGS="$LDFLAGS" +LDFLAGS="$LDFLAGS $pkg_cv_[]$1[]_LIBS" +AC_TRY_LINK([],[return 0;], [pkg_failed=no], [pkg_failed=yes]) +LDFLAGS=$pkg_save_LDFLAGS + m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS and $1[]_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.]) -- 2.41.0
[PATCH 21/24] PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works
From: "H.J. Lu" There is no need to check $pkg_cv_[]$1[]_LIBS works if package check failed. config/ChangeLog: * pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if $pkg_failed = no. --- config/pkg.m4 | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/config/pkg.m4 b/config/pkg.m4 index 45587e97c8b..7ebf517cd6a 100644 --- a/config/pkg.m4 +++ b/config/pkg.m4 @@ -148,10 +148,12 @@ _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) _PKG_CONFIG([$1][_LIBS], [libs], [$2]) dnl Check whether $pkg_cv_[]$1[]_LIBS works. -pkg_save_LDFLAGS="$LDFLAGS" -LDFLAGS="$LDFLAGS $pkg_cv_[]$1[]_LIBS" -AC_TRY_LINK([],[return 0;], [pkg_failed=no], [pkg_failed=yes]) -LDFLAGS=$pkg_save_LDFLAGS +if test $pkg_failed = no; then + pkg_save_LDFLAGS="$LDFLAGS" + LDFLAGS="$LDFLAGS $pkg_cv_[]$1[]_LIBS" + AC_TRY_LINK([],[], [], [pkg_failed=yes]) + LDFLAGS=$pkg_save_LDFLAGS +fi m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS and $1[]_LIBS to avoid the need to call pkg-config. -- 2.41.0
[PATCH 04/24] Sync with binutils: GCC: Pass --plugin to AR and RANLIB
From: "H.J. Lu" Sync with binutils for building binutils with LTO: 50ad1254d50 GCC: Pass --plugin to AR and RANLIB Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO build. ChangeLog: * Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. * configure.ac: Include config/gcc-plugin.m4. AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and RANLIB if possible. * Makefile.in: Regenerated. * configure: Likewise. config/ChangeLog: * gcc-plugin.m4 (GCC_PLUGIN_OPTION): New. libiberty/ChangeLog: * Makefile.in (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. (configure_deps): Depend on ../config/gcc-plugin.m4. * configure.ac: AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * aclocal.m4: Regenerated. * configure: Likewise. zlib/ChangeLog: * configure: Regenerated. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. --- Makefile.in| 5 +++-- Makefile.tpl | 5 +++-- config/gcc-plugin.m4 | 28 configure | 39 +++ configure.ac | 15 +++ gcc/configure | 27 +-- libatomic/configure| 27 +-- libbacktrace/configure | 27 +-- libcc1/configure | 27 +-- libffi/configure | 27 +-- libgfortran/configure | 27 +-- libgm2/configure | 27 +-- libgomp/configure | 27 +-- libiberty/Makefile.in | 5 +++-- libiberty/aclocal.m4 | 1 + libiberty/configure| 37 + libiberty/configure.ac | 12 libitm/configure | 27 +-- libobjc/configure | 27 +-- libphobos/configure| 27 +-- libquadmath/configure | 27 +-- libsanitizer/configure | 27 +-- libssp/configure | 27 +-- libstdc++-v3/configure | 39 +++ libtool.m4 | 25 - libvtv/configure | 27 +-- lto-plugin/configure | 27 +-- zlib/configure | 27 +-- 28 files changed, 621 insertions(+), 49 deletions(-) diff --git a/Makefile.in b/Makefile.in index 144bccd2603..6539fb201dc 100644 --- a/Makefile.in +++ b/Makefile.in @@ -417,7 +417,7 @@ MAKEINFOFLAGS = --split-size=500 # - AS = @AS@ -AR = @AR@ +AR = @AR@ @AR_PLUGIN_OPTION@ AR_FLAGS = rc CC = @CC@ CXX = @CXX@ @@ -428,7 +428,7 @@ LIPO = @LIPO@ NM = @NM@ OBJDUMP = @OBJDUMP@ OTOOL = @OTOOL@ -RANLIB = @RANLIB@ +RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@ READELF = @READELF@ STRIP = @STRIP@ WINDRES = @WINDRES@ @@ -66748,6 +66748,7 @@ AUTOCONF = autoconf $(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/config/acx.m4 \ $(srcdir)/config/override.m4 $(srcdir)/config/proginstall.m4 \ $(srcdir)/config/elf.m4 $(srcdir)/config/isl.m4 \ + $(srcdir)/config/gcc-plugin.m4 \ $(srcdir)/libtool.m4 $(srcdir)/ltoptions.m4 $(srcdir)/ltsugar.m4 \ $(srcdir)/ltversion.m4 $(srcdir)/lt~obsolete.m4 cd $(srcdir) && $(AUTOCONF) diff --git a/Makefile.tpl b/Makefile.tpl index 4fdca604eb0..6586e907964 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -420,7 +420,7 @@ MAKEINFOFLAGS = --split-size=500 # - AS = @AS@ -AR = @AR@ +AR = @AR@ @AR_PLUGIN_OPTION@ AR_FLAGS = rc CC = @CC@ CXX = @CXX@ @@ -431,7 +431,7 @@ LIPO = @LIPO@ NM = @NM@ OBJDUMP = @OBJDUMP@ OTOOL = @OTOOL@ -RANLIB = @RANLIB@ +RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@ READELF =
[PATCH 18/24] PR27116, Spelling errors found by Debian style checker
From: Alan Modra config/ChangeLog: * override.m4: Correct comment grammar. --- config/override.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/override.m4 b/config/override.m4 index d3e815bb1b4..5a1bffe6018 100644 --- a/config/override.m4 +++ b/config/override.m4 @@ -32,7 +32,7 @@ m4_ifndef([_GCC_AUTOCONF_VERSION], [m4_define([_GCC_AUTOCONF_VERSION], [2.69])]) dnl Test for the exact version when AC_INIT is expanded. -dnl This allows to update the tree in steps (for testing) +dnl This allows one to update the tree in steps (for testing) dnl by putting dnl m4_define([_GCC_AUTOCONF_VERSION], [X.Y]) dnl in configure.ac before AC_INIT, -- 2.41.0
[PATCH 12/24] Pass PKG_CONFIG_PATH down from top-level Makefile
From: Simon Marchi
[Sending to binutils, gdb-patches and gcc-patches, since it touches the
top-level Makefile/configure]
I have my debuginfod library installed in a non-standard location
(/opt/debuginfod), which requires me to set
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set it during
configure:
$ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure
--with-debuginfod
$ make
or
$ ./configure --with-debuginfod
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
$ make
Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
configure. When running make (which runs gdb's and binutils'
configure), PKG_CONFIG_PATH is not set, which results in their configure
script not finding the library:
checking for libdebuginfod >= 0.179... no
configure: error: "--with-debuginfod was given, but libdebuginfod is
missing or unusable."
Change the top-level configure/Makefile system to capture the value
passed when configuring the top-level and pass it down to
subdirectories (similar to CFLAGS, LDFLAGS, etc).
I don't know much about the top-level build system, so I really don't
know if I did this correctly. The changes are:
- Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
in config files (i.e. Makefile)
- Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
to @PKG_CONFIG_PATH@
- Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
variables set when running the sub-configures
I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
I don't think it's needed. AFAIU, this defines the flags to pass down
when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to
be passed down during configure. After that, it's captured in
gdb/config.status, so even if a "make" causes a re-configure later
(because gdb/configure has changed, for example), the PKG_CONFIG_PATH
value will be remembered.
Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
ChangeLog:
* configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
* configure: Re-generate.
* Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
(PKG_CONFIG_PATH): New.
* Makefile.in: Re-generate.
---
Makefile.in | 3 +++
Makefile.tpl | 3 +++
configure| 2 ++
configure.ac | 1 +
4 files changed, 9 insertions(+)
diff --git a/Makefile.in b/Makefile.in
index f177ce176fb..214a2a15544 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -221,6 +221,7 @@ HOST_EXPORTS = \
OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
OTOOL="$(OTOOL)"; export OTOOL; \
+ PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
READELF="$(READELF)"; export READELF; \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
@@ -447,6 +448,8 @@ GOCFLAGS = $(CFLAGS)
GDCFLAGS = @GDCFLAGS@
GM2FLAGS = $(CFLAGS)
+PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
+
# Pass additional PGO and LTO compiler options to the PGO build.
BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
override CFLAGS += $(BUILD_CFLAGS)
diff --git a/Makefile.tpl b/Makefile.tpl
index 6586e907964..36fa20950d4 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -224,6 +224,7 @@ HOST_EXPORTS = \
OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
OTOOL="$(OTOOL)"; export OTOOL; \
+ PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
READELF="$(READELF)"; export READELF; \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
@@ -450,6 +451,8 @@ GOCFLAGS = $(CFLAGS)
GDCFLAGS = @GDCFLAGS@
GM2FLAGS = $(CFLAGS)
+PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
+
# Pass additional PGO and LTO compiler options to the PGO build.
BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
override CFLAGS += $(BUILD_CFLAGS)
diff --git a/configure b/configure
index faa1aedaa04..b6b7487f834 100755
--- a/configure
+++ b/configure
@@ -622,6 +622,7 @@ CXX_FOR_TARGET
CC_FOR_TARGET
RANLIB_PLUGIN_OPTION
AR_PLUGIN_OPTION
+PKG_CONFIG_PATH
GDCFLAGS
READELF
OTOOL
@@ -13017,6 +13018,7 @@ fi
GDCFLAGS=${GDCFLAGS-${CFLAGS}}
+
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -plugin option" >&5
$as_echo_n "checking for -plugin option... " >&6; }
diff --git a/configure.ac b/configure.ac
index a0dff0ecac8..39e5649f360 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3708,6 +3708,7 @@ AC_SUBST(CXXFLAGS)
AC_SUBST(GDC)
AC_SUBST(GDCFLAGS)
GDCFLAGS=${GDCFLAGS-${CFLAGS}}
+AC_SUBST(PKG_CONFIG_PATH)
GCC_PLUGIN_OPTION(PLUGIN_OPTION)
AR_PLUGIN_OPTION=
--
2.41.0
[PATCH 05/24] GCC: Check if AR works with --plugin and rc
From: "H.J. Lu"
AR from older binutils doesn't work with --plugin and rc:
[hjl@gnu-cfl-2 bin]$ touch foo.c
[hjl@gnu-cfl-2 bin]$ ar --plugin
/usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
[hjl@gnu-cfl-2 bin]$ ./ar --plugin
/usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
./ar: no operation specified
[hjl@gnu-cfl-2 bin]$ ./ar --version
GNU ar (Linux/GNU Binutils) 2.29.51.0.1.20180112
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
[hjl@gnu-cfl-2 bin]$
Check if AR works with --plugin and rc before passing --plugin to AR and
RANLIB.
ChangeLog:
* configure: Regenerated.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Check if AR works with
--plugin and rc before enabling --plugin.
config/ChangeLog:
* gcc-plugin.m4 (GCC_PLUGIN_OPTION): Check if AR works with
--plugin and rc before enabling --plugin.
gcc/ChangeLog:
* configure: Regenerate.
libatomic/ChangeLog:
* configure: Regenerate.
libbacktrace/ChangeLog:
* configure: Regenerate.
libcc1/ChangeLog:
* configure: Regenerate.
libffi/ChangeLog:
* configure: Regenerate.
libgfortran/ChangeLog:
* configure: Regenerate.
libgm2/ChangeLog:
* configure: Regenerate.
libgomp/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
libitm/ChangeLog:
* configure: Regenerate.
libobjc/ChangeLog:
* configure: Regenerate.
libphobos/ChangeLog:
* configure: Regenerate.
libquadmath/ChangeLog:
* configure: Regenerate.
libsanitizer/ChangeLog:
* configure: Regenerate.
libssp/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
libvtv/ChangeLog:
* configure: Regenerate.
lto-plugin/ChangeLog:
* configure: Regenerate.
zlib/ChangeLog:
* configure: Regenerate.
---
config/gcc-plugin.m4 | 12 +
configure | 103 +
gcc/configure | 14 --
libatomic/configure| 14 --
libbacktrace/configure | 14 --
libcc1/configure | 14 --
libffi/configure | 14 --
libgfortran/configure | 14 --
libgm2/configure | 14 --
libgomp/configure | 14 --
libiberty/configure| 103 +
libitm/configure | 14 --
libobjc/configure | 14 --
libphobos/configure| 14 --
libquadmath/configure | 14 --
libsanitizer/configure | 14 --
libssp/configure | 14 --
libstdc++-v3/configure | 26 +++
libtool.m4 | 9 +++-
libvtv/configure | 14 --
lto-plugin/configure | 14 --
zlib/configure | 14 --
22 files changed, 430 insertions(+), 61 deletions(-)
diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
index d782d52858e..c731a6fab38 100644
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -150,6 +150,18 @@ for plugin in $plugin_names; do
break
fi
done
+dnl Check if ${AR} $plugin_option rc works.
+AC_CHECK_TOOL(AR, ar)
+if test "${AR}" = "" ; then
+ AC_MSG_ERROR([Required archive tool 'ar' not found on PATH.])
+fi
+touch conftest.c
+${AR} $plugin_option rc conftest.a conftest.c
+if test "$?" != 0; then
+ AC_MSG_WARN([Failed: $AR $plugin_option rc])
+ plugin_option=
+fi
+rm -f conftest.*
if test -n "$plugin_option"; then
$1="$plugin_option"
AC_MSG_RESULT($plugin_option)
diff --git a/configure b/configure
index 4aa1ca21a38..3fe4a1804cf 100755
--- a/configure
+++ b/configure
@@ -12966,6 +12966,109 @@ for plugin in $plugin_names; do
break
fi
done
+if test -n "$ac_tool_prefix"; then
+ # Extract the first word of "${ac_tool_prefix}ar", so it can be a program
name with args.
+set dummy ${ac_tool_prefix}ar; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_AR+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ if test -n "$AR"; then
+ ac_cv_prog_AR="$AR" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ac_cv_prog_AR="${ac_tool_prefix}ar"
+$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext"
>&5
+break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+fi
+fi
+AR=$ac_cv_prog_AR
+if test -n "$AR"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AR" >&5
+$as_echo "$AR" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
[PATCH 07/24] binutils, gdb: support zstd compressed debug sections
From: Fangrui Song
PR29397 PR29563: Add new configure option --with-zstd which defaults to
auto. If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
zstd compressed debug sections for most tools.
* bfd: for addr2line, objdump --dwarf, gdb, etc
* gas: support --compress-debug-sections=zstd
* ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
* objcopy: support ELFCOMPRESS_ZSTD input for
--decompress-debug-sections and --compress-debug-sections=zstd
* gdb: support ELFCOMPRESS_ZSTD input. The bfd change references zstd
symbols, so gdb has to link against -lzstd in this patch.
If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error. We
can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
is too heavyweight, so don't do it for now.
```
% ld/ld-new a.o
ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not
built with zstd support
...
% ld/ld-new a.o --compress-debug-sections=zstd
ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
% binutils/objcopy --compress-debug-sections=zstd a.o b.o
binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with
zstd support
% binutils/objcopy b.o --decompress-debug-sections
binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but
BFD is not built with zstd support
...
```
config/ChangeLog:
* zstd.m4: New file.
ChangeLog:
* configure: Regenerate.
* configure.ac: Add --with-zstd.
---
config/zstd.m4 | 23 +++
configure | 10 ++
configure.ac | 3 +++
3 files changed, 36 insertions(+)
create mode 100644 config/zstd.m4
diff --git a/config/zstd.m4 b/config/zstd.m4
new file mode 100644
index 000..6da4db68c58
--- /dev/null
+++ b/config/zstd.m4
@@ -0,0 +1,23 @@
+dnl Copyright (C) 2022 Free Software Foundation, Inc.
+dnl This file is free software, distributed under the terms of the GNU
+dnl General Public License. As a special exception to the GNU General
+dnl Public License, this file may be distributed as part of a program
+dnl that contains a configuration script generated by Autoconf, under
+dnl the same distribution terms as the rest of that program.
+
+dnl Enable features using the zstd library.
+AC_DEFUN([AC_ZSTD], [
+AC_ARG_WITH(zstd,
+ [AS_HELP_STRING([--with-zstd], [support zstd compressed debug sections
(default=auto)])],
+ [], [with_zstd=auto])
+
+AS_IF([test "$with_zstd" != no],
+ [PKG_CHECK_MODULES(ZSTD, [libzstd], [
+AC_DEFINE(HAVE_ZSTD, 1, [Define to 1 if zstd is enabled.])
+ ], [
+if test "$with_zstd" = yes; then
+ AC_MSG_ERROR([--with-zstd was given, but pkgconfig/libzstd.pc is not
found])
+fi
+ ])
+ ])
+])
diff --git a/configure b/configure
index 04369383079..a5f6282bb0e 100755
--- a/configure
+++ b/configure
@@ -800,6 +800,7 @@ ac_user_opts='
enable_option_checking
with_build_libsubdir
with_system_zlib
+with_zstd
enable_as_accelerator_for
enable_offload_targets
enable_offload_defaulted
@@ -1589,6 +1590,8 @@ Optional Packages:
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-build-libsubdir=DIR Directory where to find libraries for build
system
--with-system-zlib use installed libz
+ --with-zstd Support zstd compressed debug sections
+ (default=auto)
--with-mpc=PATH specify prefix directory for installed MPC package.
Equivalent to --with-mpc-include=PATH/include plus
--with-mpc-lib=PATH/lib
@@ -2962,6 +2965,13 @@ if test x$with_system_readline = xyes ; then
noconfigdirs="$noconfigdirs readline"
fi
+
+# Check whether --with-zstd was given.
+if test "${with_zstd+set}" = set; then :
+ withval=$with_zstd;
+fi
+
+
# some tools are so dependent upon X11 that if we're not building with X,
# it's not even worth trying to configure, much less build, that tool.
diff --git a/configure.ac b/configure.ac
index 3632216fd1c..e820940c81e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -254,6 +254,9 @@ if test x$with_system_readline = xyes ; then
noconfigdirs="$noconfigdirs readline"
fi
+AC_ARG_WITH(zstd,
+[AS_HELP_STRING([--with-zstd], [Support zstd compressed debug sections
(default=auto)])])
+
# some tools are so dependent upon X11 that if we're not building with X,
# it's not even worth trying to configure, much less build, that tool.
--
2.41.0
[PATCH 08/24] configure: require libzstd >= 1.4.0
From: Christophe Lyon gas uses ZSTD_compressStream2 which is only available with libzstd >= 1.4.0, leading to build errors when an older version is installed. This patch updates the check libzstd presence to check its version is >= 1.4.0. However, since gas seems to be the only component requiring such a recent version this may imply that we disable ZSTD support for all components although some would still benefit from an older version. I ran 'autoreconf -f' in all directories containing a configure.ac file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed several errors from autoheader in readline, as well as warnings in intl, but they are unrelated to this patch. This should fix some of the buildbots. OK for trunk? Thanks, Christophe config/ChangeLog: * zstd.m4: Add minimum version requirement of 1.4.0. --- config/zstd.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/zstd.m4 b/config/zstd.m4 index 6da4db68c58..eb34c0f36d7 100644 --- a/config/zstd.m4 +++ b/config/zstd.m4 @@ -12,7 +12,7 @@ AC_ARG_WITH(zstd, [], [with_zstd=auto]) AS_IF([test "$with_zstd" != no], - [PKG_CHECK_MODULES(ZSTD, [libzstd], [ + [PKG_CHECK_MODULES(ZSTD, [libzstd >= 1.4.0], [ AC_DEFINE(HAVE_ZSTD, 1, [Define to 1 if zstd is enabled.]) ], [ if test "$with_zstd" = yes; then -- 2.41.0
[PATCH 02/24] PR29961, plugin-api.h: "Could not detect architecture endianess"
From: Alan Modra Found when attempting to build binutils on sparc sunos-5.8 where sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER variants. This patch adds the extra tests to cope with the old machine, and tidies the header a little. include/ChangeLog: * plugin-api.h: When handling non-gcc or gcc < 4.6.0 include necessary header files before testing macros. Make more use of #elif. Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests. --- include/plugin-api.h | 49 ++-- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/include/plugin-api.h b/include/plugin-api.h index 395d5bcc598..f3cf2d8101b 100644 --- a/include/plugin-api.h +++ b/include/plugin-api.h @@ -37,7 +37,7 @@ #error cannot find uint64_t type #endif -/* Detect endianess based on __BYTE_ORDER__ macro. */ +/* Detect endianess based on gcc's (>=4.6.0) __BYTE_ORDER__ macro. */ #if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \ defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__) #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ @@ -47,46 +47,47 @@ #elif __BYTE_ORDER__ == __ORDER_PDP_ENDIAN__ #define PLUGIN_PDP_ENDIAN 1 #endif + #else -/* Older GCC releases (<4.6.0) can make detection from glibc macros. */ +/* Include header files to define endian macros. */ #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) #include -#ifdef __BYTE_ORDER -#if __BYTE_ORDER == __LITTLE_ENDIAN -#define PLUGIN_LITTLE_ENDIAN 1 -#elif __BYTE_ORDER == __BIG_ENDIAN -#define PLUGIN_BIG_ENDIAN 1 -#endif -#endif -#endif -/* Include all necessary header files based on target. */ -#if defined(__SVR4) && defined(__sun) + +#elif defined(__SVR4) && defined(__sun) #include -#endif -#if defined(__FreeBSD__) || defined(__NetBSD__) || \ -defined(__DragonFly__) || defined(__minix) + +#elif defined(__FreeBSD__) || defined(__NetBSD__) || \ + defined(__DragonFly__) || defined(__minix) #include -#endif -#if defined(__OpenBSD__) + +#elif defined(__OpenBSD__) #include #endif + +/* Detect endianess based on __BYTE_ORDER. */ +#ifdef __BYTE_ORDER +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define PLUGIN_LITTLE_ENDIAN 1 +#elif __BYTE_ORDER == __BIG_ENDIAN +#define PLUGIN_BIG_ENDIAN 1 +#endif + /* Detect endianess based on _BYTE_ORDER. */ -#ifdef _BYTE_ORDER +#elif defined _BYTE_ORDER #if _BYTE_ORDER == _LITTLE_ENDIAN #define PLUGIN_LITTLE_ENDIAN 1 #elif _BYTE_ORDER == _BIG_ENDIAN #define PLUGIN_BIG_ENDIAN 1 #endif -#endif + /* Detect based on _WIN32. */ -#if defined(_WIN32) +#elif defined _WIN32 #define PLUGIN_LITTLE_ENDIAN 1 -#endif + /* Detect based on __BIG_ENDIAN__ and __LITTLE_ENDIAN__ */ -#ifdef __LITTLE_ENDIAN__ +#elif defined __LITTLE_ENDIAN__ || defined _LITTLE_ENDIAN #define PLUGIN_LITTLE_ENDIAN 1 -#endif -#ifdef __BIG_ENDIAN__ +#elif defined __BIG_ENDIAN__ || defined _BIG_ENDIAN #define PLUGIN_BIG_ENDIAN 1 #endif #endif -- 2.41.0
[PATCH 06/24] toplevel: Recover tilegx/tilepro targets
These are still supported in Binutils.
ChangeLog:
* configure: Regenerate.
* configure.ac: Recover tilegx/tilepro targets.
---
configure| 5 -
configure.ac | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 3fe4a1804cf..04369383079 100755
--- a/configure
+++ b/configure
@@ -3072,7 +3072,7 @@ case "${ENABLE_GOLD}" in
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
configdirs="$configdirs gold"
if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -3977,6 +3977,9 @@ case "${target}" in
tic6x-*-*)
noconfigdirs="$noconfigdirs sim"
;;
+ tilepro*-*-* | tilegx*-*-*)
+noconfigdirs="$noconfigdirs sim"
+;;
v810-*-*)
noconfigdirs="$noconfigdirs bfd binutils gas gdb ld opcodes
target-libgloss"
;;
diff --git a/configure.ac b/configure.ac
index a11b1006427..3632216fd1c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -360,7 +360,7 @@ case "${ENABLE_GOLD}" in
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
configdirs="$configdirs gold"
if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -1227,6 +1227,9 @@ case "${target}" in
tic6x-*-*)
noconfigdirs="$noconfigdirs sim"
;;
+ tilepro*-*-* | tilegx*-*-*)
+noconfigdirs="$noconfigdirs sim"
+;;
v810-*-*)
noconfigdirs="$noconfigdirs bfd binutils gas gdb ld opcodes
target-libgloss"
;;
--
2.41.0
[PATCH 11/24] Disable year 2038 support on 32-bit hosts by default
From: Luis Machado
With a recent import of gnulib, code has been pulled that tests and enables
64-bit time_t by default on 32-bit hosts that support it.
Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
doesn't do these checks.
As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
This will lead to mismatches in the struct stat size, leading to memory
corruption and crashes.
This patch disables the year 2038 check for now, which makes things work
reliably again.
I'd consider this a temporary fix until we have proper bfd checks for the year
2038, if it makes sense. 64-bit hosts seems to be more common these days, so
I'm not sure how important it is to have this support enabled and how soon
we want to enable it.
Thoughts?
ChangeLog:
* configure.ac: Disable year2038 by default on 32-bit hosts.
* configure: Regenerate.
---
configure| 22 ++
configure.ac | 18 ++
2 files changed, 40 insertions(+)
diff --git a/configure b/configure
index 35c0c75ee12..faa1aedaa04 100755
--- a/configure
+++ b/configure
@@ -809,6 +809,7 @@ enable_ld
enable_gprofng
enable_compressed_debug_sections
enable_default_compressed_debug_sections_algorithm
+enable_year2038
enable_libquadmath
enable_libquadmath_support
enable_libada
@@ -1552,6 +1553,7 @@ Optional Features:
--enable-default-compressed-debug-sections-algorithm={zlib,zstd}
Default compression algorithm for
--enable-compressed-debug-sections.
+ --enable-year2038 enable support for timestamps past the year 2038
--disable-libquadmath do not build libquadmath directory
--disable-libquadmath-support
disable libquadmath support for Fortran
@@ -3194,6 +3196,20 @@ case "${host}" in
;;
esac
+# Default to --disable-year2038 until we can handle differences between
+# projects that use gnulib (which understands year 2038) and projects that
+# do not (like BFD).
+# Check whether --enable-year2038 was given.
+if test "${enable_year2038+set}" = set; then :
+ enableval=$enable_year2038; ENABLE_YEAR2038=$enableval
+else
+ ENABLE_YEAR2038=no
+fi
+
+enable_year2038=
+if test "${ENABLE_YEAR2038}" = "no" ; then
+ enable_year2038=no
+fi
# Check whether --enable-libquadmath was given.
if test "${enable_libquadmath+set}" = set; then :
@@ -10215,9 +10231,15 @@ if test "$silent" = yes; then
baseargs="$baseargs --silent"
tbaseargs="$tbaseargs --silent"
fi
+
baseargs="$baseargs --disable-option-checking"
tbaseargs="$tbaseargs --disable-option-checking"
+if test "$enable_year2038" = no; then
+ baseargs="$baseargs --disable-year2038"
+ tbaseargs="$tbaseargs --disable-year2038"
+fi
+
# Record and document user additions to sub configure arguments.
diff --git a/configure.ac b/configure.ac
index 71b923d316f..a0dff0ecac8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -459,6 +459,18 @@ case "${host}" in
;;
esac
+# Default to --disable-year2038 until we can handle differences between
+# projects that use gnulib (which understands year 2038) and projects that
+# do not (like BFD).
+AC_ARG_ENABLE(year2038,
+AS_HELP_STRING([--enable-year2038],
+ [enable support for timestamps past the year 2038]),
+ENABLE_YEAR2038=$enableval,
+ENABLE_YEAR2038=no)
+enable_year2038=
+if test "${ENABLE_YEAR2038}" = "no" ; then
+ enable_year2038=no
+fi
AC_ARG_ENABLE(libquadmath,
AS_HELP_STRING([--disable-libquadmath],
@@ -3339,9 +3351,15 @@ if test "$silent" = yes; then
baseargs="$baseargs --silent"
tbaseargs="$tbaseargs --silent"
fi
+
baseargs="$baseargs --disable-option-checking"
tbaseargs="$tbaseargs --disable-option-checking"
+if test "$enable_year2038" = no; then
+ baseargs="$baseargs --disable-year2038"
+ tbaseargs="$tbaseargs --disable-year2038"
+fi
+
# Record and document user additions to sub configure arguments.
AC_ARG_VAR([build_configargs],
[additional configure arguments for build directories])
--
2.41.0
[PATCH 03/24] gcc-4.5 build fixes
From: Alan Modra Trying to build binutils with an older gcc currently fails. Working around these gcc bugs is not onerous so let's fix them. include/ChangeLog: * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary forward declaration. --- include/xtensa-dynconfig.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/xtensa-dynconfig.h b/include/xtensa-dynconfig.h index 48877ebb6b6..45d54dcd0e0 100644 --- a/include/xtensa-dynconfig.h +++ b/include/xtensa-dynconfig.h @@ -121,8 +121,6 @@ struct xtensa_config_v4 int xchal_unaligned_store_hw; }; -typedef struct xtensa_isa_internal_struct xtensa_isa_internal; - extern const void *xtensa_load_config (const char *name, const void *no_plugin_def, const void *no_name_def); -- 2.41.0
[PATCH 09/24] add --enable-default-compressed-debug-sections-algorithm configure option
From: Martin Liska
ChangeLog:
* configure.ac: Add
--enable-default-compressed-debug-sections-algorithm.
* configure: Regenerate.
---
configure| 13 +
configure.ac | 6 ++
2 files changed, 19 insertions(+)
diff --git a/configure b/configure
index a5f6282bb0e..c5f6ae8e745 100755
--- a/configure
+++ b/configure
@@ -807,6 +807,7 @@ enable_offload_defaulted
enable_gold
enable_ld
enable_compressed_debug_sections
+enable_default_compressed_debug_sections_algorithm
enable_libquadmath
enable_libquadmath_support
enable_libada
@@ -1546,6 +1547,9 @@ Optional Features:
--enable-compressed-debug-sections={all,gas,gold,ld,none}
Enable compressed debug sections for gas, gold or ld
by default
+ --enable-default-compressed-debug-sections-algorithm={zlib,zstd}
+ Default compression algorithm for
+ --enable-compressed-debug-sections.
--disable-libquadmath do not build libquadmath directory
--disable-libquadmath-support
disable libquadmath support for Fortran
@@ -3142,6 +3146,15 @@ else
fi
+# Select default compression algorithm.
+# Check whether --enable-default_compressed_debug_sections_algorithm was given.
+if test "${enable_default_compressed_debug_sections_algorithm+set}" = set;
then :
+ enableval=$enable_default_compressed_debug_sections_algorithm;
+else
+ default_compressed_debug_sections_algorithm=
+fi
+
+
# Configure extra directories which are host specific
case "${host}" in
diff --git a/configure.ac b/configure.ac
index e820940c81e..ef30300af28 100644
--- a/configure.ac
+++ b/configure.ac
@@ -418,6 +418,12 @@ AC_ARG_ENABLE(compressed_debug_sections,
fi
], [enable_compressed_debug_sections=])
+# Select default compression algorithm.
+AC_ARG_ENABLE(default_compressed_debug_sections_algorithm,
+[AS_HELP_STRING([--enable-default-compressed-debug-sections-algorithm={zlib,zstd}],
+ [Default compression algorithm for
--enable-compressed-debug-sections.])],
+[], [default_compressed_debug_sections_algorithm=])
+
# Configure extra directories which are host specific
case "${host}" in
--
2.41.0
[PATCH 01/24] toplevel: Substitute GDCFLAGS instead of using CFLAGS
r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
implemented this change, but only on the generated file rather than in
the template it is generated from.
ChangeLog:
* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
$(CFLAGS).
---
Makefile.tpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.tpl b/Makefile.tpl
index d0fe7e2fb77..4fdca604eb0 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -447,7 +447,7 @@ LIBCFLAGS = $(CFLAGS)
CXXFLAGS = @CXXFLAGS@
LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
GOCFLAGS = $(CFLAGS)
-GDCFLAGS = $(CFLAGS)
+GDCFLAGS = @GDCFLAGS@
GM2FLAGS = $(CFLAGS)
# Pass additional PGO and LTO compiler options to the PGO build.
--
2.41.0
[PATCH 00/24] Sync shared build infrastructure with binutils-gdb
Hello, This patch set, combined with a sibling patch set sent on the binutils and GDB MLs, bring up the shared infrastructure between the two projects in sync again. It largely consists of cherry-picks from various people which have been reviewed and accepted on the binutils-gdb side, as well as a couple of patches for differences that seemed to get lost during the pick-and-regenerate process, though I've had to reformat quite a few commits so that they match what the changelog verifier expects. Some of these commits were previously applied and then reverted, namely "Check if AR works with --plugin and rc", but the reversion reason[1] seems to be no longer valid as of requiring Binutils 2.35 for LTO anyway. In addition, I'm not entirely certain that the handling of the removed targets I re-added is correct, nor what their status in binutils and gdb is, so feedback is welcome there. During this process, it appears that I overlooked passing -x to cherry-pick, so the paper trail got lost. If needed, I can hack together some code to associate commits based on subjects with their pair in the other repository, and amend the commits with these references added. These patches ignore the intl/ directory, as I plan to follow up this patchset with one that can be cleanly applied to both trees which gets rid of the intl/ directory in favor of out-of-tree gettext (ISL, GMP, et al. style). Bootstrapped and reg-tested on x86_64-pc-linux-gnu. OK for master? Thanks in advance, have a lovely day. [1]: https://inbox.sourceware.org/gcc-patches/CAMe9rOqFSOSM5Sw5SBMiy20rdgRJkftUXdw=ykexhvdmuty...@mail.gmail.com/ Alan Modra (4): PR29961, plugin-api.h: "Could not detect architecture endianess" gcc-4.5 build fixes egrep in binutils PR27116, Spelling errors found by Debian style checker Alexander von Gluck IV (1): Add support for the haiku operating system Arsen Arsenović (3): toplevel: Substitute GDCFLAGS instead of using CFLAGS toplevel: Recover tilegx/tilepro targets configure: reinstate 32b PA-RISC HP-UX target in toplevel Christophe Lyon (1): configure: require libzstd >= 1.4.0 Fangrui Song (1): binutils, gdb: support zstd compressed debug sections H.J. Lu (4): Sync with binutils: GCC: Pass --plugin to AR and RANLIB GCC: Check if AR works with --plugin and rc PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works Indu Bhagat (2): bfd: linker: merge .sframe sections toplevel: Makefile.def: add install-strip dependency on libsframe John Ericson (1): Deprecate a.out support for NetBSD targets. Luis Machado (1): Disable year 2038 support on 32-bit hosts by default Martin Liska (1): add --enable-default-compressed-debug-sections-algorithm configure option Nick Alcock (3): libtool.m4: fix nm BSD flag detection libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case libtool.m4: augment symcode for Solaris 11 Simon Marchi (1): Pass PKG_CONFIG_PATH down from top-level Makefile Vladimir Mezentsev (1): gprofng: a new GNU profiler Makefile.def | 18 ++ Makefile.in| 517 - Makefile.tpl | 10 +- config/gcc-plugin.m4 | 40 +++ config/lib-ld.m4 | 8 +- config/override.m4 | 2 +- config/picflag.m4 | 4 +- config/pkg.m4 | 8 + config/zstd.m4 | 23 ++ configure | 224 +++- configure.ac | 74 +- fixincludes/configure | 3 +- gcc/configure | 140 ++ include/collectorAPI.h | 73 ++ include/libcollector.h | 89 +++ include/libfcollector.h| 42 +++ include/plugin-api.h | 49 ++-- include/xtensa-dynconfig.h | 2 - intl/configure | 4 +- libada/configure | 4 +- libatomic/configure| 130 ++ libbacktrace/configure | 130 ++ libcc1/configure | 132 ++ libcpp/configure | 4 +- libffi/configure | 132 ++ libgcc/configure | 6 +- libgfortran/configure | 132 ++ libgm2/configure | 132 ++ libgomp/configure | 132 ++ libiberty/Makefile.in | 5 +- libiberty/aclocal.m4 | 1 + libiberty/configure| 144 ++- libiberty/configure.ac | 12 + libitm/configure | 132 ++ libobjc/configure | 130 ++ libphobos/configure| 130 ++ libquadmath/configure | 130 ++ libsanitizer/configure | 132 ++ libssp/configure | 130 ++ libstdc++-v3/configure | 148 +++ libtool.m4 | 130 ++ libvtv/configure | 132 ++ lto-plugin/configure | 130 ++ zlib/configure | 130 ++ 44 files changed, 2924 insertions(+), 956
Re: Please stop blocking xstyle/stylish
zxuiji via Gcc writes:
> Your site is far too bright and is absolutely painful to the eyes, I
> have a simple invert style that I expected to work on all sites and I
> found your site is undertaking the vile act of blocking user styles. I
> expect that sort of rotten design from microsoft & apple (which
> ironically don't), not from a site that is supposed to be on the user
> freedom of choice side of the spectrum.
We don't block either. Something else is afoot.
As a test, I set:
* {
background-color: red;
}
... in Stylus locally, and it worked fine.
What lead you to believe that it's blocked on the site (and which site
do you mean, precisely)?
Hope I can help, have a lovely day.
--
Arsen Arsenović
signature.asc
Description: PGP signature
[pushed] extend.texi: index __auto_type
gcc/ChangeLog:
* doc/extend.texi: Add @cindex on __auto_type.
---
Pushed as obvious.
gcc/doc/extend.texi | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 093bd97ba4d..ec9ffa3c86e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -843,6 +843,7 @@ Thus, @code{array (pointer (char), 4)} is the type of
arrays of 4
pointers to @code{char}.
@end itemize
+@cindex @code{__auto_type} in GNU C
In GNU C, but not GNU C++, you may also declare the type of a variable
as @code{__auto_type}. In that case, the declaration must declare
only one variable, whose declarator must just be an identifier, the
--
2.41.0
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
David Edelsohn writes: > The GNU Toolchain leadership has blacklisted people in the past, but we > have used the power sparingly. > > The behavior of the individual attracts attention, albeit negative, while > not effectively accomplishing what he purports to desire. The recommended > solution is to ignore the poster instead of trying to encourage him to > communicate more effectively. IMO, the sparing usage of this power on what are clearly purely abusive participants can only drive away users and contributors. It seems reasonable to establish a process for dealing with incidents like this (and appeals, of course), especially given their frecency. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH v2 0/5] A small Texinfo refinement
Hi,
NightStrike writes:
> Can you include texinfo in a top-level directory and have it built with the
> build, like you can with dejagnu? That's generally a decent path for
> building new gcc on older systems.
Note that the Texinfo requirement wasn't bumped, so nothing changed in
this regard, however, I believe that this is already done, as I see the
following in Makefile.def:
host_modules= { module= texinfo; no_install= true; };
(... and some relevant logic in configure.ac)
I'm not a fan of building dependencies in-tree, but I can see the
usefulness; I believe a superior solution would be one that adds .info
(et al.) files to all generated tarballs (including snapshots), hence
eliminating any extra deps anyway. These files aren't system-specific,
after all, as they are neither code nor conditionally compiled.
This is also assumed practice in other packages.
Have a lovely day.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: LSP based on GCC
David Malcolm writes: > [...snip...] > I wrote that prototype, but I haven't touched it since 2017, and I > already have more than enough other work, alas. I'm happy to help if > someone wants to pick up the work and finish it. > > That patch kit did several things: > (a) adds a new "on the side" representation of source code locations > (b) adds a JSON implementation to gcc > (c) implements an LSP server on a port, implementing only the > "textDocument/definition" method. > > Not having quite enough source code location is a pet peeve of mine > within GCC's intermediate representation, as we lose a fair bit of > location information as we go from frontends to the tree/generic > representation (e.g. "exactly where was each brace?"). You mentioned 'cousin' tools in your original post, and I largely agree with your sentiment. Many parts of the job of an FE can be reused for many other purposes, evidently. Even beyond an LSP implementation. > Unfortunately the particular approach I came up with in (a) was > rejected by frontend maintainers, so I abandoned that part of the > work. I couldn't find the relevant messages. Mind sharing a message-id or archive link? > The part of (b) for storing JSON trees in memory and writing them out > is in GCC's source tree; the JSON-parsing code isn't yet, but I have a > relatively up-to-date refreshed version of that code in one of my > working copies which I can post to the list if it will be helpful. > > As for (c), doing it on a port is probably wrong, and working with > stdin/stdout seems a much better approach. AIUI, many editors (including Emacs' Eglot) also expect this (but I suspect many can leverage other methods of connecting too). ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to implement various bits of LSP functionality, such as handling multiple TUs. This sounds like a good idea to me (at least at a high level), as it could lead to the hypothetical GNU toolchain LSP implementation being partially language-agnostic (naturally, some things like candidate lists would still need language support, as well as documentation parsing, ...), which would be quite handy. Do you happen to have any memory of that? Thanks in advance, have a lovely evening. -- Arsen Arsenović signature.asc Description: PGP signature
[pushed] doc: Fix a pinch of typos in extend.texi
gcc/ChangeLog:
* doc/extend.texi (C++ Concepts) : Remove extraneous
parenthesis. Fix misnamed index entry.
: Fix misnamed index entry.
---
Pushed as obvious.
gcc/doc/extend.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 69b21a75e62..ed8b9c8a87b 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -25460,12 +25460,12 @@ assumption is valid. For example, @code{assume(n >
0)}.
@item axiom
Introduces an axiom definition. Axioms introduce requirements on values.
-@kindex axiom
+@kindex forall
@item forall
Introduces a universally quantified object in an axiom. For example,
-@code{forall (int n) n + 0 == n}).
+@code{forall (int n) n + 0 == n}.
-@kindex axiom
+@kindex concept
@item concept
Introduces a concept definition. Concepts are sets of syntactic and semantic
requirements on types and their values.
--
2.40.1
Re: More C type errors by default for GCC 14
Po Lu via Gcc writes: ... > Where is it written that GNU CC follows your so-called > ``specification-driven development''? Any development style making documentation a source of truth matches this principle. This does not refer to ISO specifications specifically, though, normally, unless the standard disagrees with reality, as implicit-... did many years ago, ISO decisions are taken seriously. > Here is an explanation from one of the original GCC developers. It > discusses strict aliasing, but the same principles apply here: > > (199909100634.caa01...@psilocin.gnu.org) > > My comment is similar to Mark's comment. Documentation, what can > we document as working? > > We should not even try to document that these cases work. > Documentation is what we do when we add a feature. > > I am not proposing this as a feature, just as a way to avoid evitable > trouble for users. We should not even try to document a class of > cases that are "supposed" to work, because I'm not saying these are > "supposed" to work. We should just let them work. > > > Anway, more questions from me than answers... Off hand though, if > we can make the compiler generate `right' code in more cases, even > if the users code is wrong, I think we should probably do it. > > In C, we cannot divide all user code into "right" and "wrong" in this > kind of simple way, and certainly not based on the ISO standard. That > standard is just the decisions of a certain committee (which I was a > member of) about what cases conforming compilers should commit to > support. We must not let ourselves start thinking that C code is > "wrong", just because it is not conforming ISO C code. > > C programs use many cases that are not conforming, but do work. This > will be true for as long as C is used, because changing it would > require major changes in the C language. > > From time to time, there is a real *need* to make some of these cases > stop working, for the sake of some benefit that users want. When this > happens, we should do it; the user community will accept it, because > they will see that it is being done for their sake. Some will > grumble, but the users who appreciate the benefits will convince them. > > But when there is no *need* to break these cases, when we can keep > them working fairly easily, we should keep them working. If we break > them unnecessarily, we invite the legitimate anger of the users. > > and another (199909100634.caa01...@psilocin.gnu.org): > > However, I have a rather serious objection: it means that users > cannot tell whether their code is valid, even according to the GCC > rules, without knowing the internals of the compiler. > > This has always been true. It is true in the current version of GCC > with regard to aliasing, even when -fstrict-aliasing is used. It is > part of the nature of C. > > The goal of trying to avoid it is unrealistic and misguided; it can't > be done. So this cannot be a valid reason to reject a change. > > The compiler should continue to aggressively break code that > misbehaves in this way. > > This proposes to break users' code, just to bully them into changing > it. That is a callous and harsh attitude towards the users of GCC. > No wonder users are angry. They know that the problems are not due to > necessity, but due to callous disregard for them. > > We cannot do everything all users want, and sometimes a maintainer has > to say no to users. "You cannot please everyone," as the saying goes. > There are many kinds of reasons which can sometimes be good reasons to > say no. > > But maintainers should always say no reluctantly--never eagerly. We > should never aggressively cause trouble for users today, just because > someday it might be necessary. That is like amputating limbs because > someday they might be crushed. > > This treatment of users brings shame on the GNU Project. I ask > everyone therefore not to suggest that we should treat users this way. > >> Sound familiar? A bit like GCC triggering a warning, telling you that >> what you're doing is bad and should not be relied on? > > A diagnostic message is supposed to inform me of a diagnosis by the > translator. The severity of the diagnosis, is, as always, up to the > user to decide, as long as enough information remains for translation to > continue. It is, after this proposal is accepted, still up to the user to decide. The only difference is that the default would be friendlier to new code and users and most code that exists today, rather than to very old code and incorrect code. Additionally, there isn't enough information to compile. The compiler makes up new information to fill in the gaps. If that definition accepted, most error recovery should be turned into valid code paths that participate as GNU
Re: Wish: scoped enum
Hi,
Yair Lenga via Gcc writes:
> I wonder if it will be possible to add support for "scoped" enum to GCC.
> The current C standard has one name space for all enums, and different name
> space for the members of each "struct". As a result, possible to say
>
> struct foo { int a } ;
> struct bar { double a }; // This is different 'a', different type
>
> But illegal to to (ignoring the conversion to use all upper for enum).
>
> enum a { u, v } ;
> enum b { v, w } ; // can not do this, as 'v' must be distinct
>
> One annoying side effect is that any package/module creating an enum has to
> worry about namespace collision with everyone else in the world. Common
> practices include distinct prefixes, similar to the way different libraries
> use distinct prefixes to avoid function name collision. This solution is
> far from perfect and leads to excessive long enum name.
>
> A reasonable wish list - add a magic keyword that will place the enums into
> a scope, so that the following work:
>
> SCOPED enum shirt_sz { small, medium, large } ;
> SCOPED enum shoe_sz { small, medium, medium_wide, large, xlarge } ;
>
> enum shirt_sz tshift_size = shift_sz.medium ;
> enum shoe_siz boot_size = shoe_sz.xlarge ;
>
> Not perfect, but not complex, will make enum reusable across many scenario,
> where they are currently hard to implement - because of namespace conflict
> - between system header and user headers, between different packages.
>
> A smart compiler can also alert when "types" are mixed (assign value from
> shift_sz to a variable of type shoe_sz). Not critical - as my understanding
> is that this is not enforced today. For the case that an enum symbol is
> distinct (in the current compilation unit), the compiler can allow using it
> without the namespace - practically falling back into current behavior.
>
> Feedback ? Anyone know how to get a prototype into gcc ? How one get
> approval for such "extensions".
I'd suggest, if you choose to implement this, to imitate what C++ does
for these, maybe even propose it for the standard. There's already
established syntax and semantics.
It would certainly be nice to have such a thing in C.
Have a lovely evening.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: More C type errors by default for GCC 14
Eli Zaretskii writes: >> Cc: Jonathan Wakely , gcc@gcc.gnu.org >> Date: Thu, 11 May 2023 10:44:47 +0200 >> From: Arsen Arsenović via Gcc >> >> the current default of accepting this code in C is harmful to those >> who are writing new code, or are learning C. > > People who learn C should be advised to turn on all the warnings, and > should be educated not to ignore any warnings. So this is a red > herring. Indeed they should be - but warning vs. error holds significance. A beginner is much less likely to be writing clever code that allegedly uses these features properly than to be building new code, and simply having made an error that they do not want and will suffer through confused. >> This seems like a good route to me - it facilitates both veterans >> maintaining code and beginners just learning how to write C. > > No, it prefers beginners (which already have the warnings, unless they > deliberately turn them off) to veterans who know what they are doing, > and can live with those warnings. Indeed. I said facilitates, not treats equally. I think the veterans here won't lose much by having to pass -fpermissive, and I think that's a worthwhile sacrifice to make, to nurture the new without pressuring the old very much. > The right balance is exactly what we have now: emitting warnings > without breaking builds. I disagree - I think breaking builds here (remember, it takes 13 bytes to fix them) is a much lower weight than the other case being shot in the foot for an easily detectable and treatable error being made easily missable instead, so I reckon the scale is tipped heavily towards the veterans. On that note - lets presume a beginners role. I've just started using GCC. I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out. It mentions some 'implicit function generation', dunno what that means - if it mattered much, it'd have been an error. I wrote a function called test that prints the int it got in hex, but I called it with 12.3, but it printed 1.. what the heck? Why that happened is obvious to you and I (if you're on the same CPU as me), but to a beginner is utter nonsense. At this point, I can only assume one goes to revisit that warning.. I'd hope so at least. I doubt the beginner would know to pass -Werror=implicit-function-declaration in this case (or even about Werror... I just told them what -Wall and to read the warnings, which was gleefully ignored) Anyway - I'm not making that up - this circle of 'yeah the warnings actually matter.. a lot' has happened with everyone I've tutored that has had little to no contact with programming before (those who had more contact have a higher respect for the word 'warning'), and it will keep happening. Hell, I've seen professors do it, and for a simple reason: they knew how to write code, not how to use a compiler. That's a big gap. The beginner here can't adapt - they don't know what -Wall means, they just pass it because they were told to do it (if they're lucky!). At the same time, they lose out on what is, IMO, one of the most useful pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables it by default.. we do). It provides effective bug detection, when the code compiles right. It regularly spots bugs that haven't happened yet for me. (and same goes for all the other useful analysis the toolchain can do when it has sufficient information to generate correct code, or more; some of which can't reasonably be a default) (on a related note, IMO it's a shame that the toolchain hides so many possibilities behind 'cult knowledge', depths of many manuals and bad defaults) On the other hand... I've been writing C for a long time, and you have been doing so for a longer time. We see 'error: ...' in an old codebase for a pedantic (rather, by my definition, bare essential) check and we know where to look to fix it or ignore it. I build old, unfamiliar codebases all the time, and I've been using a modified toolchain that enables the error proposed today for a while; my peers and I, who are proposing this, have gone over thousands of old codebases, I've fixed some personally, yet the percentage of those that have been full-out broken by this change is small (configure scripts are almost all of it, too; Po has mentioned that they use a laxer compiler for those - we (Gentoo) test two compilers in order to detect when these differences happen, but keep the results of the laxer one, and then try to fix the code upstream - often it comes down to just running autoconf -f, even). This sample is subject to selection bias. My testing targets mostly more modern codebases that have long fixed these errors (if they have active maintainers), and exclusively Free Software, so I expect that the likelyhood that you'll need to run `export CC='gcc -fpermissive' CXX='g++ -fpermissive'` goes up the more you move towards old or more corporate codeba
Re: More C type errors by default for GCC 14
Po Lu writes: > Arsen Arsenović writes: > >> Good. The above code is nonsense, the chances that foo will be >> incorrectly called are high. > > Yet lint (or scrutiny, as should be performed with any declaration, > implicit or not) makes sure that does not happen. Relying on human scrutiny when an algorithm can trivially deduce an answer more quickly and more reliably (because even in the case that the code you showed compiles, it assumes processor specific facts) has historic precedent as being a bad idea. I'm curious, though, about how lint checks for this. >> What is this meant to produce? > > It was just an example. I'm not allowed to show any real code. > >> This is, at best, a "works by coincidence", rather than being code >> anyone should be writing. > > See what I said about being the judge, jury and executioner. > > (BTW, I thought implicit int was being discussed, not implicit >function declarations, but here goes.) > > The same problems will appear with _any_ extern declaration. If you > remove implicit function declarations, people will simply paste: > > extern int foo (); > > above the code which no longer compiles. > Or, if you force everyone to use prototypes, > > extern int foo (char *); So be it. The edge case still exists. The normal case that I expect most code is dealing with is much simpler: a missing include. That case is not discounted by the existence of misdeclarations across TUs. > You will not be able to diagnose whether or not this declaration is > correct, because the definition will lie in another translation unit. > Except that in this case, no diagnostic will be issued at all when > the declared function is called. > > The only place where you can truly fix mismatched declarations is the > linker (or collect2?) GCC proper cannot do anything about it. There's already -Wlto-type-mismatch. It has spotted a few bugs in my own code. >> Such code is already written, when building it, pass -fpermissive. >> You benefit from the error otherwise. >> >> (and no, this isn't an issue of style, the code in question *does not* >> convey sufficient information for the compiler to always do the right >> thing) > > It does on reasonable machines for which the code was written. I gave > two examples. Perhaps the 386 is another. Yes, indeed. And code should keep working on those machines, because it costs little to nothing to keep it working. And it will if you pass -fpermissive. It seems to me plausible that the paragraph in the original proposal that suggested -fpermissive might have been missed. It is unfeasible for GCC to entirely stop compiling this code, there's nobody that is advocating for doing that; however, the current default of accepting this code in C is harmful to those who are writing new code, or are learning C. This seems like a good route to me - it facilitates both veterans maintaining code and beginners just learning how to write C. Have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: More C type errors by default for GCC 14
Po Lu via Gcc writes:
> Jonathan Wakely via Gcc writes:
>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii, wrote:
>>
>>>
>>> And then people will start complaining about GCC unnecessarily
>>> erroring out, which is a compiler bug, since there's no problem
>>> producing correct code in these cases.
>>>
>>
>>
>> What is the correct code for this?
>>
>> void foo(int);
>> void bar() { foo("42"); }
>>
>> Why should this compile?
>
> Because keeping that from compiling will also keep this from compiling:
>
> bar ()
> {
> extern foo ();
>
> return foo ("42");
> }
Good. The above code is nonsense, the chances that foo will be
incorrectly called are high.
>> You keep demanding better rationale for the change, but your argument
>> amounts to nothing more than "it compiles today, it should compile
>> tomorrow".
>
> And so it should. Because for every invalid piece of code you can think
> of, there are hundereds or thousands of combinations that may as well be
> valid. For example, on the 68020, vax, or similarly reasonable 32-bit
> machine:
>
> foo (ptr)
> {
> register char *str;
>
> str = ptr;
>
> /* do stuff with str */
>
> puts (str);
> }
>
> /* In another translation unit. */
>
> bar ()
> {
> foo ("42");
> }
What is this meant to produce?
This is, at best, a "works by coincidence", rather than being code
anyone should be writing.
Such code is already written, when building it, pass -fpermissive.
You benefit from the error otherwise.
(and no, this isn't an issue of style, the code in question *does not*
convey sufficient information for the compiler to always do the right
thing)
Have a lovely day.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: More C type errors by default for GCC 14
Po Lu via Gcc writes: > jwakely@gmail.com (Jonathan Wakely) writes: > >> This isn't "be like Clang", this is "diagnose things that have been >> invalid C since 1999". > > Only if your definition of valid C is ``strictly conforming to the ISO > Standard''. I doubt there are many programs which fit such a > definition. > > And anyway, GCC accepts many other constructs which can not be used in a > strictly conforming Standard C programs. For example, the use of dollar > signs in identifiers. Should we not also reject those, identifier names > with external linkage longer than thirty two characters, hex floats, > arithmetic on void pointers, zero-length arrays, statement expressions, > and so on? None of these result in a whisper-level warning before a severe but difficult to detect breakage. >> Accepting invalid code by default is a disservice to users. Those who >> need to compile invalid C code can use an extra option to allow it, >> the default should be to tell users their code is doing something bad. > > The code is conforming, it simply relies on extensions to the Standard. > Implicit int does not break any strictly conforming program, so a C > implementation implemented it continues to be conforming, along with > those programs relying on implicit int. See this wording in the > Standard: All of the features in question actively break programs (because they allow entirely wrong code to be emitted). > A conforming implementation may have extensions (including additional > library functions), provided they do not alter the behavior of any > strictly conforming program. > > You are not trying to reject non-conforming C code. You are, for better > or worse, trying to impose your personal preferences on users of GCC. > Let's debate the real problem at hand instead of using the Standard as a > boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a > good idea. It is. -- Arsen Arsenović signature.asc Description: PGP signature
Re: More C type errors by default for GCC 14
Eli Zaretskii writes: > It is not GCC's business to force developers of packages to get their > act together. Why not? Compilers are diagnostic tools besides just machines that guess what machine code you mean. > It is the business of those package developers themselves. GCC should > give those developers effective and convenient means of detecting any > unsafe and dubious code and of correcting it as they see fit. Which > GCC already does by emitting warnings. There's a difference between dubious and unsafe code and code that is unambiguously wrong, but was chosen to be accepted many years ago. > GCC should only error out if it is completely unable to produce valid > code, which is not the case here, since it has been producing valid > code for ages. Producing call code with wrong prototypes is not within my definition of producing valid code. > It is a disservice to GCC users if a program that compiled yesterday > and worked perfectly well suddenly cannot be built because GCC was > upgraded, perhaps due to completely unrelated reasons. Please see the various porting-to pages. Compilers stop being able to produce code with older versions of programs because of them being a lil' too lax and the programs accidentally relying on that every year. There's nothing wrong there. If compilers stopped being lax, such things wouldn't happen simply because programs couldn't accidentally rely on it, so we'd get the ideal world without breakages. We don't get that by pretending code is fine when it is not, and letting developers write that code. Now, of course, this instance is different to porting-to pages, because we aren't talking about code accidentally relying on a transitive include or an edge case or somesuch, we're talking about the compiler going out of its way to produce wrong code and whispering into the wind about doing it. > It would be a grave mistake on the part of GCC to decide that part of > its mission is to teach package developers how to write their code and > when and how to modify it. It would be a grave mistake on the part of GCC to decide that part of its mission is to pretend code is fine when it is unambiguously broken, and then not tell people about it very loudly. I don't think we should send out the message of "GCC: the compiler for your untouchable legacy code, not for writing new code, or upgrading existing code". Providing compatibility here is a trivial job, we don't need to make each developer suffer with tweaking compiler flags to get the compiler to diagnose blatantly wrong code as errors, or more likely, not do it at all because they don't know about this problem. We could, of course, alter documentation to tell people that running GCC in strict mode requires some concoction of flags, or we could alter it so that it says that running GCC in a lax mode requires *one* flag, for the exceptional case where code can't be easily fixed, and it's more useful to pretend it's fine and emit broken calls. We could even provide a 'laxgcc' or such driver that covers this exceptional case OOTB (though I'm unconvinced that does anything that setting CC='gcc -fpermissive' doesn't cover). Have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: More C type errors by default for GCC 14
Thomas Koenig via Gcc writes: > Not replying to anybody in particular, just a bit of history, with > some potential parallels. > > In gfortran, we have had two major issues with interfaces. One was that > code which had happily violated the compiler ABI started failing, due > to a fix in the gfortran front end which meant that we were no longer > mixing varargs and non-varargs calls (which led to code being correctly > compiled for POWER which had been miscompiled for basically forewer). > > Among other things, this broke R, and was fixed by Jakub by applying > a workaround. After a few years, people in core libraries like BLAS > and Netlib are finally getting around to fixing their code. There is > no knowing what codes still have that, so the workaround will probably > stay around forever, although we don't promise that it does. > > Partially motivated by this, we then added a file-level check for > argument list mismatches (type and rank), which issued an error. > > That error could be disabled by a new option, -fallow-argument-mismatch, > but that caused problems for people using different versions of the > compiler. So we added this option to -std=legacy, which is a catch-all > kitchen sink, which accepts some not-so-nice things. > > Of course, as everybody on this list knows, mixing types like this is > dangerous, and is liable to break sooner or later in future compiler > release. Nonetheless, even a package like MPICH chose to use autoconf > to set the -fallow-argument-mismatch flag rather than fix the code :-( > > Others, like the LAPACK maintainers, have reacted and installed > patches. > > So... using an error message as a crowbar to change people's behavior > failed, at least partially. And you only hear from the people who > complain, not from those who are glad that they found errors that they > would otherwise have missed. > > What does that mean for the case at hand? Based on past experience, > I'd lean towards putting all the warnings about the special offending > codes into one warning option (-Wsevere, or something) which could > then be made into an error by -Werror=severe or such variant; maybe > other warnings could be grouped in there as well. And if these severe > warnings should then be made default or not, well... that (like the > rest of my mail) is open for discussion. I don't see permitting this code by default as providing any benefit, even in a world in which we presume everyone passes -fpermissive or such. We should not make the default loose. It is worse for the average responsible developer to carry a heap of flags than it is for the occasional irresponsible one (or a person dealing with legacy code) to carry a single flag (or even a couple). I can't speak on how close this is to how people will behave when dealing with C, as I have minimal Fortran experience, but I am decently sure that, unambiguously, these mistakes are entirely unwanted in C, without significant upside, and so, I'm optimistic that any maintained piece of code will soon get rid of them as a result of increasing strictenss in GCC. (again, this line of thought excludes the upside of compatibility with old code as that is not particularly hard to achieve, and so I feel it doesn't need to be considered) > Best regards > > Thomas Thank you for your insight, have a lovely evening. -- Arsen Arsenović signature.asc Description: PGP signature
Re: More C type errors by default for GCC 14
David Edelsohn writes: > This seems to be the core tension. If developers cared about these issues, > they would enable appropriate warnings and -Werror. These issues are easy to miss and overlook. Making them louder helps prevent that. Additionally, requiring the users to remember a dozen flags to make the compiler strict rather than compatible is just terrible UX. Today, developers need to both care and know about toolchain oddities to effectively catch these errors, not just to care. > The code using these idioms is not safe and does create security > vulnerabilities. And software security is increasingly important. > > The concern is using the good will of the GNU Toolchain brand as the tip of > the spear or battering ram to motivate software packages to fix their > problems. It's using GCC as leverage in a manner that is difficult for > package maintainers to avoid. Maybe that's a necessary approach, but we > should be clear about the reasoning. Again, I'm not objecting, but let's > clarify why we are choosing this approach. Both the GNU Toolchain and the GNU Toolchain users will benefit from a stricter toolchain. People can and have stopped using the GNU Toolchain due to lackluster and non-strict defaults. This is certainly not positive for the brand, and I doubt it buys it much good will. Depending on what exactly you mean by package maintainers, there's already precedent on how to provide an out (and the OP talks about that exact topic, too, as it is not something to ignore). -- Arsen Arsenović signature.asc Description: PGP signature
Re: More C type errors by default for GCC 14
Eli Zaretskii writes: >> Cc: Jonathan Wakely , gcc@gcc.gnu.org >> Date: Tue, 09 May 2023 18:38:05 +0200 >> From: Arsen Arsenović via Gcc >> >> You're actively dismissing the benefit. > > Which benefit? > > No one has yet explained why a warning about this is not enough, and > why it must be made an error. Florian's initial post doesn't explain > that, and none of the followups did, although questions about whether > a warning is not already sufficient were asked. Quite simple: people don't (as easily) choose to ignore errors. You can see this in any teaching environment, and I've had such experience in many of them, so I can say with an extremely high degree of confidence that people, by default, do not ignore errors. A student will see twenty warnings and brush it off, but will see one error and diligently go back to fix it. If we tally up the hypothetical users of the hypothetical -fpermissive coverage for enabling these broken constructs, I think that we (compiler and distro developers) will be a supermajority or more. I am absolutely certain, by virtue of us having this conversation today, that warnings are not enough. I am also absolutely certain that an opt-out error *will* work, as it has before for cases like -fcommon and the G++ -fpermissive flag (naturally, these aren't magically gone, but they are becoming rarer). Hell, I've missed warnings before as they do not normally raise a flag during development (hence -Werror), even though I have many years of dealing with loose toolchain defaults. > That's a simple question, and unless answered with valid arguments, > the proposal cannot make sense to me, at least. I'll repeat a few reasons others have cited: - implicit or misdeclared calls lead to subtly incorrect code, - implicit calls lead to a lack of toolchain features like _FORTIFY_SOURCE, - implicit calls lead to wrong symbols being chosen, leading to data being trimmed, which can on occasion hide itself for a long time, - all of these constructs have been unambiguously invalid for decades, - the impact is relatively small (Florian cited a figure of six percent, which lines up roughly with my own observation), yet an escape hatch for aged code can be easily provided. - as the compiler is less informed about what code its interfacing in, diagnostics are proportionally affected (alongside producing incorrect code). - these constructs have been invalid for decades, and, if considered an extension, they're a hideous blot. - by making GCC not a strict compiler *by default*, we encourage using non-GNU toolchains because 'they provide better error reporting'. This also applies for other components of the toolchain. I, for one, have little interest in enabling that when the cost for keeping fast-and-loose-playing compilers for old (read: broken) codebases is low. It is very much okay (nae, a feature) to be compatible with previous versions of the compiler, and a prior status quo, but we should not let it hold us to worse old standards in terms of strictness. On the contrary, I'd like to hear the upsides of keeping these defaults, besides compatibility, as that one is easily achieved without keeping horrid defaults Have a most lovely evening. -- Arsen Arsenović signature.asc Description: PGP signature
Re: More C type errors by default for GCC 14
Dave Blanchard writes:
> On Tue, 9 May 2023 16:14:28 +0100
> Jonathan Wakely via Gcc wrote:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> And in the process, break half of my system, and make it even more of a pain
> in
> the ass to compile old software. With no real gain or benefit whatsoever. To
> hell with that bullshit.
Your system seems to be already broken.
You're actively dismissing the benefit.
>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The default ALREADY IS to tell users their code is doing something bad. It's
> called a "warning." Hello?
This construct is a blatant error and is easily fixable. Not to mention
that it has been invalid, just the same as 'if {foo() == 3} ( bar{} );'
is. We're currently not emitting a warning and accepting such code, so
I don't see why this blatantly invalid construct should be taken
differently, especially when it is an exception rather than a rule in
practice.
Have a great day.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: More C type errors by default for GCC 14
Dave Blanchard writes: > On Tue, 09 May 2023 16:07:50 +0100 > Sam James via Gcc wrote: > >> Florian did note this already - ABI. Implicit function declarations are >> pretty horrible in a number of cases: >> - they prevent fortification (_FORTIFY_SOURCE) > > So what? Print a warning, for those who are writing new code or maintaining > old > code and actually care. Done. > >> - they prevent time64 and LFS migrations from working correctly > > So what? Print a warning, for those who are writing new code or maintaining > old > code and actually care. Done. > > 2038 is 15 years away. I'm trying to keep existing code working TODAY. > >> - they break with different ABIs (see e.g. Apple's arm64 ABI) > > I don't care about Apple or ARM64. I'm trying to keep old code working fine > on x86. It doesn't work fine on x86 (or any other arch). See the two points above that you've baselessly dismissed. >> - they can cause runtime crashes when combined wtih bfd's default of >> not warning on underlinking > > My system is perfectly stable, thanks. In fact it is much more stable and much > snappier than the garbage released by the likes of Fedora, RedHat, etc. If > runtime crashes and stability were a concern for those folks, they should > start > by dropping 'Linux Puttering' out of a helicopter. Employment of such language is unwanted, but sadly, I'm not surprised. >> int-conversion generally indicates severe runtime problems as well. > > Not in my experience. My system works fine, despite approximately 10,000,000 > warnings spit out by GCC during the build process. You've actively and baselessly dismissed the general case (and are, and I say this with a lot of confidence, missing subtle bugs on your system). >> Many of the cases I've seen on musl absolutely do not work at runtime and >> weren't caught by any other warnings (often because of padding mismatches). > > Well that's the risk you take by changing the C standard library. My system > works fine on glibc. If any given package has a problem on musl, I will take > that on a case by case basis. Wrecking my build process by introducing 10,000 > new errors isn't part of the solution. The number of errors is far smaller than you estimate. We've been working through the queue for a while and have a decent idea of the scope of the problem, and it is very manageable. On top of that, the errors in question are largely trivial to fix, unlike detecting the errors introduced by the current 'working' code. >> That's why Fedora and Gentoo have been aggressively working on this >> before even proposing it. We are being proactive in making sure that >> common things are fixed. > > Yeah, you're being proactive in ruining everything. Thanks. How's systemd and > pulseaudio working out for you? They compile fine, and run without subtle bugs caused by constructs that have been invalid for over 20 years. >> I don't know if it's that aggressive to drop something which was >> removed in C99 because of how dangerous it is. > > You're breaking old code unnecessarily by introducing an error, when the > existing warning is perfectly fine. > > If it was such a horrible, terrible, no-good thing that it must be removed > immediately, then why wasn't this already changed decades ago? Hint: BECAUSE > YOU ARE BREAKING PEOPLE'S FUCKING SYSTEMS FOR NO REASON. It doesn't work fine. See the points that you've dismissed above. The situation was also far simpler decades ago, and the actual trade-off far greater (now invalid code is the exception). >> Also, keep in mind, Florian went around and asked many of the first >> group (the foundational folks) who didn't object. > > No, he asked a few big shot million dollar well-funded distributions if they > had any problems with increasing their workload and maybe hiring a few extra > developers. Unsurprisingly that select group of insiders had no problem with > it. Meanwhile there are thousands of other smaller users and organizations out > there whose concerns are just as important. This seems irrelevant, and is not an accurate representation of who's involved in the process. >> Not that this is a strong argument, and I don't like making it, but >> if Clang is doing it and GCC does too, it's not like they can reassess >> their choices anyway. > > In fact that's exactly why GCC should continue just the way it is, so that > people can have an actual alternative to the "bondage and discipline" > approach, > and continue keeping their old code working just fine when there are literally > NO PROBLEMS with the status quo. Current code is subtly broken. It is a disservice to users to pretend otherwise. Have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Ping: [PATCH 0/2] Unify and deduplicate FTM code
Ping. This patch rebases cleanly as of right now. No new changes to review. Have a lovely day! -- Arsen Arsenović signature.asc Description: PGP signature
[PUSHED gcc-11] extend.texi: replace @itemx not preceded by @item.
gcc/ChangeLog:
* doc/extend.texi: Replace @itemx not being preceded by @item.
---
Fixes errors raised by newer Texinfo.
Pushed as obvious.
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index d6093397a61..64bd4c1cb6c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2487,7 +2487,7 @@ The following attributes are supported on most targets.
@table @code
@c Keep this table alphabetized by attribute name. Treat _ as space.
-@itemx access (@var{access-mode}, @var{ref-index})
+@item access (@var{access-mode}, @var{ref-index})
@itemx access (@var{access-mode}, @var{ref-index}, @var{size-index})
The @code{access} attribute enables the detection of invalid or unsafe
--
2.40.1
[PATCH 1/2] libstdc++: Implement more maintainable header
This commit replaces the ad-hoc logic in with an AutoGen
database that (mostly) declaratively generates a version.h bit which
combines all of the FTM logic across all headers together.
This generated header defines macros of the form __glibcxx_foo,
equivalent to their __cpp_lib_foo variants, according to rules specified
in version.def and, optionally, if __glibcxx_want_foo or
__glibcxx_want_all are defined, also defines __cpp_lib_foo forms with
the same definition.
libstdc++-v3/ChangeLog:
* include/Makefile.am (bits_freestanding): Add version.h.
(allcreated): Add version.h.
(${bits_srcdir}/version.h): New rule. Regenerates
version.h out of version.{def,tpl}.
* include/Makefile.in: Regenerate.
* include/bits/version.def: New file. Declares a list of
all feature test macros, their values and their preconditions.
* include/bits/version.tpl: New file. Turns version.def
into a sequence of #if blocks.
* include/bits/version.h: New file. Generated from
version.def.
* include/std/version: Replace with a __glibcxx_want_all define
and bits/version.h include.
---
libstdc++-v3/include/Makefile.am | 10 +-
libstdc++-v3/include/Makefile.in | 10 +-
libstdc++-v3/include/bits/version.def | 1591
libstdc++-v3/include/bits/version.h | 1937 +
libstdc++-v3/include/bits/version.tpl | 209 +++
libstdc++-v3/include/std/version | 350 +
6 files changed, 3758 insertions(+), 349 deletions(-)
create mode 100644 libstdc++-v3/include/bits/version.def
create mode 100644 libstdc++-v3/include/bits/version.h
create mode 100644 libstdc++-v3/include/bits/version.tpl
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index a880e8ee227..a07b4c18585 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -154,6 +154,7 @@ bits_freestanding = \
${bits_srcdir}/stl_raw_storage_iter.h \
${bits_srcdir}/stl_relops.h \
${bits_srcdir}/stl_uninitialized.h \
+ ${bits_srcdir}/version.h \
${bits_srcdir}/string_view.tcc \
${bits_srcdir}/uniform_int_dist.h \
${bits_srcdir}/unique_ptr.h \
@@ -1113,7 +1114,8 @@ allcreated = \
${host_builddir}/c++config.h \
${host_builddir}/largefile-config.h \
${thread_host_headers} \
- ${pch_build}
+ ${pch_build} \
+ ${bits_srcdir}/version.h
# Here are the rules for building the headers
all-local: ${allstamped} ${allcreated}
@@ -1463,6 +1465,12 @@ ${pch3_output}: ${pch3_source} ${pch2_output}
-mkdir -p ${pch3_output_builddir}
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) -O2 -g ${pch3_source} -o $@
+# AutoGen .
+${bits_srcdir}/version.h: ${bits_srcdir}/version.def \
+ ${bits_srcdir}/version.tpl
+ cd $(@D) && \
+ autogen version.def
+
# The real deal.
install-data-local: install-headers
install-headers:
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 0ff875b280b..f5b04d3fe8a 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -509,6 +509,7 @@ bits_freestanding = \
${bits_srcdir}/stl_raw_storage_iter.h \
${bits_srcdir}/stl_relops.h \
${bits_srcdir}/stl_uninitialized.h \
+ ${bits_srcdir}/version.h \
${bits_srcdir}/string_view.tcc \
${bits_srcdir}/uniform_int_dist.h \
${bits_srcdir}/unique_ptr.h \
@@ -1441,7 +1442,8 @@ allcreated = \
${host_builddir}/c++config.h \
${host_builddir}/largefile-config.h \
${thread_host_headers} \
- ${pch_build}
+ ${pch_build} \
+ ${bits_srcdir}/version.h
# Host includes for threads
@@ -1937,6 +1939,12 @@ ${pch3_output}: ${pch3_source} ${pch2_output}
-mkdir -p ${pch3_output_builddir}
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) -O2 -g ${pch3_source} -o $@
+# AutoGen .
+${bits_srcdir}/version.h: ${bits_srcdir}/version.def \
+ ${bits_srcdir}/version.tpl
+ cd $(@D) && \
+ autogen version.def
+
# The real deal.
install-data-local: install-headers
install-headers:
diff --git a/libstdc++-v3/include/bits/version.def
b/libstdc++-v3/include/bits/version.def
new file mode 100644
index 000..afdec9acfe3
--- /dev/null
+++ b/libstdc++-v3/include/bits/version.def
@@ -0,0 +1,1591 @@
+// Feature test macro definitions -*- C++ -*-
+// Copyright (C) 2023 Free Software Foundation, Inc.
+
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT
[PATCH 0/2] Unify and deduplicate FTM code
Greetings!
This patch set replaces all code that involves defining feature test
macros based on loosely put together conditionals in the standard
library with a unified helper for specifying and requiring feature test
macros, as well as updating most usage sites, many of which have been
migrated to following a pattern similar, in structure, to:
...
#define __glibcxx_want_foo
#include
...
namespace std {
...
#ifdef __cpp_lib_foo
template
void foonicate(T&& t)
{ __builtin_foonicate_address(std::__addressof(t)); }
#endif // __cpp_lib_foo
...
} // namespace std
In the future this should aid in preventing from being
dishonest about what the implementation provides, as well as reducing
the amount of finicky work it takes to update FTMs.
Note that this patchset is not perfect. The usage sites of various
feature test macros still include "wide" condition blocks that shadow
over the blocks that check for FTMs, mostly in places where features
with FTMs are the exception, rather than the norm.
That said, using a pair of scripts[1][2], I've tested that the code
emitted in bits/stdc++.h remains unchanged (save for a misdeclared
__cpp_lib_constexpr_string in !HOSTED), as well as regression-tested
--enable-languages=c,c++,lto on x86_64-pc-linux-gnu, and ran the
libstdc++ testsuite with
--target_board="unix{,-std=c++98,-std=gnu++11,-std=gnu++20,
-D_GLIBCXX_USE_CXX11_ABI=0/-D_GLIBCXX_DEBUG,-D_GLIBCXX_DEBUG,
-std=gnu++23}{-fno-freestanding,-ffreestanding}"
(without the line breaks) to find no relevant failures.
OK for trunk?
Thanks in advance, have a lovely day.
[1] https://git.sr.ht/~arsen/scripts/tree/master/item/difall.bash
[2] https://git.sr.ht/~arsen/scripts/tree/master/item/vercmp.bash
Arsen Arsenović (2):
libstdc++: Implement more maintainable header
libstdc++: Replace all manual FTM definitions and use
libstdc++-v3/include/Makefile.am | 10 +-
libstdc++-v3/include/Makefile.in | 10 +-
libstdc++-v3/include/bits/algorithmfwd.h |7 +-
libstdc++-v3/include/bits/align.h |8 +-
libstdc++-v3/include/bits/alloc_traits.h | 11 +-
libstdc++-v3/include/bits/allocator.h |3 +-
libstdc++-v3/include/bits/atomic_base.h | 14 +-
libstdc++-v3/include/bits/atomic_wait.h | 10 +-
libstdc++-v3/include/bits/basic_string.h | 24 +-
libstdc++-v3/include/bits/char_traits.h | 11 +-
libstdc++-v3/include/bits/chrono.h| 18 +-
libstdc++-v3/include/bits/cow_string.h|9 +-
libstdc++-v3/include/bits/erase_if.h | 11 +-
libstdc++-v3/include/bits/forward_list.h |6 +-
libstdc++-v3/include/bits/hashtable.h |9 +-
libstdc++-v3/include/bits/ios_base.h |6 +-
libstdc++-v3/include/bits/move.h |8 +-
.../include/bits/move_only_function.h |9 +-
libstdc++-v3/include/bits/node_handle.h |8 +-
libstdc++-v3/include/bits/ptr_traits.h| 15 +-
libstdc++-v3/include/bits/range_access.h | 16 +-
libstdc++-v3/include/bits/ranges_algo.h | 27 +-
libstdc++-v3/include/bits/ranges_cmp.h| 14 +-
libstdc++-v3/include/bits/shared_ptr.h| 10 +-
libstdc++-v3/include/bits/shared_ptr_atomic.h |6 +-
libstdc++-v3/include/bits/shared_ptr_base.h | 17 +-
libstdc++-v3/include/bits/specfun.h |6 +-
libstdc++-v3/include/bits/stl_algo.h | 20 +-
libstdc++-v3/include/bits/stl_algobase.h | 13 +-
libstdc++-v3/include/bits/stl_function.h | 28 +-
libstdc++-v3/include/bits/stl_iterator.h | 21 +-
libstdc++-v3/include/bits/stl_list.h |6 +-
libstdc++-v3/include/bits/stl_map.h |6 +-
libstdc++-v3/include/bits/stl_pair.h | 12 +-
libstdc++-v3/include/bits/stl_queue.h |9 +-
libstdc++-v3/include/bits/stl_stack.h |7 +-
libstdc++-v3/include/bits/stl_tree.h |7 +-
libstdc++-v3/include/bits/stl_uninitialized.h |9 +-
libstdc++-v3/include/bits/stl_vector.h|4 +-
libstdc++-v3/include/bits/unique_ptr.h| 13 +-
libstdc++-v3/include/bits/unordered_map.h |8 +-
.../include/bits/uses_allocator_args.h| 10 +-
libstdc++-v3/include/bits/utility.h | 21 +-
libstdc++-v3/include/bits/version.def | 1591 ++
libstdc++-v3/include/bits/version.h | 1937 +
libstdc++-v3/include/bits/version.tpl | 209 ++
.../include/c_compatibility/stdatomic.h |9 +-
libstdc++-v3/include/c_global/cmath | 18 +-
libstdc++-v3/include/c_global/cstddef |9 +-
libstdc++-v3/include/std/algorithm| 10 +-
libstdc++-v3/include/std/any |9 +-
libstdc++-v3/include/std/array|9 +-
libstdc++-v3/include/std/atomic | 67 +-
libstdc++-v3/include/std/barrier | 11 +-
Re: [PATCH] gcc/m2: Drop references to $(P)
Richard Biener writes: > If it doesn't show any issues after a while on trunk it's OK for 13.2 I > think. Thanks, I'll re-propose it later then. Have a lovely day! -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH] gcc/m2: Drop references to $(P)
Jakub Jelinek writes: > Doesn't fix any regression, so not ok for 13.1 and I wouldn't bother > for 13.2 either. Okay, but it can affect --enable-languages=all in a slim edge case. Why not 13.2? It seems sufficiently simple. Thanks, have a lovely night! -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH] gcc/m2: Drop references to $(P)
Hi Gaius, Gaius Mulley writes: > yes certainly this is fine. lgtm. Thanks for spotting and the patch Sure. Will push to master and wait for a RM to weigh in on 13. Thanks! -- Arsen Arsenović signature.asc Description: PGP signature
[PATCH] gcc/m2: Drop references to $(P)
$(P) seems to have been a workaround for some old, proprietary make implementations that we no longer support. It was removed in r0-31149-gb8dad04b688e9c. gcc/m2/ChangeLog: * Make-lang.in: Remove references to $(P). * Make-maintainer.in: Ditto. --- Hi, We spotted that the m2 makefile includes some long-gone compatibility variable $(P), presumably left over from when m2 was not in the tree yet. This induced a build failure on our end: https://bugs.gentoo.org/904714 Build-tested on x86_64-pc-linux-gnu. I haven't finished running the testsuite. I believe this only ever expands to an empty string (if not set by the env) in the current build system, so in theory, it should be safe. OK for gcc-13 and trunk (with a priority on the former)? gcc/m2/Make-lang.in | 4 ++-- gcc/m2/Make-maintainer.in | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index b34db0d9156..d0fa692e5b8 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -514,7 +514,7 @@ GM2_LIBS_BOOT = m2/gm2-compiler-boot/gm2.a \ cc1gm2$(exeext): m2/stage1/cc1gm2$(exeext) $(m2.prev) cp -p $< $@ -m2/stage2/cc1gm2$(exeext): m2/stage1/cc1gm2$(exeext) m2/gm2-compiler/m2flex.o $(P) \ +m2/stage2/cc1gm2$(exeext): m2/stage1/cc1gm2$(exeext) m2/gm2-compiler/m2flex.o \ $(GM2_C_OBJS) $(BACKEND) $(LIBDEPS) $(GM2_LIBS) \ m2/gm2-gcc/rtegraph.o plugin/m2rte$(soext) -test -d $(@D) || $(mkinstalldirs) $(@D) @@ -527,7 +527,7 @@ m2/stage2/cc1gm2$(exeext): m2/stage1/cc1gm2$(exeext) m2/gm2-compiler/m2flex.o $( @$(call LINK_PROGRESS,$(INDEX.m2),end) m2/stage1/cc1gm2$(exeext): gm2$(exeext) m2/gm2-compiler-boot/m2flex.o \ -$(P) $(GM2_C_OBJS) $(BACKEND) $(LIBDEPS) \ +$(GM2_C_OBJS) $(BACKEND) $(LIBDEPS) \ $(GM2_LIBS_BOOT) $(MC_LIBS) \ m2/gm2-gcc/rtegraph.o plugin/m2rte$(soext) \ $(m2.prev) diff --git a/gcc/m2/Make-maintainer.in b/gcc/m2/Make-maintainer.in index 17bd9a2d37e..a70682673cd 100644 --- a/gcc/m2/Make-maintainer.in +++ b/gcc/m2/Make-maintainer.in @@ -753,7 +753,7 @@ GM2_LIBS_PARANOID = m2/gm2-compiler-paranoid/gm2.a \ gm2.paranoid: m2/m2obj3/cc1gm2$(exeext) gm2.verifyparanoid m2/m2obj3/cc1gm2$(exeext): m2/m2obj2/cc1gm2$(exeext) m2/gm2-compiler-paranoid/m2flex.o \ -$(P) $(GM2_C_OBJS) $(BACKEND) $(LIBDEPS) $(GM2_LIBS_PARANOID) \ +$(GM2_C_OBJS) $(BACKEND) $(LIBDEPS) $(GM2_LIBS_PARANOID) \ m2/gm2-gcc/rtegraph.o plugin/m2rte$(exeext).so m2/gm2-libs-boot/M2LINK.o -test -d m2/m2obj3 || $(mkinstalldirs) m2/m2obj3 @$(call LINK_PROGRESS,$(INDEX.m2),start) -- 2.40.0
Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH
Gerald Pfeifer writes:
> On Thu, 20 Apr 2023, Arsen Arsenović wrote:
>>> I understand, just am wondering whether and why the : is required? I
>>> don't think we are using this construct anywhere else?
>> Without them, this would happen:
>>
>> ~$ "${foo:=foo}"
>> bash: foo: command not found
>> ~ 127 $ unset foo
>> ~$ echo "${foo:=foo}"
>> foo
>> ~$
>
> Ah, of course!
>
> That's why I tend to use FOO=${FOO-barbar} in such cases - which is a tad
> more characters. :)
>
>> Thank you! Hopefully we get this just in time for 13 :)
>
> The release is currently planned for the 26th and the udpated script is
> now live.
Perfect \o/
> I just ran it and things seem to work just fine. Do you spot anything
> unexpected?
Seems perfect, thank you!
Have a lovely day! :)
> Gerald
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH
Gerald Pfeifer writes:
> Hi Arsen,
>
> On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>>> Did you intentionally not implement the following part of my suggestion
>>>
>>>if [ x${MAKEINFO}x = xx ]; then
>>>:
>> > that is, allowing to override from the command-line (or crontab)?
>> (answering both the questions)
>>
>> This := operator is a handy "default assign" operator. It's a bit of an
>> oddity of the POSIX shell, but it works well. The line:
>>
>> : "${foo:=bar}"
>>
>> is a convenient way of spelling "if foo is unset or null, set it to
>> bar". the initial ':' there serves to discard the result of this
>> evaluation (so that only its side effect of updating foo if necessary is
>> kept)
>
> I understand, just am wondering whether and why the : is required? I
> don't think we are using this construct anywhere else?
Without them, this would happen:
~$ "${foo:=foo}"
bash: foo: command not found
~ 127 $ unset foo
~$ echo "${foo:=foo}"
foo
~$
> (I was aware of the ${foo:=bar} syntax, just caught up by you pushing
> that part of the logic to the lowest level whereas I had it at the top
> level. That's purely on me.)
>
> Please go ahead and push this (or a variant without the : commands) and
> I'll then pick it up from there.
Thank you! Hopefully we get this just in time for 13 :)
Pushed.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [PATCH] doc: tfix
Alejandro Colomar via Gcc-patches writes:
> Remove repeated word (typo).
>
> Signed-off-by: Alejandro Colomar
> ---
> gcc/doc/extend.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index fd3745c5608..cdfb25ff272 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -3756,7 +3756,7 @@ take function pointer arguments.
> The @code{optimize} attribute is used to specify that a function is to
> be compiled with different optimization options than specified on the
> command line. The optimize attribute arguments of a function behave
> -behave as if appended to the command-line.
> +as if appended to the command-line.
>
> Valid arguments are constant non-negative integers and
> strings. Each numeric argument specifies an optimization @var{level}.
Please include a ChangeLog like the following:
gcc/ChangeLog:
* doc/extend.texi (Common Function Attributes): Remove duplicate
word.
I can add that and push for you, if you agree.
Thanks, have a most lovely night!
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: Don't want to receive messages
Ruchit Raushan via Gcc writes: > I don't want to receive further emails. Please see https://gcc.gnu.org/mailman/listinfo/gcc -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH
Gerald Pfeifer writes:
> On Tue, 11 Apr 2023, Arsen Arsenović wrote:
>> Ah! Good idea. What do you think of the following?
>
> Did you intentionally not implement the following part of my suggestion
>
>if [ x${MAKEINFO}x = xx ]; then
>:
>
> that is, allowing to override from the command-line (or crontab)?
>
>
> And why the colons in
>
> +: "${MAKEINFO:=${makeinfo_git}/makeinfo}"
> +: "${TEXI2DVI:=${makeinfo_git}/texi2dvi}"
> +: "${TEXI2PDF:=${makeinfo_git}/texi2pdf}"
>
> ? I don't think we use these elsewhere. Do they serve a purpose or can we
> omit them and keep things simpler?
(answering both the questions)
This := operator is a handy "default assign" operator. It's a bit of an
oddity of the POSIX shell, but it works well. The line:
: "${foo:=bar}"
is a convenient way of spelling "if foo is unset or null, set it to
bar". the initial ':' there serves to discard the result of this
evaluation (so that only its side effect of updating foo if necessary is
kept)
... so, the above block translates into "if makeinfo_git/makeinfo
exists, then default MAKEINFO, TEXI2DVI, TEXI2PDF to makeinfo_git/$tool,
otherwise, default them to $tool", where $tool is the respective tool
for those variables.
>
> Please let me know, and I'll see to get this (or probably an updated
> patch) in place on gcc.gnu.org.
>
> Thanks,
> Gerald
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH
Gerald Pfeifer writes:
> On Thu, 6 Apr 2023, Arsen Arsenović wrote:
>> maintainer-scripts/ChangeLog:
>>
>> * update_web_docs_git: Add updated Texinfo to PATH
>
> Do we really need to adjust PATH, or could we just introduce a MAKEINFO
> variable, something like
>
> if [ x${MAKEINFO}x = xx ]; then
> if [ -x /home/gccadmin/texinfo/install-git/bin/makeinfo ]; then
> MAKEINFO=/home/gccadmin/texinfo/install-git/bin/makeinfo;
> else
> MAKEINFO=makeinfo
> fi
> fi
>
> ?
>
> (This also still allows overriding upon invocation.)
>
> Gerald
Ah! Good idea. What do you think of the following?
From ba00aa3882b7e0a5fa247f9fa824474e3ddc8102 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?=
Date: Thu, 6 Apr 2023 12:20:57 +0200
Subject: [PATCH] update_web_docs_git: Allow setting TEXI2*, add git build
default
maintainer-scripts/ChangeLog:
* update_web_docs_git: Add a mechanism to override makeinfo,
texi2dvi and texi2pdf, and default them to
/home/gccadmin/texinfo/install-git/bin/${tool}, if present.
---
maintainer-scripts/update_web_docs_git | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/maintainer-scripts/update_web_docs_git b/maintainer-scripts/update_web_docs_git
index d44ab27c1b7..c651e567424 100755
--- a/maintainer-scripts/update_web_docs_git
+++ b/maintainer-scripts/update_web_docs_git
@@ -14,6 +14,17 @@ export GITROOT
PATH=/usr/local/bin:$PATH
+makeinfo_git=/home/gccadmin/texinfo/install-git/bin/
+if [ -x "${makeinfo_git}"/makeinfo ]; then
+: "${MAKEINFO:=${makeinfo_git}/makeinfo}"
+: "${TEXI2DVI:=${makeinfo_git}/texi2dvi}"
+: "${TEXI2PDF:=${makeinfo_git}/texi2pdf}"
+else
+: "${MAKEINFO:=makeinfo}"
+: "${TEXI2DVI:=texi2dvi}"
+: "${TEXI2PDF:=texi2pdf}"
+fi
+
MANUALS="cpp
cppinternals
fastjar
@@ -174,10 +185,10 @@ for file in $MANUALS; do
elif [ "$file" = "gnat_ugn" ]; then
includes="$includes -I gcc/gcc/ada -I gcc/gcc/ada/doc/gnat_ugn"
fi
-makeinfo --html -c CONTENTS_OUTPUT_LOCATION=inline --css-ref $CSS $includes -o ${file} ${filename}
+"${MAKEINFO}" --html -c CONTENTS_OUTPUT_LOCATION=inline --css-ref $CSS $includes -o ${file} ${filename}
tar cf ${file}-html.tar ${file}/*.html
-texi2dvi $includes -o ${file}.dvi ${filename} /dev/null && dvips -o ${file}.ps ${file}.dvi
-texi2pdf $includes -o ${file}.pdf ${filename} /dev/null && dvips -o ${file}.ps ${file}.dvi
+"${TEXI2PDF}" $includes -o ${file}.pdf ${filename}
... since the other tools are siblings.
Thanks for the smoke test!
--
Arsen Arsenović
signature.asc
Description: PGP signature
[PATCH] update_web_docs_git: Add updated Texinfo to PATH
maintainer-scripts/ChangeLog:
* update_web_docs_git: Add updated Texinfo to PATH
---
Hi,
I'm posting this as a ping and a patch necessary to get the wwwdocs
building with the new Texinfo version that's installed on gcc.gnu.org.
It would be nice to do this ahead of the GCC 13 release.
I must ask that whoever decides to apply/update the script tests
texi2any with a simple example, like
echo @node Top | ~/texinfo/install-git/bin/makeinfo --html -o -
... before updating; this should be a representative enough smoke test.
You should see some HTML output with little text in it.
It might also be wise to test the script directly by using a different
WWWBASE, just in case, even though it should be safe.
Thanks in advance, have a lovely day.
maintainer-scripts/update_web_docs_git | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/maintainer-scripts/update_web_docs_git
b/maintainer-scripts/update_web_docs_git
index d44ab27c1b7..f9006b1f45b 100755
--- a/maintainer-scripts/update_web_docs_git
+++ b/maintainer-scripts/update_web_docs_git
@@ -12,7 +12,7 @@ set -e
GITROOT=${GITROOT:-"/git/gcc.git"}
export GITROOT
-PATH=/usr/local/bin:$PATH
+PATH=/home/gccadmin/texinfo/install-git/bin:/usr/local/bin:$PATH
MANUALS="cpp
cppinternals
--
2.40.0
Re: [PATCH 2/4] libstdc++: Add a test for FTM redefinitions
Arsen Arsenović via Libstdc++ writes: > Good idea. Both the positive and negative cases work when implemented > like this: > > From 98d302bab9a87d3f2daecf9d54d62f33ba216673 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= > Date: Wed, 8 Mar 2023 17:01:24 +0100 > Subject: [PATCH 2/4] libstdc++: Add a test for FTM redefinitions > > This test detects redefinitions by compiling stdc++.h with > -Wsystem-headers. Thanks Patrick Palka for the suggestion. > > libstdc++-v3/ChangeLog: > > * testsuite/17_intro/versionconflict.cc: New test. I've forgotten to reword this after changing the logic. New message: commit dcd7bed33cc274e8f3565ad02fb1fbc04bc845fb Author: Arsen Arsenović Date: Wed Mar 8 17:01:24 2023 +0100 libstdc++: Add a test for FTM redefinitions This test detects redefinitions by compiling stdc++.h and , by disabling the system_header pragma on the latter, to allow warnings in it. Thanks Patrick Palka for the suggestion. libstdc++-v3/ChangeLog: * testsuite/17_intro/versionconflict.cc: New test. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH 1/4] libstdc++: Harmonize and other headers
Jonathan Wakely writes:
>> [snip...]
>>+/* Duplicate definition with unique_ptr.h. */
>>+#if __cplusplus > 202002L && defined(__cpp_constexpr_dynamic_alloc)
>>+# define __cpp_lib_constexpr_memory 202202L
>>+#elif __cplusplus > 201703L
>>+# include
>
> Including is unrelated to the FTM, and should always be
> done for >= C++17, but this change means it's not included for the
> first block.
>
> Please leave the #include with the _Safe_iterator_base declaration.
Fixed:
diff --git a/libstdc++-v3/include/bits/ptr_traits.h
b/libstdc++-v3/include/bits/ptr_traits.h
index dc42a743c96..8a919ec1090 100644
--- a/libstdc++-v3/include/bits/ptr_traits.h
+++ b/libstdc++-v3/include/bits/ptr_traits.h
@@ -34,12 +34,15 @@
#include
+/* Duplicate definition with unique_ptr.h. */
+#if __cplusplus > 202002L && defined(__cpp_constexpr_dynamic_alloc)
+# define __cpp_lib_constexpr_memory 202202L
+#elif __cplusplus > 201703L
+# define __cpp_lib_constexpr_memory 201811L
+#endif
+
#if __cplusplus > 201703L
#include
-# ifndef __cpp_lib_constexpr_memory
-// Defined to a newer value in bits/unique_ptr.h for C++23
-# define __cpp_lib_constexpr_memory 201811L
-# endif
namespace __gnu_debug { struct _Safe_iterator_base; }
#endif
>> [snip...]
>
> Pleae keep them in alphabetical order (within their relevant
> blocks/groups).
I didn't even notice the ordering - apologies.
Updated patch:
From 54cdd9aebfe485dc669f5893fe14d4cf7822ed9e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?=
Date: Wed, 8 Mar 2023 12:04:11 +0100
Subject: [PATCH 1/4] libstdc++: Harmonize and other headers
Due to recent, large changes in libstdc++, the feature test macros
declared in got out of sync with the other headers that
possibly declare them.
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (__cpp_lib_constexpr_memory):
Synchronize the definition block with...
* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory):
... this one here. Also define the 202202L value, rather than
leaving it up to purely unique_ptr.h, so that the value is
synchronized across all headers.
(__gnu_debug::_Safe_iterator_base): Move into new conditional
block.
* include/std/memory (__cpp_lib_atomic_value_initialization):
Define on freestanding under the same conditions as in
atomic_base.h.
* include/std/version (__cpp_lib_robust_nonmodifying_seq_ops):
Also define on freestanding.
(__cpp_lib_to_chars): Ditto.
(__cpp_lib_gcd): Ditto.
(__cpp_lib_gcd_lcm): Ditto.
(__cpp_lib_raw_memory_algorithms): Ditto.
(__cpp_lib_array_constexpr): Ditto.
(__cpp_lib_nonmember_container_access): Ditto.
(__cpp_lib_clamp): Ditto.
(__cpp_lib_constexpr_char_traits): Ditto.
(__cpp_lib_constexpr_string): Ditto.
(__cpp_lib_sample): Ditto.
(__cpp_lib_lcm): Ditto.
(__cpp_lib_constexpr_iterator): Ditto.
(__cpp_lib_constexpr_char_traits): Ditto.
(__cpp_lib_interpolate): Ditto.
(__cpp_lib_constexpr_utility): Ditto.
(__cpp_lib_shift): Ditto.
(__cpp_lib_ranges): Ditto.
(__cpp_lib_move_iterator_concept): Ditto.
(__cpp_lib_constexpr_numeric): Ditto.
(__cpp_lib_constexpr_functional): Ditto.
(__cpp_lib_constexpr_algorithms): Ditto.
(__cpp_lib_constexpr_tuple): Ditto.
(__cpp_lib_constexpr_memory): Ditto.
---
libstdc++-v3/include/bits/ptr_traits.h | 11 ++--
libstdc++-v3/include/bits/unique_ptr.h | 11 ++--
libstdc++-v3/include/std/memory| 6 ++
libstdc++-v3/include/std/version | 87 ++
4 files changed, 66 insertions(+), 49 deletions(-)
diff --git a/libstdc++-v3/include/bits/ptr_traits.h
b/libstdc++-v3/include/bits/ptr_traits.h
index dc42a743c96..8a919ec1090 100644
--- a/libstdc++-v3/include/bits/ptr_traits.h
+++ b/libstdc++-v3/include/bits/ptr_traits.h
@@ -34,12 +34,15 @@
#include
+/* Duplicate definition with unique_ptr.h. */
+#if __cplusplus > 202002L && defined(__cpp_constexpr_dynamic_alloc)
+# define __cpp_lib_constexpr_memory 202202L
+#elif __cplusplus > 201703L
+# define __cpp_lib_constexpr_memory 201811L
+#endif
+
#if __cplusplus > 201703L
#include
-# ifndef __cpp_lib_constexpr_memory
-// Defined to a newer value in bits/unique_ptr.h for C++23
-# define __cpp_lib_constexpr_memory 201811L
-# endif
namespace __gnu_debug { struct _Safe_iterator_base; }
#endif
diff --git a/libstdc++-v3/include/bits/unique_ptr.h
b/libstdc++-v3/include/bits/unique_ptr.h
index c8daff41865..f0c6d2383b4 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -43,12 +43,11 @@
# endif
#endif
-#if __cplusplus > 202002L && __cpp_constexpr_dynamic_alloc
-# if __cpp_lib_constexpr_memory < 202202L
-// Defined with older value in bits/ptr_traits.h for C++20
-# undef __cpp_lib_constexpr_memory
-# define
Re: [PATCH 2/4] libstdc++: Add a test for FTM redefinitions
Jonathan Wakely writes:
> On 05/04/23 01:09 +0200, Arsen Arsenović wrote:
>>This test detects redefinitions by compiling stdc++.h with
>>-Wsystem-headers. Thanks Patrick Palka for the suggestion.
>>
>>libstdc++-v3/ChangeLog:
>>
>> * testsuite/17_intro/versionconflict.cc: New test.
>>---
>> libstdc++-v3/testsuite/17_intro/versionconflict.cc | 6 ++
>> 1 file changed, 6 insertions(+)
>> create mode 100644 libstdc++-v3/testsuite/17_intro/versionconflict.cc
>>
>>diff --git a/libstdc++-v3/testsuite/17_intro/versionconflict.cc
>>b/libstdc++-v3/testsuite/17_intro/versionconflict.cc
>>new file mode 100644
>>index 000..4191c7a2b08
>>--- /dev/null
>>+++ b/libstdc++-v3/testsuite/17_intro/versionconflict.cc
>>@@ -0,0 +1,6 @@
>>+// { dg-do preprocess }
>>+// { dg-additional-options "-Wsystem-headers -Werror" }
>>+
>>+// Test for redefinitions of FTMs using bits/stdc++.h.
>>+#include
>>+#include
>
> I'm concerned that this will fail if libc headers have macro
> redefinition errors, or anything else that would usually be ignored.
>
> We could make it more robust by changing like so:
>
> --- a/libstdc++-v3/include/std/version
> +++ b/libstdc++-v3/include/std/version
> @@ -30,7 +30,9 @@
> #ifndef _GLIBCXX_VERSION_INCLUDED
> #define _GLIBCXX_VERSION_INCLUDED
> +#ifndef _GLIBCXX_TESTING_SYSHDR
> #pragma GCC system_header
> +#endif
>#include
> Then the test could define that macro instead of using -Wsystem-headers.
>
> Could you see if that works?
Good idea. Both the positive and negative cases work when implemented
like this:
From 98d302bab9a87d3f2daecf9d54d62f33ba216673 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?=
Date: Wed, 8 Mar 2023 17:01:24 +0100
Subject: [PATCH 2/4] libstdc++: Add a test for FTM redefinitions
This test detects redefinitions by compiling stdc++.h with
-Wsystem-headers. Thanks Patrick Palka for the suggestion.
libstdc++-v3/ChangeLog:
* testsuite/17_intro/versionconflict.cc: New test.
---
libstdc++-v3/include/std/version | 5 -
libstdc++-v3/testsuite/17_intro/versionconflict.cc | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644 libstdc++-v3/testsuite/17_intro/versionconflict.cc
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index cdd24248c57..1069bc6c9f6 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -30,7 +30,10 @@
#ifndef _GLIBCXX_VERSION_INCLUDED
#define _GLIBCXX_VERSION_INCLUDED
-#pragma GCC system_header
+// To facilitate testsuite/17_intro/versionconflict.cc
+#ifndef _GLIBCXX_TESTING_SYSHDR
+# pragma GCC system_header
+#endif
#include
diff --git a/libstdc++-v3/testsuite/17_intro/versionconflict.cc
b/libstdc++-v3/testsuite/17_intro/versionconflict.cc
new file mode 100644
index 000..6c212980ab0
--- /dev/null
+++ b/libstdc++-v3/testsuite/17_intro/versionconflict.cc
@@ -0,0 +1,7 @@
+// { dg-do preprocess }
+// { dg-additional-options "-Werror" }
+
+// Test for redefinitions of FTMs using bits/stdc++.h.
+#define _GLIBCXX_TESTING_SYSHDR
+#include
+#include
--
2.40.0
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [PATCH 4/4] libstdc++: Fix some freestanding test failures
Jonathan Wakely writes:
> On Wed, 5 Apr 2023 at 00:13, Arsen Arsenović via Libstdc++
> wrote:
>>
>> At some point, was added to the non-hosted bit of the C++17
>> block, which induced failures in many tests.
>>
>> In addition, some tests also lacked a dg-require-effective-target hosted
>> tag.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/precompiled/stdc++.h (C++17): Don't double-include
>> , once with wrong conditions.
>> * testsuite/18_support/96817.cc: Require hosted.
>> * testsuite/18_support/bad_exception/59392.cc: Ditto.
>> * testsuite/20_util/scoped_allocator/108952.cc: Ditto.
>> * testsuite/20_util/uses_allocator/lwg3527.cc: Ditto.
>
> Maybe this could be adjusted to not use std::allocator.
>
>> * testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
>
> This fails because std::abs s not freestanding (which is surprising,
> at least for the integral overloads).
> We could adjust the test to define its own abs but maybe it's not worth it.
I can take a look in stage 1.
> OK for trunk.
>
>> Ditto.
>> ---
>> libstdc++-v3/include/precompiled/stdc++.h| 1 -
>> libstdc++-v3/testsuite/18_support/96817.cc | 1 +
>> libstdc++-v3/testsuite/18_support/bad_exception/59392.cc | 1 +
>> libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc| 1 +
>> libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc | 1 +
>> .../29_atomics/atomic/operators/pointer_partial_void.cc | 1 +
>> 6 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/libstdc++-v3/include/precompiled/stdc++.h
>> b/libstdc++-v3/include/precompiled/stdc++.h
>> index bc011986b53..176ad79ff3c 100644
>> --- a/libstdc++-v3/include/precompiled/stdc++.h
>> +++ b/libstdc++-v3/include/precompiled/stdc++.h
>> @@ -75,7 +75,6 @@
>>
>> #if __cplusplus >= 201703L
>> #include
>> -#include
>> // #include
>> #include
>> #include
>> diff --git a/libstdc++-v3/testsuite/18_support/96817.cc
>> b/libstdc++-v3/testsuite/18_support/96817.cc
>> index 70938812bd8..073fc337e8f 100644
>> --- a/libstdc++-v3/testsuite/18_support/96817.cc
>> +++ b/libstdc++-v3/testsuite/18_support/96817.cc
>> @@ -17,6 +17,7 @@
>>
>> // { dg-do run }
>> // { dg-additional-options "-pthread" { target pthread } }
>> +// { dg-require-effective-target hosted }
>>
>> // Static init cannot detect recursion for gthreads targets without futexes
>> // (and the futex case can only detect it if __libc_single_threaded==true).
>> diff --git a/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
>> b/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
>> index ac64e6eddb2..ae972d0535d 100644
>> --- a/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
>> +++ b/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
>> @@ -17,6 +17,7 @@
>>
>> // { dg-options "-Wno-deprecated" }
>> // { dg-do run { target c++14_down } }
>> +// { dg-require-effective-target hosted }
>>
>> #include
>> #include
>> diff --git a/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
>> b/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
>> index a6b9c67498c..9342f453bf4 100644
>> --- a/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
>> +++ b/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
>> @@ -1,4 +1,5 @@
>> // { dg-do compile { target c++11 } }
>> +// { dg-require-effective-target hosted }
>>
>> #include
>>
>> diff --git a/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
>> b/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
>> index ae377f4b5a3..c5a7d513b31 100644
>> --- a/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
>> +++ b/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
>> @@ -1,5 +1,6 @@
>> // { dg-options "-std=gnu++20" }
>> // { dg-do compile { target c++20 } }
>> +// { dg-require-effective-target hosted }
>>
>> #include
>>
>> diff --git
>> a/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
>> b/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
>> index ddb63233a64..e5d221ed15a 100644
>> ---
>> a/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
>> +++
>> b/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
>> @@ -1,5 +1,6 @@
>> // { dg-do run { target { c++11_only || c++14_only } } }
>> // { dg-require-atomic-builtins "" }
>> +// { dg-require-effective-target hosted }
>>
>> // Copyright (C) 2012-2023 Free Software Foundation, Inc.
>> //
>> --
>> 2.40.0
>>
--
Arsen Arsenović
signature.asc
Description: PGP signature
[PATCH 1/4] libstdc++: Harmonize and other headers
Due to recent, large changes in libstdc++, the feature test macros
declared in got out of sync with the other headers that
possibly declare them.
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (__cpp_lib_constexpr_memory):
Synchronize the definition block with...
* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory):
... this one here. Also define the 202202L value, rather than
leaving it up to purely unique_ptr.h, so that the value is
synchronized across all headers.
(__gnu_debug::_Safe_iterator_base): Move into new conditional
block.
* include/std/memory (__cpp_lib_atomic_value_initialization):
Define on freestanding under the same conditions as in
atomic_base.h.
* include/std/version (__cpp_lib_robust_nonmodifying_seq_ops):
Also define on freestanding.
(__cpp_lib_to_chars): Ditto.
(__cpp_lib_gcd): Ditto.
(__cpp_lib_gcd_lcm): Ditto.
(__cpp_lib_raw_memory_algorithms): Ditto.
(__cpp_lib_array_constexpr): Ditto.
(__cpp_lib_nonmember_container_access): Ditto.
(__cpp_lib_clamp): Ditto.
(__cpp_lib_constexpr_char_traits): Ditto.
(__cpp_lib_constexpr_string): Ditto.
(__cpp_lib_sample): Ditto.
(__cpp_lib_lcm): Ditto.
(__cpp_lib_constexpr_iterator): Ditto.
(__cpp_lib_constexpr_char_traits): Ditto.
(__cpp_lib_interpolate): Ditto.
(__cpp_lib_constexpr_utility): Ditto.
(__cpp_lib_shift): Ditto.
(__cpp_lib_ranges): Ditto.
(__cpp_lib_move_iterator_concept): Ditto.
(__cpp_lib_constexpr_numeric): Ditto.
(__cpp_lib_constexpr_functional): Ditto.
(__cpp_lib_constexpr_algorithms): Ditto.
(__cpp_lib_constexpr_tuple): Ditto.
(__cpp_lib_constexpr_memory): Ditto.
---
Evening,
This patchset is a replacement to and extension of the one presented at
https://inbox.sourceware.org/libstdc++/20230309222626.4008373-1-ar...@aarsen.me/
... that has been rebased as to include newer additions, and extended to
cover some regressions that seem to have occurred recently in
freestanding mode.
Tested on x86_64-pc-linux-gnu.
OK for trunk?
Thanks in advance, have a lovely night.
libstdc++-v3/include/bits/ptr_traits.h | 13 ++--
libstdc++-v3/include/bits/unique_ptr.h | 11 ++--
libstdc++-v3/include/std/memory| 6 ++
libstdc++-v3/include/std/version | 85 ++
4 files changed, 66 insertions(+), 49 deletions(-)
diff --git a/libstdc++-v3/include/bits/ptr_traits.h
b/libstdc++-v3/include/bits/ptr_traits.h
index dc42a743c96..f6cc6b65f93 100644
--- a/libstdc++-v3/include/bits/ptr_traits.h
+++ b/libstdc++-v3/include/bits/ptr_traits.h
@@ -34,12 +34,15 @@
#include
+/* Duplicate definition with unique_ptr.h. */
+#if __cplusplus > 202002L && defined(__cpp_constexpr_dynamic_alloc)
+# define __cpp_lib_constexpr_memory 202202L
+#elif __cplusplus > 201703L
+# include
+# define __cpp_lib_constexpr_memory 201811L
+#endif
+
#if __cplusplus > 201703L
-#include
-# ifndef __cpp_lib_constexpr_memory
-// Defined to a newer value in bits/unique_ptr.h for C++23
-# define __cpp_lib_constexpr_memory 201811L
-# endif
namespace __gnu_debug { struct _Safe_iterator_base; }
#endif
diff --git a/libstdc++-v3/include/bits/unique_ptr.h
b/libstdc++-v3/include/bits/unique_ptr.h
index c8daff41865..f0c6d2383b4 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -43,12 +43,11 @@
# endif
#endif
-#if __cplusplus > 202002L && __cpp_constexpr_dynamic_alloc
-# if __cpp_lib_constexpr_memory < 202202L
-// Defined with older value in bits/ptr_traits.h for C++20
-# undef __cpp_lib_constexpr_memory
-# define __cpp_lib_constexpr_memory 202202L
-# endif
+/* Duplicate definition with ptr_traits.h. */
+#if __cplusplus > 202002L && defined(__cpp_constexpr_dynamic_alloc)
+# define __cpp_lib_constexpr_memory 202202L
+#elif __cplusplus > 201703L
+# define __cpp_lib_constexpr_memory 201811L
#endif
namespace std _GLIBCXX_VISIBILITY(default)
diff --git a/libstdc++-v3/include/std/memory b/libstdc++-v3/include/std/memory
index 341f9857730..85c36d67ee1 100644
--- a/libstdc++-v3/include/std/memory
+++ b/libstdc++-v3/include/std/memory
@@ -91,6 +91,12 @@
# include
#endif
+/* As a hack, we declare __cpp_lib_atomic_value_initialization here even though
+ we don't include the bit that actually declares it, for consistency. */
+#if !defined(__cpp_lib_atomic_value_initialization) && __cplusplus >= 202002L
+# define __cpp_lib_atomic_value_initialization 201911L
+#endif
+
#if __cplusplus >= 201103L && __cplusplus <= 202002L && _GLIBCXX_HOSTED
namespace std _GLIBCXX_VISIBILITY(default)
{
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index a19c39c6cdd..0239fcea813 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -85,6 +85,12
[PATCH 3/4] libstdc++: Downgrade DEBUG to ASSERTIONS when !HOSTED
Supporting the debug mode in freestanding is a non-trivial job, so
instead, as a best-effort, enable assertions, which are light and easy.
libstdc++-v3/ChangeLog:
* include/bits/c++config: When __STDC_HOSTED__ is zero,
disable _GLIBCXX_DEBUG and, if it was set, enable
_GLIBCXX_ASSERTIONS.
* testsuite/lib/libstdc++.exp (check_v3_target_debug_mode):
Include when determining whether debug is
set, in order to inherit the logic from above
---
libstdc++-v3/include/bits/c++config | 7 +++
libstdc++-v3/testsuite/lib/libstdc++.exp | 1 +
2 files changed, 8 insertions(+)
diff --git a/libstdc++-v3/include/bits/c++config
b/libstdc++-v3/include/bits/c++config
index 71f2401402f..13892787e09 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -397,6 +397,13 @@ _GLIBCXX_END_NAMESPACE_VERSION
# define _GLIBCXX_END_INLINE_ABI_NAMESPACE(X) } // inline namespace X
#endif
+// In the case that we don't have a hosted environment, we can't provide the
+// debugging mode. Instead, we do our best and downgrade to assertions.
+#if defined(_GLIBCXX_DEBUG) && !__STDC_HOSTED__
+#undef _GLIBCXX_DEBUG
+#define _GLIBCXX_ASSERTIONS 1
+#endif
+
// Inline namespaces for special modes: debug, parallel.
#if defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PARALLEL)
namespace std
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 98512c973fb..490abd108fa 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1007,6 +1007,7 @@ proc check_v3_target_debug_mode { } {
global cxxflags
return [check_v3_target_prop_cached et_debug_mode {
set code "
+ #include
#if ! defined _GLIBCXX_DEBUG
# error no debug mode
#endif
--
2.40.0
[PATCH 4/4] libstdc++: Fix some freestanding test failures
At some point, was added to the non-hosted bit of the C++17
block, which induced failures in many tests.
In addition, some tests also lacked a dg-require-effective-target hosted
tag.
libstdc++-v3/ChangeLog:
* include/precompiled/stdc++.h (C++17): Don't double-include
, once with wrong conditions.
* testsuite/18_support/96817.cc: Require hosted.
* testsuite/18_support/bad_exception/59392.cc: Ditto.
* testsuite/20_util/scoped_allocator/108952.cc: Ditto.
* testsuite/20_util/uses_allocator/lwg3527.cc: Ditto.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Ditto.
---
libstdc++-v3/include/precompiled/stdc++.h| 1 -
libstdc++-v3/testsuite/18_support/96817.cc | 1 +
libstdc++-v3/testsuite/18_support/bad_exception/59392.cc | 1 +
libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc| 1 +
libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc | 1 +
.../29_atomics/atomic/operators/pointer_partial_void.cc | 1 +
6 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/precompiled/stdc++.h
b/libstdc++-v3/include/precompiled/stdc++.h
index bc011986b53..176ad79ff3c 100644
--- a/libstdc++-v3/include/precompiled/stdc++.h
+++ b/libstdc++-v3/include/precompiled/stdc++.h
@@ -75,7 +75,6 @@
#if __cplusplus >= 201703L
#include
-#include
// #include
#include
#include
diff --git a/libstdc++-v3/testsuite/18_support/96817.cc
b/libstdc++-v3/testsuite/18_support/96817.cc
index 70938812bd8..073fc337e8f 100644
--- a/libstdc++-v3/testsuite/18_support/96817.cc
+++ b/libstdc++-v3/testsuite/18_support/96817.cc
@@ -17,6 +17,7 @@
// { dg-do run }
// { dg-additional-options "-pthread" { target pthread } }
+// { dg-require-effective-target hosted }
// Static init cannot detect recursion for gthreads targets without futexes
// (and the futex case can only detect it if __libc_single_threaded==true).
diff --git a/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
b/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
index ac64e6eddb2..ae972d0535d 100644
--- a/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
+++ b/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
@@ -17,6 +17,7 @@
// { dg-options "-Wno-deprecated" }
// { dg-do run { target c++14_down } }
+// { dg-require-effective-target hosted }
#include
#include
diff --git a/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
b/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
index a6b9c67498c..9342f453bf4 100644
--- a/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
+++ b/libstdc++-v3/testsuite/20_util/scoped_allocator/108952.cc
@@ -1,4 +1,5 @@
// { dg-do compile { target c++11 } }
+// { dg-require-effective-target hosted }
#include
diff --git a/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
b/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
index ae377f4b5a3..c5a7d513b31 100644
--- a/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
+++ b/libstdc++-v3/testsuite/20_util/uses_allocator/lwg3527.cc
@@ -1,5 +1,6 @@
// { dg-options "-std=gnu++20" }
// { dg-do compile { target c++20 } }
+// { dg-require-effective-target hosted }
#include
diff --git
a/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
b/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
index ddb63233a64..e5d221ed15a 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
@@ -1,5 +1,6 @@
// { dg-do run { target { c++11_only || c++14_only } } }
// { dg-require-atomic-builtins "" }
+// { dg-require-effective-target hosted }
// Copyright (C) 2012-2023 Free Software Foundation, Inc.
//
--
2.40.0
[PATCH 2/4] libstdc++: Add a test for FTM redefinitions
This test detects redefinitions by compiling stdc++.h with
-Wsystem-headers. Thanks Patrick Palka for the suggestion.
libstdc++-v3/ChangeLog:
* testsuite/17_intro/versionconflict.cc: New test.
---
libstdc++-v3/testsuite/17_intro/versionconflict.cc | 6 ++
1 file changed, 6 insertions(+)
create mode 100644 libstdc++-v3/testsuite/17_intro/versionconflict.cc
diff --git a/libstdc++-v3/testsuite/17_intro/versionconflict.cc
b/libstdc++-v3/testsuite/17_intro/versionconflict.cc
new file mode 100644
index 000..4191c7a2b08
--- /dev/null
+++ b/libstdc++-v3/testsuite/17_intro/versionconflict.cc
@@ -0,0 +1,6 @@
+// { dg-do preprocess }
+// { dg-additional-options "-Wsystem-headers -Werror" }
+
+// Test for redefinitions of FTMs using bits/stdc++.h.
+#include
+#include
--
2.40.0
Re: [PATCH] Introduce -nolibstdc++ option
Hi Alexandre, Alexandre Oliva via Gcc-patches writes: > Hello, Gerald, > > On Feb 11, 2023, Gerald Pfeifer wrote: > >> On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote: >>> Introduce -nostdlib++ option >>> >>> Using g++ to link without libstdc++, as in g++.dg/abi/pure-virtual1.C, >>> is error prone, because there's no way to tell g++ to drop libstdc++ >>> without also dropping libc and any other libraries that the target >>> implicitly links in. > >> % grep -r nostdlib $WWWDOCS >> % > >> Should this be documented in gcc-13/changes.html? Would you mind proposing >> a snippet (or going ahead and pushing it)? > > I can't make my mind up about this. > > At first, the goal of adding the option was just to aid this specific > test. But then, it transpired that other compilers offered a similar > option, with the spelling that we ended up using, so perhaps it would > make sense to document it, after all. IMO, yes - in fact, the libstdc++ manual even has a use-case for this (freestanding when the compiler is *not* built with libstdc++ in freestanding mode) and documents using the gcc driver rather than the g++ one. See libstdc++-v3/doc/xml/manual/using.xml: If you're using a libstdc++ configured for hosted environments, and would like to not involve the libraries libstdc++ would depend on in your programs, you will need to use gcc to link your application with only libsupc++.a, like so: If you think the flag you added fits here, would you mind also including this file in your patch? Note that this flag is only applicable here if MATH_LIBRARY is omitted but libsupc++.a is kept on the linker command line (apologies for not checking ahead of writing this email - I'm not currently in a convenient spot to do so). Thanks in advance, have a lovely day. > How about this, does this seem useful? > > diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html > index ff70d2eefecec..c1bbbfa28e18e 100644 > --- a/htdocs/gcc-13/changes.html > +++ b/htdocs/gcc-13/changes.html > @@ -333,6 +333,9 @@ a work-in-progress. >The href="https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wpessimizing-move;>-Wpessimizing-move > and href="https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wredundant-move;>-Wredundant-move > warnings have been extended to warn in more contexts. > + The href="https://gcc.gnu.org/onlinedocs/gcc/Link_Options.html#index-nostdlib_002b_002b;>-nostdlib++ > +option has been added, to enable linking with g++ > +without implicitly linking in the C++ standard library. > > > Runtime Library (libstdc++) -- Arsen Arsenović signature.asc Description: PGP signature
Re: cgraph: does node->inlined_to imply node->clones is non-empty?
Hi,
Martin Jambor writes:
> Hi,
>
> On Sat, Mar 18 2023, Arsen Arsenović wrote:
>> Martin Jambor writes:
>
> [...]
>
For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
seems to try to remove an unreachable function that was already inlined
into a different unreachable function.
>>>
>>> No, it fails to remove it. It is still there but should not have been,
>>> that is the problem.
>>
>> Ah - I see.
>>
This decision later trips up the gcc_assert in:
/* Inline clones might be kept around so their materializing allows
further
cloning. If the function the clone is inlined into is removed, we
need
to turn it into normal cone. */
FOR_EACH_FUNCTION (node)
{
if (node->inlined_to
&& !node->callers)
{
gcc_assert (node->clones);
node->inlined_to = NULL;
update_inlined_to_pointer (node, node);
}
node->aux = NULL;
}
.. because it is expecting that an inlined function without callers
(which is necessarily true here as this function is unreachable and so
was ->remove ()'d earlier) has clones.
>>>
>>> The assert makes sure that if we encounter an inlined-to node without
>>> any caller, that it merely holds as the holder of the function body for
>>> its other specialized (think IPA-CP) or inline clones. If node->clones
>>> is false, there are no such clones and it was a bug to mark the node as
>>> required during the removal of unreachable nodes.
>>
>> I see. That makes sense. So, this assert is placed here by convenience
>> rather than being this invariant being absolutely required for the
>> purpose of the loop? (it is related, so this placement makes sense, I
>> just want to confirm whether it's a "mandatory" invariant)
>
> If the assert fails, the algorithm does not work as intended. OTOH, It
> could be a gcc_checking_assert only since user compiled code would still
> work, just would be unnecessarily bigger.
Yes, that is what I was trying to ask ;-) Apologies for failing to
articulate so.
>>
>>> It is correct. An inlined function without a caller is even a logical
>>> oxymoron and can only exist if it has the purpose described above (and
>>> even then probably only in a fairly special circumstances).
>>
>> Right. I wasn't quite sure whether setting inlined_to would remove that
>> caller, but if I understood right, it should not.
>>
>> What is interesting, though, is that there is an attempt to remove this
>> node during ipa_inline:
>
> IPA-inline calls remove_unreachable_nodes to get rid of call graph nodes
> which are known not to be necessary after inlining (inlining can lead to
> redirection of some call graph edges to __builtin_unreachable) and
> unreachable removal... well.. removes nodes.
>
>>
>> (gdb) bt
>> #0 cgraph_edge::remove_callee (
>> this=> "__ct_base "/18> -> )>)
>> at ../../gcc/gcc/cgraph.h:3299
>> #1 0x00d03c37 in cgraph_node::remove_callees (this=> * const 0x76dedaa0 "__ct_base "/18>) at
>> ../../gcc/gcc/cgraph.cc:1743
>> #2 0x00d04387 in cgraph_node::remove (this=> 0x76dedaa0 "__ct_base "/18>) at ../../gcc/gcc/cgraph.cc:1884
>> #3 0x010da74f in symbol_table::remove_unreachable_nodes
>> (this=0x76ddb000, file=0x77a814c0 <_IO_2_1_stderr_>) at
>> ../../gcc/gcc/ipa.cc:518
>> #4 0x02b51e53 in ipa_inline () at
>> ../../gcc/gcc/ipa-inline.cc:2761
>> #5 0x02b52cf7 in (anonymous
>> namespace)::pass_ipa_inline::execute (this=0x3c8d5b0) at
>> ../../gcc/gcc/ipa-inline.cc:3153
>> (etc)
>>
>> ... I presume that my assumption that cgraph_node::remove () should
>> remove nodes from the cgraph_node::next chain is wrong?
>
> Ummm the function does that through the call to
> symtab_node::unregister. But how is that related?
Oh - my bad. I seem to have broken on the wrong condition here.
"value"/28 is *not* removed.
That makes more sense, it'd be confusing if remove() still lead to
FOR_EACH_FUNCTION touching a node.
>>
And as a side question, do all clone nodes have a ->clones pointing to
the same list of all clones, or are they in a tree-ish arrangement,
where clones of clones end up forming a tree, with the clone_of pointer
being a pointer to the parent?
>>>
>>> The latter, they form a tree.
>>
>> I see, that makes sense. Thanks.
>>
(in this instance, the node that trips
the assert has a nullptr clone_of and clones value, which would AIUI
imply that it is the original)
>>>
>>> Yes.
>>>
This train of thinking doesn't end up involving any devirtualization
code, which the PR was originally reproduced with, but my current theory
is that devirtualizing here just exposed an edge case that is decently
well hidden, rather than it playing a crucial role.
>>>
>>> The inlined function is - I believe erroneously - marked as reachable by
Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias
Arsen Arsenović via Gcc-patches writes: > Thank you! I'll do a final rebase and push in the morning. Done! Gerald, please update the scripts when you get a chance (but back the old ones up just in case!) If makeinfo is updated as I've asked in one of the other emails, will the script eventually automatically regenerate docs with the newer makeinfo? Thanks, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias
Sandra Loosemore writes: > On 3/18/23 14:14, Arsen Arsenović via Gcc-patches wrote: >> Evening, >> Ping on this patch series. >> I believe we're close to being able to apply it, with contents of the >> documentation changes being approved, and only a small build system >> change and a revised patch series "shape" left to review. > > Yup. I think you can go ahead and commit everything but the part with the > configure/makefile hackery, which still needs somebody other than me to > approve > it. > >> The former change of these two is in: >> https://inbox.sourceware.org/gcc-patches/20230311203234.2257423-1-ar...@aarsen.me/ >> The patch adds a test for the presence of CONTENTS_OUTPUT_LOCATION into >> the build system in order to avoid shortcontents coming after contents >> in HTML output. We've also updated Texinfo to output shortcontents >> before contents by default as a result of the discussion here, though >> that will only happen in newer versions. >> The latter "shape" is a git log documented at: >> https://inbox.sourceware.org/gcc-patches/87ttysppsc@aarsen.me/ >> As always, I've freshly rebased the patch series at >>https://git.sr.ht/~arsen/gcc texinfo_improvements >> ... or, in (git)web form, at: >>https://git.sr.ht/~arsen/gcc/log/texinfo_improvements >> ... with the render at: >>https://www.aarsen.me/~arsen/final/ >> Thank you all in advance, have a lovely day. > > Joseph, could you maybe review the last piece? A direct pointer to it in > Arsen's git is > > https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3 > > -Sandra Thank you! I'll do a final rebase and push in the morning. -- Arsen Arsenović signature.asc Description: PGP signature
Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias
Joseph Myers writes: > On Mon, 20 Mar 2023, Sandra Loosemore wrote: > >> Joseph, could you maybe review the last piece? A direct pointer to it in >> Arsen's git is >> >> https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3 > > That's OK, assuming I understand correctly that makeinfo will still > succeed with a warning when it's an older version (gcc.gnu.org, where > update_web_docs_git runs, has version 6.5). It should, yes, but I'd like to ask for that server to be updated to Texinfo straight from the press (the press is currently at commit e2d30b1270deacf5a1eab1d383733a5a088827d6). Mark told me that this needs approval from the GCC admins to do. The reason for this is that the in-dev versions of Texinfo produce more accessible HTML documentation due to a few changes that I've incorporated into them, as well as a few made by the Texinfo maintainers. Do you think that would be OK? Thanks, have a lovely night. -- Arsen Arsenović signature.asc Description: PGP signature
Re: Is it possible to enable data sections and function sections without explicitly giving flags "-fdata-sections" and "-ffunction-sections"?
"3119369616.qq via Gcc" writes: > To divide functions into sections and then remove unused sections, I must > provide flags "-fdata-sections" and "-ffunction-sections" in GCC and a flag > "--gc-sections" in LD. Most of the build systems don't support these flags so > GCC will generate bigger binaries. > Is it possible to enable this feature without giving any command line > flags manually? All (at least decent) build systems support passing extra flags to the compiler and linker (e.g. CXXFLAGS="-ffunction-sections"), or passing a custom compiler and linker (which can set those flags, something like CC="gcc -ffunction-sections"). This is how you should be setting such flags. If you're interested in DCE and other size-reducing optimizations, you might also be interested in LTO and -Os. -- Arsen Arsenović signature.asc Description: PGP signature
Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias
Evening, Ping on this patch series. I believe we're close to being able to apply it, with contents of the documentation changes being approved, and only a small build system change and a revised patch series "shape" left to review. The former change of these two is in: https://inbox.sourceware.org/gcc-patches/20230311203234.2257423-1-ar...@aarsen.me/ The patch adds a test for the presence of CONTENTS_OUTPUT_LOCATION into the build system in order to avoid shortcontents coming after contents in HTML output. We've also updated Texinfo to output shortcontents before contents by default as a result of the discussion here, though that will only happen in newer versions. The latter "shape" is a git log documented at: https://inbox.sourceware.org/gcc-patches/87ttysppsc@aarsen.me/ As always, I've freshly rebased the patch series at https://git.sr.ht/~arsen/gcc texinfo_improvements ... or, in (git)web form, at: https://git.sr.ht/~arsen/gcc/log/texinfo_improvements ... with the render at: https://www.aarsen.me/~arsen/final/ Thank you all in advance, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: cgraph: does node->inlined_to imply node->clones is non-empty?
Hi Martin,
Thank you for the thorough response, and apologies for replying so late
(I'm busy most hours of most workdays nowadays).
Martin Jambor writes:
> Hello,
>
> I had been aware of your message even before Martin Liška pointed to it,
> but I could not answer the questions without looking into the problem
> myself.
>
> On Mon, Mar 13 2023, Arsen Arsenović via Gcc wrote:
>> Hi,
>>
>> I was debugging PR96059 and ran into a question which does not seem
>> obvious from the code.
>
> Thanks for looking into old bugs, it really is appreciated!
My pleasure.
>> When the original inline
>> happens, ipa-inline-transform.cc:clone_inlined_nodes decides not to make
>> a clone, since the function being cloned is a master clone but with no
>> non-inline clones.
>
> The reason is rather that cloning can simply be avoided if you know that
> you do not need an offline copy, for anything, be it other normal calls,
> calls from outside of the compilation unit, indirect calls, virtual
> calls, calls through aliases, thunks... that you do not need the intact
> body of the function to create other inline copies, other specialized
> clones... and maybe I forgot about something. But this is an efficiency
> thing.
Right. I was just trying to be specific about which requirement in the
if turned out to be false.
>>
>> For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
>> seems to try to remove an unreachable function that was already inlined
>> into a different unreachable function.
>
> No, it fails to remove it. It is still there but should not have been,
> that is the problem.
Ah - I see.
>>
>> This decision later trips up the gcc_assert in:
>>
>> /* Inline clones might be kept around so their materializing allows further
>> cloning. If the function the clone is inlined into is removed, we need
>> to turn it into normal cone. */
>> FOR_EACH_FUNCTION (node)
>> {
>> if (node->inlined_to
>>&& !node->callers)
>> {
>>gcc_assert (node->clones);
>>node->inlined_to = NULL;
>>update_inlined_to_pointer (node, node);
>> }
>> node->aux = NULL;
>> }
>>
>> .. because it is expecting that an inlined function without callers
>> (which is necessarily true here as this function is unreachable and so
>> was ->remove ()'d earlier) has clones.
>
> The assert makes sure that if we encounter an inlined-to node without
> any caller, that it merely holds as the holder of the function body for
> its other specialized (think IPA-CP) or inline clones. If node->clones
> is false, there are no such clones and it was a bug to mark the node as
> required during the removal of unreachable nodes.
I see. That makes sense. So, this assert is placed here by convenience
rather than being this invariant being absolutely required for the
purpose of the loop? (it is related, so this placement makes sense, I
just want to confirm whether it's a "mandatory" invariant)
>>
>> Either removing the assertion or making clone_inline_nodes clone when
>> there are no existing clones 'fixes' (suppresses, but I haven't verified
>> whether the results are correct) the problem.
>>
>> Is this gcc_assert correct in that an inlined function without callers
>> necessarily must have clones?
>
> It is correct. An inlined function without a caller is even a logical
> oxymoron and can only exist if it has the purpose described above (and
> even then probably only in a fairly special circumstances).
Right. I wasn't quite sure whether setting inlined_to would remove that
caller, but if I understood right, it should not.
What is interesting, though, is that there is an attempt to remove this
node during ipa_inline:
(gdb) bt
#0 cgraph_edge::remove_callee (
this= -> )>)
at ../../gcc/gcc/cgraph.h:3299
#1 0x00d03c37 in cgraph_node::remove_callees (this=) at
../../gcc/gcc/cgraph.cc:1743
#2 0x00d04387 in cgraph_node::remove (this=) at ../../gcc/gcc/cgraph.cc:1884
#3 0x010da74f in symbol_table::remove_unreachable_nodes
(this=0x76ddb000, file=0x77a814c0 <_IO_2_1_stderr_>) at
../../gcc/gcc/ipa.cc:518
#4 0x02b51e53 in ipa_inline () at
../../gcc/gcc/ipa-inline.cc:2761
#5 0x02b52cf7 in (anonymous
namespace)::pass_ipa_inline::execute (this=0x3c8d5b0) at
../../gcc/gcc/ipa-inline.cc:3153
(etc)
... I presume that my assumption that cgraph_node::remove () should
remove nodes from the cgraph_node::next chain is wrong?
>>
>> And as a side question, do all clone nodes have a ->clones pointing to
>> the same list of
Re: [GSoC] gccrs Unicode support
Philip Herron via Gcc writes: > Hi Raiki Welcome, Raiki! > Excellent work on getting up to speed on the rust front-end. From my > perspective I am interested to see what the wider GCC community thinks > about using https://www.gnu.org/software/libunistring/ library within GCC > instead of rolling our own, this means it will be another dependency on GCC. As my $0.02, it is likely best not to create yet another re-implementation. There's already precedent for including dependencies that can do a very complex job well, like GMP and MPFR. Text handling is deceivingly simple, and in practice, nobody seems to get it fully right. The effort is minimized, and yet most effectively shared, if done in a library. (note: I don't have a horse in the race wrt which specific library to use, as I'm no expert, but I suspect libunistring could work well) Have a wonderful day! > The other option is there is already code in the other front-ends to do > this so in the worst case it should be possible to extract something out of > them and possibly make this a shared piece of functionality which we can > mentor you through. > > Thanks > > --Phil > > On Mon, 13 Mar 2023 at 16:19, Raiki Tamura via Gcc wrote: > >> Hello, >> >> My name is Raiki Tamura, an undergraduate student at Kyoto University in >> Japan and I want to work on Unicode support in gccrs this year. >> I have already written my proposal (linked below) and shared it with the >> gccrs team in Zulip. >> In the project, I am planning to use the GNU unistring library to handle >> Unicode characters and the GNU IDN library to normalize identifiers. >> According to my potential mentor, it would provide Unicode libraries for >> all frontends in GCC. If there are concerns or feedback about this, please >> tell me about it. >> Thank you. >> >> Link to my proposal: >> >> https://docs.google.com/document/d/1MgsbJMF-p-ndgrX2iKeWDR5KPSWw9Z7onsHIiZ2pPKs/edit?usp=sharing >> >> Raiki Tamura >> -- Arsen Arsenović signature.asc Description: PGP signature
Re: [GSoC] gccrs Unicode support
Philip Herron via Gcc writes: > Hi Raiki Welcome, Raiki! > Excellent work on getting up to speed on the rust front-end. From my > perspective I am interested to see what the wider GCC community thinks > about using https://www.gnu.org/software/libunistring/ library within GCC > instead of rolling our own, this means it will be another dependency on GCC. As my $0.02, it is likely best not to create yet another re-implementation. There's already precedent for including dependencies that can do a very complex job well, like GMP and MPFR. Text handling is deceivingly simple, and in practice, nobody seems to get it fully right. The effort is minimized, and yet most effectively shared, if done in a library. (note: I don't have a horse in the race wrt which specific library to use, as I'm no expert, but I suspect libunistring could work well) Have a wonderful day! > The other option is there is already code in the other front-ends to do > this so in the worst case it should be possible to extract something out of > them and possibly make this a shared piece of functionality which we can > mentor you through. > > Thanks > > --Phil > > On Mon, 13 Mar 2023 at 16:19, Raiki Tamura via Gcc wrote: > >> Hello, >> >> My name is Raiki Tamura, an undergraduate student at Kyoto University in >> Japan and I want to work on Unicode support in gccrs this year. >> I have already written my proposal (linked below) and shared it with the >> gccrs team in Zulip. >> In the project, I am planning to use the GNU unistring library to handle >> Unicode characters and the GNU IDN library to normalize identifiers. >> According to my potential mentor, it would provide Unicode libraries for >> all frontends in GCC. If there are concerns or feedback about this, please >> tell me about it. >> Thank you. >> >> Link to my proposal: >> >> https://docs.google.com/document/d/1MgsbJMF-p-ndgrX2iKeWDR5KPSWw9Z7onsHIiZ2pPKs/edit?usp=sharing >> >> Raiki Tamura >> -- Arsen Arsenović signature.asc Description: PGP signature -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH v2 0/5] A small Texinfo refinement
Richard Biener writes: > On Fri, Mar 10, 2023 at 8:00 PM Gerald Pfeifer wrote: >> >> On Fri, 10 Mar 2023, Sandra Loosemore wrote: >> > AFAIK we have not knowingly changed any specific requirements beyond the >> > stated 4.7 and 4.9 for PDF output, but it concerns me that nobody is >> > likely to be using versions that old on a regular basis to make sure >> > they continue to work and we haven't unknowingly introduced dependencies >> > on newer Texinfo features. >> >> I'm generally very interested in ensuring we do not hurt users who do not >> have the latest and greatest of the day. On the other hand, if there's a >> few people using (more or less deliberately abandonware) we should not >> feel too bad if something breaks. >> >> > Anyway, I think I will leave the existing requirement alone for now, and >> > just add a note that newer versions produce better output. >> >> With Richi mentioning that SLE 12 (which was first released 9 years ago) >> uses texinfo 4.13a and Andrew mentioning that RHEL 7 uses texinfo 5.1 I >> would feel very comfortable making either 4.13 or even 5.1 the new minimum. >> >> (Not because we need to cater to those two Enterprise Linux distros, >> rather since they tend to fall on the conversative side.) > > We could also opt to ship generated pdf documentation with the > release tarballs - the pre-built info format plus manual pages is > probably of less use these days? They're still widely installed and I suspect many open the manpages as a quick reference. I guess that fewer open the info pages, but it's not nobody (I certainly do, but I also have texinfo installed so I can generate them anyway, as I do for the weekly snapshots that I have installed). > Richard. > >> Gerald -- Arsen Arsenović signature.asc Description: PGP signature
cgraph: does node->inlined_to imply node->clones is non-empty?
Hi,
I was debugging PR96059 and ran into a question which does not seem
obvious from the code.
For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
seems to try to remove an unreachable function that was already inlined
into a different unreachable function. When the original inline
happens, ipa-inline-transform.cc:clone_inlined_nodes decides not to make
a clone, since the function being cloned is a master clone but with no
non-inline clones.
This decision later trips up the gcc_assert in:
/* Inline clones might be kept around so their materializing allows further
cloning. If the function the clone is inlined into is removed, we need
to turn it into normal cone. */
FOR_EACH_FUNCTION (node)
{
if (node->inlined_to
&& !node->callers)
{
gcc_assert (node->clones);
node->inlined_to = NULL;
update_inlined_to_pointer (node, node);
}
node->aux = NULL;
}
.. because it is expecting that an inlined function without callers
(which is necessarily true here as this function is unreachable and so
was ->remove ()'d earlier) has clones.
Either removing the assertion or making clone_inline_nodes clone when
there are no existing clones 'fixes' (suppresses, but I haven't verified
whether the results are correct) the problem.
Is this gcc_assert correct in that an inlined function without callers
necessarily must have clones?
And as a side question, do all clone nodes have a ->clones pointing to
the same list of all clones, or are they in a tree-ish arrangement,
where clones of clones end up forming a tree, with the clone_of pointer
being a pointer to the parent? (in this instance, the node that trips
the assert has a nullptr clone_of and clones value, which would AIUI
imply that it is the original)
This train of thinking doesn't end up involving any devirtualization
code, which the PR was originally reproduced with, but my current theory
is that devirtualizing here just exposed an edge case that is decently
well hidden, rather than it playing a crucial role.
Thanks in advance, have a lovely day.
--
Arsen Arsenović
signature.asc
Description: PGP signature
[PATCH gcc-{11, 12}] c++: top level bind when rewriting coroutines [PR106188]
In the edge case of a coroutine not containing any locals, the ifcd/switch
temporaries would get added to the coroutine frame, corrupting its
layout. To prevent this, we can make sure there is always a BIND_EXPR at
the top of the function body, and thus, always a place for our new
temporaries to go without interfering with the coroutine frame.
PR c++/106188 - Incorrect frame layout after transforming conditional statement
without top-level bind expression
PR c++/106713 - if (co_await ...) crashes with a jump to ud2
PR c++/106188
PR c++/106713
gcc/cp/ChangeLog:
* coroutines.cc (coro_rewrite_function_body): Ensure we have a
BIND_EXPR wrapping the function body.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr106188.C: New test.
---
Morning,
A while back, we merged this patch into GCC 13 to fix PR106188, but
never backported it into GCC 11 and 12, which both still suffer from
this bug.
I've tested the same patch against releases/gcc-{11,12} and they apply
and fix the testcase (and the testcase fails without them, as expected)
on x86_64-pc-linux-gnu.
OK for backporting?
Thanks in advance.
gcc/cp/coroutines.cc | 9 ++
gcc/testsuite/g++.dg/coroutines/pr106188.C | 34 ++
2 files changed, 43 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/coroutines/pr106188.C
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index e982cdb89a7..ea3850082cf 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4067,6 +4067,15 @@ coro_rewrite_function_body (location_t fn_start, tree
fnbody, tree orig,
BLOCK_SUPERCONTEXT (replace_blk) = top_block;
BLOCK_SUBBLOCKS (top_block) = replace_blk;
}
+ else
+{
+ /* We are missing a top level BIND_EXPR. We need one to ensure that we
+don't shuffle around the coroutine frame and corrupt it. */
+ tree bind_wrap = build3_loc (fn_start, BIND_EXPR, void_type_node,
+ NULL, NULL, NULL);
+ BIND_EXPR_BODY (bind_wrap) = fnbody;
+ fnbody = bind_wrap;
+}
/* Wrap the function body in a try {} catch (...) {} block, if exceptions
are enabled. */
diff --git a/gcc/testsuite/g++.dg/coroutines/pr106188.C
b/gcc/testsuite/g++.dg/coroutines/pr106188.C
new file mode 100644
index 000..9db3778d079
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr106188.C
@@ -0,0 +1,34 @@
+// { dg-do run { target c++20 } }
+// test case from pr106188, w/o workaround
+#include
+
+struct task {
+ struct promise_type {
+task get_return_object() { return task{}; }
+void return_void() {}
+void unhandled_exception() {}
+auto initial_suspend() noexcept { return std::suspend_never{}; }
+auto final_suspend() noexcept { return std::suspend_never{}; }
+ };
+};
+
+struct suspend_and_resume {
+ bool await_ready() const { return false; }
+ void await_suspend(std::coroutine_handle<> h) { h.resume(); }
+ void await_resume() {}
+};
+
+task f() {
+ if (co_await suspend_and_resume{}, false) {}
+}
+
+task g() {
+ switch (co_await suspend_and_resume{}, 0) {
+default: break;
+ }
+}
+
+int main() {
+ f();
+ g();
+}
--
2.39.2
Re: [PATCH v2 1/5] docs: Create Indices appendix
Gerald Pfeifer writes: > On Sat, 11 Mar 2023, Arsen Arsenović wrote: >> Sandra Loosemore writes: >>> Hmmm, first off, I think somebody other than me needs to approve the >>> configure and makefile pieces, as well as the maintainer-scripts part. >>> It looks conceptually right to me > > Per gcc/MAINTAINERS that'd be > > build machinery (*.in) Paolo Bonzini > build machinery (*.in) Nathanael Nerode > build machinery (*.in) Alexandre Oliva > build machinery (*.in) Ralf Wildenhues > > though I don't recall seeing much (if anything) from others than Alexandre > for quite a while. > > So more likely one of the Global Reviewers in that same file. Okay, thanks. I'll let some time pass before pinging people for the v2 I sent yesterday. With that, we should be left with just a review of the updated Git log before this series is ready for trunk, IIRC. Have a great day! > Gerald -- Arsen Arsenović signature.asc Description: PGP signature
[PATCH v2] html: Set CONTENTS_OUTPUT_LOCATION=inline if makeinfo supports it
This flag allows us to restore old (pre-6.8) behavior of the
@{summary,}content commands, so that texi2any continues to emit
summarycontents first.
maintainer-scripts/ChangeLog:
* update_web_docs_git: Set CONTENTS_OUTPUT_LOCATION=inline in
order to put @shortcontents above contents.
gcc/ChangeLog:
* configure.ac: Add check for the Texinfo 6.8
CONTENTS_OUTPUT_LOCATION customization variable and set it if
supported.
* configure: Regenerate.
* Makefile.in (MAKEINFO_TOC_INLINE_FLAG): New variable. Set by
configure.ac to -c CONTENTS_OUTPUT_LOCATION=inline if
CONTENTS_OUTPUT_LOCATION support is detected, empty otherwise.
($(build_htmldir)/%/index.html): Pass MAKEINFO_TOC_INLINE_FLAG.
---
Here's an updated version of that patch, for review. I'm sending it
separately and properly to not accidentally alienate potential
reviewers.
gcc/Makefile.in| 6 -
gcc/configure | 35 --
gcc/configure.ac | 21
maintainer-scripts/update_web_docs_git | 2 +-
4 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6001c9e3b55..d8b76d83d68 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -787,6 +787,9 @@ INSTALL_HEADERS=install-headers install-mkheaders
# Control whether Info documentation is built and installed.
BUILD_INFO = @BUILD_INFO@
+# Control flags for @contents placement in HTML output
+MAKEINFO_TOC_INLINE_FLAG = @MAKEINFO_TOC_INLINE_FLAG@
+
# Control whether manpages generated by texi2pod.pl can be rebuilt.
GENERATED_MANPAGES = @GENERATED_MANPAGES@
@@ -3461,7 +3464,8 @@ html:: $(HTMLS_BUILD)
$(build_htmldir)/%/index.html: %.texi
$(mkinstalldirs) $(@D)
rm -f $(@D)/*
- $(TEXI2HTML) -I $(abs_docdir) -I $(abs_docdir)/include -o $(@D) $<
+ $(TEXI2HTML) $(MAKEINFO_TOC_INLINE_FLAG) \
+ -I $(abs_docdir) -I $(abs_docdir)/include -o $(@D) $<
# Duplicate entry to handle renaming of gccinstall
$(build_htmldir)/gccinstall/index.html: $(TEXI_GCCINSTALL_FILES)
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 62bc908b991..120151c474a 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1242,6 +1242,27 @@ else
fi
AC_SUBST(BUILD_INFO)
+# Determine whether makeinfo supports the CONTENTS_OUTPUT_LOCATION variable.
+# If it does, we want to pass it to makeinfo in order to restore the old
+# behavior of @{summary,}contents placement.
+MAKEINFO_TOC_INLINE_FLAG=
+AS_IF([test x"$MAKEINFO" != x], [
+ AC_CACHE_CHECK([for CONTENTS_OUTPUT_LOCATION support in $MAKEINFO],
+[gcc_cv_texi_add_toc_inline_flags], [
+# Detect the unknown variable CONTENTS_OUTPUT_LOCATION warning
+if "$MAKEINFO" -c CONTENTS_OUTPUT_LOCATION=inline &1 \
+ | grep CONTENTS_OUTPUT_LOCATION >/dev/null; then
+ gcc_cv_texi_add_toc_inline_flags=no
+else
+ gcc_cv_texi_add_toc_inline_flags=yes
+fi
+ ])
+ if test x"$gcc_cv_texi_add_toc_inline_flags" = xyes; then
+MAKEINFO_TOC_INLINE_FLAG='-c CONTENTS_OUTPUT_LOCATION=inline'
+ fi
+])
+AC_SUBST([MAKEINFO_TOC_INLINE_FLAG])
+
# Is pod2man recent enough to regenerate manpages?
AC_MSG_CHECKING([for recent Pod::Man])
if (perl -e 'use 1.10 Pod::Man') >/dev/null 2>&1; then
diff --git a/maintainer-scripts/update_web_docs_git
b/maintainer-scripts/update_web_docs_git
index 9ded1744df4..c9f14d1a4d1 100755
--- a/maintainer-scripts/update_web_docs_git
+++ b/maintainer-scripts/update_web_docs_git
@@ -169,7 +169,7 @@ for file in $MANUALS; do
if [ "$file" = "gnat_ugn" ]; then
includes="$includes -I gcc/gcc/ada -I gcc/gcc/ada/doc/gnat_ugn"
fi
-makeinfo --html --css-ref $CSS $includes -o ${file} ${filename}
+makeinfo --html -c CONTENTS_OUTPUT_LOCATION=inline --css-ref $CSS
$includes -o ${file} ${filename}
tar cf ${file}-html.tar ${file}/*.html
texi2dvi $includes -o ${file}.dvi ${filename} /dev/null &&
dvips -o ${file}.ps ${file}.dvi
texi2pdf $includes -o ${file}.pdf ${filename}
Re: [PATCH v2 1/5] docs: Create Indices appendix
Gerald Pfeifer writes:
> On Sat, 11 Mar 2023, Arsen Arsenović wrote:
>> OK, changed up a bit, what do you think of this:
>
>> maintainer-scripts/ChangeLog:
>>
>> * update_web_docs_git: Set CONTENTS_OUTPUT_LOCATION=inline in
>> order to put @shortcontents above contents. See
>> 9dd976a4-4e09-d901-b949-6d5037567...@codesourcery.com on
>> gcc-patches.
>
> In the ChangeLog we only describe *what* has change, so the first half of
> the first sentence.
>
> The rest then goes in between the first line of the Git commit message
> (= the subject of your mail) and the ChangeLog entries.
Ah, OK. I decided to put it there, too (and repeat it twice), since the
ChangeLog crafting script doesn't include the commit message for
context. I've dropped that now.
>
>> --- a/gcc/configure
>> +++ b/gcc/configure
>
> We usually don't post diffs for generated files. Not a biggie, I figured I
> mention it since it makes reviewing easier and patches shorter, and thus
> tends to increase the chance reviewers short on time jump in. :-)
Ah, d'oh. I forgot to filter that out. Apologies.
>
>> --- a/maintainer-scripts/update_web_docs_git
>> +++ b/maintainer-scripts/update_web_docs_git
>> @@ -169,7 +169,7 @@ for file in $MANUALS; do
>> if [ "$file" = "gnat_ugn" ]; then
>> includes="$includes -I gcc/gcc/ada -I gcc/gcc/ada/doc/gnat_ugn"
>> fi
>> -makeinfo --html --css-ref $CSS $includes -o ${file} ${filename}
>> +makeinfo --html -c CONTENTS_OUTPUT_LOCATION=inline --css-ref $CSS
>> $includes -o ${file} ${filename}
>
> Sandra deferred to me on this one, so explicitly: Ack, thank you. :-)
>
> Note, update_web_docs_git runs once a day, at 0:50 GMT, see
> gcc/maintainer-scripts/crontab, and needs to be updated on the gcc.gnu.org
> system. I am happy to do that for you, just drop me a note when the commit
> is in.
Sure thing, thanks!
> Gerald
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [PATCH v2 1/5] docs: Create Indices appendix
Sandra Loosemore writes: > On 3/11/23 05:22, Arsen Arsenović wrote: >> OK, changed up a bit, what do you think of this: >> maintainer-scripts/ChangeLog: >> * update_web_docs_git: Set CONTENTS_OUTPUT_LOCATION=inline in >> order to put @shortcontents above contents. See >> 9dd976a4-4e09-d901-b949-6d5037567...@codesourcery.com on >> gcc-patches. >> gcc/ChangeLog: >> * configure.ac: Add check for the Texinfo 6.8 >> CONTENTS_OUTPUT_LOCATION customization variable and set it if >> supported. >> * configure: Regenerate. >> * Makefile.in (MAKEINFO_TOC_INLINE_FLAG): New variable. Set by >> configure.ac to -c CONTENTS_OUTPUT_LOCATION=inline if >> CONTENTS_OUTPUT_LOCATION support is detected, empty otherwise. >> ($(build_htmldir)/%/index.html): Pass MAKEINFO_TOC_INLINE_FLAG. >> See 9dd976a4-4e09-d901-b949-6d5037567...@codesourcery.com on >> gcc-patches. > > Hmmm, first off, I think somebody other than me needs to approve the configure > and makefile pieces, as well as the maintainer-scripts part. It looks > conceptually right to me, although I would add a comment to new configure.ac > piece like > > "Newer versions of Texinfo put the table of contents in the wrong place by > default in HTML output, but provide a command-line option to restore the > desired behavior. Check whether we need to do that." This sounds good, will drop in. Who can review these? > I don't know whether the maintainer-scripts change needs to be made > conditional > too. :-S I don't think so, I was thinking of omitting it for the usual build too since it's a nonfatal error to pass non-existent customization variables, but I decided that this would introduce too much noise to the normal path. This shouldn't emit a warning on the server that runs the update anyway since, hopefully, we'd be updating it 7.0dev for the other goodies. > BTW, this change probably needs to be backported to all active GCC branches > (10, 11, and 12) too after it's committed to mainline. I'm not opposed to doing that. > -Sandra -- Arsen Arsenović signature.asc Description: PGP signature
