On Wed, Sep 12, 2018 at 5:07 PM Jeff Law <l...@redhat.com> wrote: > > On 9/12/18 8:42 AM, Richard Biener wrote: > > On Wed, Sep 12, 2018 at 12:56 AM Jeff Law <l...@redhat.com> wrote: > >> > >> On 9/5/18 5:48 AM, a...@codesourcery.com wrote: > >>> > >>> The HSA GPU drivers can't cope with binaries that have the same symbol > >>> defined > >>> multiple times, even though the names are not exported. This happens > >>> whenever > >>> there are file-scope static variables with matching names. I believe > >>> it's also > >>> an issue with switch tables. > >>> > >>> This is a bug, but outside our control, so we must work around it when > >>> multiple > >>> translation units have the same symbol defined. > >>> > >>> Therefore, we've implemented name mangling via > >>> TARGET_MANGLE_DECL_ASSEMBLER_NAME, but found some places where the > >>> middle-end > >>> assumes that the decl name matches the name in the source. > >>> > >>> This patch fixes up those cases by falling back to comparing the unmangled > >>> name, when a lookup fails. > >>> > >>> 2018-09-05 Julian Brown <jul...@codesourcery.com> > >>> > >>> gcc/ > >>> * cgraphunit.c (handle_alias_pairs): Scan for aliases by DECL_NAME > >>> if > >>> decl assembler name doesn't match. > >>> > >>> gcc/c-family/ > >>> * c-pragma.c (maye_apply_pending_pragma_weaks): Scan for aliases > >>> with > >>> DECL_NAME if decl assembler name doesn't match. > >> This should be fine. But please verify there's no regressions on the > >> x86_64 linux target, particularly for the multi-versioning tests (mv*.c > >> mv*.C > > > > Err - the patch clearly introduces quadraticness into a path which > > isn't acceptable. > > get_for_asmname works through a hashtable. > But isn't this only being rused when we aren't able to find the symbol?
This case seems to happen though. > My impression was that should be rare, except for the GCN target. Still even for the GCN target it looks like a hack given the linear search. I think it is required to track down the "invalid" uses of DECL_NAME vs. "mangled" name instead. > > > > It also looks like !target can readily happen so I wonder what happens if an > > assembler name does not match but a DECL_NAME one does by accident? > > > > I fear you have to fix this one in a different way... (and I hope > > Honza agrees with me). > Honza certainly knows the code better than I. If he thinks there's a > performance issue and this needs to be resolved a better way, then I'll > go along with that. I think the symptom GCN sees needs to be better understood - like wheter it is generally OK to mangle things arbitrarily. Note that TARGET_MANGLE_DECL_ASSEMBLER_NAME might not be a general symbol mangling hook but may be restricted to symbols with specific visibility. Richard. > > Jeff
