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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppa...@gcc.gnu.org>:

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

commit r11-9794-ge95c514cadc4517b7910ead5f8c1dd5b4fd4d991
Author: Patrick Palka <ppa...@redhat.com>
Date:   Thu Feb 3 18:54:23 2022 -0500

    c++: dependence of member noexcept-spec [PR104079]

    Here a stale TYPE_DEPENDENT_P/_P_VALID value for f's function type
    after replacing the type's DEFERRED_NOEXCEPT with the parsed dependent
    noexcept-spec causes us to try to instantiate g's noexcept-spec ahead
    of time (since it in turn appears non-dependent), leading to an ICE.

    This patch fixes this by clearing TYPE_DEPENDENT_P_VALID in
    fixup_deferred_exception_variants appropriately (as in
    build_cp_fntype_variant).

    That turns out to fix the testcase for C++17 but not for C++11/14,
    because it's not until C++17 that a noexcept-spec is part of (and
    therefore affects dependence of) the function type.  Since dependence of
    NOEXCEPT_EXPR is defined in terms of instantiation dependence, the most
    appropriate fix for earlier dialects seems to be to make instantiation
    dependence consider dependence of a noexcept-spec.

            PR c++/104079

    gcc/cp/ChangeLog:

            * pt.c (value_dependent_noexcept_spec_p): New predicate split
            out from ...
            (dependent_type_p_r): ... here.
            (instantiation_dependent_r): Use value_dependent_noexcept_spec_p
            to consider dependence of a noexcept-spec before C++17.
            * tree.c (fixup_deferred_exception_variants): Clear
            TYPE_DEPENDENT_P_VALID.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/noexcept74.C: New test.
            * g++.dg/cpp0x/noexcept74a.C: New test.

    (cherry picked from commit 82e31c8973eb1a752c2ffd01005efe291d35cee3)
  • [Bug c++/104079] [9/10/11 Regr... cvs-commit at gcc dot gnu.org via Gcc-bugs

Reply via email to