[Bug c++/98538] New: [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[Bug c++/98538] New: [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[doko at debian dot org]

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

            Bug ID: 98538
           Summary: [11 Regression] ICE in cp_build_qualified_type_real,
                    at cp/tree.c:1335
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20210102, building krita:

$ cat KoOptimizedCompositeOpFactory.ii
template <typename U, long> using CArray = U[];
template <typename U, long Extent, const CArray<U, Extent>

$ g++ -std=gnu++11 -Wall -c -O0 KoOptimizedCompositeOpFactory.ii 
KoOptimizedCompositeOpFactory.ii:2:42: internal compiler error: in
cp_build_qualified_type_real, at cp/tree.c:1335
    2 | template <typename U, long Extent, const CArray<U, Extent>
      |                                          ^~~~~~~~~~~~~~~~~
0x6133b4 cp_build_qualified_type_real(tree_node*, int, int)
        ../../src/gcc/cp/tree.c:1335
0x1302fc2 cp_build_qualified_type_real(tree_node*, int, int)
        ../../src/gcc/cp/tree.c:1307
0x1302fc2 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
        ../../src/gcc/cp/decl.c:11806
0x13b3bb4 cp_parser_template_parameter
        ../../src/gcc/cp/parser.c:17008
0x13b3bb4 cp_parser_template_parameter_list
        ../../src/gcc/cp/parser.c:16569
0x13b336c cp_parser_explicit_template_declaration
        ../../src/gcc/cp/parser.c:30247
0x12ec6ec cp_parser_declaration
        ../../src/gcc/cp/parser.c:14006
0x17e4663 cp_parser_toplevel_declaration
        ../../src/gcc/cp/parser.c:14104
0x17e4663 cp_parser_translation_unit
        ../../src/gcc/cp/parser.c:4936
0x17e4663 c_parse_file()
        ../../src/gcc/cp/parser.c:45118
0x17c602a c_common_parse_file()
        ../../src/gcc/c-family/c-opts.c:1211
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

building is configured with --enable-checking=yes,extra,rtl

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org,
                   |                            |nathan at gcc dot gnu.org
           Priority|P3                          |P1
   Target Milestone|---                         |11.0
   Last reconfirmed|                            |2021-01-05
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r11-5825.

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Valid test:

template <typename U, long> using CArray = U[];
template <typename U, long Extent, const CArray<U, Extent>> struct X { };

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Extended test:

template<typename T> using A = int[1];
template<typename T, const A<T>> struct X { };

template<typename T>
void
f (const A<T>)
{
  const A<T> a;
}

template<typename T>
struct Y {
  const A<T> a;
};

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Oops, I hadn't noticed that this PR has an assignee, since it's still in NEW. 
Anyway, this was my patch:

--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1341,7 +1341,9 @@ cp_build_qualified_type_real (tree type,
       if (!t)
    {
      gcc_checking_assert (TYPE_DEPENDENT_P_VALID (type)
-                  || !dependent_type_p (type));
+                  || !dependent_type_p (type)
+                  || dependent_alias_template_spec_p (type,
+                                  nt_opaque));
      t = build_cplus_array_type (element_type, TYPE_DOMAIN (type),
                      TYPE_DEPENDENT_P (type));

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

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

--- Comment #5 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
I don;t think your patch is quite right.  the call afterwards is making the
assumption that DEPENDENT_TYPE_P is only ever set when DEPENDENT_TYPE_P_VALID
is true, and as I discovered, that is not correct.    see this code near
pt.c:14899

     set_underlying_type (r);
            if (TYPE_DECL_ALIAS_P (r))
              /* An alias template specialization can be dependent
                 even if its underlying type is not.  */
              TYPE_DEPENDENT_P_VALID (TREE_TYPE (r)) = false;
          }

I did wonder if we should just recalculate properly there though ...

'tis annoying that 'taking' a bug does not put it in the assigned state :(

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathan Sidwell <nathan@gcc.gnu.org>:

https://gcc.gnu.org/g:9beb6d88effdab4209beb8bc5e4b8773317f1d33

commit r11-6741-g9beb6d88effdab4209beb8bc5e4b8773317f1d33
Author: Nathan Sidwell <nathan@acm.org>
Date:   Fri Jan 15 11:38:43 2021 -0800

    c++: Fix qualified array-type construction [PR 98538]

    This was an assert that was too picky.  The reason I had to alter
    array construction was that on stream in, we cannot dynamically determine
    a type's dependentness.  Thus on stream out of the 'problematic' types,
    we save the dependentness for reconstruction.  Fortunately the paths into
    cp_build_qualified_type_real from streamin with arrays do have the array's
    dependentess set as needed.

            PR c++/98538
            gcc/cp/
            * tree.c (cp_build_qualified_type_real): Propagate an array's
            dependentness to the copy, if known.
            gcc/testsuite/
            * g++.dg/template/pr98538.C: New.

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
9beb6d88eff 2021-01-15 | c++: Fix qualified array-type construction [PR 98538]

[Bug c++/98538] [11 Regression] ICE in cp_build_qualified_type_real, at cp/tree.c:1335

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #5)
> I don;t think your patch is quite right.  the call afterwards is making the
> assumption that DEPENDENT_TYPE_P is only ever set when
> DEPENDENT_TYPE_P_VALID is true, and as I discovered, that is not correct.
> see this code near pt.c:14899
> 
>      set_underlying_type (r);
> 	    if (TYPE_DECL_ALIAS_P (r))
> 	      /* An alias template specialization can be dependent
> 		 even if its underlying type is not.  */
> 	      TYPE_DEPENDENT_P_VALID (TREE_TYPE (r)) = false;
> 	  }

Right, that's what lead me to tweaking the assert to not crash for alias
template specializations.

But I like your patch better.

> I did wonder if we should just recalculate properly there though ...
> 
> 'tis annoying that 'taking' a bug does not put it in the assigned state :(

Indeed :/.

Thanks for fixing this.