Message ID | BF230D13CA30DD48930C31D4099330003A42A186@FMSMSX101.amr.corp.intel.com |
---|---|
State | New |
Headers | show |
> ... This patch pasted below should fix that issue. ...
A quick test on darwin (no bootstrap, no full regtest) with
make -k check-gcc RUNTESTFLAGS="cilk-plus.exp --target_board=unix'{-m32,-m64}'"
gives
=== gcc Summary for unix/-m64 ===
# of expected passes 2904
=== gcc Summary ===
# of expected passes 5808
So the patch fixes the darwin issue.
Thanks,
Dominique
> -----Original Message----- > From: Dominique Dhumieres [mailto:dominiq@lps.ens.fr] > Sent: Saturday, June 01, 2013 2:35 AM > To: gcc-patches@gcc.gnu.org; Iyer, Balaji V > Cc: dominiq@lps.ens.fr > Subject: Re: [PATCH] fix for pr 57474 > > > ... This patch pasted below should fix that issue. ... > > A quick test on darwin (no bootstrap, no full regtest) with make -k check-gcc > RUNTESTFLAGS="cilk-plus.exp --target_board=unix'{-m32,-m64}'" > gives > > === gcc Summary for unix/-m64 === > > # of expected passes 2904 > > === gcc Summary === > > # of expected passes 5808 > > So the patch fixes the darwin issue. Thanks for confirming this. Is this OK for trunk? Balaji V. Iyer. > > Thanks, > > Dominique
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? jeff
> -----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
On 06/03/2013 02:34 PM, Iyer, Balaji V wrote: > > >> -----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) OK. The patch is fine in that case. Thanks, jeff
diff --git gcc/c/c-array-notation.c gcc/c/c-array-notation.c index 5376e6b..7fbd573 100644 --- gcc/c/c-array-notation.c +++ gcc/c/c-array-notation.c @@ -1547,7 +1547,10 @@ build_array_notation_expr (location_t location, tree lhs, tr } else for (jj = 0; jj < rhs_rank; jj++) - rhs_vector[ii][jj] = false; + { + rhs_vector[ii][jj] = false; + rhs_length[ii][jj] = NULL_TREE; + } } if (length_mismatch_in_expr_p (EXPR_LOCATION (lhs), lhs_length, @@ -1561,6 +1564,7 @@ build_array_notation_expr (location_t location, tree lhs, tre if (lhs_list_size > 0 && rhs_list_size > 0 && lhs_rank > 0 && rhs_rank > 0 && TREE_CODE (lhs_length[0][0]) == INTEGER_CST + && rhs_length[0][0] && TREE_CODE (rhs_length[0][0]) == INTEGER_CST) { HOST_WIDE_INT l_length = int_cst_value (lhs_length[0][0]);