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: Ian Lance Taylor <iant at google dot com>
- To: Sriraman Tallam <tmsriram at google dot com>
- Cc: Cary Coutant <ccoutant at gmail dot com>, Xinliang David Li <davidxl at google 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:23:41 -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>
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