[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer

redi at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Aug 5 09:12:28 GMT 2021


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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed by r11-7289:

    c++: Tweak PR969626 patch

    It occurred to me that other types of conversions use
rvaluedness_matches_p,
    but those uses don't affect overload resolution, so we shouldn't look at
the
    flag for them.  Fixing that made decltype64.C compile successfully, because
    the non-template candidate was a perfect match, so we now wouldn't consider
    the broken template.  Changing the argument to const& makes it no longer a
    perfect match (because of the added const), so we again get the infinite
    recursion.

    This illustrates the limited nature of this optimization/recursion break;
it
    works for most copy/move constructors because the constructor we're looking
    for is almost always a perfect match.  If it happens to help improve
compile
    time for other calls, that's just a bonus.

    gcc/cp/ChangeLog:

            PR c++/96926
            * call.c (perfect_conversion_p): Limit rvalueness
            test to reference bindings.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/decltype64.C: Change argument to const&.

Which was a follow-up to r11-7287:

    c++: Tuple of self-dependent classes [PR96926]

    When compiling this testcase, trying to resolve the initialization for the
    tuple member ends up recursively considering the same set of tuple
    constructor overloads, and since two of them separately depend on
    is_constructible, the one we try second fails to instantiate
    is_constructible because we're still in the middle of instantiating it the
    first time.

    Fixed by implementing an optimization that someone suggested we were
already
    doing: if we see a non-template candidate that is a perfect match for all
    arguments, we can skip considering template candidates at all.  It would be
    enough to do this only when LOOKUP_DEFAULTED, but it shouldn't hurt in
other
    cases.

    gcc/cp/ChangeLog:

            PR c++/96926
            * call.c (perfect_conversion_p): New.
            (perfect_candidate_p): New.
            (add_candidates): Ignore templates after a perfect non-template.

    gcc/testsuite/ChangeLog:

            PR c++/96926
            * g++.dg/cpp0x/overload4.C: New test.

Thi might be a dup of PR 96926 but we could add the testcase to be sure.


More information about the Gcc-bugs mailing list