This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Unreviewed patch for c-decl.c


On Fri, 3 Oct 2003, Dhananjay R. Deshpande wrote:

> This would appear to restrict allocation of a declaration-via-typedef
> to .data until you consider that (1) the array elements are const, (2)
> array types are not modifiable lvalues.  Therefore neither the array
> type nor the array element type can be modified, therefore they are both
> const, therefore they can safely be located in .rodata.

Whether something is constant is a separate matter from whether its type 
is const-qualified.  The internal data structure for a declaration or 
expression's type should accurately reflect the type it has in the C 
standard.  The deduction of whether something can be allocated in .rodata 
can then be made by whatever logic is appropriate, but should not cause a 
type to be const-qualified if it isn't according to the standard.

Possibly TREE_READONLY on the DECL is what you want to set.  But this
could cause other bugs, since Mark's patch
<http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00498.html> (which gave
variables their correct types rather than relying on qualifications on
their DECLs) has yet to be followed up with a general cleanup of places in
the C front end that look at TREE_READONLY (decl) to determine whether a
DECL is on const-qualified type.

The minimal test for not getting inappropriate const-qualification leaking
out would be that

static const int a[2] = { 1, 2 };
typedef const int ci;
static ci b[2] = { 3, 4 };
typedef int ia[2];
static const ia c = { 5, 6 };
typedef const int cia[2];
static cia d = { 7, 8 };
void *p = &a;
void *q = &b;
void *r = &c;
void *s = &d;

compiles silently (adapted appropriately as a testcase for gcc.dg; testing
that what you want to go in .rodata actually does so may be more
difficult).  That test would suffice given a patch that only tries to get 
TREE_READONLY set properly on the DECL and doesn't attempt to adjust the 
type of the array itself.

-- 
Joseph S. Myers
jsm@polyomino.org.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]