Re: [PATCH] Two level comdat priorities in gold

[Sriraman Tallam <tmsriram at google dot com>]

On Thu, Jul 23, 2015 at 10:34 AM, Cary Coutant <ccoutant@gmail.com> wrote:
>> 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?
>
> If the compiler does drop down out-of-line instances of both
> declarations, gold's --detect-odr-violations option should catch it.
> Why should we permit it, especially when we know it can lead to a link
> error as is?
>
> I suggested that both should be declared static, but perhaps only the
> AVX-optimized version needs to be static. That would allow the generic
> version to be COMDAT'ed if necessary, avoiding too much code
> duplication.

Nice, this seems similar to localization of the functions  except that
always inlining it means there is no issue with exposing the pointer
of the specialized comdats.  It is not clear to me if this would work
for virtual comdat functions. Looks like there could be an unsat?  I
could work around this by forcing the unspecialized modules to always
generate a copy of the virtual comdat function.

I can either change the headers to use "always_inline" and/or static
or if that is not possible something like -falways-inline-comdats that
only applies to the AVX module in my example.

Thanks
Sri

>
> -cary