diff options
author | Jakub Jelinek <jakub@redhat.com> | 2025-04-01 11:40:58 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@gcc.gnu.org> | 2025-04-01 11:41:21 +0200 |
commit | a6c2248cfd4bc922378f554578ee44e6b4690f5d (patch) | |
tree | 0390afc04c6d861884a7cd72e8d4258132efa1d4 /gcc/rust/backend/rust-compile-expr.cc | |
parent | 2f58d8ac03911063d6a8887a2bee7b4e25ac1871 (diff) | |
download | gcc-a6c2248cfd4bc922378f554578ee44e6b4690f5d.zip gcc-a6c2248cfd4bc922378f554578ee44e6b4690f5d.tar.gz gcc-a6c2248cfd4bc922378f554578ee44e6b4690f5d.tar.bz2 |
gimple-low: Diagnose assume attr expressions defining labels which are used as unary && operands outside of those [PR119537]
The following testcases ICE on invalid code which defines
labels inside of statement expressions and then uses &&label
from code outside of the statement expressions.
The C++ FE diagnoses that with a warning (not specifically for
assume attribute, genericallly about taking address of a label
outside of a statement expression so computed goto could violate
the requirement that statement expression is not entered from
outside of it through a jump into it), the C FE doesn't diagnose
anything.
Normal direct gotos to such labels are diagnosed by both C and C++.
In the assume attribute case it is actually worse than for
addresses of labels in normal statement expressions, in that case
the labels are still in the current function, so invalid program
can still jump to those (and in case of OpenMP/OpenACC where it
is also invalid and stuff is moved to a separate function, such
movement is done post cfg discovery of FORCED_LABELs and worst
case one can run into cases which fail to assemble, but I haven't
succeeded in creating ICE for that).
For assume at -O0 we'd just throw away the assume expression if
it is not a simple condition and so the label is then not defined
anywhere and we ICE during cfg pass.
The gimplify.cc hunks fix that, as we don't have FORCED_LABELs
discovery done yet, it preserves all assume expressions which contain
used user labels.
With that we ICE during IRA, which is upset about an indirect jump
to a label which doesn't exist.
So, the gimple-low.cc hunks add diagnostics of the problem, it gathers
uids of all the user used labels inside of the assume expressions (usually
none) and if it finds any, walks the IL to find uses of those from outside
of those expressions now outlined into separate magic functions.
2025-04-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/119537
* gimplify.cc (find_used_user_labels): New function.
(gimplify_call_expr): Don't remove complex assume expression at -O0
if it defines any user labels.
* gimple-low.cc: Include diagnostic-core.h.
(assume_labels): New variable.
(diagnose_assume_labels): New function.
(lower_function_body): Call it via walk_gimple_seq if assume_labels
is non-NULL, then BITMAP_FREE assume_labels.
(find_assumption_locals_r): Record in assume_labels uids of user
labels defined in assume attribute expressions.
* c-c++-common/pr119537-1.c: New test.
* c-c++-common/pr119537-2.c: New test.
Diffstat (limited to 'gcc/rust/backend/rust-compile-expr.cc')
0 files changed, 0 insertions, 0 deletions