[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-20 Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It's not possible. I meant to make it possible for GCC 8 (maybe even switch make the gnu-versioned-namespace *always* use the new ABI, with no option to use the old one).
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jonathan Wakely changed: What|Removed |Added Target Milestone|11.0|---
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.3 |9.4 --- Comment #4 from Jakub Jelinek --- GCC 9.3.0 has been released, adjusting target milestone.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.4 |11.0
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.2 |9.3 --- Comment #3 from Jakub Jelinek --- GCC 9.2 has been released.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jonathan Wakely changed: What|Removed |Added Target Milestone|8.0 |9.0
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #2 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jonathan Wakely changed: What|Removed |Added Keywords||patch Last reconfirmed|2017-11-20 00:00:00 |2023-08-10 --- Comment #5 from Jonathan Wakely --- New patch dropped: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626925.html
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #6 from Iain Sandoe --- is there a version available for testing, rebased to trunk (the one I saw from Aug 19th pretty much fails to apply for most entries)?
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #7 from François Dumont --- Sure, if you follow the email thread you'll see my latest patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628399.html
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #8 from Iain Sandoe --- (In reply to François Dumont from comment #7) > Sure, if you follow the email thread you'll see my latest patch: > > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628399.html Well, I thought I have the right one, but unfortunately, that no longer applies to trunk (or somehow I'm not getting the right attachment).
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #9 from Iain Sandoe --- (In reply to Iain Sandoe from comment #8) > (In reply to François Dumont from comment #7) > > Sure, if you follow the email thread you'll see my latest patch: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628399.html > > Well, I thought I have the right one, but unfortunately, that no longer > applies to trunk (or somehow I'm not getting the right attachment). OK. So hopefully, now I had the right version (which applied) I tried a configuration : --disable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new the build failed for me in stage 1 target build with : duplicate symbol 'typeinfo name for std::basic_ostringstream, std::allocator >' in: .libs/libstdc++.lax/libc++11convenience.a/cow-sstream-inst.o .libs/libstdc++.lax/libc++11convenience.a/sstream-inst.o duplicate symbol 'typeinfo for std::basic_stringbuf, std::allocator >' in: .libs/libstdc++.lax/libc++11convenience.a/cow-sstream-inst.o .libs/libstdc++.lax/libc++11convenience.a/sstream-inst.o ld: 16 duplicate symbols for architecture x86_64
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #10 from François Dumont --- This is because you are facing the PR65762 issue. I just attached a path proposal to it that you need to apply too to be able to run your test. You'll be even able to simply use --disable-libstdcxx-dual-abi cause I made cxx11 abi the default in this case.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #11 from Iain Sandoe --- (In reply to François Dumont from comment #10) > This is because you are facing the PR65762 issue. I just attached a path > proposal to it that you need to apply too to be able to run your test. > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I made > cxx11 abi the default in this case. Yes, with the second patch applied, that works for me also. Does gnu-versioned-namespace work for you with these two patches applied? (I have a patch to enable versioned namespace on Darwin, which is very similar to the GNU one, but it no longer builds)..
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #12 from Iain Sandoe --- (In reply to Iain Sandoe from comment #11) > (In reply to François Dumont from comment #10) > > This is because you are facing the PR65762 issue. I just attached a path > > proposal to it that you need to apply too to be able to run your test. > > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I made > > cxx11 abi the default in this case. > > Yes, with the second patch applied, that works for me also. > > Does gnu-versioned-namespace work for you with these two patches applied? > (I have a patch to enable versioned namespace on Darwin, which is very > similar to the GNU one, but it no longer builds).. FAOD, by which I mean "--enable-symvers=gnu-versioned-namespace" with no other configure options (which AFAICT disables dual ABI and enables the new one) ... I have more-or-less copied the gnu case for Darwin, but perhaps missed some case?
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #13 from Iain Sandoe --- (In reply to Iain Sandoe from comment #12) > (In reply to Iain Sandoe from comment #11) > > (In reply to François Dumont from comment #10) > > > This is because you are facing the PR65762 issue. I just attached a path > > > proposal to it that you need to apply too to be able to run your test. > > > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I > > > made > > > cxx11 abi the default in this case. > > > > Yes, with the second patch applied, that works for me also. > > > > Does gnu-versioned-namespace work for you with these two patches applied? > > (I have a patch to enable versioned namespace on Darwin, which is very > > similar to the GNU one, but it no longer builds).. It looks like this was a merge artefact, which I resolved and now it builds - I have some testsuite fails to examine.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #14 from François Dumont --- Good news then. On my side I only had some failures due to a faulty friend declaration in gnu-versioned-namespace mode in for which I've submitted a patch: https://gcc.gnu.org/pipermail/libstdc++/2023-August/056560.html
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077
--- Comment #15 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Iain Sandoe from comment #11)
> > > (In reply to François Dumont from comment #10)
> > > > This is because you are facing the PR65762 issue. I just attached a path
> > > > proposal to it that you need to apply too to be able to run your test.
> > > > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I
> > > > made
> > > > cxx11 abi the default in this case.
> It looks like this was a merge artefact, which I resolved and now it builds
> - I have some testsuite fails to examine.
With both patches applied (on top of trunk from yesterday) on both Linux and
Darwin I am seeing regressions in the C++ and libstdc++ test suites. For the
darwin case, I could perhaps have another merge error - but the Linux case has
only your two patches and configured with
--enable-symvers=gnu-versioned-namespace (only).
---
many of the libstdc++ fails are of this form:
/home/iains/gcc-master/bld-patched/x86_64-pc-linux-gnu/32/libstdc++-v3/include/format:3519:
error: 'std::__format::_Arg_store<_Context, _Args>::_Arg_store(_Tp& ...) [with
_Tp = {const std::chrono::time_point > >}; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}]' is private within this context
many of the c++ fails are of this form:
contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to
`handle_contract_violation(std::experimental::contract_violation const&)'
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #16 from Iain Sandoe --- (In reply to François Dumont from comment #14) > Good news then. > > On my side I only had some failures due to a faulty friend declaration in > gnu-versioned-namespace mode in for which I've submitted a patch: > https://gcc.gnu.org/pipermail/libstdc++/2023-August/056560.html Ah so probably that covers most of the libstdc++ cases - they do seem to be format-related.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #17 from François Dumont --- (In reply to Iain Sandoe from comment #15) > > many of the c++ fails are of this form: > > contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to > `handle_contract_violation(std::experimental::contract_violation const&)' I'm surprised that my patch can have an impact on the C++ front end but I'll give it a try. Did you first run those without my patches ? I've never run the C++ tests. They can be run without a proper libstdc++ build, no ?
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #18 from Iain Sandoe --- for changes to libstdc++ or the FE I usually run "make check-c++" which does the library (plus the libgomp and itm deps) and the FE. My guess is that the FE is referencing something that needs to have an inline namespace added. There are also some failing coroutine tests (because their scan strings need to account for the inline namespace - I have a WIP patch for that, it's just tedious editing of pattern matches).
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #19 from Iain Sandoe --- (In reply to François Dumont from comment #17) > (In reply to Iain Sandoe from comment #15) Your proposed patch for the friend issue does fix the libstdc++ cases for my Darwin patchset. > > many of the c++ fails are of this form: > > > > contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to > > `handle_contract_violation(std::experimental::contract_violation const&)' > > I'm surprised that my patch can have an impact on the C++ front end but I'll > give it a try. I do not think it's affecting the FE as such - but rather that some of the tests include stdc++ headers (I try to avoid it in the testsuite, but obviously things like coroutines cannot avoid it)
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #20 from François Dumont --- I run make check-c++ before and after my patch and I see no regression. I even have less failures with the patch even if I haven't check yet why. So I think the patch is quite safe, just waiting for validation now.
