[Bug c++/96137] New: [11 Regression] GCC hang on in invalid function definition

[Bug c++/96137] New: [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

            Bug ID: 96137
           Summary: [11 Regression] GCC hang on in invalid function
                    definition
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This simple code makes GCC-trunk hang on. The memory seems ok, only with
endless compiling.

$cat bug.cc
void a () { .operator b }

$g++ bug.cc
bug.cc: In function ‘void a()’:
bug.cc:1:13: error: expected primary-expression before ‘.’ token
    1 | void a () { .operator b }
      |             ^
...

I tested the trunk version:
GCC version 11.0.0 20200708 (experimental) (GCC) 

The GCC-10 or GCC-9 compiles this as normal. I guess this is a regression
issue?

Thanks,
Haoxin

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu <haoxintu at gmail dot com> ---
Also, I want to know are those cases (invalid code but makes GCC hang on) worth
reporting? If those cases can help improve the GCC FE or its performance, I
will continue to file more reports. Otherwise, I will just stop doing that.

Thanks

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[mpolacek at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-09
             Status|UNCONFIRMED                 |ASSIGNED
   Target Milestone|---                         |11.0
           Keywords|                            |compile-time-hog
                 CC|                            |mpolacek at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with my:
r11-86-gef3479afc5ab415f00a53fc6f6a990df7f6a0747

(In reply to Haoxin Tu from comment #1)
> Also, I want to know are those cases (invalid code but makes GCC hang on)
> worth reporting? If those cases can help improve the GCC FE or its
> performance, I will continue to file more reports. Otherwise, I will just
> stop doing that.

I would treat them just like ICEs.  They are useful if the testcase isn't
complete garbage.  This one is sort of useful because it shows that my change
above has a corner case that I didn't consider.

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

--- Comment #3 from Haoxin Tu <haoxintu at gmail dot com> ---
(In reply to Marek Polacek from comment #2)

> I would treat them just like ICEs.  They are useful if the testcase isn't
> complete garbage.  This one is sort of useful because it shows that my
> change above has a corner case that I didn't consider.

Ok, I got it. Thank you, Marek.

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

--- Comment #4 from Haoxin Tu <haoxintu at gmail dot com> ---
Add two cases. I guess the reason is the same.

//case1
static_assert (->operator a, "")

//case2
alignas (->operator a)

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
A more realistic test:

void
fn ()
{
  X.operator T();
}

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-6967-gf8f5388c9e94d4324c31d82b335fa138518e3171
Author: Marek Polacek <polacek@redhat.com>
Date:   Thu Jan 28 22:18:32 2021 -0500

    c++: Fix infinite looping with invalid operator [PR96137]

    My r11-86 adjusted cp_parser_class_name to do

    -  scope = parser->scope;
    +  scope = parser->scope ? parser->scope : parser->context->object_type;
       if (scope == error_mark_node)
         return error_mark_node;

    but that caused endless looping in cp_parser_type_specifier_seq (the
    while (true) loop) in this invalid test, because we never set a parser
    error, therefore cp_parser_type_specifier returned error_mark_node
    instead of NULL_TREE, and we never issued the "expected type-specifier"
    error.

    At first I thought I'd just add cp_parser_simulate_error right before
    the return, but that regresses crash81.C -- we'd emit multiple errors
    for "T::X".  So the next best thing seemed to revert to pre-r11-86
    behavior: return early when parser->scope is bad, otherwise proceed to
    get the parser error.

    gcc/cp/ChangeLog:

            PR c++/96137
            * parser.c (cp_parser_class_name): If parser->scope is
            error_mark_node, return it, otherwise continue.

    gcc/testsuite/ChangeLog:

            PR c++/96137
            * g++.dg/parse/error63.C: New test.

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.