Re: [PATCH] middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR

Re: [PATCH] middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR

[Jakub Jelinek]

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

[PATCH] middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR

[Richard Biener]

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