[Bug c++/96873] Internal compiler error in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96873 --- Comment #3 from Mateusz Pusz --- Are there any chances for it to be fixed for gcc-11 or gcc-10.3? This feature is essential for the Physical Units library for C++Next.
[Bug c++/96873] Internal compiler error in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96873 --- Comment #5 from Mateusz Pusz --- Thanks!
[Bug c++/113966] New: Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966
Bug ID: 113966
Summary: Internal compiler error in `do_auto_deduction`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
The following ICE has been happening for a longer time now for
https://godbolt.org/z/7EK64PPr6:
```
quantity.h:316:9: internal compiler error: in do_auto_deduction, at
cp/pt.cc:31135
315 | {
| ~
316 | a += b
| ^~
317 | } -> std::same_as;
| ~~~
0x264d1cc internal_error(char const*, ...)
???:0
0xa526c5 fancy_abort(char const*, int, char const*)
???:0
0xad5976 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xacf547 maybe_substitute_reqs_for(tree_node*, tree_node const*)
???:0
0xcb4d66 instantiate_class_template(tree_node*)
???:0
0xd0b594 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0xd0b6ac require_complete_type(tree_node*, int)
???:0
0xa6d24d build_cxx_call(tree_node*, int, tree_node**, int, tree_node*)
???:0
0xa87af8 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xd0e002 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xc555aa c_parse_file()
???:0
0xda9739 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/111471] New: Incorrect NTTP printing in the error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111471
Bug ID: 111471
Summary: Incorrect NTTP printing in the error messages
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
Please see the following example https://godbolt.org/z/qajTKdnGq:
There are many similar issues:
```
required for the satisfaction of 'ReferenceOf::type, V>' [with Q =
mp_units::quantity<{}, double>; V = _ZTAXtlN8mp_units3isq5speedEEE]
```
The `{}` part above does not help at all and should print the actual type of
the NTTP somewhere. `_ZTAXtlN8mp_units3isq5speedEEE` should be properly
demangled.
```
note: the expression 'implicitly_convertible({}, QS) [with T =
mp_units::kind_of_<{}>; QS = _ZTAXtlN8mp_units3isq5speedEEE]' evaluated to
'false'
```
Again, lack of demangling and mysterious `{}`.
[Bug c++/111474] New: Consider stripping from the error message the identifiers of namespaces brought with using-directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111474 Bug ID: 111474 Summary: Consider stripping from the error message the identifiers of namespaces brought with using-directives Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mateusz.pusz at gmail dot com Target Milestone: --- It would be awesome if the compiler was able to strip the identifiers for namespaces brought with using-directive in the source code that produces an error. It does it for some, but not all names already. If the full names are considered useful in some scenarios (to better point to the source type in an unknown code base), maybe a command line option for the verbosity of messages could be introduced? Let's consider the following example: ```cpp using namespace mp_units; using namespace mp_units::si::unit_symbols; auto q = (5 * m) * (1. * s); quantity v1 = q; quantity v2 = q; ``` `quantity` in the above code is declared in the `mp_units` namespace but in the following error messages, it is printed without the namespace identifier, which is awesome. However, the rest of the identifiers from this namespace (even though it is brought to the current scope with the using-directive are using this namespace identifier). ``` : In function 'int main()': :9:41: error: conversion from 'quantity(),[...]>' to non-scalar type 'quantity >(),[...]>' requested 9 | quantity v1 = q; | ^ :10:36: error: conversion from 'quantity(),[...]>' to non-scalar type 'quantity >()>(),[...]>' requested 10 | quantity v2 = q; |^ Compiler returned: 1 ``` If the compiler was able to strip such namespaces, the error message would look like this: ``` : In function 'int main()': :9:41: error: conversion from 'quantity(),[...]>' to non-scalar type 'quantity >(),[...]>' requested 9 | quantity v1 = q; | ^ :10:36: error: conversion from 'quantity(),[...]>' to non-scalar type 'quantity >()>(),[...]>' requested 10 | quantity v2 = q; |^ Compiler returned: 1 ``` which is much terser and easier to read. As the user brings the `mp-units` namespace to the current scope, he/she should not be surprised by the meaning of the shorter type identifiers and would certainly appreciate easier-to-understand error messages. Please note that GCC already removed some important information from the error messages with the `[...]` anyway now, so there is a precedence for preferring terse error messages already. Consider also how it would improve error messages for `std::filesystem` of `std::chrono` in the standard library. As they are quite long, users already often bring them in the current scope with the using-declaration or use namespace aliases, which is probably too much for the error message generator to follow?
[Bug c++/115314] New: Type of the `auto` template parameter in a concept is not decayed when called as dependent name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115314
Bug ID: 115314
Summary: Type of the `auto` template parameter in a concept is
not decayed when called as dependent name
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
```
struct X {
static constexpr int val = 42;
};
template
concept A = std::same_as;
template
concept B = A;
static_assert(A);
static_assert(B);
```
The first static assert passes while the other one fails. Both cases work on
clang and MSVC: https://godbolt.org/z/v5z6bee7c
Affects all gcc versions from 12 to 15.
