This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Two level comdat priorities in gold
- From: Sriraman Tallam <tmsriram at google dot com>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Ian Lance Taylor <iant at google 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:44:56 -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> <CAJimCsFBJ_bABfL4L+D4+YwK05seiFmsMK7-6F=Fa77+RzU57g at mail dot gmail dot com>
On Thu, Jul 23, 2015 at 10:34 AM, Cary Coutant <email@example.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
> 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
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.