[Bug c/63760] Support __func__ in PROGMEM

[Bug c/63760] Support __func__ in PROGMEM

[mojo at world3 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760

--- Comment #2 from mojo at world3 dot net ---
On platforms with this kind of architecture the default is to place everything
in RAM, unless you specifically state otherwise.

With Harvard style architectures different instructions are used to access RAM
and program memory. GCC doesn't handle that natively, so you need to add things
like PROGMEM or __flash to tell it where to store and how to access the data.

[Bug c/63760] Support __func__ in PROGMEM

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|AVR                         |avr
           Priority|P3                          |P5

--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #1)
> Why aren't read-only data being placed in progmem by default?

Suppose

char func (const char *X)
{
    return *X;
}


Just that func does not alter *X does /not/ mean *X won't change in the
program.  It is completely legal for a program to use func like so:

void foo (char c)
{
    func (&c);
    c++;
    func (&c);
}

Hence the default linker description file locates .rodata in RAM and the
compiler may not assume data is located in flash just because a particular
function does not change it.

With a different ABI that reserved, e.g., Bit 15 of the address to tag whether
the object lives in .rodata or not, it would be possible to achieve this, but
it would also add quite some overhead to runtime and flash usage and pressure
on Z register like address space __memx does.

[Bug c/63760] Support __func__ in PROGMEM

[mojo at world3 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760

--- Comment #4 from mojo at world3 dot net ---
I agree, a separate __funcP__is the best option.