]> git.ipfire.org Git - thirdparty/gcc.git/commit
Clarify that effective-targets 'exceptions' and 'exceptions_enabled' are orthogonal
authorThomas Schwinge <tschwinge@baylibre.com>
Thu, 6 Feb 2025 21:46:51 +0000 (22:46 +0100)
committerThomas Schwinge <tschwinge@baylibre.com>
Sat, 8 Feb 2025 11:34:01 +0000 (12:34 +0100)
commit9f4feba699f3b3fef29bc8199db69a8eb7d64d07
treefd45c5d710f8aaab58ee11ad30947ca25bb82679
parent0e602b2315f3cdf9a50441b28cabb8b204827492
Clarify that effective-targets 'exceptions' and 'exceptions_enabled' are orthogonal

In Subversion r268025 (Git commit 3f21b8e3f7be32dd2b3624a2ece12f84bed545bb)
"Add dg-require-effective-target exceptions", effective-target 'exceptions'
was added, which "says that AMD GCN does not support [exception handling]".

In Subversion r279246 (Git commit a9046e9853024206bec092dd63e21e152cb5cbca)
"MSP430: Add -fno-exceptions multilib", effective-target 'exceptions_enabled'
was added "to check if the testing configuration supports exceptions".  Testing
"if exceptions are unsupported or disabled (e.g. by passing -fno-exceptions)"
works as expected if exception handling is disabled at the front-end level
('-fno-exceptions'; the "exceptions are [...] disabled" case):

    exceptions_enabled2066068.cc: In function ‘void foo()’:
    exceptions_enabled2066068.cc:3:27: error: exception handling disabled, use ‘-fexceptions’ to enable

However, effective-target 'exceptions_enabled' additionally assumes that
"If exceptions aren't supported [by the target], then they're not enabled".
This is not correct: it's not unlikely that, in presence of explicit/implicit
'-fexceptions', exception handling code gets fully optimized away by the
compiler, and therefore effective-target 'exceptions_enabled' test cases may
PASS even for targets that don't support effective-target 'exceptions'; these
two effective-targets are orthogonal concepts.

(For completeness: code with trivial instances of C++ exception handling may
translate into simple '__cxa_allocate_exception', '__cxa_throw' function calls
without requiring any back end-level "exceptions magic", and then trigger
unresolved symbols at link time, if these functions are not available.)

This change only affects GCN, as that one currently is the only target declared
as not supporting effective-target 'exceptions'.

gcc/
* doc/sourcebuild.texi (Effective-Target Keywords): Clarify that
effective-target 'exceptions' and 'exceptions_enabled' are
orthogonal.
gcc/testsuite/
* lib/gcc-dg.exp (gcc-dg-prune): Clarify effective-target
'exceptions_enabled'.
* lib/target-supports.exp
(check_effective_target_exceptions_enabled): Don't consider
effective-target 'exceptions'.
libstdc++-v3/
* testsuite/lib/prune.exp (libstdc++-dg-prune): Clarify
effective-target 'exceptions_enabled'.
gcc/doc/sourcebuild.texi
gcc/testsuite/lib/gcc-dg.exp
gcc/testsuite/lib/target-supports.exp
libstdc++-v3/testsuite/lib/prune.exp