The documentation for the REG_EH_REGION could easily be read
(especially by non-native speakers) to indicate that it should be
attached to insn at the destination of an excpetion edge. Despite the
original text saying that the note "specifies the destination," it is
actually always attached to the source instruction.
This updates the documentation to make it clear that the REG_EH_REGION
note is always attached to instructions originating an exception edge
and that the value of the note specifies where the exception edge
leads to.
gcc/ChangeLog:
* doc/cfg.texi: Update the exception handling section for the
REG_EH_REGION notes to make it clear that the note is attached
to the instruction throwing the exception.
Co-Developed-by: Philipp Tomsich <philipp.toms...@vrull.eu>
---
gcc/doc/cfg.texi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/cfg.texi b/gcc/doc/cfg.texi
index b8c6427c076..bbd66946b75 100644
--- a/gcc/doc/cfg.texi
+++ b/gcc/doc/cfg.texi
@@ -297,10 +297,12 @@ edge. The opposite conversion is difficult, but should
not happen
anyway. The edges can be eliminated via @code{purge_dead_edges} call.
@findex REG_EH_REGION, EDGE_ABNORMAL_CALL
-In the RTL representation, the destination of an exception edge is
-specified by @code{REG_EH_REGION} note attached to the insn.
-In case of a trapping call the @code{EDGE_ABNORMAL_CALL} flag is set
-too. In the @code{GIMPLE} representation, this extra flag is not set.
+In the RTL representation, a @code{REG_EH_REGION} note is attached to
+an instruction that can throw an exception. The destination of the
+exception edge originating at such an instruction is specified by the
+value of the @code{REG_EH_REGION} note. In case of a trapping call
+the @code{EDGE_ABNORMAL_CALL} flag is set too. In the @code{GIMPLE}
+representation, this extra flag is not set.
@findex may_trap_p, tree_could_trap_p
In the RTL representation, the predicate @code{may_trap_p} may be used
--
2.48.1
