Added error message

Added error message

[Richard Kenner]

What was the purpose of adding an error message in layout_type when an
array's size cannot be represented in size_t?

We should give an error if the size of an *object* can't be
representable, but why a type?  Note that you don't check for RECORD_TYPE,
just ARRAY_TYPE.

It's a fairly common idiom in Ada to make an array type whose bounds
are all integers to represent "all memory".  If it's an array of bytes
that's OK, but not if it's an array of anything wider.  So this error
causes problems there.

But I don't understand its purpose at all.

Re: Added error message (for too-large array)

[Jason Merrill]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

> What was the purpose of adding an error message in layout_type when an
> array's size cannot be represented in size_t?

If the size cannot be represented in size_t, it isn't represented
internally in gcc in any useful way; it overflows to some number bearing
little relation to what the user intended.

Now I notice that the C frontend already caught this, in grokdeclarator.  I
suppose the C++ frontend could handle it similarly, but I didn't see how a
type too large to represent could be useful for any language.

> We should give an error if the size of an *object* can't be
> representable, but why a type?

I suppose that moving the test for overflowing TYPE_SIZE to layout_decl
would be plausible.

> Note that you don't check for RECORD_TYPE, just ARRAY_TYPE.

I suppose that would make sense for completeness, though the problem is
much less likely there.

> It's a fairly common idiom in Ada to make an array type whose bounds
> are all integers to represent "all memory".  If it's an array of bytes
> that's OK, but not if it's an array of anything wider.  So this error
> causes problems there.

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
value.

Jason