public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
[not found] <bug-21018-9497@http.gcc.gnu.org/bugzilla/>
@ 2007-11-15 16:19 ` manu at gcc dot gnu dot org
2007-11-15 21:22 ` j at uriah dot heep dot sax dot de
` (4 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: manu at gcc dot gnu dot org @ 2007-11-15 16:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
[not found] <bug-21018-9497@http.gcc.gnu.org/bugzilla/>
2007-11-15 16:19 ` [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const manu at gcc dot gnu dot org
@ 2007-11-15 21:22 ` j at uriah dot heep dot sax dot de
2007-11-16 2:35 ` schlie at comcast dot net
` (3 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: j at uriah dot heep dot sax dot de @ 2007-11-15 21:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
[not found] <bug-21018-9497@http.gcc.gnu.org/bugzilla/>
2007-11-15 16:19 ` [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const manu at gcc dot gnu dot org
2007-11-15 21:22 ` j at uriah dot heep dot sax dot de
@ 2007-11-16 2:35 ` schlie at comcast dot net
2009-08-05 15:08 ` manu at gcc dot gnu dot org
` (2 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: schlie at comcast dot net @ 2007-11-16 2:35 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
[not found] <bug-21018-9497@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2007-11-16 2:35 ` schlie at comcast dot net
@ 2009-08-05 15:08 ` manu at gcc dot gnu dot org
2010-04-14 20:46 ` tfrancuz at mp dot pl
2010-09-20 16:52 ` eric dot weddington at atmel dot com
5 siblings, 0 replies; 13+ messages in thread
From: manu at gcc dot gnu dot org @ 2009-08-05 15:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
[not found] <bug-21018-9497@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2009-08-05 15:08 ` manu at gcc dot gnu dot org
@ 2010-04-14 20:46 ` tfrancuz at mp dot pl
2010-09-20 16:52 ` eric dot weddington at atmel dot com
5 siblings, 0 replies; 13+ messages in thread
From: tfrancuz at mp dot pl @ 2010-04-14 20:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
[not found] <bug-21018-9497@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2010-04-14 20:46 ` tfrancuz at mp dot pl
@ 2010-09-20 16:52 ` eric dot weddington at atmel dot com
5 siblings, 0 replies; 13+ messages in thread
From: eric dot weddington at atmel dot com @ 2010-09-20 16:52 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <bug-21018-4@http.gcc.gnu.org/bugzilla/>]
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
[not found] <bug-21018-4@http.gcc.gnu.org/bugzilla/>
@ 2011-08-03 19:41 ` gjl at gcc dot gnu.org
0 siblings, 0 replies; 13+ messages in thread
From: gjl at gcc dot gnu.org @ 2011-08-03 19:41 UTC (permalink / raw)
To: gcc-bugs
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 ***
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, should be readonly static const.
@ 2005-04-14 6:45 schlie at comcast dot net
2005-04-14 14:21 ` [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, " pinskia at gcc dot gnu dot org
` (5 more replies)
0 siblings, 6 replies; 13+ messages in thread
From: schlie at comcast dot net @ 2005-04-14 6:45 UTC (permalink / raw)
To: gcc-bugs
The following two literal initializer data should both be considered static const data references:
char s[5] = "abcde";
char t[5] = {'a','b','c','d','e'};
the memory reference to "abcde" should be marked readonly, not frame-relative (as it isn't),
as otherwise it's impossible to properly identify "static const data" memory references at the
tree/rtl level as may be required for target specific code/data generation/optimization.
The following shows the problem (as well as a missed optimization associated with potentially
being able to access the initializer data directly, as opposed to accessesing the frame-relative
variable data string/array after being copied if never modifed; and an inappropriate inline of
function foo() which should not have likely been inlined given it's size, and note that bar being
identical wan't inlined, which is correct):
volatile char v;
void foo ( void )
{
char x[5] = "abcde";
v = x[v];
}
void bar ( void )
{
char y[5] = {'a','b','c','d','e'};
v = y[v];
}
int main ( void )
{
char x[5] = "abcde"; // Initializer string not marked READONLY static const.
char y[5] = {'a','b','c','d','e'}; // Although char arrary is correctly.
v = x[v];
v = y[v];
foo();
bar();
return 0;
}
resulting code:
volatile char v;
void foo ( void )
{
c6: cf 93 push r28
c8: df 93 push r29
ca: cd b7 in r28, 0x3d ; 61
cc: de b7 in r29, 0x3e ; 62
ce: 25 97 sbiw r28, 0x05 ; 5
d0: 0f b6 in r0, 0x3f ; 63
d2: f8 94 cli
d4: de bf out 0x3e, r29 ; 62
d6: 0f be out 0x3f, r0 ; 63
d8: cd bf out 0x3d, r28 ; 61
char x[5] = "abcde";
da: de 01 movw r26, r28
dc: 11 96 adiw r26, 0x01 ; 1
de: e0 e0 ldi r30, 0x00 ; 0
e0: f1 e0 ldi r31, 0x01 ; 1
e2: 85 e0 ldi r24, 0x05 ; 5
e4: 01 90 ld r0, Z+
e6: 0d 92 st X+, r0
e8: 81 50 subi r24, 0x01 ; 1
ea: e1 f7 brne .-8 ; 0xe4 <foo+0x1e>
v = x[v];
ec: 80 91 10 01 lds r24, 0x0110
f0: fe 01 movw r30, r28
f2: e8 0f add r30, r24
f4: f1 1d adc r31, r1
f6: 81 81 ldd r24, Z+1 ; 0x01
f8: 80 93 10 01 sts 0x0110, r24
fc: 25 96 adiw r28, 0x05 ; 5
fe: 0f b6 in r0, 0x3f ; 63
100: f8 94 cli
102: de bf out 0x3e, r29 ; 62
104: 0f be out 0x3f, r0 ; 63
106: cd bf out 0x3d, r28 ; 61
108: df 91 pop r29
10a: cf 91 pop r28
10c: 08 95 ret
0000010e <bar>:
}
void bar ( void )
{
10e: cf 93 push r28
110: df 93 push r29
112: cd b7 in r28, 0x3d ; 61
114: de b7 in r29, 0x3e ; 62
116: 25 97 sbiw r28, 0x05 ; 5
118: 0f b6 in r0, 0x3f ; 63
11a: f8 94 cli
11c: de bf out 0x3e, r29 ; 62
11e: 0f be out 0x3f, r0 ; 63
120: cd bf out 0x3d, r28 ; 61
char y[5] = {'a','b','c','d','e'};
122: de 01 movw r26, r28
124: 11 96 adiw r26, 0x01 ; 1
126: e6 e0 ldi r30, 0x06 ; 6
128: f1 e0 ldi r31, 0x01 ; 1
12a: 85 e0 ldi r24, 0x05 ; 5
12c: 04 90 lpm r0, Z
12e: 0d 92 st X+, r0
130: 81 50 subi r24, 0x01 ; 1
132: e1 f7 brne .-8 ; 0x12c <bar+0x1e>
v = y[v];
134: 80 91 10 01 lds r24, 0x0110
138: fe 01 movw r30, r28
13a: e8 0f add r30, r24
13c: f1 1d adc r31, r1
13e: 81 81 ldd r24, Z+1 ; 0x01
140: 80 93 10 01 sts 0x0110, r24
144: 25 96 adiw r28, 0x05 ; 5
146: 0f b6 in r0, 0x3f ; 63
148: f8 94 cli
14a: de bf out 0x3e, r29 ; 62
14c: 0f be out 0x3f, r0 ; 63
14e: cd bf out 0x3d, r28 ; 61
150: df 91 pop r29
152: cf 91 pop r28
154: 08 95 ret
00000156 <main>:
}
int main ( void )
{
156: c0 ef ldi r28, 0xF0 ; 240
158: d0 e1 ldi r29, 0x10 ; 16
15a: de bf out 0x3e, r29 ; 62
15c: cd bf out 0x3d, r28 ; 61
char x[5] = "abcde"; // Initializer string not marked READONLY static const.
15e: de 01 movw r26, r28
160: 11 96 adiw r26, 0x01 ; 1
162: e0 e0 ldi r30, 0x00 ; 0
164: f1 e0 ldi r31, 0x01 ; 1
166: 85 e0 ldi r24, 0x05 ; 5
168: 01 90 ld r0, Z+
16a: 0d 92 st X+, r0
16c: 81 50 subi r24, 0x01 ; 1
16e: e1 f7 brne .-8 ; 0x168 <main+0x12>
char y[5] = {'a','b','c','d','e'}; // Although char arrary is correctly.
170: de 01 movw r26, r28
172: 16 96 adiw r26, 0x06 ; 6
174: eb e0 ldi r30, 0x0B ; 11
176: f1 e0 ldi r31, 0x01 ; 1
178: 85 e0 ldi r24, 0x05 ; 5
17a: 04 90 lpm r0, Z
17c: 0d 92 st X+, r0
17e: 81 50 subi r24, 0x01 ; 1
180: e1 f7 brne .-8 ; 0x17a <main+0x24>
v = x[v];
182: 80 91 10 01 lds r24, 0x0110
186: fe 01 movw r30, r28
188: e8 0f add r30, r24
18a: f1 1d adc r31, r1
18c: 81 81 ldd r24, Z+1 ; 0x01
18e: 80 93 10 01 sts 0x0110, r24
v = y[v];
192: 80 91 10 01 lds r24, 0x0110
196: fe 01 movw r30, r28
198: e8 0f add r30, r24
19a: f1 1d adc r31, r1
19c: 86 81 ldd r24, Z+6 ; 0x06
19e: 80 93 10 01 sts 0x0110, r24
foo(); char x[5] = "abcde";
1a2: de 01 movw r26, r28
1a4: 1b 96 adiw r26, 0x0b ; 11
1a6: e0 e0 ldi r30, 0x00 ; 0
1a8: f1 e0 ldi r31, 0x01 ; 1
1aa: 85 e0 ldi r24, 0x05 ; 5
1ac: 01 90 ld r0, Z+
1ae: 0d 92 st X+, r0
1b0: 81 50 subi r24, 0x01 ; 1
1b2: e1 f7 brne .-8 ; 0x1ac <main+0x56>
foo(); v = x[v];
1b4: 80 91 10 01 lds r24, 0x0110
1b8: fe 01 movw r30, r28
1ba: e8 0f add r30, r24
1bc: f1 1d adc r31, r1
1be: 83 85 ldd r24, Z+11 ; 0x0b
1c0: 80 93 10 01 sts 0x0110, r24
bar();
1c4: 0e 94 87 00 call 0x10e <bar>
return 0;
}
1c8: 80 e0 ldi r24, 0x00 ; 0
1ca: 90 e0 ldi r25, 0x00 ; 0
1cc: 0c 94 e8 00 jmp 0x1d0 <_exit>
000001d0 <_exit>:
1d0: ff cf rjmp .-2 ; 0x1d0 <_exit>
from gimple:
;; Function main (main)
main ()
{
static char C.3[5] = {97, 98, 99, 100, 101}; // should probably be "static const char"
volatile char v.4;
int D.1152;
char D.1153;
volatile char v.5;
int D.1155;
char D.1156;
int D.1157;
{
char x[5];
char y[5];
x = "abcde"; // should have been separatly declared "static const char" initilizer.
y = C.3;
v.4 = v;
D.1152 = (int) v.4;
D.1153 = x[D.1152];
v = D.1153;
v.5 = v;
D.1155 = (int) v.5;
D.1156 = y[D.1155];
v = D.1156;
{
{
volatile char v.0;
int D.1185;
char D.1186;
char x[5];
x = "abcde";
v.0 = v;
D.1185 = (int) v.0;
D.1186 = x[D.1185];
v = D.1186;
}
}
(void) 0;
bar ();
D.1157 = 0;
return D.1157;
}
D.1157 = 0;
return D.1157;
}
resulting tree/rtl:
showing frame-relative reference to "abcde" initializing data which is wrong:
(insn 12 11 13 1 (set (reg:HI 44)
(symbol_ref/f:HI ("*.LC0") [flags 0x2] <string_cst 0x160b840>)) -1 (nil)
(nil))
showing readonly reference to {'a','b','c','d','e') initializing data which is correct:
(insn 23 36 24 3 (set (reg:QI 42 [ v.0 ])
(mem/v/i:QI (symbol_ref:HI ("v") <var_decl 0x16791b0 v>) [0 v+0 S1 A8])) -1 (nil)
(nil))
--
Summary: initilizing string litteral data improperly maked
frame-relative, should be readonly static const.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc-apple-darwin7.8
GCC host triplet: ppc-apple-darwin7.8
GCC target triplet: ppc-apple-darwin7.8 / avr-none-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
2005-04-14 6:45 [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, " schlie at comcast dot net
@ 2005-04-14 14:21 ` pinskia at gcc dot gnu dot org
2005-04-16 16:45 ` pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-14 14:21 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
2005-04-14 6:45 [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, " schlie at comcast dot net
2005-04-14 14:21 ` [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, " pinskia at gcc dot gnu dot org
@ 2005-04-16 16:45 ` pinskia at gcc dot gnu dot org
2005-04-16 16:46 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-16 16:45 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
2005-04-14 6:45 [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, " schlie at comcast dot net
2005-04-14 14:21 ` [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, " pinskia at gcc dot gnu dot org
2005-04-16 16:45 ` pinskia at gcc dot gnu dot org
@ 2005-04-16 16:46 ` pinskia at gcc dot gnu dot org
2005-04-16 18:22 ` schlie at comcast dot net
` (2 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-16 16:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
2005-04-14 6:45 [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, " schlie at comcast dot net
` (2 preceding siblings ...)
2005-04-16 16:46 ` pinskia at gcc dot gnu dot org
@ 2005-04-16 18:22 ` schlie at comcast dot net
2005-04-16 18:41 ` schlie at comcast dot net
2005-04-19 15:47 ` ericw at evcohs dot com
5 siblings, 0 replies; 13+ messages in thread
From: schlie at comcast dot net @ 2005-04-16 18:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
2005-04-14 6:45 [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, " schlie at comcast dot net
` (3 preceding siblings ...)
2005-04-16 18:22 ` schlie at comcast dot net
@ 2005-04-16 18:41 ` schlie at comcast dot net
2005-04-19 15:47 ` ericw at evcohs dot com
5 siblings, 0 replies; 13+ messages in thread
From: schlie at comcast dot net @ 2005-04-16 18:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
2005-04-14 6:45 [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, " schlie at comcast dot net
` (4 preceding siblings ...)
2005-04-16 18:41 ` schlie at comcast dot net
@ 2005-04-19 15:47 ` ericw at evcohs dot com
5 siblings, 0 replies; 13+ messages in thread
From: ericw at evcohs dot com @ 2005-04-19 15:47 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-08-03 19:41 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-21018-9497@http.gcc.gnu.org/bugzilla/>
2007-11-15 16:19 ` [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const manu at gcc dot gnu dot org
2007-11-15 21:22 ` j at uriah dot heep dot sax dot de
2007-11-16 2:35 ` schlie at comcast dot net
2009-08-05 15:08 ` manu at gcc dot gnu dot org
2010-04-14 20:46 ` tfrancuz at mp dot pl
2010-09-20 16:52 ` eric dot weddington at atmel dot com
[not found] <bug-21018-4@http.gcc.gnu.org/bugzilla/>
2011-08-03 19:41 ` gjl at gcc dot gnu.org
2005-04-14 6:45 [Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, " schlie at comcast dot net
2005-04-14 14:21 ` [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, " pinskia at gcc dot gnu dot org
2005-04-16 16:45 ` pinskia at gcc dot gnu dot org
2005-04-16 16:46 ` pinskia at gcc dot gnu dot org
2005-04-16 18:22 ` schlie at comcast dot net
2005-04-16 18:41 ` schlie at comcast dot net
2005-04-19 15:47 ` ericw at evcohs dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).