This is the mail archive of the
mailing list for the GCC project.
Re: Added error message (for too-large array)
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: Added error message (for too-large array)
- From: Jason Merrill <jason_merrill at redhat dot com>
- Date: 25 Sep 2001 14:22:16 +0100
- Cc: gcc at gcc dot gnu dot org, law at cygnus dot com, jason_merrill at redhat dot com
- References: <10109251246.AA10596@vlsi1.ultra.nyu.edu>
>>>>> "Richard" == Richard Kenner <email@example.com> writes:
> It would think the Ada frontend should set TYPE_SIZE itself for such an
> ARRAY_TYPE, rather than let the middle-end come up with a meaningless
> Why? There's no meaningful value for it, set by anybody. All you can do
> with such a type is basically to take a pointer to it or use it to index
> an array. Any computation that needs the size is incorrect.
OK. You're saying that an array with an unrepresentable size is valid in
Ada, so my assumption that it would be invalid for all languages was
incorrect. I suppose I'll move the test into layout_decl, since you seem
to agree that creating an object of such a type is invalid.
> But I still don't understand what motiviated this test.
One of the g++ tests failing with an ICE in assign_stack_temp_for_type on a
16-bit target. An example that fails on an x86 compiler:
int main ()
The C frontend catches this in grokdeclarator, as I mentioned before.