https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2025-04-16
Status|RESOLVED |REOPENED
Resolution|DUPLICATE |---
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Keywords| |openacc
--- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> [...], there may be a problem with nvptx
> c++ support, but the alias issue seems to have been addresses, so I'm
> closing this one.
..., and then:
(In reply to myself from comment #6)
> This was implemented via PR104957 "[nvptx] Use .alias directive (available
> starting ptx isa version 6.3)".
>
> *** This bug has been marked as a duplicate of bug 104957 ***
I'm now setting this REOPENED, as (a) 'libgomp.c++/pr96390.C' is still XFAILed
for nvptx offloading, and (b) this PR is -- as far as I can tell -- the first
one to report the issue that...
(In reply to Tobias Burnus from comment #0)
> [for certain C++ code], GCC calls the "complete object constructor" C1:
> _ZN1VILi1EEC1ImvEET_
> but generates the function definition for "base object constructor" C2:
> _ZN1VILi1EEC2ImvEET_
>
> And it generates a weak alias between the two.
..., but the latter (alias) is missing for nvptx offloading compilation.
This was later re-reported in PR106445 "nvptx offloading: C++ constructor
symbol alias getting lost", and PR117010 "[nvptx] Incorrect ptx code-gen for
C++ code with templates", and possible others. (..., which I'll mark as
duplicate of or depending on this PR here, as applicable.)
> Using .alias should work – the aliasee should not be weak but I believe in
> our case only the alias itself is weak. – Hence, it should work.
..., but only due to "other lucky coincidences"; PR119833 "Clarify which
semantics offloading compilation does (not) inherit from using the LTO
infrastructure", so...
> I wonder whether this could be solved at LTO time – after all, except for
> linked libraries (libgomp, libm) it should be know.
... this is happening to a certain degree. ;-)
(Resolving aliases via LTO is another thought.)
