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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Lewis Hyatt <lhy...@gcc.gnu.org>:

https://gcc.gnu.org/g:44ba7bcb752a40ec7490dea53d3a472ce633371d

commit r14-9561-g44ba7bcb752a40ec7490dea53d3a472ce633371d
Author: Lewis Hyatt <lhy...@gmail.com>
Date:   Wed Nov 8 16:13:14 2023 -0500

    diagnostics: Fix behavior of permerror options after diagnostic pop
[PR111918]

    When a diagnostic pragma changes the classification of a given diagnostic,
    the global options flags (such as warn_narrowing, etc.) may get changed
too.
    Specifically, if a warning was not enabled initially and was later enabled
    by a pragma, then the corresponding global flag will change from false to
    true when the pragma is processed. That change is permanent and is not
    undone by a subsequent `#pragma GCC diagnostic pop'; the warning flag needs
    to remain enabled since a diagnostic could be generated later on for a
    source location prior to the pop.

    So in order to support popping to the initial classification, given that
the
    global options flags no longer reflect that state, the diagnostic_context
    object itself remembers the way things were before it changed anything. The
    current implementation works fine for diagnostics that are always errors or
    always warnings, but it doesn't do the right thing for diagnostics that
    could be either, such as -Wnarrowing. The classification of that diagnostic
    (or any permerror diagnostic) depends on the state of -fpermissive; for the
    particular case of -Wnarrowing it also matters whether a compile-time or
    run-time narrowing is being diagnosed.

    The problem is that the current implementation insists on recording whether
    an enabled diagnostic should be a DK_WARNING or a DK_ERROR, and then, after
    popping to the initial state, it overrides it always to that type only. Fix
    that up by adding a new internal diagnostic type DK_ANY. This just
indicates
    that the diagnostic is enabled without mandating exactly what type of
    diagnostic it should be. Then the diagnostic can be emitted with whatever
    type the frontend asks for.

    Incidentally, while making this change, I noticed that
classify_diagnostic()
    spends some time computing a return value (the old classification kind)
that
    is not used anywhere. The computed value seems to have some problems,
mainly
    that it does not take into account `#pragma GCC diagnostic pop' at all, and
    so the returned value doesn't seem like it could make sense in many
    contexts. Given it would also not be desirable to leak the new
internal-only
    DK_ANY type to outside callers, I think it would make sense in a subsequent
    cleanup patch to remove the return value altogether.

    gcc/ChangeLog:

            PR c++/111918
            * diagnostic-core.h (enum diagnostic_t): Add DK_ANY special flag.
            * diagnostic.cc
(diagnostic_option_classifier::classify_diagnostic):
            Make use of DK_ANY to indicate a diagnostic was initially enabled.
            (diagnostic_context::diagnostic_enabled): Do not change the type of
            a diagnostic if the saved classification is type DK_ANY.

    gcc/testsuite/ChangeLog:

            PR c++/111918
            * g++.dg/cpp0x/Wnarrowing21a.C: New test.
            * g++.dg/cpp0x/Wnarrowing21b.C: New test.
            * g++.dg/cpp0x/Wnarrowing21c.C: New test.
            * g++.dg/cpp0x/Wnarrowing21d.C: New test.
  • [Bug c++/111918] #pragma GCC di... cvs-commit at gcc dot gnu.org via Gcc-bugs

Reply via email to