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 ***

Reply via email to