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

            Bug ID: 127295
           Summary: [c++26][contracts] ICE in grok_contract on the
                    __contract_assert extension spelling
           Product: gcc
           Version: 16.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: berne at notadragon dot com
  Target Milestone: ---

Created attachment 65540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65540&action=edit
ICE on __contract_assert, with the standard spelling as a control

GCC accepts __contract_assert as its own extension spelling of
contract_assert, and then ICEs on it.

```
void f(int x)
{
    __contract_assert(x > 0);   // ICE
}

// CONTROL: the standard spelling is fine, which is what places the defect in
// recognising the token rather than in assertion-statements generally.
void g(int x)
{
    contract_assert(x > 0);
}
```

```
$ ./gcc-16.2.0/bin/g++ -std=c++26 -fsyntax-only \
    contract-assert-alt-spelling-ice.cpp
contract-assert-alt-spelling-ice.cpp: In function 'void f(int)':
contract-assert-alt-spelling-ice.cpp:12:27: internal compiler error: in
grok_contract, at cp/contracts.cc:2068
   12 |     __contract_assert(x > 0);   // ICE
      |                           ^
0x78ce6002a1c9 __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x78ce6002a28a __libc_start_main_impl
        ../csu/libc-start.c:360
```

The standard spelling in g() is accepted, which is what places the defect in
recognising the token rather than in assertion-statements generally.

>From a trunk build (7dab38c9d71) configured the same way, but with -g, we
get a more complete stack trace:

```
0x24e67c5 internal_error(char const*, ...)
        /workarea/gnu_gcc_trunk/gcc/diagnostic-global-context.cc:787
0x824eb1 fancy_abort(char const*, int, char const*)
        /workarea/gnu_gcc_trunk/gcc/diagnostics/context.cc:1813
0x7bec9f grok_contract(tree_node*, tree_node*, tree_node*, cp_expr, unsigned
long)
        /workarea/gnu_gcc_trunk/gcc/cp/contracts.cc:2102
0x9a67b4 cp_parser_contract_assert
        /workarea/gnu_gcc_trunk/gcc/cp/parser.cc:33941
0x9a67b4 cp_parser_statement
        /workarea/gnu_gcc_trunk/gcc/cp/parser.cc:14457
0x9a7e9e cp_parser_statement_seq_opt
        /workarea/gnu_gcc_trunk/gcc/cp/parser.cc:15140
0x9a8097 cp_parser_compound_statement
        /workarea/gnu_gcc_trunk/gcc/cp/parser.cc:14987
0x9da51e cp_parser_function_body
        /workarea/gnu_gcc_trunk/gcc/cp/parser.cc:29010
0x9da51e cp_parser_ctor_initializer_opt_and_function_body
        /workarea/gnu_gcc_trunk/gcc/cp/parser.cc:29061
0x9a82ab cp_parser_function_definition_after_declarator
        /workarea/gnu_gcc_trunk/gcc/cp/parser.cc:36364
```

DISCOVERY

Found by an audit comparing every test in a C++26 contracts implementation's
own suite against stock trunk, looking for cases that pass locally because
they were fixed locally.  This one had been fixed without ever being
classified as upstream's.

ANALYSIS

c-common.cc maps both __contract_assert and the standard contract_assert to
RID_CONTASSERT, so the two arrive at grok_contract indistinguishably as far
as the parser is concerned.  grok_contract then tested only for the standard
spelling and fell off the end of its if/else chain into the trailing
assertion.

So this is an ICE on a spelling the compiler itself defines, reachable with
nothing but a C++26 mode.

VERSIONS -- all on x86_64-linux-gnu

  source              version                       ICE
  compiler-explorer   16.1.0                        yes (contracts.cc:2068)
  compiler-explorer   16.2.0                        yes (contracts.cc:2068)
  compiler-explorer   17.0.0 20260909, 919c0d16c91  yes (contracts.cc:2102)
  local build -g      17.0.0 20260909, 7dab38c9d71  yes (contracts.cc:2102)

```
$ ./gcc-16.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=./gcc-16.2.0/bin/g++
COLLECT_LTO_WRAPPER=/home/jberne4/repos/compilers/gcc-16.2.0/bin/../libexec/gcc/x86_64-linux-gnu/16.2.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-16.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,m2,rust,cobol,algol68
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.44
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.2.0 (Compiler-Explorer-Build-gcc--binutils-2.44)
```
  • [Bug c++/127295] New: [c++26][c... berne at notadragon dot com via Gcc-bugs

Reply via email to