Re: [named address] rejects-valid: error: initializer element is not computable@load time

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > It's not a restriction so much, it's simply that TR 18037 does not say anything
> > about string literals at all, so they keep working as they do in standard C.
> 
> Take the following bit more elaborate example where you want to describe 
> a menu:
[snip]
> Thus you have no alternative and have to use menu1_t:
> 
> const char __as STR_YES[] = "Yes";
> const char __as STR_NO[]  = "No";
> const char __as STR_DUNNO[] = "Don't really know and will decide later";
> 
> const menu1_t menu3 =
> {
>      1,
>      {
>          STR_YES,
>          STR_NO,
>          STR_DUNNO
>      }
> };
> 
> With some menues you soon end up with dozens of unnecessary variables 
> just because TR 18037 has a blank area on it's map.

I agree that this is best approach.  You can even avoid the unnecessary
variables by using a compound literal with AS-qualified char array type,
and initialize the AS pointer to its address, like e.g. so:

const __as char *pallo = (const __as char []){"pallo"};

That's still a bit awkward, but that could be hidden via a macro ...

> This means that a line like
>     const __as char * pallo = "pallo";
> can be very useful and that there is exactly one meaning that makes 
> sense: put "pallo" in __as because otherwise you won't be able to 
> reference that string.

That's not really true: on some targets, the generic address space
will indeed be a subset of __as, so you *can* assign the address of
a string literal in the generic space to an __as pointer variable.

Even on the SPU, this works when the assignment is not done at
initialization time:

const __ea char *p;
int test (void)
{
  p = "test";
}

This will generate code to convert the address of the literal "test"
in the generic address space into a __ea address and assign it to
the __ea pointer.

> Even more preferred would be to assign the only sensible meaning 
> (provided a target allows it), which should be legal as that extension 
> is implementation defined, anyway.

What is implementation defined is whether conversion of a pointer
to a different address space is allowed at *initialization* time
or not.

What is *not* implementation defined is that string literals are
always in the generic address space -- that's simply a requirement
of the standard.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com