/* The character codes corresponding to all the access modes.  */
  static constexpr char mode_chars[5] = { '-', 'r', 'w', 'x', '^' };
Is this after building stage 1 or after building stage 2 ?

It's after stage1.  I'm bisecting.

Possibly a dup of PR100727?

This ICE was introduced by the following commit:

commit eb2a917fa0779b689f09ac8d8c41b0456facbe62 (HEAD)
Author: Martin Sebor <msebor@redhat.com>
Date:   Wed May 19 16:13:13 2021 -0600

    PR c/100619 - ICE on a VLA parameter with too many dimensions

    gcc/c-family/ChangeLog:

            PR c/100619
            * c-attribs.c (build_attr_access_from_parms): Handle arbitrarily many
            bounds.

Breakpoint 1, attr_access::from_mode_char (
    c=<error reading variable: Cannot access memory at address 0x0>)
    at ../../gcc/gcc/attribs.h:304
304       gcc_unreachable ();
(gdb) bt
#0  attr_access::from_mode_char (
    c=<error reading variable: Cannot access memory at address 0x0>)
    at ../../gcc/gcc/attribs.h:304
#1  0x4000000000a8311c in init_attr_rdwr_indices (rwm=0x800003fffdff14e0,
    attrs=0x800003fffdf1b9b0) at ../../gcc/gcc/attribs.c:2146
#2  0x4000000000d1e554 in warn_parm_array_mismatch (origloc=2147484671,
    fndecl=0x800003fffdf1b9b0, newparms=0x7ae4b8)
    at ../../gcc/gcc/c-family/c-warn.c:3369
#3  0x4000000000b5ebc0 in c_parser_declaration_or_fndef (
    parser=0x800003fffdff14e0, fndef_ok=128, static_assert_ok=false,
    empty_ok=true, nested=false, start_attr_ok=false,
    objc_foreach_object_declaration=0x4000000000887f48 <copy_list(tree_node*)::__FUNCTION__>, omp_declare_simd_clauses=..., have_attrs=false,
    attrs=0x800003fffdf1d700,
    oacc_routine_data=0x4000000002f7501f <fndecl_built_in_p(tree_node const*)+92>, fallthru_attr_p=0x800003fffdff17a0) at ../../gcc/gcc/c/c-parser.c:2342
#4  0x4000000000b5cb98 in c_parser_external_declaration (
    parser=0x800003fffdff14e0) at ../../gcc/gcc/c/c-parser.c:1777
#5  0x4000000000b5c240 in c_parser_translation_unit (parser=0x800003fffdff14e0)
    at ../../gcc/gcc/c/c-parser.c:1650
#6  0x4000000000bc644c in c_parse_file () at ../../gcc/gcc/c/c-parser.c:21994
#7  0x4000000000cafd10 in c_common_parse_file ()
    at ../../gcc/gcc/c-family/c-opts.c:1219
#8  0x40000000017db87c in compile_file () at ../../gcc/gcc/toplev.c:457
#9  0x40000000017e26e8 in do_compile () at ../../gcc/gcc/toplev.c:2203
#10 0x40000000017e2e68 in toplev::main (this=0x800003fffdff14e0,
    argc=-2147482625, argv=0x7ae4b8) at ../../gcc/gcc/toplev.c:2342
#11 0x4000000002abbee4 in main (argc=-2147482625, argv=0x800003fffdf1b9b0)
    at ../../gcc/gcc/main.c:39
(gdb) frame 1
#1  0x4000000000a8311c in init_attr_rdwr_indices (rwm=0x800003fffdff14e0,
    attrs=0x800003fffdf1b9b0) at ../../gcc/gcc/attribs.c:2146
2146              acc.mode = acc.from_mode_char (*m);
(gdb) p *m
$2 = 0 '\000'

(In reply to Richard Biener from comment #3)
> Possibly a dup of PR100727?

I think it is unrelated.

The problem is the fix for PR 100619, sets the attributes to be "+" but the code in attribs.c, skip over the '+' but does not check if it is the end of the string:
          /* Skip the internal-only plus sign.  */
          if (*m == '+')
            ++m;

          acc.str = m;
          acc.mode = acc.from_mode_char (*m);

(In reply to Andrew Pinski from comment #6)
> (In reply to Richard Biener from comment #3)
> > Possibly a dup of PR100727?
> 
> I think it is unrelated.
> 
> The problem is the fix for PR 100619, sets the attributes to be "+" but the
> code in attribs.c, skip over the '+' but does not check if it is the end of
> the string:

This patch might fix the ICE (sorry for the tab to spaces):
diff --git a/gcc/attribs.c b/gcc/attribs.c
index ebc0783c439..4adbe9fed5e 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -2140,7 +2140,10 @@ init_attr_rdwr_indices (rdwr_map *rwm, tree attrs)

          /* Skip the internal-only plus sign.  */
          if (*m == '+')
-           ++m;
+           {
+             ++m;
+             continue;
+           }

          acc.str = m;
          acc.mode = acc.from_mode_char (*m);

The plus character should always be followed by a nonempty string.  John, can you please attach a translation unit to see if by chance I can reproduce with a cross-compiler?  In parallel, I wonder if there's something funny about snprintf on HP-UX.  Does the snprintf call added in r12-930 do the right thing (i.e., append a nonempty string to spec)?

(In reply to John David Anglin from comment #5)
> Breakpoint 1, attr_access::from_mode_char (
>     c=<error reading variable: Cannot access memory at address 0x0>)
>     at ../../gcc/gcc/attribs.h:304
> 304       gcc_unreachable ();

This error says that &c is null.  c comes from the code below:

#1  0x4000000000a8311c in init_attr_rdwr_indices (rwm=0x800003fffdff14e0,
    attrs=0x800003fffdf1b9b0) at ../../gcc/gcc/attribs.c:2146

      mode = TREE_VALUE (mode);
      if (TREE_CODE (mode) != STRING_CST)
	continue;
      gcc_assert (TREE_CODE (mode) == STRING_CST);

      for (const char *m = TREE_STRING_POINTER (mode); *m; )

Either TREE_STRING_POINTER (mode) is null or mode is set to null after one of the calls to strtoul() later in the function.

Created attachment 50874 [details]
c-attribs.c.txt

On 2021-05-25 3:04 p.m., msebor at gcc dot gnu.org wrote:
> In parallel, I wonder if there's something funny about
> snprintf on HP-UX.  Does the snprintf call added in r12-930 do the right thing
> (i.e., append a nonempty string to spec)?
No.  When passed a size of 0, snprintf on hpux11.11 returns 0.  This issue is noted in Linux man page
for snprintf.

Attached a possible fix.

On 2021-05-26 3:32 p.m., dave.anglin at bell dot net wrote:
> Attached a possible fix.
While the patch fixes boot, pr100619.c fails:

spawn /test/gnu/gcc/objdir64/gcc/xgcc -B/test/gnu/gcc/objdir64/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr100619.c -fdiagnostics-plain-output
-Wall -S -o pr100619.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr100619.c:14:1: internal compiler error: Segmentation fault

Using libiberty snprintf and vsnprintf on hppa*-*-hpux* works.

The master branch has been updated by John David Anglin <danglin@gcc.gnu.org>:

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

commit r12-1240-ga0864ce8662bb9d715b51513697309f198f1da19
Author: John David Anglin <danglin@gcc.gnu.org>
Date:   Sat Jun 5 15:48:04 2021 +0000

    Use libiberty snprintf and vsnprintf on hppa*-*-hpux*.
    
    libiberty/ChangeLog:
    
            PR target/100734
            * configure.ac: Use libiberty snprintf and vsnprintf on
            hppa*-*-hpux*.
            * configure: Regenerate.

Fixed.

The releases/gcc-11 branch has been updated by John David Anglin <danglin@gcc.gnu.org>:

https://gcc.gnu.org/g:356390c14aa70a95c15845512f2381b627cf9a96

commit r11-9051-g356390c14aa70a95c15845512f2381b627cf9a96
Author: John David Anglin <danglin@gcc.gnu.org>
Date:   Fri Oct 1 17:18:32 2021 +0000

    Use libiberty snprintf and vsnprintf on hppa*-*-hpux*.
    
    libiberty/ChangeLog:
    
            PR target/100734
            * configure.ac: Use libiberty snprintf and vsnprintf on
            hppa*-*-hpux*.
            * configure: Regenerate.