This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Set TREE_READONLY const POD arrays with sizedetermined from initialize (PR c++/21454)
- From: Paul Schlie <schlie at comcast dot net>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>,Mark Mitchell <mark at codesourcery dot com>,"Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 12 May 2005 06:56:06 -0400
- Subject: Re: [PATCH] Set TREE_READONLY const POD arrays with sizedetermined from initialize (PR c++/21454)
> From: Jakub Jelinek <jakub@redhat.com>
> On Wed, May 11, 2005 at 06:37:53PM -0400, Paul Schlie wrote:
>>> Jakub Jelinek <jakub@redhat.com> writes:
>>>
>>> This is a fallout of the PR c++/20073 fix.
>>> For arrays like:
>>> const int a[] = { 0, 1, 2, 3 };
>>> when cp_apply_type_quals_to_decl is called, its type is not complete yet,
>>> so C++ frontend does not set TREE_READONLY flag. But such variables
>>> aren't put into incomplete_vars chain either, so nothing sets the flag
>>> afterwards.
>>> Ok for 4.0/HEAD if it passes regtesting?
>>
>> What's the difference between TREE_READONLY and MEM_READONLY_P ?
>
> TREE_READONLY is a tree flag, MEM_READONLY_P is a rtl flag.
> They both mean basically the same thing, that the object is not modified
> once the program gets control (i.e. e.g. variables in read-only sections are
> ok,
- Yup, makes sense.
> variables in writable sections that are there just because they need to
> be relocated by the dynamic linker (which is even before constructors are
> run) and are never modified afterwards are ok too.
- Just to double check, as dynamically allocated variables can never be
designated READONLY; I presume you mean that such variables may be
initialized with read-only literal data (which is distinct from the
variables themselves, not a relocation), as opposed to READONLY variables
and/or literals, which are equivalent to their initializing data. i.e.:
char foo (int x, int y)
{
char s[3] = "abc";
s[x] = 'x';
return s[y];
}
where "abc" (a READONLY literal char array) initializes by being copied
to s[] (a non-READONLY variable char array) upon entry to foo, vs.
static const char s[3] = "abc";
where s[] is equivalent to the literal "abc" and are one and the same.
>> (To the best of my knowledge "const int a[]" is allocated and initialized
>> at run-time in RAM with the READONLY ROM literal value "{1,2,3,4}"; so a[]
>> is not READONLY, although it's literal initializer is; as opposed to
>> "static const a[] = {0,1,2,3}" where they are considered equivalent.)
>
> No, there is no difference outside of function body whether there is
> static keyword or not.
OK that makes sense, as static is essentially presumed; however within a
function body, I presume only "static const" variables (and literal data),
may be classified as being READONLY?