[Bug target/112858] New: nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[Bug target/112858] New: nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

            Bug ID: 112858
           Summary: nvptx: 'unresolved symbol __cxa_thread_atexit_impl'
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: testsuite-fail
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: vries at gcc dot gnu.org
  Target Milestone: ---

With commit r14-6082-gf4dd9416843308d4ae519983415fe62212662536 "libsupc++: try
cxa_thread_atexit_impl at runtime", there's one regression in nvptx target
testing (only visible on top of my WIP C++ enablement changes):

    [-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++14 (test for excess
errors)
    [-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++14 [-execution
test-]{+compilation failed to produce executable+}
    [-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++17 (test for excess
errors)
    [-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++17 [-execution
test-]{+compilation failed to produce executable+}
    [-PASS:-]{+FAIL:+} g++.dg/tls/thread_local6.C  -std=c++20 (test for excess
errors)
    [-PASS:-]{+UNRESOLVED:+} g++.dg/tls/thread_local6.C  -std=c++20 [-execution
test-]{+compilation failed to produce executable+}
    UNSUPPORTED: g++.dg/tls/thread_local6.C  -std=c++98

    unresolved symbol __cxa_thread_atexit_impl
    collect2: error: ld returned 1 exit status

Very likely, this isn't an issue with that commit, but rather due to GCC/nvptx'
deficient implementation of weak symbols.

[Bug target/112858] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Indeed in 'build-gcc/nvptx-none/libstdc++-v3/libsupc++/atexit_thread.o' I see:

    // BEGIN GLOBAL FUNCTION DECL: __cxa_thread_atexit_impl
    .extern .func (.param .u32 %value_out) __cxa_thread_atexit_impl (.param
.u64 %in_ar0, .param .u64 %in_ar1, .param .u64 %in_ar2);

That is, '.extern' instead of '.weak' linking directive, huh.

..., but still doing the NULL check:

    [...]
    .reg .u64 %r29;
    .reg .pred %r30;
    [...]
    mov.u64 %r29,__cxa_thread_atexit_impl;
    setp.eq.u64 %r30,%r29,0;
    @ %r30 bra $L9;
    .loc 2 156 37
    {
    .param .u32 %value_in;
    .param .u64 %out_arg1;
    st.param.u64 [%out_arg1],%r26;
    .param .u64 %out_arg2;
    st.param.u64 [%out_arg2],%r27;
    .param .u64 %out_arg3;
    st.param.u64 [%out_arg3],%r28;
    call (%value_in),__cxa_thread_atexit_impl,(%out_arg1,%out_arg2,%out_arg3);
    ld.param.u32 %r34,[%value_in];
    }
    mov.u32 %r25,%r34;
    .loc 2 156 59
    bra $L8;
    $L9:
    [...]

[Bug target/112858] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Earlier in 'libstdc++-v3/libsupc++/atexit_thread.cc', we have:

    [...]
    #if _GLIBCXX_HAVE___CXA_THREAD_ATEXIT

    // Libc provides __cxa_thread_atexit definition.

    #elif _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL

    extern "C" int __cxa_thread_atexit_impl (void (_GLIBCXX_CDTOR_CALLABI
*func) (void *),
                                             void *arg, void *d);
    extern "C" int
    __cxxabiv1::__cxa_thread_atexit (void (_GLIBCXX_CDTOR_CALLABI *dtor)(void
*),
                                     void *obj, void *dso_handle)
      _GLIBCXX_NOTHROW
    {
      return __cxa_thread_atexit_impl (dtor, obj, dso_handle);
    }

    #else /* _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL */
    [...]

..., that is, indeed a non-weak '__cxa_thread_atexit_impl' declaration --
however, that's active only if not '_GLIBCXX_HAVE___CXA_THREAD_ATEXIT' and not
'_GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL', but we have per
'include/nvptx-none/bits/c++config.h':

    /* Define to 1 if you have the `__cxa_thread_atexit' function. */
    /* #undef _GLIBCXX_HAVE___CXA_THREAD_ATEXIT */

    /* Define to 1 if you have the `__cxa_thread_atexit_impl' function. */
    /* #undef _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL */

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |libstdc++
   Target Milestone|---                         |14.0
            Summary|nvptx: 'unresolved symbol   |[14 Regression] nvptx:
                   |__cxa_thread_atexit_impl'   |'unresolved symbol
                   |                            |__cxa_thread_atexit_impl'

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
AIX was also reported as being broken by this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639416.html

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|nvptx                       |nvptx, powerpc-ibm-aix*
   Last reconfirmed|                            |2023-12-05
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |dje at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #4 from David Edelsohn <dje at gcc dot gnu.org> ---
Confirmed.

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

--- Comment #5 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(I did see that the '__cxa_thread_atexit_impl' issue has been resolved
differently, but there is a genuine GCC/nvptx issue here.)

(In reply to myself from comment #1)
> Indeed in 'build-gcc/nvptx-none/libstdc++-v3/libsupc++/atexit_thread.o' I
> see:
> 
>     // BEGIN GLOBAL FUNCTION DECL: __cxa_thread_atexit_impl
>     .extern .func (.param .u32 %value_out) __cxa_thread_atexit_impl (.param
> .u64 %in_ar0, .param .u64 %in_ar1, .param .u64 %in_ar2);
> 
> That is, '.extern' instead of '.weak' linking directive, huh.

That one indeed is a GCC/nvptx back end issue.  A fix might look similar to the
following:

    --- gcc/config/nvptx/nvptx.cc
    +++ gcc/config/nvptx/nvptx.cc
    @@ -1001,10 +1001,11 @@ write_fn_proto_1 (std::stringstream &s, bool
is_defn,
                      const char *name, const_tree decl, bool force_public)
     {
    -  if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)) == NULL)
    +  if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)) == NULL
    +      && !DECL_WEAK (decl))
         write_fn_marker (s, is_defn, TREE_PUBLIC (decl) || force_public,
name);

       /* PTX declaration.  */
       if (DECL_EXTERNAL (decl))
    -    s << ".extern ";
    +    s << (DECL_WEAK (decl) ? ".weak " : ".extern ");
       else if (TREE_PUBLIC (decl) || force_public)
         s << (DECL_WEAK (decl) ? ".weak " : ".visible ");

> ..., but still doing the NULL check: [...]

..., and that check ('if (__cxa_thread_atexit_impl)') then fails to assemble,
and thus the build (!) fails:

    ptxas fatal   : Cannot take address of function '__cxa_thread_atexit_impl' 

Thus, more smarts are needed to make "weak, undefined" work.  (May be able to
fix this up in the linker, assuming seeing the whole program; similar to
PR105018 "[nvptx] Need better alias support" ideas?)  (For reference, "weak,
defined" does not run into this problem.)

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Thanks for the report, sorry about the regressions.  The faulty patch was
reverted, another patch with this and other problems fixed will be pushed
shortly, once testing completes.  I am not, however, taking this PR because
this issue is pretty much resolved, and I understand there's another nvptx
issue with weakundef symbols yet to be resolved, so I'm leaving this PR for
that.

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alexandre Oliva <aoliva@gcc.gnu.org>:

https://gcc.gnu.org/g:3d0f3382fa7b5677f35a9becf75ac436cd7eda7b

commit r14-6261-g3d0f3382fa7b5677f35a9becf75ac436cd7eda7b
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Dec 7 00:38:14 2023 -0300

    libsupc++: try cxa_thread_atexit_impl at runtime

    g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
    a platform that lacks __cxa_thread_atexit_impl, even if the program is
    built and run using that toolchain on a (later) platform that offers
    __cxa_thread_atexit_impl.

    This patch adds runtime testing for __cxa_thread_atexit_impl on select
    platforms (GNU variants, for starters) that support weak symbols.


    for  libstdc++-v3/ChangeLog

            PR libstdc++/112858
            * config/os/gnu-linux/os_defines.h
            (_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL): Define.
            * libsupc++/atexit_thread.cc [__GXX_WEAK__ &&
            _GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL]
            (__cxa_thread_atexit): Add dynamic detection of
            __cxa_thread_atexit_impl.

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |aoliva at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Alexandre Oliva from comment #6)
> Thanks for the report, sorry about the regressions.  The faulty patch was
> reverted, another patch with this and other problems fixed will be pushed
> shortly, once testing completes.  I am not, however, taking this PR because

So unassigning.

> this issue is pretty much resolved, and I understand there's another nvptx
> issue with weakundef symbols yet to be resolved, so I'm leaving this PR for
> that.

Is that other issue a regression, or can we remove [14 Regression] from the
summary?

[Bug libstdc++/112858] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 Regression] nvptx:      |nvptx: 'unresolved symbol
                   |'unresolved symbol          |__cxa_thread_atexit_impl'
                   |__cxa_thread_atexit_impl'   |
   Target Milestone|14.0                        |---
           Assignee|aoliva at gcc dot gnu.org          |unassigned at gcc dot gnu.org

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm assuming it is not.