[PATCH] Fix PR c/25682 (4.0/4.1/trunk P1 regression)

Jakub Jelinek jakub@redhat.com
Mon Jan 16 21:27:00 GMT 2006


On Mon, Jan 16, 2006 at 03:57:51PM -0500, Jakub Jelinek wrote:
> > I too think the patch is fine, though I'd prefer to have the C++ front
> > end set the array size to error_mark_node, rather than integer_one_node.
> >  The general principle has been to fill in erroneous values with
> > error_mark_node, which keeps the rest of the compiler from reporting
> > confusing messages about values that are not what the user expects.
> 
> compute_array_index_type sets size to integer_one_node in a bunch of
> other places after reporting an error, so I just followed that.
> I can surely test the patch with error_mark_node instead, but should the
> other places be changed too?

error_mark_node doesn't work there, several routines rely on it not actually
being error_mark_node, otherwise there are further ICEs down the road.
Returning error_mark_node from compute_array_index_type is not a good idea
either, as although there is no ICE in that case, e.g. on the array-size2.C
testcase it thinks the g and h arrays aren't defined at all and so issues
another 2 errors on the next line.  Is it ok to commit the patch as is and
perhaps later on on trunk only play with it and find if it is possible to
use error_mark_node in all places where integer_one_node is used now in
compute_array_index_type and get reasonable diagnostics?

	Jakub



More information about the Gcc-patches mailing list