[PATCH] Two level comdat priorities in gold
Xinliang David Li
davidxl@google.com
Thu Jul 23 17:46:00 GMT 2015
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
More information about the Binutils
mailing list