| Message ID | 53848F63.2010500@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > I noticed that string constants built by the Fortran frontend don't set > TREE_READONLY for STRING_CST (and subsequently noticed that nothing seems to > set it for COMPLEX_CST). That was confusing the ptx backend I'm working on. > The -fwritable-strings option for C was removed a while ago, so I tested the > following patch to just set the flag unconditionally, and passed bootstrap > and test on x86_64-linux. Ok? Hmm? Not so obvious. TREE_READONLY has no purpose on tcc_constant nodes if I read documentation correctly (tree.h). In fact base.readonly_flag is unused for tcc_constant (and would be redundant with TREE_CONSTANT). Richard. > > Bernd
On 05/27/2014 04:57 PM, Richard Biener wrote: > On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >> I noticed that string constants built by the Fortran frontend don't set >> TREE_READONLY for STRING_CST (and subsequently noticed that nothing seems to >> set it for COMPLEX_CST). That was confusing the ptx backend I'm working on. >> The -fwritable-strings option for C was removed a while ago, so I tested the >> following patch to just set the flag unconditionally, and passed bootstrap >> and test on x86_64-linux. Ok? > > Hmm? Not so obvious. TREE_READONLY has no purpose on tcc_constant > nodes if I read documentation correctly (tree.h). In fact > base.readonly_flag is unused for tcc_constant (and would be redundant > with TREE_CONSTANT). Well, the C frontend still sets it for strings (in fix_string_type), and gcc.dg/lvalue-5.c fails if that is removed. So things are a little inconsistent between frontends. Bernd
On Wed, May 28, 2014 at 12:00 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 05/27/2014 04:57 PM, Richard Biener wrote: >> >> On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt <bernds@codesourcery.com> >> wrote: >>> >>> I noticed that string constants built by the Fortran frontend don't set >>> TREE_READONLY for STRING_CST (and subsequently noticed that nothing seems >>> to >>> set it for COMPLEX_CST). That was confusing the ptx backend I'm working >>> on. >>> The -fwritable-strings option for C was removed a while ago, so I tested >>> the >>> following patch to just set the flag unconditionally, and passed >>> bootstrap >>> and test on x86_64-linux. Ok? >> >> >> Hmm? Not so obvious. TREE_READONLY has no purpose on tcc_constant >> nodes if I read documentation correctly (tree.h). In fact >> base.readonly_flag is unused for tcc_constant (and would be redundant >> with TREE_CONSTANT). > > > Well, the C frontend still sets it for strings (in fix_string_type), and > gcc.dg/lvalue-5.c fails if that is removed. So things are a little > inconsistent between frontends. Then fix that instead. The ptx backend shouldn't use TREE_READONLY on tcc_constant, so you can resolve the issue completely within the ptx backend anyway. Richard. > > Bernd >
* tree.c (build_string, build_complex): Set TREE_READONLY. diff --git a/gcc/tree.c b/gcc/tree.c index 22b92f3..067f15a 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -1755,6 +1755,7 @@ build_string (int len, const char *str) memset (s, 0, sizeof (struct tree_typed)); TREE_SET_CODE (s, STRING_CST); TREE_CONSTANT (s) = 1; + TREE_READONLY (s) = 1; TREE_STRING_LENGTH (s) = len; memcpy (s->string.str, str, len); s->string.str[len] = '\0'; @@ -1776,6 +1777,7 @@ build_complex (tree type, tree real, tree imag) TREE_IMAGPART (t) = imag; TREE_TYPE (t) = type ? type : build_complex_type (TREE_TYPE (real)); TREE_OVERFLOW (t) = TREE_OVERFLOW (real) | TREE_OVERFLOW (imag); + TREE_READONLY (t) = 1; return t; }