This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Two level comdat priorities in gold
- From: Xinliang David Li <davidxl at google dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Sriraman Tallam <tmsriram at google dot com>, Cary Coutant <ccoutant at gmail dot com>, binutils <binutils at sourceware dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Daniel Berlin <dannyb at google dot com>
- Date: Thu, 23 Jul 2015 10:46:55 -0700
- Subject: Re: [PATCH] Two level comdat priorities in gold
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8HmwHCWKf+Onx=ERLgLpk6276f+jhuW-WiKpvhz6QDxWQ2Q at mail dot gmail dot com> <CAKOQZ8wrnsj5UZx-trKXD+RBXS64TijHQPsJ1zwYeooZ5Kufsg at mail dot gmail dot com> <CAAkRFZLOacc874KkFD4iYuPk17qEMPLB5Sy4V57+UiCg0F48fA at mail dot gmail dot com> <CAKOQZ8ximo=B65dk2t6Ojwp_KEzWWr5zX6xpkR6_bVNMquJMcg at mail dot gmail dot com> <CAAkRFZ+OacKbu1iGGGXVEJu2OucOzObF8aMiLV0646e0JONdWw at mail dot gmail dot com> <CAAs8Hmyy2A8Ly-bXxVXu16pWcHkA71tmat747CGeF3aTGcJ9SQ at mail dot gmail dot com> <CAJimCsFkbsrOSRagS7aHEzxoLH_-8AF49yWS8S_Y11rV9YdsKQ at mail dot gmail dot com> <CAAs8HmyAkkA0+7jHd9HCDT-pHVDO7V446Z97CEFAJaRY+-M1aQ at mail dot gmail dot com> <CAKOQZ8xqOZ=UApsOWq5oSzDpRt_=nAOcPeYB+9CO6Foe4tvTzg at mail dot gmail dot com> <CAAs8Hmws26=3JudjXzxDNiNVDO2DV7tORG8afdVP4ZomorU_qg at mail dot gmail dot com> <CAKOQZ8w0v5hcL9myUQBj8fe6yN6_YEWKG-paPANwid3txvS6hA at mail dot gmail dot com>
We should clearly forbid obvious ODR violations like this.
David
On Thu, Jul 23, 2015 at 10:23 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Thu, Jul 23, 2015 at 10:09 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>> On Thu, Jul 23, 2015 at 8:49 AM, Ian Lance Taylor <iant@google.com> wrote:
>>> On Thu, Jul 23, 2015 at 12:05 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>>>>
>>>> 2) Cary's idea of simply not applying the extra -mxxx flags on
>>>> COMDATS, the out of line inlines and the instantiated template bodies.
>>>>
>>>> Unfortunately this idea does not work too for code like this:
>>>>
>>>> #ifdef __AVX__
>>>> inline foo () {
>>>> avx intrnsics
>>>> }
>>>> ...
>>>> #else
>>>> inline foo() {
>>>> non-avx intrinsics.
>>>> }
>>>> ...
>>>> #endif
>>>>
>>>> This means the AVX comdats are already there past the pre-processor
>>>> once we use -mavx and we cannot undo this in the compiler. Example
>>>> header : https://bitbucket.org/eigen/eigen/src/6ed647a644b8e3924800f0916a4ce4addf9e7739/Eigen/Core?at=default
>>>
>>>
>>> If you compile this code both with and without -mavx and link the
>>> results together, you have a simple, no excuses, ODR violation, so I
>>> don't find this example convincing.
>>
>> Agreed. It is clear there is a ODR violation but this usage is also
>> not uncommon. Unless multiple binaries, one for each target variant,
>> are built there is going to be a ODR violation with using such
>> headers. I was hoping for a mitigation mechanism.
>
> I think it's one thing to discuss some way to handle CPU-specific
> variants of code where there is no ODR violation. That's a real
> problem and I agree that some solution seems necessary.
>
> It is an entirely different thing to discuss ways to permit actual ODR
> violations. This example makes clear that your proposal is in fact a
> powerful mechanism to let people mix and match multiple copies of
> functions with the same name in the same binary, as long as those
> functions are inline. The language forbids this. It seems that the
> result can be very confusing. It's like an overload where the
> resolution of the overload depends not on any language rule but rather
> than the specific set of compilation options. Why should we permit
> this?
>
> Ian