[Bug libstdc++/105915] [11 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915 --- Comment #5 from Benda Xu --- (In reply to Jonathan Wakely from comment #4) > (In reply to Benda Xu from comment #0) > > 2. https://github.com/gentoo/gentoo/pull/25313 > > N.B. I'm fixing it like this instead of backporting 42eff613d0, so that pull > request might want to use the same patch: > > commit 60c84707034f025de3c8821cc5d6f27ff59143b0 (HEAD -> gcc-11) > Author: Jonathan Wakely > Date: Fri Jun 10 13:01:16 2022 +0100 > > libstdc++: Partially revert r11-9772-g6f8133689f4397 [PR105915] > > The r11-9772-g6f8133689f4397 backport made two changes, but only one was > needed on the gcc-11 branch. The other should not have been backported, > and causes errors with clang. This removes the unwanted part. > > libstdc++-v3/ChangeLog: > > PR libstdc++/105915 > * include/experimental/bits/fs_path.h (path::begin, path::end): > Remove noexcept from declarations. > > diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h > b/libstdc++-v3/include/experimental/bits/fs_path.h > index 1cc1b3bf686..a2bc931c696 100644 > --- a/libstdc++-v3/include/experimental/bits/fs_path.h > +++ b/libstdc++-v3/include/experimental/bits/fs_path.h > b/libstdc++-v3/include/experimental/bits/fs_path.h > index 1cc1b3bf686..a2bc931c696 100644 > --- a/libstdc++-v3/include/experimental/bits/fs_path.h > +++ b/libstdc++-v3/include/experimental/bits/fs_path.h > @@ -425,8 +425,8 @@ namespace __detail > class iterator; > typedef iterator const_iterator; > > -iterator begin() const noexcept; > -iterator end() const noexcept; > +iterator begin() const; > +iterator end() const; > > /// @cond undocumented > // Create a basic_string by reading until a null character. > @@ -425,8 +425,8 @@ namespace __detail > class iterator; > typedef iterator const_iterator; > > -iterator begin() const noexcept; > -iterator end() const noexcept; > +iterator begin() const; > +iterator end() const; > > /// @cond undocumented > // Create a basic_string by reading until a null character. Thank you Jonathan! We have confirmed in the same environment that the patch works great.
[Bug libstdc++/105915] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915 --- Comment #3 from Benda Xu --- (In reply to Jonathan Wakely from comment #2) > > Only when compiling with clang, presumably. Yes, that's true. To be specific, we meet it in the AMD ROCm on Gentoo, where the HIP compiler is based on llvm and our system compiler is gcc-11.3.0.
[Bug libstdc++/105915] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915 --- Comment #1 from Benda Xu --- Hi Jonathan, I am involving you in the Cc thinking that you will have a better idea on this issue. Thanks!
[Bug libstdc++/105915] New: commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
Bug ID: 105915
Summary: commit 42eff613 should be backported to gcc-11 for
bits/fs_path.h consistency
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: heroxbd at sohu dot com
Target Milestone: ---
Hi, comments 42eff613d0 is followed by 944da70a5d to add 'noexcept' to
path::iterator members. But in the gcc-11.3.0 release, only 944da70a5d was
applied.
With a MWE of
```c++
#include
int main(){}
```
would produce
```
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include/g++-v11/experimental/bits/fs_path.h:1209:9:
error: 'begin' is missing exception specification 'noexcept'
path::begin() const
^
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include/g++-v11/experimental/bits/fs_path.h:428:14:
note: previous declaration is here
iterator begin() const noexcept;
^
```
on a Gentoo system.
After applying 42eff613d0 to gcc-11.3.0, the bug disappears.
Please see also:
1. https://bugs.gentoo.org/842405
2. https://github.com/gentoo/gentoo/pull/25313
[Bug bootstrap/70473] genautomata memory footprint for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70473 --- Comment #8 from Benda Xu --- (In reply to BillyBarty from comment #7) > I was having this same issue building gcc 5.2.0 on my Raspberry Pi 3. Thank you for your report. Is your Raspberry Pi 3 running aarch64 (arm64) or arm (32 bit)?
[Bug bootstrap/60743] build/genautomata uses 700 MB memory for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60743 Benda Xu changed: What|Removed |Added CC||heroxbd at sohu dot com --- Comment #18 from Benda Xu --- Redirected to bug 70473.
[Bug bootstrap/70473] genautomata memory footprint for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70473 Benda Xu changed: What|Removed |Added CC||heroxbd at sohu dot com --- Comment #4 from Benda Xu --- I can reproduce this bug on armv7a (TI OMAP 4430) with 1GB of memory, build/genautomata took 900MB of ram and the system freezed. To ktkachov, but gcc-4.9 has a moderate memory footprint. This should be considered a regression of gcc-5. But thanks for working on this issue. I'd vote for it.
[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556
--- Comment #5 from Benda Xu ---
Dear Jakub,
I find your comment misleading for the --with-specs option.
It sets CONFIGURE_SPECS macro, which is used in gcc.c as
static const char *const driver_self_specs[] = {
"%{fdump-final-insns:-fdump-final-insns=.} %
[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556
Benda Xu changed:
What|Removed |Added
CC||heroxbd at sohu dot com
--- Comment #4 from Benda Xu ---
(In reply to Jakub Jelinek from comment #2)
> Just use -Wl,-dynamic-linker=/whatever/ld.so
-Wl,-dynamic-linker=/whatever/ld.so cannot be set permanently. It requires a
wrapper to inject such argument all the time, which is ugly.
> or you could use --with-specs configure option.
Builtin specs of GCC is already very complicated (output from gcc-4.7.3
-dumpspecs on amd64):
...
*link:
%{!static:--eh-frame-hdr} %{m32|mx32:;:-m elf_x86_64}
%{m32:-m elf_i386}%{mx32:-m elf32_x86_64}
%{shared:-shared} %{!shared: %{!static: %{rdynamic:-export-dynamic}
%{m32:-dynamic-linker
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/lib/ld-linux.so.2}}}
%{m32|mx32:;:-dynamic-linker
%{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:/lib64/ld-linux-x86-64.so.2}}}
%{mx32:-dynamic-linker
%{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin/linkerx32;:/libx32/ld-linux-x32.so.2
%{static:-static}}
...
writing an equivalent specs with prefixed dynamic linker is horrible.
Please consider sopport dynamic linker prefix by an extra configure option.
