https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805
--- Comment #10 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> I don't see any bug actually. You are just saying that the str1 variable is
> __flash, during optimization (already in C FE) it optimizes str1[i] into
> "0123456789"[i] and that is the string literal that is mergeable, string
> literals unlike variables don't really have non-default address spaces.
Well, it's access as if it was located in an address space (namely using LPM
which is only used if the accessing code is accessing AS). The object sections
and accessor code must macht, otherwise it's wrong code.
If STRING_CST must not reside in AS (I already wondered that non-DECLs are in
AS) then my proposed fix to PR83801 is wrong: In that PR, a STRING_CST is
passed to TARGET_ASM_SELECT_SECTION, and it's TREE_TYP has some AS set. The
patch puts the STRING_CST in some AS-related section, and if that's wrong then
it's abut in the C front because the code is accessing an AS object.
IIUC you are saying that my fix to PR83801 is wrong and that the C FE should
never use a STRING_CST but should use a VAR_DECL (like v7 and prior did).
> If you want to prevent that, either make the var const volatile, or use some
> optimization barrier, like:
> static const __flash char str1[] = "0123456789";
> const char *ptr;
> __asm ("" : "=r" (ptr) : "0" (str1));
> return ptr[i];
Really, I have to control over code in user space, and the code supplied in the
test case is valid.
And the code you are showing makes really on sense...
