This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC version bikeshedding
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, Eric Botcazou <ebotcazou at libertysurf dot fr>, Ian Lance Taylor <iant at google dot com>, Jason Merrill <jason at redhat dot com>
- Date: Wed, 6 Aug 2014 12:57:54 +0200
- Subject: Re: GCC version bikeshedding
- Authentication-results: sourceware.org; auth=none
- References: <201408060925 dot 48414 dot ebotcazou at libertysurf dot fr> <20140806074223 dot GY7393 at tucnak dot redhat dot com> <CAFiYyc1+LTfbPF=nT3O4pA4ST6Z2X5FJ0ywMxL9bk3UsqwnV2w at mail dot gmail dot com> <20140806084803 dot GB7393 at tucnak dot redhat dot com> <CAFiYyc0+YgrRA-CheSFx5not6XadTWOa-mr_LWpX4sZ_gQMgdg at mail dot gmail dot com> <20140806090635 dot GD7393 at tucnak dot redhat dot com> <CAH6eHdSkX-kvXTN8ysKh38dWy1nUeQMnX6nGSm+sOdbSm7z1cw at mail dot gmail dot com> <CAFiYyc3fxDDX9TZeySaF8vMZqwb3ipwQs-vCmiOHK3Vdwe7uUg at mail dot gmail dot com> <CAH6eHdQtB4kNpvBWtFY0Eqyxi4JekEeLYw3Sc2RzO-qOcdeDkg at mail dot gmail dot com> <CAFiYyc0cxwM478wn54-V8Au4yX7MSmobsmk4Qc_Mjk3efogU+g at mail dot gmail dot com> <20140806103641 dot GG7393 at tucnak dot redhat dot com> <alpine dot DEB dot 2 dot 11 dot 1408061242170 dot 30821 at stedding dot saclay dot inria dot fr>
On Wed, Aug 6, 2014 at 12:50 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Wed, 6 Aug 2014, Jakub Jelinek wrote:
>
>> On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
>>>
>>> Ok, so the problematical case is
>>>
>>> struct X { std::string s; };
>>> void foo (X&);
>>
>>
>> Yeah.
>>
>>> then. OTOH I remember that then mangling of X changes as well?
>>
>>
>> Only if you add abi_tag attribute to X.
>
>
> Note that -Wabi-tag can tell you where it is needed.
>
> struct __attribute__((abi_tag("marc"))) X {};
> struct Y { X x; };
>
> a.cc:2:8: warning: 'Y' does not have the "marc" abi tag that 'X' (used in
> the type of 'Y::x') has [-Wabi-tag]
> struct Y { X x; };
> ^
> a.cc:2:14: note: 'Y::x' declared here
> struct Y { X x; };
> ^
> a.cc:1:41: note: 'X' declared here
> struct __attribute__((abi_tag("marc"))) X {};
>
> ^
>
>> I hope the libstdc++ folks will add some macro which will
>> include the right abi_tag attribute for the std::list/std::string
>> cases, so you'd in the end just add
>> #ifndef _GLIBCXX_ABI_TAG_SOMETHING
>> #define _GLIBCXX_ABI_TAG_SOMETHING
>> #endif
>> ...
>> struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
>> void foo (X&);
>> or similar.
>
>
> So we only need to patch every project out there...
I wonder if the linker could not do the propagation for us ...
(ok, it needs to rewrite all symbols and typeinfos, etc., but
certainly doable, no?)
That said, if the public API merely has a forward declaration
class X;
and always passes that by reference the ABI doesn't change.
Of course it now _would_ change if you'd change the mangling
of X ...
abigail to the rescue?
>> A clean .so.7 break would be significantly worse nightmare. We've been
>> there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly
>> fewer C++ plugins etc. in packages and it still it was unsolvable.
>> With the abi_tag stuff, you have the option to make stuff interoperable
>> when mixing compiler, either with no effort at all, or some limited
>> effort. With .so.7, you have no option, nothing will be interoperable.
>
>
> I disagree that it is worse, but you have more experience, I guess we
> will see the results in a few years...
Indeed.
Richard.
> --
> Marc Glisse