Hi Jason! On 2025-03-20T11:59:07-0400, Jason Merrill <ja...@redhat.com> wrote: > On 3/20/25 11:35 AM, Thomas Schwinge wrote: >> Appears that I'm too dumb to implement >> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544#c22>: >> >> | We "simply" need to transform any symbol aliases into thunks calling the >> aliasee (or duplicate the bodies, if we must). >> >> ..., and implementing proper support for symbol aliases via the nvptx >> 'ld': <https://gcc.gnu.org/PR105018> "[nvptx] Need better alias support", >> won't be complete any time soon, but fortunately there's a way to handle >> the cases that we're concerned about here in an even simpler way, for >> reasonably modern configurations; any comments before I push the attached >> "nvptx: In offloading compilation, special-case certain host-setup symbol >> aliases [PR101544]"? >> In particular, is the use of a new 'c++ cdtor alias' attribute OK? > > Hmm, seems weird to use aliases in that one case but not others.
Yeah... The problem is the mismatch between host and offload target: the host of course typically is 'TARGET_SUPPORTS_ALIASES', but nvptx offloading typically is '!TARGET_SUPPORTS_ALIASES', because: > If > you're going to use aliases, why not just turn on alias support? We can't unconditionally enable GCC/nvptx' '-malias', because the support is incomplete, and if enabled, will cause GCC target library build failures, for example. > If aliases aren't supported, I think you want to fix can_alias_cdtor to > return false. We can't: we don't want to pessimize host code generation. Therefore, we have to handle this in the nvptx offloading flow. Grüße Thomas
