Ulrich Weigand wrote: > Georg-Johann Lay wrote: > >> For the following 1-liner I get an error with current trunk r177267: >> >> const __pgm char * pallo = "pallo"; >> >> __pgm as a named address space qualifier. > [snip] >> Moreover, if a user writes a line like >> const __pgm char * pallo = "pallo"; >> he wants the string literal to be placed in the non-default address >> space. There is no other way to express that except something like >> const __pgm char * pallo = (const __pgm char*) "pallo"; >> which doesn't work either and triggers >> >> pgm.c:1:1: error: initializer element is not constant >> >> with a tree dump similar to above. > > This is pretty much working as expected. "pallo" is a string literal > which (always) resides in the default address space. According to the > named address space specification (TR 18037) there are no string literals > in non-default address spaces ...
The intension of TR 18037 to supply "Extension to Support Embedded Systems" and these are systems where every byte counts -- and it counts *where* the byte will be placed. Basically named AS provide something like target specific qualifiers, and if GCC, maybe under the umbrella of GNU-C, would actually implement a feature like target specific qualifiers, that would be a great gain and much more appreciated than -- users will perceive it that way -- being more catholic than the pope ;-) For example, you can have any combination of qualifiers like const, restrict or volatile, but it is not possible for named AS. That's clear as long as named AS is as strict as TR 18037. However, users want features to write down their code an a comfortable, type-safe way and not as it is at the moment, i.e. by means of dreaded inline assembler macros (for my specific case). For example, the backend could decide what qualifier combinations are valid and what machine mode is associated to them or emit a diagnostic. It's target specific, the backend knows it! > The assignment above would therefore need to convert a pointer to the > string literal in the default space to a pointer to the __pgm address > space. This might be impossible (depending on whether __pgm encloses > the generic space), and even if it is possible, it is not guaranteed > that the conversion can be done as a constant expression at compile time. The backend can tell. It likes to implement features to help users. It knows about the semantic and if it's legal or not. And even if it's all strict under TR 18037, the resulting error messages are *really* confusing to users because to them, a string literal's address is known. > What I'd do to get a string placed into the __pgm space is to explicitly > initialize an *array* in __pgm space, e.g. like so: > > const __pgm char pallo[] = "pallo"; > > This is defined to work according to TR 18037, and it does actually > work for me on spu-elf. Ya, but it different to the line above. Was just starting with the work and it worked some time ago, so I wondered. And I must admit I am not familiar will all the dreaded restriction TR 18037 imposes to render it less functional :-( > > Bye, > Ulrich > Anyway, thanks for your explanations. Do you think a feature like "target specific qualifier" would be reasonable? IMO it would be greatly appreciated by users. Should not be too hard atop the work already being done for named addresses. Johann
