Confirmed, reduced:

template <class T>
struct lit {
  lit(T) { }
};

template <class T>
int operator+(lit<T>, lit<T>) {
  return 0;
}

auto r2 = (lit(0)) + lit(0);



11 | auto r2 = (lit(0)) + lit(0);
   |            ^~~
ctad.cc:2:8: note: 'template<class T> struct lit' declared here
2 | struct lit {
  |        ^~~

Oops, I missed the first line of the diagnostic. The error from trunk is:


ctad.cc:11:12: error: missing template arguments after 'lit'
11 | auto r2 = (lit(0)) + lit(0);
   |            ^~~
ctad.cc:2:8: note: 'template<class T> struct lit' declared here
2 | struct lit {
  |        ^~~

*** Bug 87712 has been marked as a duplicate of this bug. ***

There is a pretty good (speculative) analysis of this issue here: https://stackoverflow.com/a/52986284/331785
I am copying it to here for completeness, but credit for this goes to the author of that post:

There are two kinds of expressions that look similar but have vastly different meaning:

(type) + expr
(expr) + expr

The first is a C-style cast expression, that converts the unary expression + expr to type, the second is a binary expression that performs addition.

To disambiguate an expression of form (something) + expr, GCC first assumes that something is a type and does a tentative parse. If that succeeds, then the whole expression is treated as a cast expression, otherwise, something is reparsed as an expression.

Now here's where I think the bug resides: during the tentative parse, GCC wrongly believes that class template argument deduction (CTAD) cannot appear, so it issues an error when it appears. But in fact, even though the tentative parse will definitely fail in this case, something may still be a valid function-style cast expression, and thus the reparse might be successful.

For cat((lit('b')), lit('d')), lit('b') + lit('d'), and (lit('b')), GCC is clever enough to see that they can't be C-style cast expression, so it does not do the tentative parse. For (lit<char>('b')) + lit('d'), there's no CTAD in lit<char>('b'), so it is fine as well.

Prove of the above analysis:

If + is changed to / (or most operators other than -, * or &), no error occurs, because (something) / expr can't be a valid cast expression.

Similar ambiguity exists in sizeof(something) (could be sizeof(type) or sizeof(expr)), and as expected, sizeof(lit(0)) triggers a similar error.

*** Bug 88020 has been marked as a duplicate of this bug. ***

From Bug 88020:

template <class T>
struct S{
    S(T){}
};
static_assert(sizeof(S{0}));



<source>:5:22: error: missing template arguments after 'S'
 static_assert(sizeof(S{0}));
                      ^
<source>:2:8: note: 'template<class T> struct S' declared here
 struct S{
        ^

*** Bug 89220 has been marked as a duplicate of this bug. ***

This was ASSIGNED but no actual assignee.

Whoops, sorry about that, I meant to assign myself.  Trying again..

The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:5f1a2cb9c2dc09eed53da5d5787d14bec700b10b

commit r12-99-g5f1a2cb9c2dc09eed53da5d5787d14bec700b10b
Author: Patrick Palka <ppalka@redhat.com>
Date:   Sat Apr 24 00:01:42 2021 -0400

    c++: Hard error with tentative parse and CTAD [PR87709]
    
    When parsing e.g. the operand of sizeof, where both types and
    expressions are accepted, if during the tentative type parse we
    encounter an unexpected template placeholder, we must simulate
    an error rather than issue a real error because the expression
    parse can still succeed.
    
    gcc/cp/ChangeLog:
    
            PR c++/87709
            * parser.c (cp_parser_type_id_1): If we see a template
            placeholder, first try simulating an error before issuing
            a real error.
    
    gcc/testsuite/ChangeLog:
    
            PR c++/87709
            * g++.dg/cpp1z/class-deduction86.C: New test.

Fixed.

*** Bug 96878 has been marked as a duplicate of this bug. ***

*** Bug 88762 has been marked as a duplicate of this bug. ***