[Bug c++/114275] New: using std::thread within a templated function in a module fails to compile

[Bug c++/114275] New: using std::thread within a templated function in a module fails to compile

[michael.kenzel at gmail dot com]

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

            Bug ID: 114275
           Summary: using std::thread within a templated function in a
                    module fails to compile
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: michael.kenzel at gmail dot com
  Target Milestone: ---

The following example will reproduce the issue:

        // A.ixx
        module;

        #include <thread>

        export module A;

        export void fun(auto&&)
        {
                std::thread([]{}).join();
        }

        // main.cpp
        import A;

        int main()
        {
                fun(42);
        }

build with

        g++ -std=c++23 -fmodules-ts -c -x c++ A.ixx
        g++ -std=c++23 -fmodules-ts main.cpp A.o

results in

        ‘
        /usr/include/c++/13/tuple:491: confused by earlier errors, bailing out

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
In file included from
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:39,
                 from
/home/apinski/upstream-gcc-match/include/c++/14.0.1/stop_token:40,
                 from
/home/apinski/upstream-gcc-match/include/c++/14.0.1/thread:42,
                 from A.ixx:4,
of module A, imported at main.cpp:2:
/home/apinski/upstream-gcc-match/include/c++/14.0.1/tuple: In instantiation of
‘struct std::_Tuple_impl@A<0, fun@A<int>(int&&)::<lambda()> >’:
/home/apinski/upstream-gcc-match/include/c++/14.0.1/tuple:834:11:   required
from ‘class std::tuple@A<fun@A<int>(int&&)::<lambda()> >’
  834 |     class tuple : public _Tuple_impl<0, _Elements...>
      |           ^~~~~
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:280:9:  
required from ‘struct
std::thread@A::_Invoker<std::tuple@A<fun@A<int>(int&&)::<lambda()> > >’
  280 |         _Tuple _M_t;
      |                ^~~~
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:236:13:  
required from ‘struct
std::thread@A::_State_impl<std::thread@A::_Invoker<std::tuple@A<fun@A<int>(int&&)::<lambda()>
> > >’
  236 |         _Callable               _M_func;
      |                                 ^~~~~~~
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:164:29:  
required from ‘std::thread@A::thread(_Callable&&, _Args&& ...) [with _Callable
= fun@A<int>(int&&)::<lambda()>; _Args = {}; <template-parameter-1-3> = void]’
  164 |         _M_start_thread(_State_ptr(new _State_impl<_Wrapper>(
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
  165 |               std::forward<_Callable>(__f),
std::forward<_Args>(__args)...)),
      |              
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A.ixx:10:8:   required from ‘void fun@A(auto:38&&) [with auto:38 = int]’
   10 |                 std::thread([]{}).join();
      |                      ^~~~~~~~~~~~
main.cpp:6:6:   required from here
    6 |                 fun(42);
      |                 ~~~^~~~
/home/apinski/upstream-gcc-match/include/c++/14.0.1/tuple:551:51: error:
conflicting declaration of template ‘template<long unsigned int <anonymous>,
class ...> struct std::_Tuple_impl’
  551 |       template<size_t, typename...> friend struct _Tuple_impl;
      |                                                   ^~~~~~~~~~~

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[nshead at gcc dot gnu.org]

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

Nathaniel Shead <nshead at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |nshead at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-03-08

--- Comment #2 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
Minimised:


// m.cpp
module;

template <typename... _Elements> struct T;

template <typename H> struct T<H> {
  template <typename...> friend struct T;
};

export module M;
export template <typename=void> void fun() { T<int> t; }


// main.cpp
import M;

int main() { fun(); }

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
PR105320 seems similar.

Another maybe related testcase:

$ cat testcase.C
export module M;
template<class> struct A {
  template<class> friend struct B;
};
A<int> a;
template<class> struct B { };

$ cat testcase.C | g++ -fmodules-ts -x c++ -
<stdin>:6:27: error: cannot declare ‘struct B< <template-parameter-1-1> >’ in a
different module
<stdin>:3:34: note: declared here
<stdin>:1:8: warning: not writing module ‘M’ due to errors

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P2

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[nshead at gcc dot gnu.org]

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

--- Comment #4 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
I suspect there are a number of issues tied together here. Some of the things
I've discovered so far:

- 'tsubst_friend_class' calls 'lookup_name', which when called from a module
that doesn't export the class that was befriended fails to find it, and so it
substitutes in a new instance of that type (which then later fails
duplicate_decls).

- Instantiating an elaborated type specifier doesn't attach it to the module
the containing template was declared in.

- Sometimes it seems that the container of a MK_local_friend decl is not always
correctly streamed: in particular, in the comment 2 testcase the container
streamed is a complete type on write, but on read is not complete (TYPE_SIZE is
null) and so is not properly read on stream-in in the first place.

Additionally, it looks like you can hide some of the errors by making the
importer a named module, because on instantiation it only calls
'duplicate_decls' on names imported from a partition.

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Nathaniel Shead from comment #4)
> I suspect there are a number of issues tied together here. Some of the
> things I've discovered so far:
> 
> - 'tsubst_friend_class' calls 'lookup_name', which when called from a module
> that doesn't export the class that was befriended fails to find it, and so
> it substitutes in a new instance of that type (which then later fails
> duplicate_decls).
> 
> - Instantiating an elaborated type specifier doesn't attach it to the module
> the containing template was declared in.
Nathan's comments from the threads

https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603288.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611215.html

seem relevant here.
> 
> - Sometimes it seems that the container of a MK_local_friend decl is not
> always correctly streamed: in particular, in the comment 2 testcase the
> container streamed is a complete type on write, but on read is not complete
> (TYPE_SIZE is null) and so is not properly read on stream-in in the first
> place.
Interesting, it looks like the definition does eventually get streamed in but
only after streaming in the MK_local_friend decl.  MK_field decls seem to get
streamed in beforehand too.
> 
> Additionally, it looks like you can hide some of the errors by making the
> importer a named module, because on instantiation it only calls
> 'duplicate_decls' on names imported from a partition.

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathaniel Shead <nshead@gcc.gnu.org>:

https://gcc.gnu.org/g:b5f6a56940e70838a07e885de03a92e2bd64674a

commit r15-59-gb5f6a56940e70838a07e885de03a92e2bd64674a
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date:   Mon Apr 29 17:00:13 2024 +1000

    c++: Fix instantiation of imported temploid friends [PR114275]

    This patch fixes a number of issues with the handling of temploid friend
    declarations.

    The primary issue is that instantiations of friend declarations should
    attach the declaration to the same module as the befriending class, by
    [module.unit] p7.1 and [temp.friend] p2; this could be a different
    module from the current TU, and so needs special handling.

    The other main issue here is that we can't assume that just because name
    lookup didn't find a definition for a hidden class template, that it
    doesn't exist at all: it could be a non-exported entity that we've
    nevertheless streamed in from an imported module.  We need to ensure
    that when instantiating template friend classes that we return the same
    TEMPLATE_DECL that we got from our imports, otherwise we will get later
    issues with 'duplicate_decls' (rightfully) complaining that they're
    different when trying to merge.

    This doesn't appear necessary for function templates due to the existing
    name lookup handling already finding these hidden declarations.

            PR c++/105320
            PR c++/114275

    gcc/cp/ChangeLog:

            * cp-tree.h (propagate_defining_module): Declare.
            (lookup_imported_hidden_friend): Declare.
            * decl.cc (duplicate_decls): Also check if hidden decls can be
            redeclared in this module.
            * module.cc (imported_temploid_friends): New.
            (init_modules): Initialize it.
            (trees_out::decl_value): Write it; don't consider imported
            temploid friends as attached to a module.
            (trees_in::decl_value): Read it.
            (get_originating_module_decl): Follow the owning decl for an
            imported temploid friend.
            (propagate_defining_module): New.
            * name-lookup.cc (get_mergeable_namespace_binding): New.
            (lookup_imported_hidden_friend): New.
            * pt.cc (tsubst_friend_function): Propagate defining module for
            new friend functions.
            (tsubst_friend_class): Lookup imported hidden friends.  Check
            for valid module attachment of existing names.  Propagate
            defining module for new classes.

    gcc/testsuite/ChangeLog:

            * g++.dg/modules/tpl-friend-10_a.C: New test.
            * g++.dg/modules/tpl-friend-10_b.C: New test.
            * g++.dg/modules/tpl-friend-10_c.C: New test.
            * g++.dg/modules/tpl-friend-10_d.C: New test.
            * g++.dg/modules/tpl-friend-11_a.C: New test.
            * g++.dg/modules/tpl-friend-11_b.C: New test.
            * g++.dg/modules/tpl-friend-12_a.C: New test.
            * g++.dg/modules/tpl-friend-12_b.C: New test.
            * g++.dg/modules/tpl-friend-12_c.C: New test.
            * g++.dg/modules/tpl-friend-12_d.C: New test.
            * g++.dg/modules/tpl-friend-12_e.C: New test.
            * g++.dg/modules/tpl-friend-12_f.C: New test.
            * g++.dg/modules/tpl-friend-13_a.C: New test.
            * g++.dg/modules/tpl-friend-13_b.C: New test.
            * g++.dg/modules/tpl-friend-13_c.C: New test.
            * g++.dg/modules/tpl-friend-13_d.C: New test.
            * g++.dg/modules/tpl-friend-13_e.C: New test.
            * g++.dg/modules/tpl-friend-13_f.C: New test.
            * g++.dg/modules/tpl-friend-13_g.C: New test.
            * g++.dg/modules/tpl-friend-14_a.C: New test.
            * g++.dg/modules/tpl-friend-14_b.C: New test.
            * g++.dg/modules/tpl-friend-14_c.C: New test.
            * g++.dg/modules/tpl-friend-14_d.C: New test.
            * g++.dg/modules/tpl-friend-9.C: New test.

    Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
    Reviewed-by: Jason Merrill <jason@redhat.com>

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[nshead at gcc dot gnu.org]

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

Nathaniel Shead <nshead at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |nshead at gcc dot gnu.org
   Target Milestone|---                         |14.2

--- Comment #7 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
Fixed for GCC 15 for now.

Will backport later to GCC 14.2 with adjustments requested by Jason here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650204.html

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #8 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to GCC Commits from comment #6)
> The master branch has been updated by Nathaniel Shead <nshead@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:b5f6a56940e70838a07e885de03a92e2bd64674a
> 
> commit r15-59-gb5f6a56940e70838a07e885de03a92e2bd64674a
> Author: Nathaniel Shead <nathanieloshead@gmail.com>
> Date:   Mon Apr 29 17:00:13 2024 +1000
> 
>     c++: Fix instantiation of imported temploid friends [PR114275]
>     
>     This patch fixes a number of issues with the handling of temploid friend
>     declarations.
>     
>     The primary issue is that instantiations of friend declarations should
>     attach the declaration to the same module as the befriending class, by
>     [module.unit] p7.1 and [temp.friend] p2; this could be a different
>     module from the current TU, and so needs special handling.
>     
>     The other main issue here is that we can't assume that just because name
>     lookup didn't find a definition for a hidden class template, that it
>     doesn't exist at all: it could be a non-exported entity that we've
>     nevertheless streamed in from an imported module.  We need to ensure
>     that when instantiating template friend classes that we return the same
>     TEMPLATE_DECL that we got from our imports, otherwise we will get later
>     issues with 'duplicate_decls' (rightfully) complaining that they're
>     different when trying to merge.
>     
>     This doesn't appear necessary for function templates due to the existing
>     name lookup handling already finding these hidden declarations.
>     
>             PR c++/105320
>             PR c++/114275
>     
>     gcc/cp/ChangeLog:
>     
>             * cp-tree.h (propagate_defining_module): Declare.
>             (lookup_imported_hidden_friend): Declare.
>             * decl.cc (duplicate_decls): Also check if hidden decls can be
>             redeclared in this module.
>             * module.cc (imported_temploid_friends): New.
>             (init_modules): Initialize it.
>             (trees_out::decl_value): Write it; don't consider imported
>             temploid friends as attached to a module.
>             (trees_in::decl_value): Read it.
>             (get_originating_module_decl): Follow the owning decl for an
>             imported temploid friend.
>             (propagate_defining_module): New.
>             * name-lookup.cc (get_mergeable_namespace_binding): New.
>             (lookup_imported_hidden_friend): New.
>             * pt.cc (tsubst_friend_function): Propagate defining module for
>             new friend functions.
>             (tsubst_friend_class): Lookup imported hidden friends.  Check
>             for valid module attachment of existing names.  Propagate
>             defining module for new classes.
>     
>     gcc/testsuite/ChangeLog:
>     
>             * g++.dg/modules/tpl-friend-10_a.C: New test.
>             * g++.dg/modules/tpl-friend-10_b.C: New test.
>             * g++.dg/modules/tpl-friend-10_c.C: New test.
>             * g++.dg/modules/tpl-friend-10_d.C: New test.
>             * g++.dg/modules/tpl-friend-11_a.C: New test.
>             * g++.dg/modules/tpl-friend-11_b.C: New test.
>             * g++.dg/modules/tpl-friend-12_a.C: New test.
>             * g++.dg/modules/tpl-friend-12_b.C: New test.
>             * g++.dg/modules/tpl-friend-12_c.C: New test.
>             * g++.dg/modules/tpl-friend-12_d.C: New test.
>             * g++.dg/modules/tpl-friend-12_e.C: New test.
>             * g++.dg/modules/tpl-friend-12_f.C: New test.
>             * g++.dg/modules/tpl-friend-13_a.C: New test.
>             * g++.dg/modules/tpl-friend-13_b.C: New test.
>             * g++.dg/modules/tpl-friend-13_c.C: New test.
>             * g++.dg/modules/tpl-friend-13_d.C: New test.
>             * g++.dg/modules/tpl-friend-13_e.C: New test.
>             * g++.dg/modules/tpl-friend-13_f.C: New test.
>             * g++.dg/modules/tpl-friend-13_g.C: New test.
>             * g++.dg/modules/tpl-friend-14_a.C: New test.
>             * g++.dg/modules/tpl-friend-14_b.C: New test.
>             * g++.dg/modules/tpl-friend-14_c.C: New test.
>             * g++.dg/modules/tpl-friend-14_d.C: New test.
>             * g++.dg/modules/tpl-friend-9.C: New test.
>     
>     Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
>     Reviewed-by: Jason Merrill <jason@redhat.com>

This has triggered some regression on aarch64 [1]:

Running g++:g++.dg/modules/modules.exp ...
FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17  (test for errors, line 16)
FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17  (test for errors, line 19)
FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (internal compiler error: in
set_originating_module, at cp/module.cc:19236)
FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for excess errors)

https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-build/1092/artifact/artifacts/notify/mail-body.txt/*view*/

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Adhemerval Zanella from comment #8)
> This has triggered some regression on aarch64 [1]:
> 
> Running g++:g++.dg/modules/modules.exp ...
> FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17  (test for errors, line 16)
> FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17  (test for errors, line 19)
> FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (internal compiler error:
> in set_originating_module, at cp/module.cc:19236)
> FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for excess errors)
> 
> https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-build/
> 1092/artifact/artifacts/notify/mail-body.txt/*view*/

Yes this is known already see thread starting at
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650315.html . I think there
was a new patch submitted already too.

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathaniel Shead <nshead@gcc.gnu.org>:

https://gcc.gnu.org/g:ec2365e07537e8b17745d75c28a2b45bf33be119

commit r15-220-gec2365e07537e8b17745d75c28a2b45bf33be119
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date:   Fri May 3 19:36:17 2024 +1000

    c++/modules: Fix dangling pointer with imported_temploid_friends

    I got notified by Linaro CI and by checking testresults that there seems
    to be some occasional failures in tpl-friend-4_b.C on some architectures
    and standards modes since r15-59-gb5f6a56940e708.  I haven't been able
    to reproduce but looking at the backtrace I suspect the issue is that
    we're adding to the 'imported_temploid_friend' map a decl that is
    ultimately discarded, which then has its address reused by a later decl
    causing a failure in the assert in 'set_originating_module'.

    This patch fixes the problem by ensuring 'imported_temploid_friends' is
    correctly marked as a GTY root, and that 'duplicate_decls' properly
    removes entries from the map for declarations that it frees.

            PR c++/114275

    gcc/cp/ChangeLog:

            * cp-tree.h (remove_defining_module): Declare.
            * decl.cc (duplicate_decls): Call remove_defining_module on
            to-be-freed newdecl.
            * module.cc (imported_temploid_friends): Mark as GTY root...
            (init_modules): ...and allocate from ggc.
            (trees_in::decl_value): Only track for declarations that won't
            be discarded.
            (remove_defining_module): New function.

    Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
    Reviewed-by: Jason Merrill <jason@redhat.com>
    Reviewed-by: Patrick Palka <ppalka@redhat.com>