[Bug other/96595] New: docs: typos in gfortran -fallow-argument-mismatch invoke description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96595 Bug ID: 96595 Summary: docs: typos in gfortran -fallow-argument-mismatch invoke description Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: mkrupcale at matthewkrupcale dot com Target Milestone: --- Created attachment 49053 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49053&action=edit patch fixing typos in gfortran -fallow-argument-mismatch description There are some typos in the gfortran invoke description for -fallow-argument-mismatch: whith->with, wi1th->with, vial->via. See attached patch.
[Bug c++/93790] New: Cannot initialize reference from std::reference_wrapper using direct- or list-initialization syntax in GCC 10 c++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93790
Bug ID: 93790
Summary: Cannot initialize reference from
std::reference_wrapper using direct- or
list-initialization syntax in GCC 10 c++2a mode
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mkrupcale at matthewkrupcale dot com
Target Milestone: ---
The following results in a compile error in GCC 10 -std=c++2a mode[1]:
===
struct S {};
class S_refwrap {
S& Sref_;
public:
S_refwrap(S& Sref) : Sref_(Sref) {}
operator S&() { return Sref_; }
};
S s;
S_refwrap s_rw(s);
S& s_r(s_rw);
===
$ g++ --version
g++ (GCC) 10.0.1 20200216 (Red Hat 10.0.1-0.8)
$ g++ -std=c++2a -c /tmp/test1.cpp
/tmp/test1.cpp:11:12: error: invalid initialization of non-const reference of
type ‘S&’ from an rvalue of type ‘’
11 | S& s_r(s_rw);
|^
This does not result in an error in c++17 mode or with GCC 9.2 in c++2a mode.
However, using list-initialization with GCC 9.2 in c++2a mode does result in
the same error.
I originally encountered this when trying to initialize a reference from a
std::reference_wrapper using direct initialization. This also failed with
list-initialization but works with copy initialization (i.e. S& s_r = s_rw;).
The error with a constant reference is similar:
error: invalid initialization of reference of type ‘const S&’ from expression
of type ‘’
This might be related to the following bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63604
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77875
[1] https://godbolt.org/z/4udMyJ
[Bug libstdc++/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #2 from Matthew Krupcale ---
I can confirm that I'm still observing this when building multilib bootstrap
GCC 4.8.3 using GCC 9.2.1 on Fedora 30[1,2]. I tried to verify this issue when
building GCC 6.4.1 (GLIBCXX_3.4.22, CXXABI_1.3.10), but it looks like it may
not require ABI from GCC 9.2.1 (i.e. GLIBCXX_3.4.26, CXXABI_1.3.11) and thus
does not fail in this way. So this likely is currently only observable when
building GCC < 5 which does not have CXXABI_1.3.9 with GCC >= 5. However, this
could change in the future if the host executables e.g. cc1{,plus}, lto1 ever
use features which change ABI.
Is it possible to verify that this is an issue on a theoretical level? When I
mentioned the issue on IRC, there was uncertainty as to how this situtation
would arise because it was suspected that the stage1 host programs already used
the build libstdc++. However, I do not believe this is the case because the
current Makefile adds at all stages the target libstdc++ to LD_LIBRARY_PATH and
thus ends up using the target libstdc++ (after it has been built) during stage1
target modules section, despite the fact that the stage1 host programs depend
on the build libstdc++. The above patches try to fix this.
Is there any additional information I can provide to help confirm or refute
this issue?
[1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1040355/
[2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1040368/
[Bug libstdc++/87858] New: Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 Bug ID: 87858 Summary: Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mkrupcale at matthewkrupcale dot com Target Milestone: --- Created attachment 44944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44944&action=edit Makefile.tpl patch portion which allowed me to build GCC 4.8.3 using GCC 8.1 This is related to building multilib bootstrap GCC version 4.8.3 using GCC 8.1. Particularly, the stage1 host module cc1plus would fail to load libstdc++ after building the target 64-bit libstdc++ because this was placed in LD_LIBRARY_PATH, but stage1 cc1plus depends on the newer build libstdc++, and the older target libstdc++ does not provide the required version definitions. I suspect this issue is not specific to these versions or even to building old GCC with new GCC because the stage1 host modules will always depend on the build libstdc++ and therefore should not try to use the target libstdc++ built during stage1. Attached are two patches: 1) gcc48-stage1-build-libstdc++.patch: Makefile.tpl patch portion which allowed me to build GCC 4.8.3 using GCC 8.1 2) gcc82-stage1-build-libstdc++.patch: analogous patch for GCC 8.2 potentially allowing future GCC to build GCC 8.2 (untested). What they do is add the target libstdc++ to the target exports LD_LIBRARY_PATH only after stage1. Additional information / mailing list patches: [1] https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00176.html [2] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01978.html
[Bug libstdc++/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 --- Comment #1 from Matthew Krupcale --- Created attachment 44945 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44945&action=edit analogous patch for GCC 8.2 potentially allowing future GCC to build GCC 8.2 (untested)
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 --- Comment #3 from Matthew Krupcale --- I now observe this failure in the following two circumstances building multilib bootstrap GCC: - GCC 4.8.3 using GCC 10.2.1-9 on Fedora 33[1] /builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/xgcc -shared-libgcc -B/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc -nostdinc++ -L/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src -L/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src/.libs -B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem /usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include -m32 -x c++-header -nostdinc++ -O2 -g -grecord-gcc-switches -Wformat -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE -m32 -I/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include/x86_64-redhat-linux -I/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include -I/builddir/build/BUILD/gcc-4.8.3-20140911/libstdc++-v3/libsupc++ -O2 -g /builddir/build/BUILD/gcc-4.8.3-20140911/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-redhat-linux/bits/stdc++.h.gch/O2g.gch /builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/cc1plus: /builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/src/.libs/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/cc1plus) - GCC 8.2.1 using GCC 11.0.0-0.7 on Fedora 34[2] /builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/xgcc -shared-libgcc -B/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc -nostdinc++ -L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src -L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src/.libs -L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem /usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include -m32 -x c++-header -nostdinc++ -O2 -g -grecord-gcc-switches -Wformat -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -m32 -I/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include/x86_64-redhat-linux -I/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include -I/builddir/build/BUILD/gcc-8.2.1-20181215/libstdc++-v3/libsupc++ -O2 -g /builddir/build/BUILD/gcc-8.2.1-20181215/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-redhat-linux/bits/stdc++.h.gch/O2g.gch /builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/cc1plus: /builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/cc1plus) Furthermore, the build is successful when applying the aforementioned patches to their respective versions: - patched GCC 4.8.3 using GCC 10.2.1-9 on Fedora 33[3] - patched GCC 8.2.1 using GCC 11.0.0-0.7 on Fedora 34[4] Thus, I can validate my remarks in comment 0 and comment 2 that this does not only apply to GCC 4.8.3 but also to other (future) versions of GCC. In particular, I have now successfully tested the GCC 8.2 patch of comment 1. It took some time to demonstrate this because, for example, building unpatched GCC 8.2.1 is successful on F33 with GCC 10.2.1-9[2] but fails in this way on F34 with GCC 11.0.0-0.7[2]. As far as I can tell, this issue still applies to the latest GCC. That is, stage1 host modules attempt to use the stage1 target libstdc++ when they should instead use the build libstdc++. [1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1843629/ [2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/1843814/ [3] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1843525/ [4] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/1843815/
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 --- Comment #6 from Matthew Krupcale --- (In reply to Andrew Pinski from comment #5) > Best way to support this really is to build a 4.8 cross compiler and then > build a canandian cross GCC 4.8 and then bootstrap a 4.8.x using that newly > build canandian cross compiler. I'm not sure I follow exactly because I wasn't trying to build a cross compiler, although I suppose once you have a GCC 4.8 compiler built (cross or not), you wouldn't have a problem building 4.8.x with it in theory. But the problem is building that initial GCC 4.8 (cross or not) with the newer GCC version. > New enough GCC uses -static-libstdc++ and that avoids the shared library > problem mentioned here. This won't help during stage1 of the bootstrap build if you don't have the static libstdc++ library installed on the build host. Once the static libstdc++ library is built, this problem won't happen during the later stages. For stage1, however, GCC will currently attempt to use the build host libstdc++ and its newer symbols for building host executables. When the old libstdc++ is built then--and in the absence of a static libstdc++ on the build host--the host executables will fail to load due to the old libstdc++ being on LD_LIBRARY_PATH and lacking the newer symbols required by the host executables. Note that as far as I'm aware, this issue still exists in modern versions of GCC and is not exclusive to building only GCC 4.8. As shown by comment 3 and comment 4, this problem is demonstrable by building GCC v8.2.1 or v10 with GCC 11 and possibly other versions. I was also able to confirm in comment 3 that my patch for GCC 8.2 did resolve the issue when building with GCC 11.
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 --- Comment #8 from Matthew Krupcale --- (In reply to Andrew Pinski from comment #7) > You misunderstood. Building a cross compiler and a canadian cross is so the > new 4.8 compiler is NOT exposing to the bootstrap issue you mentioned. Fair enough, that seems likely to work as well. But you still need to build that initial compiler with the newer compiler. > 4.8 and 8.x are no longer maintained so fixing those are out of the question. I'm not suggesting to patch 4.8 or 8.x series. I'm suggesting that the issue still likely exists on the latest GCC. Of course you won't be able to verify that unless you intentionally create some new ABI in libstdc++ which is also used by the host programs and then try to build the old ABI libstdc++ with the the new one on the build host. That's why it took so long to verify that GCC 8 had the issue (as well as all versions between 4.8 and 8) and is likely still in the latest version. > stage1 of gcc does not require the LD_LIBRARY_PATH to be set at all I may be using the wrong name--perhaps it's not LD_LIBRARY_PATH specifically, but the effect is similar. My patch actually modifies the RPATH_ENVVAR to not include the target libstdc++ path during stage1 of the bootstrap since the stage1 host binaries depend on the build host libstdc++. Then in stages 2 and 3 the RPATH_ENVVAR can include the target libstdc++ path and build successfully.
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 --- Comment #10 from Matthew Krupcale --- Created attachment 55186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55186&action=edit GCC 7 post stage1 libstdc++ path export patch This patch is for GCC 7 and exports the target libstdc++ path on LD_LIBRARY_PATH only after stage1 for both host and target modules.
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 Matthew Krupcale changed: What|Removed |Added Attachment #44945|0 |1 is obsolete|| --- Comment #11 from Matthew Krupcale --- Created attachment 55187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55187&action=edit GCC 8 post stage1 libstdc++ path export patch This patch is for GCC 8 and exports the target libstdc++ path on LD_LIBRARY_PATH only after stage1 for both host and target modules.
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 --- Comment #12 from Matthew Krupcale --- I've updated the patch to include the target libstdc++ path on LD_LIBRARY_PATH only after stage1 for both host and target module exports--that is, previously, the patches only modified the LD_LIBRARY_PATH exports for target modules, whereas the new version does the same for host modules as well. This fixes an issue I found while building GCC 7 on RHEL 9 in which the gotools host module failed to build with similar ABI issues as described in this thread. See my copr repos [1,2] for both GCC 7 and 8 now both building with the respective patches on multiple OS (RHEL 9, Fedora 37, 38), architectures (aarch64, ppc64le, s390x, x86_64), and host GCC versions (11.3, 12.2, 13.0). (In reply to Libor Bukata from comment #4) > We also cannot build older GCC versions with GCC 11 nightly (commit > 8a6a62614a8ae) on Solaris Trunk: > ... > > GLIBCXX_3.4.29 is a new addition to libstdc++.so.6 that is not available in > older libstdc++.so.6 libraries of GCC 7, 9, and 10. Without the patches, I did also observe the issue Libor Bukata saw in comment #4 while building GCC 7 or 8 with GCC 11. (In reply to Ed Gar from comment #9) > I confirm that the issue persists even when using either patch suggested by > Matthew Krupcale. I was unable to reproduce your build issue with my patches. [1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-7/build/5787271/ [2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/5798225/
