On 09/06/2026 14:24, Richard Biener wrote:
On Thu, 21 May 2026, Alfie Richards wrote:
The 05/21/2026 16:23, Tamar Christina wrote:
Hi Alfie,
-----Original Message-----
From: Alfie Richards <[email protected]>
Sent: 21 May 2026 15:38
To: [email protected]
Cc: [email protected]; Tamar Christina <[email protected]>;
[email protected]; [email protected]; [email protected]; Alfie
Richards <[email protected]>
Subject: [PATCH 1/2] vect: add null check for ptr_incr optional in
vect_create_data_ref_ptr
gcc/ChangeLog:
* tree-vect-data-refs.cc (vect_create_data_ref_ptr): Check for null
pntr_incr.
---
gcc/tree-vect-data-refs.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index da65f1d652c..9ec21429686 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -5841,7 +5841,8 @@ vect_create_data_ref_ptr (vec_info *vinfo,
stmt_vec_info stmt_info,
{
gcc_assert (bb_vinfo);
only_init = true;
- *ptr_incr = NULL;
+ if (ptr_incr)
+ *ptr_incr = NULL;
}
It seems odd that we can get here with ptr_incr being null. Under what
circumstances does this happen?
Before the next patch it doesn't happen.
However it seems this function was at one point written to handle the
case there it is NULL as all other derefrences are guarded and it seems
this one was missed? So I think it is a simple and consistent change.
Does it work to perform the NULL init unconditionally then? It's
currently only done for BB vectorization which implies that for
some reason a non-NULL ptr_incr was asserted there? In fact we
currently never pass NULL, even for loop vect.
I was getting ICE's from this dereference with the next patch.
That patch passes in NULL for ptr_incr in most cases.
And yes, the vect_create_data_ref_ptr / bump_vector_ptr pair of APIs
are a bit bloated ...
Thanks
Alfie
Thanks,
Tamar
/* Create an expression for the first address accessed by this load
--
2.34.1
