This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Don't ICE in build_array_ref trying to SET_EXPR_LOCATION on error_mark_node (PR c++/37552)
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Jason Merrill <jason at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 17 Sep 2008 10:06:10 -0400
- Subject: Re: [C++ PATCH] Don't ICE in build_array_ref trying to SET_EXPR_LOCATION on error_mark_node (PR c++/37552)
- References: <20080917105855.GO20215@hs20-bc2-1.build.redhat.com>
On Wed, Sep 17, 2008 at 06:58:55AM -0400, Jakub Jelinek wrote:
> Hi!
>
> In these 2 spots, ret can be error_mark_node, so using SET_EXPR_LOCATION
> unconditionally leads to ICE. Ok for trunk?
I think you can commit this under the obvious rule.
> BTW, Aldy, why do you check for error_mark_node in
> protected_set_expr_location? AFAIK error_mark_node doesn't satisfy
In testing for regressions I found a testcase or two where we were
passing an error_mark_node down the call chain, and it was easier to
catch this case here rather than in the caller. However, I don't have
the testcase handy to double check, though I'm sure you can remove the
check and run make check again to find if it's worth it.
> CAN_HAVE_LOCATION_P (t). And, couldn't protected_set_expr_location be
> inlined? Having an out-of-line function for something this cheap
> (especially when --enable-checking=release, which we should optimize for)
> is IMHO undesirable.
Shrug. Sure.