Patch to allow Ada to work with tree-ssa

Nathan Sidwell nathan@codesourcery.com
Wed Jun 23 12:40:00 GMT 2004


Richard Kenner wrote:
>         Variable-length automatic arrays are allowed in ISO C99, and as an
>         extension GCC accepts them in C89 mode and in C++.  (However, GCC's
>         implementation of variable-length arrays does not yet conform in
>         detail to the ISO C99 standard.)  These arrays are declared like any
>         other automatic arrays, but with a length that is not a constant
>         expression.  The storage is allocated at the point of declaration and
>         deallocated when the brace-level is exited.  For example: --snip
> 
>     It does *not* say variable length arrays are supported in all the places
>     fixed sized arrays are (because we don't)
> 
> Actually, we *do* support it in all the places fixed-size automatic arrays
> are.  Can you give an example where we don't?
that's not what you said in your previous email. You said
'We document that GNU C allow variable-sized arrays in general.' You
said nothing about this only applying to automatic variables.

> And that's what I interpret "like any other automatic array" to mean: it can
> be used in any place a normal automatic array can be used.  If that's not
> what it means, then what *does* that phrase mean to you?
'automatic array' implies to me an  automatic variable of *array* type.
This interpretation is reinforced by the remainder of that subclause,
'... are allowed in ISO C99'.  C99 has this to say about variable length
array types [6.7.5.2]/6 (lines 27-34) 'All variably modified types must be
declared at either block scope of function prototype scope. ... *This
eliminates structure and union members.*' (my emphasis).  The subsequent
paragraph gives some rationale as to why struct and union members are
eliminated.

>     Nor does it give additional special cases such as putting a variable
>     length array in the middle (or end) of a struct. Nor does it say a
>     struct with a variable length array in it can be an automatic (or any
>     other kind of) variable.
> 
> There's also nothing in C that explicitly says that you can have a struct
> that contains an array of structs.  You don't need to: that's a composition
> of existing features.  Likewise here.  If you say "we've added this new
> data type", then, unless you say something to the contrary, you can use
> that data type anywhere you can use other data types.
C distinguishes complete and incomplete types, there are things you can
do with one and not with the other.  Is it unreasonable to presume
that variable-length types (a dynamic type, if you will), might have
different constraints to both complete and incomplete types? Indeed,
the above sentance from C99 explicitly makes it clear that there are
differences. One might desire full generality, but is it always both useful
and implementable?

>     2) You cannot put an arbitrary type inside a struct.  prior to C99 you
>     could not put an incomplete array in a struct at all, and in C99 there
>     are restrictions on where you can put it (and recursive restrictions
>     on where you can place a struct with an incomplete array member).
> 
> I'm talking GNU C, not standard C.
you did not make that at all clear, your sentance was 'It's part of C that
you can put an arbitrary type inside a struct'.  As this discussion is about
the differences between C and GNU C, you should make explicitly clear when
you're talking about a GNU extension.

>     Plus that it *doesn't work* in some cases indicates that perhaps it's
>     not actually used outside of Ada.
> 
> Be careful with the tense there!  It has worked in all *released* of GCC.
> The only time it was broken was between the tree-ssa merge and yesterday, a
Maybe I misremembered one of the earlier emails of yours or rth's or someone
else, but I got the impressions that something 'never worked'.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk




More information about the Gcc mailing list