This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Two level comdat priorities in gold

We should clearly forbid obvious ODR violations like this.


On Thu, Jul 23, 2015 at 10:23 AM, Ian Lance Taylor <> wrote:
> On Thu, Jul 23, 2015 at 10:09 AM, Sriraman Tallam <> wrote:
>> On Thu, Jul 23, 2015 at 8:49 AM, Ian Lance Taylor <> wrote:
>>> On Thu, Jul 23, 2015 at 12:05 AM, Sriraman Tallam <> 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 :
>>> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]