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. Thanks Alfie > > Thanks, > Tamar > > > > /* Create an expression for the first address accessed by this load > > -- > > 2.34.1 > -- Alfie Richards
