Re: Extension compatibility policy

[Paul Schlie <schlie at comcast dot net>]

> Bernardo Innocenti wrote:
>> Joseph S. Myers wrote:
>>> On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
>>> To move strings into program memory, there's a macro like this:
>>>
>>> #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })
>>>
>>> But this wouldn't work because __func__ does not work like a string literal:
>>>
>>> #define TRACEMSG(msg,...) __tracemsg(PSTR(__func__), msg, ## __VA_ARGS__)
>>>
>>> C99's __func__ is supposed to work as if a "const char __func__[]".
>>> The __FUNCTION__ extension could instead be made to work like a
>>> string literal.   We could live without string pasting capabilities
>>> if it helps keeping the interface between cpp and the C frontend
>>> cleaner.
>>
>> How about calling decl_attributes from fname_decl so a target
>> insert_attributes hook can add attributes to __func__?
>> Would that suffice to solve your problem?
>>
> It would be an excellent solution for myself, but portable code
> might not expect __func__ to be stored in program memory.  This isn't
> as transparent a a .rodata section.

After having the chance to experiment a little, it would seem most ideal in
the short term to enable GCC to add an explicit target specific attribute to
the effective implied __FUNCTION__ declaration; in AVR's case for example:

  #define ROM __attribute__((__progmem__)) /* an avr attribute */

  something (ROM __FUNCTION__);

Thereby effectively implying the local declaration/use of __FUNCTION__ as:

  ROM static const char __FUNCTION__[4] = "foo";
  something (__FUNCTION__);

Which would enable the backward compatible addition of target specific
attributes to the implied declaration of __FUNCTION__, enabling avr's
backend to place it in progmem, and be explicitly accessed using PSTR()
macros.

Where in the longer term, if target specific attributes are properly
retained through the compilation process, the backend can automatically
reference objects stored in progmem properly without need of an explicit
macro to do so.

(Although I know there's concern about enabling fine grain specification
 of attributes for implied static const initializer objects; but now believe
 that both both fine grain as well as having the ability to define a target
 specific attribute in bulk for all implied static const initializer objects
 as may be most appropriate in different circumstances; a more detailed
 analysis/summary will follow.)