On 3/20/25 12:48 PM, Thomas Schwinge wrote:
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.
Ah.
Can you use DECL_CXX_{CON,DE}STRUCTOR_P instead of a new attribute?
Jason
