[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
> This seems to be a regression from GCC 9.

Are you sure?  I see the same thing with GCC 6.

[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
With this patch GCC 9 ICEs on:

$ ./cc1plus -quiet pr87768.C -std=gnu++2a -fconcepts
pr87768.C: In instantiation of ‘constexpr const bool c::f’:
pr87768.C:14:29:   required from here
pr87768.C:9:29: internal compiler error: in tsubst_copy, at cp/pt.c:15833
9 |   requires requires(d e) { e[0]; }
  |~^
0xaaad12 tsubst_copy
/home/mpolacek/src/gcc9/gcc/cp/pt.c:15833
0xac0b50 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:19709
0xaba51d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:18434
0xab8707 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:17969
0x8c892b satisfy_expression_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2070
0x8c92ff satisfy_constraint_1
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2242
0x8c90c9 satisfy_parameterized_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2185
0x8c9388 satisfy_constraint_1
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2257
0x8c944d satisfy_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2294
0x8c9511 satisfy_associated_constraints
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2318
0x8c97ed constraints_satisfied_p(tree_node*)
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2393
0x8454e3 add_function_candidate
/home/mpolacek/src/gcc9/gcc/cp/call.c:
0x851d96 add_candidates
/home/mpolacek/src/gcc9/gcc/cp/call.c:5754
0x84d828 build_op_call_1
/home/mpolacek/src/gcc9/gcc/cp/call.c:4712
0x84e172 build_op_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc9/gcc/cp/call.c:4808
0xb0e895 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc9/gcc/cp/semantics.c:2602
0xabdd43 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:19195
0xab8707 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:17969
0xaa9801 tsubst_init
/home/mpolacek/src/gcc9/gcc/cp/pt.c:15527
0xad2f31 regenerate_decl_from_template
/home/mpolacek/src/gcc9/gcc/cp/pt.c:24262

because tsubst_copy/NON_LVALUE_EXPR gets
NON_LVALUE_EXPR (e)>

Don't know if I should pursue this backport.

[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-04
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|Broken diagnostic:  |[10 Regression] Broken
   |'result_decl' not supported |diagnostic: 'result_decl'
   |by dump_expr|not supported by dump_expr
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r10-5821-g10d2f801f472931137deae1714d5b690c1862037

[Bug c++/93898] [9/10 Regression] internal compiler error: in output_constructor_regular_field

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Marek Polacek  ---
Which has been fixed.

*** This bug has been marked as a duplicate of bug 90432 ***

[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
*** Bug 93898 has been marked as a duplicate of this bug. ***

[Bug c++/90505] [9 Regression] g++ rejects valid code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Marek Polacek  ---
Fixed.

[Bug sanitizer/93436] [9 Regression] ICE during GIMPLE pass: sanopt with -fsanitize=address -fdump-tree-sanopt

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/93299] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15779

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
It depends on r10-3735-gcb57504a550158913258e5be8ddb991376475efb :/

So, we'd have to play some games with unwrapping the NON_LVALUE_EXPR.

[Bug c++/92948] internal compiler error: in tsubst_copy, at cp/pt.c:15788

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Marek Polacek  ---
Unfortunately backporting is proving to be difficult.  nontype-class28.C ICEs
without r273597.  That was backported to 9 in r273597, but the
build_converted_constant_expr_internal bit is different.  Tweaking GCC 9 so
that it doesn't copy a class in a template breaks everything.

I'm too nervous about messing with that now.  So closing.

[Bug c++/91754] [c++2a] Defining member function outside of class body fails to compile when containing class is templated on class-type NTTP

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Since I can't really backport bug 91754, not going to backport this one either.

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Here's the thread where the patch originated:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01189.html

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Looks like we're losing the TYPE_USER_ALIGN bit.  That's probably because arm
is STRICT_ALIGNMENT and so finalize_type_size does this:

1930   /* Don't override a larger alignment requirement coming from a user
1931  alignment of one of the fields.  */
1932   if (mode_align >= TYPE_ALIGN (type))
1933 {
1934   SET_TYPE_ALIGN (type, mode_align);
1935   TYPE_USER_ALIGN (type) = 0;
1936 }

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
But that happens even before
r10-1302-gc3337b44c40dd1545e00034cb8e1ae1c0dae0fa6.

The actual problem is that in layout_class_type for TenuredCell we see that the
size of TenuredCell and its CLASSTYPE_AS_BASE match, so we set
CLASSTYPE_AS_BASE (t) = t;

But while TYPE_USER_ALIGN of TenuredCell was 0, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE was 1.  After we replace it, it's no longer 1.

So then we perform layout_empty_base_or_field for TenuredCell.  Since
TYPE_USER_ALIGN of its CLASSTYPE_AS_BASE is now 0, we don't do this:

  if (CLASSTYPE_USER_ALIGN (type))
{
  rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
  if (warn_packed)
rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN
(type));
  TYPE_USER_ALIGN (rli->t) = 1;
}

where rli->t is BaseShape.  And that's how we lose the alignas info on
BaseShape.  Then sizeof thinks its size is 20B and it's not aligned to 24B.

CLASSTYPE_USER_ALIGN is defined as TYPE_USER_ALIGN (CLASSTYPE_AS_BASE (NODE)).

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
So quite obviously *a* fix would be

--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -6705,6 +6705,7 @@ layout_class_type (tree t, tree *virtuals_p)

   /* If we didn't end up needing an as-base type, don't use it.  */
   if (CLASSTYPE_AS_BASE (t) != t
+  && !CLASSTYPE_USER_ALIGN (t)
   && tree_int_cst_equal (TYPE_SIZE (t),
 TYPE_SIZE (CLASSTYPE_AS_BASE (t
 CLASSTYPE_AS_BASE (t) = t;

(needs a comment of course).  Since the original fix was to avoid creating
extra copies for LTO purposes, this slight degradation should not be too bad?

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ABI, patch
 Status|NEW |ASSIGNED
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
  Known to fail||10.0

[Bug c++/91465] [9/10 Regression] unexpected expression of kind overload (ICE)

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Unfortunately that ship has sailed.  What we need is a more complete solution:
.  It's not a trivial
problem and I'm not sure if the backport will be viable.  Sorry about that.

[Bug c++/94066] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-06
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-06
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #3 from Marek Polacek  ---
Most likely a dup, should be fixed by my
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01712.html overhaul.  But more
tests are always welcome.

[Bug c++/94074] New: bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94074
   Summary: bogus modifying a const object error with const
COMPONENT_REF
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

typedef decltype (sizeof (0)) size_t;

template 
struct array
{
  constexpr const E &operator[](size_t n) const noexcept { return elems[n]; }
  E elems[N];
};

template 
struct S {
  using U = array;
  U m;
  constexpr S(int) : m{}
  {
const_cast(const_cast(m)[0]) = 42;
  }
};

constexpr S p = { 10 };

$ ./cc1plus -quiet q.C
q.C:20:27:   in ‘constexpr’ expansion of ‘S(10)’
q.C:16:52: error: modifying a const object ‘(int&)(&(&(const
U&)(&((S*)this)->S::m))->array::operator[](0))’ is not
allowed in a constant expression
   16 | const_cast(const_cast(m)[0]) = 42;
  | ~~~^~~~
q.C:20:27: note: originally declared ‘const’ here
   20 | constexpr S p = { 10 };
  |   ^

ISTM we shouldn't error here.

[Bug c++/94074] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-06
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
This breaks Chromium.

[Bug c++/94074] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
And this should be diagnosed but isn't:

struct X {
  int i;
};

template 
struct S {
  const X x;
  constexpr S(int) : x{}
  {
const_cast(x).i = 19; // { dg-error "modifying a const object" }
  }
};

constexpr S p = { 10 }; // { dg-message "originally declared" }

[Bug c++/94100] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:12765

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-09
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
The ICE started with r0-128638-gb0ff7fe1d223260aea5b7dc3f36892aa57d43c77 -- a
while ago.  Before that:

94100.C:19:24: error: no matching function for call to ‘Foo::foo()’
   Foo::foo();
^

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/94074] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
And this should be diagnosed but isn't:

struct X {
  int i;
};

template 
struct S {
  const X x;
  constexpr S(int) : x{}
  {
const_cast(x).i = 19; // { dg-error "modifying a const object" }
  }
};

constexpr S p = { 10 }; // { dg-message "originally declared" }

[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create &TARGET_EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(&operator~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create &TARGET_EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug c++/94068] [9 Regression] Internal compiler error when trying to resolve function overload since r9-2384

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Summary|[9/10 Regression] Internal  |[9 Regression] Internal
   |compiler error when trying  |compiler error when trying
   |to resolve function |to resolve function
   |overload since r9-2384  |overload since r9-2384

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 10.  I'm undecided about backporting this, but we have other PRs
about this anyway (listed in the commit message).

[Bug c++/91465] [9 Regression] unexpected expression of kind overload (ICE)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10 Regression]   |[9 Regression] unexpected
   |unexpected expression of|expression of kind overload
   |kind overload  (ICE)| (ICE)

--- Comment #9 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create &TARGET_EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(&operator~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create &TARGET_EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug c++/92031] [9 Regression] Incorrect "taking address of r-value" error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10 Regression] Incorrect |[9 Regression] Incorrect
   |"taking address of r-value" |"taking address of r-value"
   |error   |error

--- Comment #2 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create &TARGET_EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(&operator~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create &TARGET_EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug c++/93870] [8/9/10 Regression] User-defined conversion function not working in evaluation of template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create &TARGET_EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(&operator~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create &TARGET_EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug c++/94117] deferred noexcept specifications and friend fns

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
Yes, it was a conscious decision not to defer parsing of noexcept-spec of
friend functions.  The standard currently doesn't say we shouldn't defer, but
no compiler implements it.  The problem was that friend declarations can be
redeclared and it would be tricky to see if their noexcept-specs match.

[Bug c++/93895] [10 Regression] ICE (segmentation fault) in use of __is_constructible intrinsic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
If it's so complicated I wouldn't probably bother and just close this PR.

[Bug c++/94124] [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since r10-6388-ge98ebda074bf8fc5

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #1 from Marek Polacek  ---
I'll try to look and see what the problem is here.

[Bug c++/94124] [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since r10-6388-ge98ebda074bf8fc5

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
This is a bad interaction between sharing a constructor for an array and
stripping trailing zero-initializers, which is why this test works with
{{{1}}}.

While here you can initialize D from {{}}, you can't initialize it from {{0}}. 
So when we drop that 0, we suddenly allow both F() overloads, making this
ambiguous.

Slightly tweaked testcase:

template  struct A { typedef int _Type[N]; };
template  struct B { typename A::_Type _M_elems; };
class C { };
struct D {
  D(C);
};

struct F {
  F(B<2>);
  F(D);
};
F fn1() { return {{{0}}}; }

[Bug c++/94124] [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since r10-6388-ge98ebda074bf8fc5

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Marek Polacek  ---
I have a patch.

[Bug c++/94124] [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since r10-6388-ge98ebda074bf8fc5

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
commit e11d05c1ed26257493130762a8ae240f1bc06e87
Author: Marek Polacek 
Date:   Tue Mar 10 18:55:42 2020 -0400

c++: Fix wrong conversion error with non-viable overload [PR94124]

This is a bad interaction between sharing a constructor for an array
and stripping its trailing zero-initializers.  Here we reuse a ctor
and then strip its 0s.  This breaks overload resolution in this test:
D can be initialized from {} but not from {0}, so if we truncate the
constructor not to include the zero, the F(D) overload becomes valid
and then we get the ambiguous conversion error.

PR c++/94124 - wrong conversion error with non-viable overload.
* decl.c (reshape_init_array_1): Unshare a constructor if we
stripped trailing zero-initializers.

* g++.dg/cpp0x/initlist-overload1.C: New test.

[Bug c++/94098] [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||mpolacek at gcc dot gnu.org

[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
C++20 paren-init -> mine.

[Bug c++/94074] [10 Regression] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
commit 7eb5be6ab91ec03f93038ac2bcf3028cf2e7c82b
Author: Marek Polacek 
Date:   Fri Mar 6 17:30:11 2020 -0500

c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).

While looking into this I noticed that we don't detect modifying a const
object in certain cases like in
.  That's because
we never evaluate an X::X() CALL_EXPR -- there's none.  Fixed as per
Jason's suggestion by setting TREE_READONLY on a CONSTRUCTOR after
initialization in cxx_eval_store_expression.

2020-03-11  Marek Polacek  
Jason Merrill  

PR c++/94074 - wrong modifying const object error for
COMPONENT_REF.
* constexpr.c (cref_has_const_field): New function.
(modifying_const_object_p): Consider a COMPONENT_REF
const only if any of its fields are const.
(cxx_eval_store_expression): Mark a CONSTRUCTOR of a const type
as readonly after its initialization has been done.

* g++.dg/cpp1y/constexpr-tracking-const17.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const18.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const19.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const20.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const21.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const22.C: New test.

[Bug c++/94074] [10 Regression] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Marek Polacek  ---
Hopefully fixed.

[Bug c++/93425] [9/10 Regression] Template parameter deduction failure when template parameters have template template parameter since r9-3807-g5d9a0e3b99e31a21

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Fixed, presumably by

commit 6b3302da9ef26aa11940f8c0dc92bec19e15c09b
Author: Marek Polacek 
Date:   Tue Mar 3 17:56:44 2020 -0500

c++: Fix mismatch in template argument deduction [PR90505]

[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-12

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Not relate to parameter packs.  Also happens with normal member functions:

template  class A {
  template  class B {
B(A::B&);
void fn(A::B &);
  };
};

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
The root cause isn't the C++20 feature it seems.  The following version with
explicit 'typename' is rejected, but compiles fine with clang/icc:

template  class A {
  template  class B {
B(typename A::B&);
void fn(typename A::B &);
  };
};

[Bug c++/54164] C++11: confusing error messages for spurious "typename"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Marek Polacek  ---
Fixed in GCC 4.9.0.  Now we say:

54164.C:6:25: error: expected nested-name-specifier before ‘base’
6 |   using type = typename base;
  |

[Bug c++/53102] typename gives access to private type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Fixed in GCC 4.8.1, likely by
r0-117899-g0e69fdf016311cb8570c43d8ec67e9d5cb2f2aeb.

[Bug c++/58590] Hidden typename not ill-formed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #11 from Marek Polacek  ---
The original test is still rejected:

58590.C:9:31: error: static assertion failed
9 | static_assert(sizeof(f(0)) == 2, "");
  |   ^~~~

[Bug c++/64259] Erroneous "declaration 'struct ...' does not declare anything" when using "typename"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
GCC 10 still prints the warning:

64259.C:8:30: warning: declaration ‘struct details::B’ does not declare
anything
8 | using BB = typename details::B;
  |  ^

[Bug c++/64924] Callback function passed as a parameter with typename declaration produces an ICE.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Still ICEs with GCC 10.

[Bug c++/89636] Duplicate diagnostic when resolving ambiguity between variable and function template using implicit typename

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-03-12

--- Comment #1 from Marek Polacek  ---
Confirmed.  With -std=c++2a:

Starting with

commit 96c35892bea68ac180f19079cf08fea3b6cda0a8
Author: Marek Polacek 
Date:   Sat Dec 1 17:56:27 2018 +

Implement P0634R3, Down with typename!

there is no error at all, and starting with

commit b6d0f41ac5c1786911858b4763bb6f92519166f4
Author: Marek Polacek 
Date:   Mon Jan 28 22:14:27 2019 +

PR c++/88358 - name wrongly treated as type.

there are two errors.  So mine.

[Bug c++/78286] typename, type members and non-type members: code should be rejected, but it is not

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Marek Polacek  ---
Dup.

*** This bug has been marked as a duplicate of bug 48920 ***

[Bug c++/48920] typename specifier should not ignore non-type names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||michele.caini at gmail dot com

--- Comment #4 from Marek Polacek  ---
*** Bug 78286 has been marked as a duplicate of this bug. ***

[Bug c++/69778] Bogus "qualifiers cannot be applied" error with redundant (but legal) 'typename'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-12
 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Confirmed.

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(We accept it when the template keyword is added: "typename A::template
B".)

[Bug c++/94161] Implement DR 228: Use of template keyword with non-member templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Keywords||rejects-valid
   Last reconfirmed||2020-03-12

[Bug c++/94161] New: Implement DR 228: Use of template keyword with non-member templates

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94161
   Summary: Implement DR 228: Use of template keyword with
non-member templates
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This should compile:

template
struct X {
void f(); 
};

template
struct Y {
  void g(X x) {
x.template X::f();
  }
};

Since the DR says that the name prefixed by 'template' doesn't have to be a
member template.

[Bug c++/94190] [10 Regression] error: no post-decrement operator for type since r10-7096-gd417b4f5414d9076

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #16 from Marek Polacek  ---
That patch will generate a -Wparentheses warning, and more importantly, doesn't
fix the ICE, which you could have tried by yourself.

[Bug c++/94210] ICE in tsubst, at cp/pt.c:15105

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-03-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code

--- Comment #1 from Marek Polacek  ---
Confirmed, but not a recent regression; even g++ 5 ICEs.

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
(In reply to Nicholas Krause from comment #1)
> Hi Marin,
> I've not sure if this is correct but it does not ICE with this fix:
> tree off = fold_convert (ptr_type_node, op1);
> -   return build_fold_addr_expr_loc
> -   (loc,
> +   return build1_loc
> +   (loc, ADDR_EXPR, TREE_TYPE (op0),
>  fold_build2 (MEM_REF,
>   TREE_TYPE (TREE_TYPE (op0)),
>   unshare_expr (op0), off));
> 
> should actually be:  
> (EXPR_LOCATION(off), ADDR_EXPR, TREE_TYPE (op0),
>  fold_build2 (MEM_REF,
>   TREE_TYPE (TREE_TYPE (op0)),
>   unshare_expr (op0), off));

Huh?  Why do you think that changing the location should fix the ICE?  That's a
completely random change that you never bothered to test, because it doesn't
fix the crash.

[Bug c++/94227] ambiguous lookup for nested-name-specifier in using-declaration is not diagnosed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-03-19
 Status|UNCONFIRMED |NEW
   Keywords||accepts-invalid

--- Comment #1 from Marek Polacek  ---
Confirmed, thanks for the report.

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #13 from Marek Polacek  ---
Is this FIXED now?

[Bug c++/94302] New: Implement DR 2310: Type completeness and derived-to-base pointer conversions

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94302
   Summary: Implement DR 2310: Type completeness and
derived-to-base pointer conversions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This issue was approved as a DR at Kona 2019:

  template struct check_derived_from { 
static A a; 
static constexpr B *p = &a; 
  }; 
  struct W {}; 
  struct X {}; 
  struct Y {}; 
  struct Z : W, 
X, check_derived_from,  // #1 
check_derived_from, Y { // #2 
check_derived_from cdf; // #3 
  }; 


All three attempted conversions in the example are ill-formed.

[Bug target/94297] PPCLE std::replace internal compiler error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I can't reproduce this with latest trunk on ppc64le.  Can you please provide a
preprocessed source file for this ICE?

[Bug c++/87910] Missing typename/template not diagnosed

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
This PR might get resolved by
.

[Bug c++/65969] typename allowed in using declaration of non-types names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Another test:

struct A {
  void g();
};

namespace N {
  void f();
};

namespace M {
  using typename N::f;
}

struct X : A {
  using typename A::g;
};

[Bug c++/94190] [10 Regression] error: no post-decrement operator for type since r10-7096-gd417b4f5414d9076

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #2 from Marek Polacek  ---
*** Bug 94309 has been marked as a duplicate of this bug. ***

[Bug c++/94309] Fail to find post-increment operator in templated function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
Dup.  I've posted a patch.

*** This bug has been marked as a duplicate of bug 94190 ***

[Bug lto/94311] New: LTO produces line info entries with invalid line numbers

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94311
   Summary: LTO produces line info entries with invalid line
numbers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Unfortunately this doesn't have a simple reproducer, but can be seen when
compiling valgrind:

$ wget https://sourceware.org/pub/valgrind/valgrind-3.15.0.tar.bz2
$ tar -xf valgrind-3.15.0.tar.bz2
$ cd valgrind-3.15
$ ./autogen.sh
$ ./configure --prefix=`pwd`/install --enable-only64bit --enable-lto
$ make install

then

$ ./install/bin/valgrind -q date

produces warnings like

   ==14497== warning: Can't handle line info entry with line number 177277754
greater than 1048575
   ==14497== (Nb: this message is only shown once)
   ==14497== warning: Can't handle inlined call info entry with line number
177277750 greater than 1048575 
   ==14497== (Nb: this message is only shown once)
Tue 24 Mar 2020 03:54:34 PM EDT

while with GCC 8 these warnings weren't issued.

[Bug target/94297] PPCLE std::replace internal compiler error

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Still can't reproduce with mainline trunk/9/8.

Since I happen to work on DTS, I've also tried
devtoolset-8-gcc-8.2.1-3.el7.ppc64le and devtoolset-8-gcc-8.3.1-3.2.el7.ppc64le
but couldn't reproduce it either.  Did you use any special options not
mentioned in this bug report?

[Bug c++/94190] [10 Regression] error: no post-decrement operator for type since r10-7096-gd417b4f5414d9076

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/94257] ICE in inline nested namespace

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This compiled without errors until
r8-952-g945bf9e13f706bed44ec760ac60693e00c59b146:

94257.C:4:18: error: conflicting declaration of namespace ‘B’
 inline namespace B {
  ^

and the ICE started with 
r8-1488-g71bbbd133f65c26f65709037401154362210560e

[Bug c++/94336] New: template keyword accepted before destructor names

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94336
   Summary: template keyword accepted before destructor names
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

We accept the following:

template void f(T *p) { p->template ~X(); }
template struct X {};
void g(X *p) { f(p); }

but arguably we shouldn't because [temp.names]/5: A name prefixed by the
keyword template shall be a template-id or the name shall refer to a class
template or an alias template.

[Bug c++/94336] template keyword accepted before destructor names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Marek Polacek  ---
Fixed.  I don't think I want to backport this one.  To make it work with G++ 9,
add the template keyword.

[Bug c++/94336] template keyword accepted before destructor names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542767.html

[Bug c++/94336] template keyword accepted before destructor names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #13 from Marek Polacek  ---
The fix hasn't been backported to gcc 8 but the problem exists there too. 
Martin, will you fix 8 too?

[Bug c++/94255] template specialization in different namespace causes crash

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-27

--- Comment #4 from Marek Polacek  ---
Confirmed, started with r0-113135-g28704289327e4295928663b5bab7953718f71bc1

[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Reduced:

template  struct A {
  int i;
  T t;
  constexpr A(int, T e) : i(), t(e) {}
};

void
f()
{
  A> g[1]({1, {1, 1}});
}

We ICE because we don't satisfy:
 4662   /* ??? Here's to hoping the front end fills in all of the indices,
 4663  so we don't have to figure out what's missing ourselves.  */
 4664   gcc_assert (purpose);

[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Even simpler:

struct S { int i, j; };

struct A {
  S s;
  constexpr A(S e) : s(e) {}
};

void
f()
{
  A g[1]({{1, 1}});
}

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Yep, bisected it to r241187.

[Bug c++/94404] New: [meta-bug] C++ core issues

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94404
   Summary: [meta-bug] C++ core issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This meta bug tracks open reports for various C++ DRs.

[Bug c++/94405] New: [temp.names]p4 not fully implemented

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94405
   Summary: [temp.names]p4 not fully implemented
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

<https://eel.is/c++draft/temp.names#4.sentence-2> says "In a qualified-id of a
declarator-id or in a qualified-id formed by a class-head-name or
enum-head-name, the keyword template shall not appear at the top level." so the
following probably shouldn't compile:

template struct A {
  template struct B;
  template struct B;
};
template template struct A::template B {};

[Bug c++/94415] New: Implement DR 2237: Can a template-id name a constructor?

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94415
   Summary: Implement DR 2237:  Can a template-id name a
constructor?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Implement <https://eel.is/c++draft/diff.cpp17.class#2>:

template
struct A {
  A();   // error: simple-template-id not allowed for constructor
  A(int);   // OK, injected-class-name used
  ~A();  // error: simple-template-id not allowed for destructor
};

Note this is not a DR against C++17, the above is only ill-formed in C++20
onwards.

[Bug c++/94415] Implement DR 2237: Can a template-id name a constructor?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-30
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Keywords||accepts-invalid

[Bug c++/94457] using ~VariableName in trailing return type deduction does not compile

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Marek Polacek  ---
g++ 5 is not supported anymore and all the supported versions work as expected,
so closing.

[Bug c++/93597] [9 Regression] ICE in get_fns since r10-6219

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Yes, will do it today, thanks.

[Bug c++/94470] [8/9/10 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|10.0|8.5

[Bug c++/94470] [8/9/10 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Priority|P3  |P2
   Keywords|ice-on-valid-code   |rejects-valid

[Bug c++/94475] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-03

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/94475] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10 Regression] ICE: tree   |[9/10 Regression] ICE: tree
   |check: expected class   |check: expected class
   |'type', have 'exceptional'  |'type', have 'exceptional'
   |(error_mark) in |(error_mark) in
   |element_mode, at|element_mode, at
   |tree.c:13813|tree.c:13813
   Target Milestone|--- |9.4

--- Comment #2 from Marek Polacek  ---
Started with r9-4974-gdfd7fdca2ac17d8b823a16700525824ca312ade0.

[Bug c++/94415] Implement DR 2237: Can a template-id name a constructor?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Marek Polacek  ---
Patch posted:

[Bug c++/93597] [9 Regression] ICE in get_fns since r10-6219

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Marek Polacek  ---
Fixed on 9 too.

[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/94489] ICE: unexpected expression ‘std::min’ of kind overload

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Keywords|ice-on-valid-code   |ice-on-invalid-code,
   ||needs-reduction

--- Comment #2 from Marek Polacek  ---
Doesn't seem like valid code; clang++ trunk also rejects it:
94489.C:28:61: error: no matching constructor for initialization of
'std::plus'

I think the fix should be

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3748,6 +3748,7 @@ expand_integer_pack (tree call, tree args, tsubst_flags_t
complain,
 }
   else
 {
+  hi = instantiate_non_dependent_expr_sfinae (hi, complain);
   hi = cxx_constant_value (hi);
   int len = valid_constant_size_p (hi) ? tree_to_shwi (hi) : -1;


but it'd be nice to have a reduced version.

[Bug c++/94489] ICE: unexpected expression ‘std::min’ of kind overload

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Likely still invalid, but it compiles without errors with the patch above.

template  struct S { };
template  using U = S;
template  constexpr long g(T) { return 1l; }
template> struct X { };

template
auto foo(T)
{
  []() {
  foo(1);
  X x;
  };
}

[Bug c++/94507] New: internal compiler error: tree check: expected template_decl, have error_mark in tsubst_lambda_expr

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94507
   Summary: internal compiler error: tree check: expected
template_decl, have error_mark in tsubst_lambda_expr
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct S { };

template
auto foo(T, U)
{
  [] <> () { foo (S{}, S{}); };
}

$ ./cc1plus -quiet -std=c++20 z.C
z.C: In function ‘auto foo(T, U)’:
z.C:6:7: error: expected identifier before ‘>’ token
6 |   [] <> () { foo (S{}, S{}); };
  |   ^
z.C: In instantiation of ‘auto foo(T, U) [with T = S; U = S]’:
z.C:6:27:   required from here
z.C:6:3: note: invalid template non-type parameter
6 |   [] <> () { foo (S{}, S{}); };
  |   ^~~~
z.C:6:3: internal compiler error: tree check: expected template_decl, have
error_mark in tsubst_lambda_expr, at cp/pt.c:18880
0x19afd31 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/mpolacek/src/gcc/gcc/tree.c:9727
0x912e6b tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3279
0xbe40a1 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:18880
0xbeb2fb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:20321
0xbe2d59 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:18614
0xbdb83f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17727
0xbdb5d1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17697
0xbde18e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:18015
0xc01c32 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:25539
0xc025eb instantiate_pending_templates(int)
/home/mpolacek/src/gcc/gcc/cp/pt.c:25655
0xa66864 c_parse_final_cleanups()
/home/mpolacek/src/gcc/gcc/cp/decl2.c:4874
0xd45bae c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.c:1212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/94507] [8/9/10 Regression] internal compiler error: tree check: expected template_decl, have error_mark in tsubst_lambda_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|internal compiler error:|[8/9/10 Regression]
   |tree check: expected|internal compiler error:
   |template_decl, have |tree check: expected
   |error_mark in   |template_decl, have
   |tsubst_lambda_expr  |error_mark in
   ||tsubst_lambda_expr
   Priority|P3  |P4
   Target Milestone|--- |8.5
   Keywords||error-recovery,
   ||ice-on-invalid-code