> -----Original Message-----
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Friday, May 31, 2013 11:50 AM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
> Subject: Re: [PATCH] pr57457
>
> On 05/31/2013 07:54 AM, Iyer, Balaji V wrote:
> > Hello Everyone,
> > This patch will fix a bug reported in PR57457. One of the array notation
> function was not checking for NULL_TREE before accessing its fields. This
> patch
> should fix that issue. A test case is also added.
> >
> > Is this OK for trunk?
> >
> > Here are the ChangeLog Entries:
> >
> > gcc/c/ChangeLog
> > 2013-05-31 Balaji V. Iyer <balaji.v.i...@intel.com>
> >
> > * c-array-notation.c (is_cilkplus_reduce_builtin): Added a check
> > for
> > NULL_TREE parameter input.
> >
> > gcc/testsuite/ChangeLog
> > 2013-05-31 Balaji V. Iyer <balaji.v.i...@intel.com>
> >
> > PR c/57457
> > * c-c++-common/cilk-plus/AN/pr57457.c: New testcase.
> So what you need to do is explain how you got into this function with a NULL
> fndecl and why that's OK.
Hi Jeff,
I looked into it, and there is another function call called
inform_declaration, and that does exactly what I did (i.e. check for NULL
fundecl before accessing its fields). From what I can tell, fundecl will be
NULL_TREE if a function declaration is a function pointer.
Thanks,
Balaji V. Iyer.
>
> ie, it's easy to sprinkle tests for NULL pointers in the sources to change
> behaviour, but it's more important to look at why we're getting a NULL pointer
> at any particular point and decide if it's valid or not.
>
> You've probably already done the analysis, you just need to make sure to
> include
> it in the patch submission. That way the reviewer can easily see the change
> is
> correct and the analysis is preserved for future reference.
>
>
> Jeff
