* [PATCH] middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR
@ 2024-04-16 14:00 Richard Biener
0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2024-04-16 14:00 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek
Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
(but -fsanitize=undefined does nothing). That's not consistent
with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
with -ftrapv. Both are because of the way we select whether to use
the trapping or the non-trapping optab - we look at the result type
of the expression and check
trapv = INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type);
the bugreport correctly complains that -ftrapv affects pointer
subtraction (there's no -ftrapv-pointer). Now that we have
POINTER_DIFF_EXPR we can honor that appropriately.
The patch moves both POINTER_DIFF_EXPR and POINTER_PLUS_EXPR
handling so they will never consider trapping (or saturating)
optabs.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK for stage1?
Thanks,
Richard.
PR middle-end/13421
* optabs-tree.cc (optab_for_tree_code): Do not consider
{add,sub}v or {us,ss}{add,sub} optabs for POINTER_DIFF_EXPR
or POINTER_PLUS_EXPR.
---
gcc/optabs-tree.cc | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gcc/optabs-tree.cc b/gcc/optabs-tree.cc
index e7bd0d10892..b69a5bc3676 100644
--- a/gcc/optabs-tree.cc
+++ b/gcc/optabs-tree.cc
@@ -135,6 +135,12 @@ optab_for_tree_code (enum tree_code code, const_tree type,
case MIN_EXPR:
return TYPE_UNSIGNED (type) ? umin_optab : smin_optab;
+ case POINTER_PLUS_EXPR:
+ return add_optab;
+
+ case POINTER_DIFF_EXPR:
+ return sub_optab;
+
case REALIGN_LOAD_EXPR:
return vec_realign_load_optab;
@@ -249,13 +255,11 @@ optab_for_tree_code (enum tree_code code, const_tree type,
trapv = INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type);
switch (code)
{
- case POINTER_PLUS_EXPR:
case PLUS_EXPR:
if (TYPE_SATURATING (type))
return TYPE_UNSIGNED (type) ? usadd_optab : ssadd_optab;
return trapv ? addv_optab : add_optab;
- case POINTER_DIFF_EXPR:
case MINUS_EXPR:
if (TYPE_SATURATING (type))
return TYPE_UNSIGNED (type) ? ussub_optab : sssub_optab;
--
2.35.3
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR
[not found] <36467.124041610010004075@us-mta-690.us.mimecast.lan>
@ 2024-04-16 14:06 ` Jakub Jelinek
0 siblings, 0 replies; 2+ messages in thread
From: Jakub Jelinek @ 2024-04-16 14:06 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
On Tue, Apr 16, 2024 at 04:00:59PM +0200, Richard Biener wrote:
> Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
> (but -fsanitize=undefined does nothing). That's not consistent
> with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
> with -ftrapv. Both are because of the way we select whether to use
> the trapping or the non-trapping optab - we look at the result type
> of the expression and check
>
> trapv = INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type);
>
> the bugreport correctly complains that -ftrapv affects pointer
> subtraction (there's no -ftrapv-pointer). Now that we have
> POINTER_DIFF_EXPR we can honor that appropriately.
>
> The patch moves both POINTER_DIFF_EXPR and POINTER_PLUS_EXPR
> handling so they will never consider trapping (or saturating)
> optabs.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK for stage1?
>
> Thanks,
> Richard.
>
> PR middle-end/13421
> * optabs-tree.cc (optab_for_tree_code): Do not consider
> {add,sub}v or {us,ss}{add,sub} optabs for POINTER_DIFF_EXPR
> or POINTER_PLUS_EXPR.
LGTM.
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-04-16 14:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-16 14:00 [PATCH] middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR Richard Biener
[not found] <36467.124041610010004075@us-mta-690.us.mimecast.lan>
2024-04-16 14:06 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).