[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Priority|P2                          |P3
                 CC|                            |gjl at gcc dot gnu.org
         Resolution|WONTFIX                     |DUPLICATE
           Severity|normal                      |enhancement

--- Comment #11 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2011-08-03 19:40:32 UTC ---
Setting this as duplicate; not because it's a real duplicate -- the original
message is rather confusing and I can't really depict what it's intention is --
but because the contributors to this PR might be also interestet in PR43746
which touches similar topic like duplicate strings and string merging on AVR
that is addressed here, too.

(In reply to comment #0)
> char s[5] = "abcde";
> char t[5] = {'a','b','c','d','e'};

Note that "abcde" is a string literal containing 6 chars (only 5 are copied)
and the second initializer has length 5 bytes and is not a string.

> resulting tree/rtl:
>
> showing frame-relative reference to "abcde" initializing data which is wrong:
>
> (set (reg:HI 44)
>      (symbol_ref/f:HI ("*.LC0") [flags 0x2] <string_cst 0x160b840>))

Note that the /f flag has different meanings depending on where it is attached
to, see http://gcc.gnu.org/viewcvs/trunk/gcc/rtl.h?view=markup

(In reply to comment #6)

> Now, if that macro is called with identical string literals within one
> translation unit, the strings are allocated separately rather than merged
> into a single location.
> 
> This behaviour is reproducable as well on the i386 target, so it looks like
> not really related to the avr backend.
> 
> [...]
> 
> #define PROGMEM __attribute__((__progmem__))
> 
> #define PSTR(x) \
> (__extension__({static const char __c[] PROGMEM = (x); &__c[0];}))
> 
> extern void puts_P(const char *);
> 
> void dosomething(void)
> {
>         puts_P(PSTR("Hello world!"));
>         puts_P(PSTR("Hello world!"));
> }
> 
> Compiling for the avr target yields:
> 
> [...]
>         .section        .progmem.data,"a",@progbits
>         .type   __c.1473, @object
>         .size   __c.1473, 13
> __c.1473:
>         .string "Hello world!"
>         .type   __c.1471, @object
>         .size   __c.1471, 13
> __c.1471:
>         .string "Hello world!"
>
> 
> Compiling the same file for the i386 target also shows two copies of the
> string literal: [...]

Problem is not the duplicate string literals it's the missing section flags
like "aMS" for mergeable strings and binutils would take care of this.

This is rooted in the way avr backend up to now implements progem attribute,
i.e. is simply bangs a "section .progmem" against a decl without caring for the
kind of data. This is not hard to change, but it has to be implemented.

For constants in .rodata string merging was achieved wihout effort by cleaning
up the avr backend.  Notice that .rodata is still in RAM but named .rodata now
and not mapped to .data as in <= 4.6.

*** This bug has been marked as a duplicate of bug 43746 ***

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[eric dot weddington at atmel dot com]

------- Comment #10 from eric dot weddington at atmel dot com  2010-09-20 16:51 -------
Closed as WONTFIX.


-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[tfrancuz at mp dot pl]

------- Comment #9 from tfrancuz at mp dot pl  2010-04-14 20:45 -------
*** Bug 43746 has been marked as a duplicate of this bug. ***


-- 

tfrancuz at mp dot pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tfrancuz at mp dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[manu at gcc dot gnu dot org]

------- Comment #8 from manu at gcc dot gnu dot org  2009-08-05 15:07 -------
OK, setting it back to NEW, but I don't have any idea about how to approach
this.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|manu at gcc dot gnu dot org |
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-08-05 15:07:42
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[schlie at comcast dot net]

------- Comment #7 from schlie at comcast dot net  2007-11-16 02:35 -------
Subject: Re:  Initializing string literal data
 improperly marked frame-relative?, should be readonly static const.

I believe so.


> From: manu at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> Reply-To: <gcc-bugzilla@gcc.gnu.org>
> Date: 15 Nov 2007 16:19:49 -0000
> To: <schlie@comcast.net>
> Subject: [Bug middle-end/21018] Initializing string literal data improperly
> marked frame-relative?, should be readonly static const.
> 
> 
> 
> ------- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 16:19 -------
> Is this still a valid bug?
> 
> 
> -- 
> 
> manu at gcc dot gnu dot org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |manu at gcc dot gnu dot org
>              Status|UNCONFIRMED                 |WAITING
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[j at uriah dot heep dot sax dot de]

------- Comment #6 from j at uriah dot heep dot sax dot de  2007-11-15 21:21 -------
I'm not sure whether this is related or not... but from the description, it
looks so.

avr-libc contains a macro that helps the users declaring a flash-ROM string,
lacking any real support in GCC for different memory sections (as proposed
by the Embedded C draft).  This works by using the GCC extension that a
block can return a value: a block is openened, and a block-scope static
variable is allocated, using the string literal passed in by the user.  Then,
that block returns the address of this variable to the caller.  By giving
the block-scope variable the "progmem" attribute, it will eventually be
allocated in ROM rather than RAM.

Now, if that macro is called with identical string literals within one
translation unit, the strings are allocated separately rather than merged
into a single location.

This behaviour is reproducable as well on the i386 target, so it looks like
not really related to the avr backend.

Here's a simple test case.  For simplicity, the original PSTR() macro is
just reproduced in the file rather than including the entire original
header(s).

#if defined(__AVR__)
#  define PROGMEM __attribute__((__progmem__))
#else
#  define PROGMEM /* nothing */
#endif

#define PSTR(x) \
(__extension__({static const char __c[] PROGMEM = (x); &__c[0];}))

extern void puts_P(const char *);

void
dosomething(void)
{
        puts_P(PSTR("Hello world!"));
        puts_P(PSTR("Hello world!"));
}

Compiling for the avr target yields:

        .file   "foo.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
        .global __do_copy_data
        .global __do_clear_bss
        .text
.global dosomething
        .type   dosomething, @function
dosomething:
/* prologue: frame size=0 */
/* prologue end (size=0) */
        ldi r24,lo8(__c.1471)
        ldi r25,hi8(__c.1471)
        rcall puts_P
        ldi r24,lo8(__c.1473)
        ldi r25,hi8(__c.1473)
        rcall puts_P
/* epilogue: frame size=0 */
        ret
/* epilogue end (size=1) */
/* function dosomething size 7 (6) */
        .size   dosomething, .-dosomething
        .section        .progmem.data,"a",@progbits
        .type   __c.1473, @object
        .size   __c.1473, 13
__c.1473:
        .string "Hello world!"
        .type   __c.1471, @object
        .size   __c.1471, 13
__c.1471:
        .string "Hello world!"
/* File "foo.c": code    7 = 0x0007 (   6), prologues   0, epilogues   1 */

Compiling the same file for the i386 target also shows two copies of the
string literal:

        .file   "foo.c"
        .section        .rodata
        .type   __c.0, @object
        .size   __c.0, 13
__c.0:
        .string "Hello world!"
        .type   __c.1, @object
        .size   __c.1, 13
__c.1:
        .string "Hello world!"
        .text
.globl dosomething
        .type   dosomething, @function
dosomething:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   $__c.0
        call    puts_P
        movl    $__c.1, (%esp)
        call    puts_P
        leave
        ret
        .size   dosomething, .-dosomething
        .ident  "GCC: (GNU) 3.4.4 [FreeBSD] 20050518"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[manu at gcc dot gnu dot org]

------- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 16:19 -------
Is this still a valid bug?


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[ericw at evcohs dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ericw at evcohs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-04-16 18:41 -------
Subject: Re:  Initializing string literal data
 improperly marked frame-relative?, should be readonly static const.

> From: Paul Schlie <schlie@comcast.net>
> Subject: Re: [Bug middle-end/21018] Initializing string literal data
> improperly marked frame-relative?, should be readonly static const.
> 
>> Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr
>> should be changed to recongize them as such.
> 
> Actually the problem seems then be that literal string constants aren't
> being consistently defined through CONST_DECL's (just as initializing char
> array data, which are equivalent to string initializers, and all other literal
> and static constants which end up being stored as literal data are); for which
> MEM_READONLY_P allows all memory references to, to be easily identified, which
> seems to be it's intent.
> 
> Is there any reason that literal string constant data shouldn't be similarly
> declared and correspondingly identifiable? (or just an oversight?)

I suspect it was likely an artifact of the now depreciated writeable-strings
extension, which previously pretended that literal string constants were not
READONLY after being copied from the executable image into read/write
memory.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-04-16 18:22 -------
Subject: Re:  Initializing string literal data
 improperly marked frame-relative?, should be readonly static const.

> Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr
> should be changed to recongize them as such.

Actually the problem seems then be that literal string constants aren't
being consistently defined through CONST_DECL's (just as initializing char
array data, which are equivalent to string initializers, and all other
literal and static constants which end up being stored as literal data are);
for which MEM_READONLY_P allows all memory references to, to be easily
identified, which seems to be it's intent.

Is there any reason that literal string constant data shouldn't be similarly
declared and correspondingly identifiable? (or just an oversight?)




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-16 16:46 -------
Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr should be changed to 
recongize them as such.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|ppc-apple-darwin7.8         |
   GCC host triplet|ppc-apple-darwin7.8         |
 GCC target triplet|ppc-apple-darwin7.8 / avr-  |avr
                   |none-none                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018