[Bug c++/115198] Class template argument deduction fails for copy ctor when used with an alias template if the aliased class template has explicitly defaulted copy ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115198 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Target Milestone|--- |14.2
[Bug c++/115159] internal compiler error: in nothrow_spec_p, at cp/except.cc:1206 when using modules and QCoreApplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115159 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Known to fail||14.1.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Known to work||15.0 --- Comment #5 from Patrick Palka --- Should be fixed on trunk now, sadly the fix isn't suitable for backporting.
[Bug c++/115139] [14 Regression] Enum inside variadic template class can't define one of self with usage another value from this enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115139 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug c++/115159] internal compiler error: in nothrow_spec_p, at cp/except.cc:1206 when using modules and QCoreApplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115159
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2024-05-19 00:00:00 |2024-05-21
Status|UNCONFIRMED |NEW
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
Confirmed, thanks for the reproducer.
Reduced:
$ cat 115159_a.H
struct QDebug;
template void f(T);
template struct QList {
QDebug operator<(QList ) noexcept(noexcept(f(other)));
QDebug operator>(QList ) noexcept(noexcept(f(other)));
};
struct QObjectData {
QList children;
};
struct QIODevice {
QObjectData d_ptr;
};
struct QDebug {
QDebug(QIODevice);
};
$ cat 115159_b.C
import "115159_a.H";
$ g++ -fno-module-lazy -fmodules-ts -std=c++20 115159_{a.H,b.C}
115159_b.C:1:22: internal compiler error: in nothrow_spec_p, at
cp/except.cc:1202
[Bug c++/115114] aggregate initialization with parens fails when there is a base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115114 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Target Milestone|--- |14.2 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug libstdc++/115126] TU-local entity exposures in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115126 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- For __is_unique_ptr, seems we could just remove it since it isn't actually used anywhere.
[Bug c++/115139] [14 Regression] Enum inside variadic template class can't define one of self with usage another value from this enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115139 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.2 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-05-17 Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Summary|Enum inside variadic|[14 Regression] Enum inside |template class can't define |variadic template class |one of self with usage |can't define one of self |another value from this |with usage another value |enum|from this enum CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed, started with r14-4796-g3e3d73ed5e85e7. Interestingly r15-123-gf04dc89a991ddc made us accept this testcase on trunk, so this is a 14 regression only.
[Bug c++/114850] co_await a async function which result type is std::unique_ptr<...> or shared_ptr in a initializer list causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- (In reply to Jeremy Pewterschmidt from comment #3) > This issue is no longer reproducible in GCC 14. > Should I mark this as `RESOLVED` ? Yes, the ICE disappeared after r14-8437-g44868e7298de50, so I reckon this is a dup of 109227. *** This bug has been marked as a duplicate of bug 109227 ***
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 Patrick Palka changed: What|Removed |Added CC||jeremypewterschmidt at gmail dot c ||om --- Comment #9 from Patrick Palka --- *** Bug 114850 has been marked as a duplicate of this bug. ***
[Bug c++/86933] GCC fails to recognize specialization of variadic non-type template parameter declared with `auto`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86933 Patrick Palka changed: What|Removed |Added CC||420 at zerberste dot es --- Comment #1 from Patrick Palka --- *** Bug 115079 has been marked as a duplicate of this bug. ***
[Bug c++/115079] unexpected error with partial specialization of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115079 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #1 from Patrick Palka --- dup of PR86933 I think *** This bug has been marked as a duplicate of bug 86933 ***
[Bug c++/115061] Compiling gcc failed when using clang 16.0.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115061 Patrick Palka changed: What|Removed |Added Target Milestone|--- |15.0 CC||ppalka at gcc dot gnu.org
[Bug c++/113332] [12/13 regression] checking ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|12.4|14.0 --- Comment #6 from Patrick Palka --- It doesn't seem worth backporitng this relatively risky patch just to fix a checking-only assertion failure that we otherwise gracefully handle.
[Bug c++/112658] [12/13 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112658 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|12.4|14.0 Status|ASSIGNED|RESOLVED --- Comment #9 from Patrick Palka --- Not backporting any of these fixes since this never properly worked -- it was either wrong-code, rejects-valid or (most recently) ice-on-valid -- and so not really a regression.
[Bug c++/114903] constraint of CTAD alias deduction guide is evaluated on a wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114903 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.2 CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Fixed for GCC 14.2
[Bug c++/114901] GCC internal_error on CTAD alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114901 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.2 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 14.2
[Bug c++/114974] CTAD; templated inner class of template class seems to be handled incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114974 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.2 Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Fixed for GCC 14.2, thanks for the reports.
[Bug c++/114990] Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #3 from Patrick Palka --- I reckon it's not something we can fix/implement in a point release of GCC 14, but hopefully for 15...
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Patrick Palka ---
A bit more reduced, demostrating it's not specific to UDLs:
struct udl_arg {
udl_arg operator=(int);
};
void g(udl_arg&&);
template
void h() {
udl_arg x;
g(x=42);
}
int main() {
h();
}
[Bug c++/114990] Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Depends on||99000
--- Comment #1 from Patrick Palka ---
After preprocessing, it seems Main.cpp basically boils down to:
import CompilerVersions; // #1
#include// #2
import TypeTraits; // #3
int main()
{
return 0;
}
The issue here seems to be the #include appearing after the
import of CompilerVersions which (indirectly) also includes (in
its GMF). GCC currently supports import-after-include GMF merging (so #2
followed by #3 is OK) not but include-after-import. See also
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html
So one workaround would be to arrange that all #includes come before imports
which might include the same thing. Another workaround would be to compile the
problematic headers ( in this case) as a header unit so that
#includes thereof implicitly translated into imports, via e.g.
g++ -fmodules-ts -x c++-system-header type_traits
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99000
[Bug 99000] [modules] merging of textual redefinitions: declaration
std::__copy_move_a2 conflicts with import
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 114889, which changed state. Bug 114889 Summary: [modules] ICE in friend_accessible_p with imported class template specialization befriending class template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/114889] [modules] ICE in friend_accessible_p with imported class template specialization befriending class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed for GCC 14.2
[Bug c++/99678] [concepts] requires-clause allows undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678
Patrick Palka changed:
What|Removed |Added
Summary|c++20 trailing requires |[concepts] requires-clause
|clauses allows undeclared |allows undeclared
|identifier |identifier
CC||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
>From PR114946:
(In reply to Nathaniel Shead from comment #0)
> The following sample compiles fine with 'g++ -std=c++20 -pedantic-errors':
>
> template
> requires
> struct S {};
>
> template
> requires
> void foo() {}
>
> Note that '' has not been declared or defined. Both MSVC and Clang
> complain about the undeclared identifier. GCC does error if we attempt to
> instantiate either of these specialisations, but they always (silently) lose
> to a better match:
>
> template struct S {};
> template requires struct S {};
>
> template void foo() {}
> template requires void foo() {}
>
> int main() {
> S x;
> foo();
> }
[Bug c++/99678] c++20 trailing requires clauses allows undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678 Patrick Palka changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #1 from Patrick Palka --- *** Bug 114946 has been marked as a duplicate of this bug. ***
[Bug c++/114946] [concepts] No error for invalid requires constraint in declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114946 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 99678 ***
[Bug c++/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=110802|a/show_bug.cgi?id=110822 --- Comment #8 from Patrick Palka --- PR110822 rather seems closely related if not a dup.
[Bug c++/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110802 CC||ppalka at gcc dot gnu.org --- Comment #7 from Patrick Palka --- PR110802
[Bug c++/113141] [13 Regression] ICE on conversion to reference in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Patrick Palka --- Fixed for 13.3/14.
[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
--- Comment #7 from Patrick Palka ---
The following seems to minimally fix it:
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index c35e70b8cb8..57ccaec5ebd 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -6798,7 +6798,7 @@ trees_in::core_vals (tree t)
body) anyway. */
decl = maybe_duplicate (decl);
- if (!DECL_P (decl) || DECL_CHAIN (decl))
+ if (!DECL_P (decl) || (*chain && *chain != decl))
{
set_overrun ();
break;
In 114630_c.C end up streaming the definition of _M_do_parse() twice, once
from modB and once from the transitive import of modA (which seems wasteful).
The second time around the chain of local types _M_do_parse::A/B get
streamed as simple back references and therefore on stream-in they'll already
have DECL_CHAIN properly set, so we shouldn't give up just because DECL_CHAIN
is already set. Rather, only give up if DECL_CHAIN of the previous decl isn't
what we expect it to be, i.e. either empty or what we want to set it to.
This raises the question, why do we stream the definition of _M_do_parse()
from the GMF of modA even though the same definition is already reachable (and
has been deduplicated) from the import of modB? Seems like this is something
we could/should avoid.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 106820, which changed state. Bug 106820 Summary: [modules] ICE in function_and_variable_visibility with modules and weakref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/99227] [meta-bug] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 106820, which changed state. Bug 106820 Summary: [modules] ICE in function_and_variable_visibility with modules and weakref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/106820] [modules] ICE in function_and_variable_visibility with modules and weakref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |14.0 --- Comment #11 from Patrick Palka --- Fixed for GCC 14(?)
[Bug c++/108059] internal compiler error: in tsubst_copy, at cp/pt.c:16425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059 --- Comment #6 from Patrick Palka --- FWIW a workaround for most valid code is to replace e.g. ignore_index_t, where v is the problematic NTTP argument, with ignore_index_t.
[Bug c++/114889] [modules] ICE in friend_accessible_p with imported class template specialization befriending class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.2
[Bug c++/114888] [14/15 Regression] ICE when cross compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Patrick Palka --- Fixed.
[Bug c++/114888] [14/15 Regression] ICE when cross compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888 --- Comment #6 from Patrick Palka --- Yeah I think the TREE_TYPE of a compound type should never be null, at least as far as type dependence is concerned.
[Bug c++/114888] [14/15 Regression] ICE when cross compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
Patrick Palka changed:
What|Removed |Added
Summary|[14 Regression] ICE when|[14/15 Regression] ICE when
|cross compiling binutils|cross compiling binutils
Keywords||ice-checking,
||ice-on-valid-code
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #3 from Patrick Palka ---
Seems we're missing a dependence check in the sizeof / sizeof code:
diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index e5a52dc2b39..284f6e29e36 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -5500,7 +5500,7 @@ cp_build_binary_op (const op_location_t ,
type0 = TREE_TYPE (type0);
if (!TYPE_P (type1))
type1 = TREE_TYPE (type1);
- if (type0
+ if (type0 && type1
&& INDIRECT_TYPE_P (type0)
&& same_type_p (TREE_TYPE (type0), type1))
{
[Bug c++/114889] [modules] ICE in friend_accessible_p with imported class template specialization befriending class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Blocks||103524 Ever confirmed|0 |1 Keywords||ice-checking, rejects-valid Last reconfirmed||2024-04-29 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug c++/114889] New: [modules] ICE in friend_accessible_p with imported class template specialization befriending class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889
Bug ID: 114889
Summary: [modules] ICE in friend_accessible_p with imported
class template specialization befriending class
template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase_a.C
export module mymod;
template
struct _Hashtable;
export
template
struct _Map_base {
void f() {
_Hashtable<_Key, _Val> __h;
__h._M_hash_code(0);
}
};
template
struct _Hashtable {
template friend struct _Map_base;
protected:
void _M_hash_code(int);
};
_Hashtable m;
$ cat testcase_b.C
import mymod;
int main() {
_Map_base m;
m.f();
}
$ g++ -fmodules-ts testcase_*
In module mymod, imported at testcase_b.C:1:
testcase_a.C: In instantiation of ‘void _Map_base@mymod<_Key, _Val>::f() [with
_Key = int; _Val = int]’:
testcase_b.C:5:6: required from here
5 | m.f();
| ~~~^~
testcase_a.C:11:21: internal compiler error: in friend_accessible_p, at
cp/search.cc:803
11 | __h._M_hash_code(0);
| ^~~
[Bug libstdc++/111258] std::string cannot to be moved in constant evaluated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111258 --- Comment #4 from Patrick Palka --- Many of these testcases (from here and the related PRs) are now accepted by GCC 14 after r14-10134.
[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630 --- Comment #6 from Patrick Palka --- (In reply to Nathaniel Shead from comment #5) > That said, my version doesn't actually solve the underlying issue: my > adjustment of your testcase to put instantiations into the module purview > (and force emission there) still gives the same error for me. So it sounds > like there's something else being affected by DECL_MODULE_PURVIEW_P being > set when maybe it shouldn't for an explicit specialisation. Interesting, I guess one difference with your approach is that for 114630_b.C we'll still end up installing the imported instantiations of _M_do_parse()::A/B instead of instantiating them ourselves (within the GMF), and so DECL_MODULE_IMPORT_P will be set on these local type instantiations, and yet not on _M_do_parse() because this function specialization was formed (but not instantiated) within the GMF. That seems like a weird inconsistency, that DECL_MODULE_IMPORT_P is set on the local types but not on the containing function..
[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630 --- Comment #4 from Patrick Palka --- (In reply to Patrick Palka from comment #3) > And in 114630_c.C we no longer try to stream in the definition > of _M_do_parse() twice, for some reason. Oops, looks like we still stream in the definition twice with the fix but the local types therein get deduplicated correctly now.
[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
The following hack which forces instantiations induced from the GMF to actually
get instantiated within the GMF seems to fix the underlying issue:
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 1339f210dde..dab98c02a63 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -2549,7 +2549,7 @@ decl_needed_p (tree decl)
/* If necessary, write out the vtables for the dynamic class CTYPE.
Returns true if any vtables were emitted. */
-static bool
+bool
maybe_emit_vtables (tree ctype, vec _vtables)
{
tree vtbl;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 50d3ad35b61..7b91e2b6499 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -15173,6 +15173,23 @@ cp_parser_module_declaration (cp_parser *parser,
module_parse mp_state,
}
else
{
+ if (mp_state == MP_GLOBAL)
+ /* ??? Make sure used specializations and vtables used within the
+ GMF are instantiated before starting the module purview. */
+ for (int i = 0; i < 10; i++)
+ {
+ instantiate_pending_templates (0);
+ extern bool maybe_emit_vtables (tree, vec &);
+ tree t;
+ auto_vec consteval_vtables;
+ at_eof = 1;
+ for (int i = keyed_classes->length ();
+keyed_classes->iterate (--i, );)
+ if (maybe_emit_vtables (t, consteval_vtables))
+ keyed_classes->unordered_remove (i);
+ at_eof = 0;
+ }
+
module_state *mod = cp_parser_module_name (parser);
if (mod && cp_lexer_peek_token (parser->lexer)->type == CPP_COLON)
mod = cp_parser_module_partition (parser, mod);
But I don't really understand why.. What changes is that for 114630_b.C we now
instantiate the local types _M_do_parse()::A/B locally at the end of the
GMF rather than at EOF, and later when doing the import we deduplicate their
imported definition rather than installing their imported definition. And in
114630_c.C we no longer try to stream in the definition of _M_do_parse()
twice, for some reason.
Maybe related, but I noticed that for
module;
template int f() { return 42; }
inline int x = f();
export module foo;
without the above fix we instantiate f() at EOF time and so
set_instantiating_module sets DECL_MODULE_PURVIEW_P for it, even though the
instantiation was induced from the GMF not the module purview. With the above
fix we now instantiate f() while still within the GMF and no longer set
DECL_MODULE_PURVIEW_P for f(). I wonder to what extent
DECL_MODULE_PURVIEW_P matters on implicit instantiations?
[Bug c++/114854] [11/12/13/14 Regression] checking ICE with default initializer of const reference member at cp/cp-gimplify.cc:900 since r10-5822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Last reconfirmed||2024-04-25 Summary|[14 Regression] ICE with|[11/12/13/14 Regression] |default initializer of |checking ICE with default |const reference member at |initializer of const |cp/cp-gimplify.cc:900 |reference member at ||cp/cp-gimplify.cc:900 since ||r10-5822 Keywords||ice-checking Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |11.5 --- Comment #1 from Patrick Palka --- Confirmed. This checking assert failure started ever since the introduction of the assert, r10-5822-g08f594eb399dab.
[Bug c++/114709] [12/13 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context since r12-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709 Patrick Palka changed: What|Removed |Added Summary|[12/13/14 Regression] |[12/13 Regression] |Incorrect handling of |Incorrect handling of |inactive union member |inactive union member |access via pointer to |access via pointer to |member in constant |member in constant |evaluated context since |evaluated context since |r12-6425|r12-6425 --- Comment #4 from Patrick Palka --- Fixed for GCC 14 so far.
[Bug c++/105841] [12 Regression] Change in behavior of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841 --- Comment #16 from Patrick Palka --- (In reply to Haojian Wu from comment #15) > Hi, I notice that the __is_deducible was hidden in the commit > https://github.com/gcc-mirror/gcc/commit/ > 30556bf81f4385c2a9c449948865dbcf35664764. > > Is there any reason behind the change? > > (Context: I'm implementing the is_deducible part for alias CTAD in clang, > and I'm considering to add a similar builtin in clang). IIRC we didn't want to commit to an API for the built-in, and we also didn't have any motivating use cases for the it within libstdc++.
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061 --- Comment #7 from Patrick Palka --- (In reply to Patrick Palka from comment #6) > It seems reasonable for this to work but there might be a defect, or at > least lack of clarity, in the standard in this situation. > > http://eel.is/c++draft/class.spaceship#3 specifies how a defaulted <=> is > defined, in terms of <=> comparisons of corresponding subobjects. But it's > not clear how each of these <=> comparisons is written. If they're always > written like operator expressions, e.g. x_i <=> y_i then if x_i / y_i are > base class subobjects that have a protected <=>, then such a definition > would indeed be ill-formed due to the protected access: > https://godbolt.org/z/5h4ednq9 The <=> comparison would need to be written > A::operator<=>(b) as mentioned in comment #2 in order for the definition to > be valid IIUC? Oops, the full CE link is https://godbolt.org/z/5h4ednq9E
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Patrick Palka --- It seems reasonable for this to work but there might be a defect, or at least lack of clarity, in the standard in this situation. http://eel.is/c++draft/class.spaceship#3 specifies how a defaulted <=> is defined, in terms of <=> comparisons of corresponding subobjects. But it's not clear how each of these <=> comparisons is written. If they're always written like operator expressions, e.g. x_i <=> y_i then if x_i / y_i are base class subobjects that have a protected <=>, then such a definition would indeed be ill-formed due to the protected access: https://godbolt.org/z/5h4ednq9 The <=> comparison would need to be written A::operator<=>(b) as mentioned in comment #2 in order for the definition to be valid IIUC?
[Bug c++/114685] [modules] ICE when exporting a type through a different alias then one declared in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- (N.B. https://gcc.gnu.org/PR114600#c10 contains a full std module with workarounds)
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 114600, which changed state. Bug 114600 Summary: [14 Regression] [modules] redefinition errors when using certain std headers in GMF https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Patrick Palka --- IIUC the regression is fixed.
[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 --- Comment #12 from Patrick Palka --- (In reply to m.cencora from comment #10) > Created attachment 57924 [details] > Full "std' modules with workarounds > > Here is an improved version of "std" module, with workarounds for: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685 Interesting, thanks! IIUC in light of these 'export using' bugs the most robust way to implement the std module in GCC 14 is probably: $ cat std.C export module std; export import ; $ g++ -fmodules-ts -x c++-system-header bits/stdc++.h -x c++ std.C This has the disadvantage of exposing implementation-detail entities and requiring an additional step to build the header module, but should otherwise just work.
[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795 --- Comment #9 from Patrick Palka --- The "invalid conversion in return statement" error should hopefully be fixed now.
[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-04-23
CC||ppalka at gcc dot gnu.org
--- Comment #7 from Patrick Palka ---
Reduced version of comment #6 testcase:
$ cat 114795_a.H
template
struct A {
auto f() { return 0; }
};
template
inline void g() {
A a;
a.f();
}
$ cat 114795_b.C
template
struct A {
auto f() { return 0; }
};
A a;
import "114795_a.H";
int main() {
g();
}
$ g++ -fmodules-ts 114795_*
In module ./114795-2_a.H, imported at 114795_b.C:8:
114795_a.H: In instantiation of ‘void g() [with T = int]’:
114795_b.C:11:9: required from here
11 | g();
| ~~^~
114795_a.H:9:6: error: use of ‘auto A::f() [with T = int]’ before deduction
of ‘auto’
9 | a.f();
| ~~~^~
114795_a.H:9:6: error: use of ‘auto A::f() [with T = int]’ before deduction
of ‘auto’
I think I have a fix -- we need to propagate an already-deduced return type
during deduplication.
[Bug c++/114709] [12/13/14 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context since r12-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/102680] lambda-expression in template-argument plus templateed using leads to further using-directive being ignored within template scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102680 Patrick Palka changed: What|Removed |Added Keywords||c++-lambda Target Milestone|--- |14.0 Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Patrick Palka --- This seems fixed for GCC 14 after r14-9943-gd74fe10b13336b.
[Bug c++/99902] Deduced return type of lambda in default template argument takes return type from variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99902 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick Palka --- This seems fixed for GCC 14 after r14-9943-gd74fe10b13336b.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 105106, which changed state. Bug 105106 Summary: Non-dependent call with defaulted NTTP lambda fails https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105106 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/105106] Non-dependent call with defaulted NTTP lambda fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105106 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.2 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105652 --- Comment #2 from Patrick Palka --- This is fixed for 12.2/13 by the fix for PR105652.
[Bug c++/114632] ICE with explicit this in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114632
--- Comment #3 from Patrick Palka ---
Looks like static op() lambdas are affected too:
struct S {};
auto lambda = [](auto, const int x) static /* -> void */ {};
int main()
{
void (*func)(int, int) = lambda;
return 0;
}
[Bug c++/107168] [11/12/13 Regression] Wrong errors for concepts with default lambda not-type argument since r11-3714-gc1c62aec6751678e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107168 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|11.5|14.0 --- Comment #4 from Patrick Palka --- Backporting is unlikely, the patch is kind of risky and this worked earlier only by accident.
[Bug c++/112769] [11/12 Regression] ICE on valid code related to requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112769 Patrick Palka changed: What|Removed |Added Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE on |on valid code related to|valid code related to |requires-expression |requires-expression --- Comment #6 from Patrick Palka --- Now also backported for GCC 13.3 as r13-8608-g38c2679ff9330d and r13-8609-g265f207a46bc38.
[Bug c++/110006] [11/12 Regression] friend function template with constraint doesn't match existing declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110006 Patrick Palka changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] friend |friend function template|function template with |with constraint doesn't |constraint doesn't match |match existing declaration |existing declaration --- Comment #6 from Patrick Palka --- Now also backported for GCC 13.3 as r13-8608-g38c2679ff9330d and r13-8609-g265f207a46bc38.
[Bug c++/106820] [modules] ICE in function_and_variable_visibility with modules and weakref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 --- Comment #10 from Patrick Palka --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:62a0ef0d02cbb74cd865c1db2ecb7ca1b11f87cd commit r14-9959-g62a0ef0d02cbb74cd865c1db2ecb7ca1b11f87cd Author: Nathaniel Shead Date: Sat Feb 17 23:10:49 2024 +1100 c++: Setup aliases imported from modules [PR106820] I wonder if more generally we need to be doing more work when importing definitions from header units especially to handle all the work that 'make_rtl_for_nonlocal_decl' and 'rest_of_decl_compilation' would have been performing. But this patch fixes at least one missing step. PR c++/106820 gcc/cp/ChangeLog: * module.cc (trees_in::decl_value): Assemble alias when needed. gcc/testsuite/ChangeLog: * g++.dg/modules/pr106820_a.H: New test. * g++.dg/modules/pr106820_b.C: New test. Signed-off-by: Nathaniel Shead
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 104548, which changed state. Bug 104548 Summary: parser rejects alias template id of lambda in unevaluated-context and accepts when no alias is used https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104548 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 104548, which changed state. Bug 104548 Summary: parser rejects alias template id of lambda in unevaluated-context and accepts when no alias is used https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104548 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/104548] parser rejects alias template id of lambda in unevaluated-context and accepts when no alias is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104548 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- Fixed for GCC 14 by the PR114393 fixes.
[Bug c++/106821] Incorrect behavior when using type alias template containing unevaluated lambda expression in a template context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106821 Bug 106821 depends on bug 106221, which changed state. Bug 106221 Summary: lamba inside a decltype in a using statement does not always work https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106221 What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |---
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 106221, which changed state. Bug 106221 Summary: lamba inside a decltype in a using statement does not always work https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106221 What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |---
[Bug c++/106221] lamba inside a decltype in a using statement does not always work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106221 Patrick Palka changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW --- Comment #6 from Patrick Palka --- oops no it's not, this still doesn't work
[Bug c++/106821] Incorrect behavior when using type alias template containing unevaluated lambda expression in a template context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106821 Bug 106821 depends on bug 106221, which changed state. Bug 106221 Summary: lamba inside a decltype in a using statement does not always work https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106221 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 106221, which changed state. Bug 106221 Summary: lamba inside a decltype in a using statement does not always work https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106221 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/106221] lamba inside a decltype in a using statement does not always work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106221 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- dup of the recently fixed PR92707 *** This bug has been marked as a duplicate of bug 92707 ***
[Bug c++/92707] type alias on type alias on lambda in unevaluated context does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92707 Patrick Palka changed: What|Removed |Added CC||elliot.haisley at gmail dot com --- Comment #4 from Patrick Palka --- *** Bug 106221 has been marked as a duplicate of this bug. ***
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 92211, which changed state. Bug 92211 Summary: Lamdas in unevaluated context bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92211 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/92211] Lamdas in unevaluated context bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92211 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Patrick Palka --- This seems fixed for GCC 14 after r14-9938 / r14-9943 for PR114393.
[Bug c++/113141] [13/14 Regression] ICE on conversion to reference in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141 --- Comment #10 from Patrick Palka --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:df7bfdb7dbf2d46aa5768a0280d4dcfcc868b7f9 commit r14-9947-df7bfdb7dbf2d46aa5768a0280d4dcfcc868b7f9 Author: Jason Merrill Date: Wed Apr 10 15:12:26 2024 -0400 c++: reference cast, conversion fn [PR113141] The second testcase in 113141 is a separate issue: we first decide that the conversion is ill-formed, but then when recalculating the special c_cast_p handling makes us think it's OK. We don't want that, it should continue to fall back to the reinterpret_cast interpretation. And while we're here, let's warn that we're not using the conversion function. Note that the standard seems to say that in this case we should treat (Matrix &) as const_cast(static_cast(X)), which would use the conversion operator, but that doesn't match existing practice, so let's resolve that another day. I've raised this issue with CWG; at the moment I lean toward never binding a temporary in a C-style cast to reference type, which would also be a change from existing practice. PR c++/113141 gcc/c-family/ChangeLog: * c.opt: Add -Wcast-user-defined. gcc/ChangeLog: * doc/invoke.texi: Document -Wcast-user-defined. gcc/cp/ChangeLog: * call.cc (reference_binding): For an invalid cast, warn and don't recalculate. gcc/testsuite/ChangeLog: * g++.dg/conversion/ref12.C: New test. Co-authored-by: Patrick Palka
[Bug c++/113141] [13/14 Regression] ICE on conversion to reference in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141 --- Comment #9 from Patrick Palka --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:d435571b54b02946c97b5b24f20e5a7058fd96a1 commit r14-9946-gd435571b54b02946c97b5b24f20e5a7058fd96a1 Author: Jason Merrill Date: Fri Apr 12 13:24:44 2024 -0400 c++: reference list-init, conversion fn [PR113141] The original testcase in PR113141 is an instance of CWG1996; the standard fails to consider conversion functions when initializing a reference directly from an initializer-list of one element, but then does consider them when initializing a temporary. I have a proposed fix for this defect, which is implemented here. DR 1996 PR c++/113141 gcc/cp/ChangeLog: * call.cc (reference_binding): Check direct binding from a single-element list. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-ref1.C: New test. * g++.dg/cpp0x/initlist-ref2.C: New test. * g++.dg/cpp0x/initlist-ref3.C: New test. Co-authored-by: Patrick Palka
[Bug c++/114303] [11/12/13 Regression] ICE with constexpr if and accessing captures across nested generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114303 Patrick Palka changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE |ICE with constexpr if and |with constexpr if and |accessing captures across |accessing captures across |nested generic lambdas |nested generic lambdas --- Comment #6 from Patrick Palka --- Fixed for GCC 14 so far
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99426, which changed state. Bug 99426 Summary: [modules] failed to read compiled module cluster 1186: Bad file data https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 99426, which changed state. Bug 99426 Summary: [modules] failed to read compiled module cluster 1186: Bad file data https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Patrick Palka --- Fixed for GCC 14 (although PR114630 remains at large).
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 --- Comment #11 from Patrick Palka --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:716af95fd454871473c4b118b8412b6a68459b75 commit r14-9948-716af95fd454871473c4b118b8412b6a68459b75 Author: Patrick Palka c++/modules: local type merging [PR99426] One known missing piece in the modules implementation is merging of a streamed-in local type (class or enum) with the corresponding in-TU version of the local type. This missing piece turns out to cause a hard-to-reduce use-after-free GC issue due to the entity_ary not being marked as a GC root (deliberately), and manifests as a serialization error on stream-in as in PR99426 (see comment #6 for a reduction). It's also reproducible on trunk when running the xtreme-header tests without -fno-module-lazy. This patch implements this missing piece, making us merge such local types according to their position within the containing function's definition, analogous to how we merge FIELD_DECLs of a class according to their index in the TYPE_FIELDS list. PR c++/99426 gcc/cp/ChangeLog: * module.cc (merge_kind::MK_local_type): New enumerator. (merge_kind_name): Update. (trees_out::chained_decls): Move BLOCK-specific handling of DECL_LOCAL_DECL_P decls to ... (trees_out::core_vals) : ... here. Stream BLOCK_VARS manually. (trees_in::core_vals) : Stream BLOCK_VARS manually. Handle deduplicated local types.. (trees_out::key_local_type): Define. (trees_in::key_local_type): Define. (trees_out::get_merge_kind) : Return MK_local_type for a local type. (trees_out::key_mergeable) : Use key_local_type. (trees_in::key_mergeable) : Likewise. (trees_in::is_matching_decl): Be flexible with type mismatches for local entities. (trees_in::register_duplicate): Also register the DECL_TEMPLATE_RESULT of a TEMPLATE_DECL as a duplicate. (depset_cmp): Return 0 for equal IDENTIFIER_HASH_VALUEs. gcc/testsuite/ChangeLog: * g++.dg/modules/merge-17.h: New test. * g++.dg/modules/merge-17_a.H: New test. * g++.dg/modules/merge-17_b.C: New test. * g++.dg/modules/xtreme-header-7_a.H: New test. * g++.dg/modules/xtreme-header-7_b.C: New test. Reviewed-by: Jason Merrill
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 93595, which changed state. Bug 93595 Summary: [c++20] function call, substitution failure of template parameter with a lambda default in template context https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/93595] [c++20] function call, substitution failure of template parameter with a lambda default in template context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Patrick Palka --- Fixed for GCC 14.
[Bug c++/93595] [c++20] function call, substitution failure of template parameter with a lambda default in template context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595 --- Comment #10 from Patrick Palka --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917 commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917 Author: Patrick Palka c++: templated substitution into lambda-expr [PR114393] The below testcases use a lambda-expr as a template argument and they all trip over the below added tsubst_lambda_expr sanity check ultimately because current_template_parms is empty which causes push_template_decl to return error_mark_node from the call to begin_lambda_type. Were it not for the sanity check this silent error_mark_node result leads to nonsensical errors down the line, or silent breakage. In the first testcase, we hit this assert during instantiation of the dependent alias template-id c1_t<_Data> from instantiate_template, which clears current_template_parms via push_to_top_level. Similar story for the second testcase. For the third testcase we hit the assert during partial instantiation of the member template from instantiate_class_template which similarly calls push_to_top_level. These testcases illustrate that templated substitution into a lambda-expr is not always possible, in particular when we lost the relevant template context. I experimented with recovering the template context by making tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if current_template_parms is empty which worked but seemed like a hack. I also experimented with preserving the template context by keeping current_template_parms set during instantiate_template for a dependent specialization which also worked but it's at odds with the fact that we cache dependent specializations (and so they should be independent of the template context). So instead of trying to make such substitution work, this patch uses the extra-args mechanism to defer templated substitution into a lambda-expr when we lost the relevant template context. PR c++/114393 PR c++/107457 PR c++/93595 gcc/cp/ChangeLog: * cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define. (tree_lambda_expr::extra_args): New field. * module.cc (trees_out::core_vals) : Stream LAMBDA_EXPR_EXTRA_ARGS. (trees_in::core_vals) : Likewise. * pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR. (tree_extra_args): Handle LAMBDA_EXPR. (tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated substitution into a lambda-expr if we lost the template context. Add sanity check for error_mark_node result from begin_lambda_type. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-targ2.C: New test. * g++.dg/cpp2a/lambda-targ3.C: New test. * g++.dg/cpp2a/lambda-targ4.C: New test. Reviewed-by: Jason Merrill
[Bug c++/107457] ICE when template lambda alias used as default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107457 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Fixed for GCC 14.
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 107457, which changed state. Bug 107457 Summary: ICE when template lambda alias used as default template argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107457 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/107457] ICE when template lambda alias used as default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107457 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917 commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917 Author: Patrick Palka c++: templated substitution into lambda-expr [PR114393] The below testcases use a lambda-expr as a template argument and they all trip over the below added tsubst_lambda_expr sanity check ultimately because current_template_parms is empty which causes push_template_decl to return error_mark_node from the call to begin_lambda_type. Were it not for the sanity check this silent error_mark_node result leads to nonsensical errors down the line, or silent breakage. In the first testcase, we hit this assert during instantiation of the dependent alias template-id c1_t<_Data> from instantiate_template, which clears current_template_parms via push_to_top_level. Similar story for the second testcase. For the third testcase we hit the assert during partial instantiation of the member template from instantiate_class_template which similarly calls push_to_top_level. These testcases illustrate that templated substitution into a lambda-expr is not always possible, in particular when we lost the relevant template context. I experimented with recovering the template context by making tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if current_template_parms is empty which worked but seemed like a hack. I also experimented with preserving the template context by keeping current_template_parms set during instantiate_template for a dependent specialization which also worked but it's at odds with the fact that we cache dependent specializations (and so they should be independent of the template context). So instead of trying to make such substitution work, this patch uses the extra-args mechanism to defer templated substitution into a lambda-expr when we lost the relevant template context. PR c++/114393 PR c++/107457 PR c++/93595 gcc/cp/ChangeLog: * cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define. (tree_lambda_expr::extra_args): New field. * module.cc (trees_out::core_vals) : Stream LAMBDA_EXPR_EXTRA_ARGS. (trees_in::core_vals) : Likewise. * pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR. (tree_extra_args): Handle LAMBDA_EXPR. (tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated substitution into a lambda-expr if we lost the template context. Add sanity check for error_mark_node result from begin_lambda_type. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-targ2.C: New test. * g++.dg/cpp2a/lambda-targ3.C: New test. * g++.dg/cpp2a/lambda-targ4.C: New test. Reviewed-by: Jason Merrill
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed, GCC trunk should now happily compile stdexec trunk, and our support for lambdas as template arguments should be more robust to boot. thanks for the bug report
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 --- Comment #7 from Patrick Palka --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d74fe10b13336b9de2e025ced4af00a25ff1d3e7 commit r14-9943-d74fe10b13336b9de2e025ced4af00a25ff1d3e7 Author: Patrick Palka c++: templated substitution into lambda-expr, cont [PR114393] The original PR114393 testcase is unfortunately still not accepted after r14-9938-g081c1e93d56d35 due to return type deduction confusion when a lambda-expr is used as a default template argument. The below reduced testcase demonstrates the bug. Here when forming the dependent specialization b_v we substitute the default argument of F, a lambda-expr, with _Descriptor=U. (In this case in_template_context is true since we're in the context of the template c_v, so we don't defer.) This substitution in turn lowers the level of the lambda's auto return type from 2 to 1 and so later, when instantiating c_v we wrongly substitute this auto with the template argument at level=0,index=0, i.e. int, instead of going through do_auto_deduction which would yield char. One way to fix this would be to use a level-less auto to represent a deduced return type of a lambda, but that might be too invasive of a change at this stage, and it might be better to do this across the board for all deduced return types. Another way would be to pass tf_partial from coerce_template_parms during dependent substitution into a default template argument so that the substitution doesn't do any level-lowering, but that wouldn't do the right thing in this case due to the tf_partial early exit in the LAMBDA_EXPR case of tsubst_expr. Yet another way, and the approach that this patch takes, is to just defer all dependent substitution into a lambda-expr, building upon the logic added in r14-9938-g081c1e93d56d35. This also helps ensure LAMBDA_EXPR_REGEN_INFO consists only of the concrete template arguments that were ultimately substituted into the most general lambda. PR c++/114393 gcc/cp/ChangeLog: * pt.cc (tsubst_lambda_expr): Also defer all dependent substitution. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-targ2a.C: New test. Reviewed-by: Jason Merrill
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 --- Comment #6 from Patrick Palka --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917 commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917 Author: Patrick Palka c++: templated substitution into lambda-expr [PR114393] The below testcases use a lambda-expr as a template argument and they all trip over the below added tsubst_lambda_expr sanity check ultimately because current_template_parms is empty which causes push_template_decl to return error_mark_node from the call to begin_lambda_type. Were it not for the sanity check this silent error_mark_node result leads to nonsensical errors down the line, or silent breakage. In the first testcase, we hit this assert during instantiation of the dependent alias template-id c1_t<_Data> from instantiate_template, which clears current_template_parms via push_to_top_level. Similar story for the second testcase. For the third testcase we hit the assert during partial instantiation of the member template from instantiate_class_template which similarly calls push_to_top_level. These testcases illustrate that templated substitution into a lambda-expr is not always possible, in particular when we lost the relevant template context. I experimented with recovering the template context by making tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if current_template_parms is empty which worked but seemed like a hack. I also experimented with preserving the template context by keeping current_template_parms set during instantiate_template for a dependent specialization which also worked but it's at odds with the fact that we cache dependent specializations (and so they should be independent of the template context). So instead of trying to make such substitution work, this patch uses the extra-args mechanism to defer templated substitution into a lambda-expr when we lost the relevant template context. PR c++/114393 PR c++/107457 PR c++/93595 gcc/cp/ChangeLog: * cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define. (tree_lambda_expr::extra_args): New field. * module.cc (trees_out::core_vals) : Stream LAMBDA_EXPR_EXTRA_ARGS. (trees_in::core_vals) : Likewise. * pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR. (tree_extra_args): Handle LAMBDA_EXPR. (tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated substitution into a lambda-expr if we lost the template context. Add sanity check for error_mark_node result from begin_lambda_type. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-targ2.C: New test. * g++.dg/cpp2a/lambda-targ3.C: New test. * g++.dg/cpp2a/lambda-targ4.C: New test. Reviewed-by: Jason Merrill
[Bug c++/114625] requires { T{}; } wrongly returns false when T{} is ill-formed while in concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625
Patrick Palka changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=94885
--- Comment #3 from Patrick Palka ---
Non-concepts testcase:
struct b { explicit b(); };
struct d : b {};
template void f(int) = delete;
template void f(...);
int main() {
f(0);
}
This seems related to PR94885 / r11-20-g30da2906ac5217, maybe Marek would be
interested.
[Bug c++/92707] type alias on type alias on lambda in unevaluated context does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92707 Patrick Palka changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #2 from Patrick Palka --- *** Bug 114654 has been marked as a duplicate of this bug. ***
[Bug c++/114654] Alias template cannot be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114654 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 92707 ***
[Bug c++/114630] [14 Regression] [modules] building module with submodule causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-04-08
Ever confirmed|0 |1
Target Milestone|--- |14.0
Status|UNCONFIRMED |NEW
Summary|[modules] building module |[14 Regression] [modules]
|with submodule causes |building module with
|corrupt gcm |submodule causes corrupt
||gcm
CC||nshead at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Known to work||13.2.0
--- Comment #1 from Patrick Palka ---
Thanks for the report, reduced:
$ cat 114630_a.C
module;
#include "format.ii"
export module modB;
$ cat 114630_b.C
module;
#include "format.ii"
export module modA;
import modB;
$ cat 114630_c.C
#include "format.ii"
import modA;
$ cat format.ii
template
void _M_do_parse() {
struct A { };
struct B { };
}
template
struct formatter;
template
requires __is_same(_Tp, int)
struct formatter<_Tp, _CharT> { };
template
requires __is_same(_Tp, int*)
struct formatter<_Tp, _CharT> { };
template<> struct formatter {
void parse() { _M_do_parse(); }
};
$ g++ -fmodules-ts -std=c++20 114630_*.C
In module imported at 114630_c.C:3:1:
modA: error: failed to read compiled module cluster 5: Bad file data
modA: note: compiled module file is ‘gcm.cache/modA.gcm’
In file included from 114630_c.C:1:
format.ii:19:34: fatal error: failed to load pendings for ‘::_M_do_parse’
19 | void parse() { _M_do_parse(); }
| ^~
compilation terminated.
We started rejecting this after r14-8408. We seem to be streaming in the
definition of _M_do_parse() twice, dunno if that's expected or not.
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 --- Comment #9 from Patrick Palka --- Huh, interesting! If --param=ggc-min-expand=1 doesn't help then it's most likely a distinct bug. A testcase would be much appreciated if possible.
[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 --- Comment #5 from Patrick Palka --- (In reply to Nathaniel Shead from comment #4) > In general we don't yet implement merging of textual redefinitions; I guess > this ultimately falls under that, but I'm not sure we have a dedicated bug > report for that yet? Maybe PR99000. Makes sense. > I'm not yet sure exactly why my patch caused this to start failing though; > it sounds like it's exporting some using-decls even though they aren't > directly exported, which I suppose is still a bug in its own right. Hmm, should the check added to add_binding_entity flags & (WMB_Using | WMB_Export) instead be (flags & WMB_Using) && (flags & WMB_Export) ?
[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=109679
Keywords||ice-on-valid-code
--- Comment #3 from Patrick Palka ---
Shorter reduction demonstrating an ICE:
$ cat 114600.h # other files same as before
namespace std {
template struct A { int n; };
template A f();
namespace __swappable_details { using std::f; }
}
internal compiler error: in finish_member_declaration, at cp/semantics.cc:3771
