This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] fix for pr 57474
- From: "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "dominiq at lps dot ens dot fr" <dominiq at lps dot ens dot fr>
- Date: Mon, 3 Jun 2013 20:34:00 +0000
- Subject: RE: [PATCH] fix for pr 57474
- References: <BF230D13CA30DD48930C31D4099330003A42A186 at FMSMSX101 dot amr dot corp dot intel dot com> <51ACF3B7 dot 2020608 at redhat dot com>
> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
> owner@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Monday, June 03, 2013 3:51 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; dominiq@lps.ens.fr
> Subject: Re: [PATCH] fix for pr 57474
>
> On 05/31/2013 06:28 PM, Iyer, Balaji V wrote:
> > Hello Everyone,
> > PR reports that sec_implicit2 and sec_implicit regression tests were
> failing in darwin. I looked into it and it is due to an uninitialized variable
> (rhs_length). This patch pasted below should fix that issue. Is this OK for trunk?
> >
> > Here are the ChangeLog entries:
> >
> > 2013-05-31 Balaji V. Iyer <balaji.v.iyer@intel.com>
> > PR c/57474
> > * c-array-notation.c (build_array_notation_expr): Initialized rhs_length
> > array to NULL_TREE if they are unused. Also added a check for the
> > field to be NULL before its fields are used in future.
> Does lhs_length need similar initialization & checks? If not, why?
The only reason why we will get to this spot is if we have the following :
E.g. X[:] = Z + Y[:]
Where Z is an expression with rank 0.
The reason why we do not need to check for null length for LHS is because we cannot have such a scenario: (e.g. Z+Y = Q is invalid)
Thanks,
Balaji V. Iyer.
>
> jeff