--- Comment #15 from eric dot weddington at atmel dot com 2008-06-06 20:39
---
This bug report is completely unclear. 'static const' will not be overloaded to
imply that a variable is stored in flash. The relevant C language draft
concerning mulitple memory spaces will have to be
--- Additional Comments From schlie at comcast dot net 2005-02-28 13:51
---
(In reply to comment #9)
IMHO, solution of this issue would require a language different from C that
is
able to handle different classes of pointers.
Was hoping that any designated read access to data
--- Additional Comments From schlie at comcast dot net 2005-02-28 13:55
---
(In reply to comment #10)
(In reply to comment #9)
IMHO, solution of this issue would require a language different from C that
is
able to handle different classes of pointers.
Was hoping that any
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-28 21:58 ---
I think the key problem is, that C language permits you to pass pointers to
your static const data structures to other functions. Possibly functions that
are not located within the same source file.
--- Additional Comments From ericw at evcohs dot com 2005-02-28 22:01
---
Subject: Re: static initialization .data redundantly copied
to ram prior to use.
bjoern dot m dot haase at web dot de wrote:
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-28
--- Additional Comments From schlie at comcast dot net 2005-03-01 01:02
---
Subject: Re: static initialization .data redundantly
copied to ram prior to use.
--- Additional Comments From bjoern dot m dot haase at web dot de
I think the key problem is, that C language permits you
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
04:07 ---
Huh?
--
What|Removed |Added
Component|c |target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
04:11 ---
I assume you are talking about the following code:
/* __do_copy_data is only necessary if there is anything in .data section.
Does not use RAMPZ - crt*.o provides a replacement for 64K devices. */
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
04:14 ---
And this fixme:
/* FIXME: output these only if there is anything in the .data / .bss
sections - some code size could be saved by not linking in the
initialization code from libgcc if one or both
--- Additional Comments From schlie at comcast dot net 2005-02-28 04:24
---
(In reply to comment #3)
*** This bug has been marked as a duplicate of 18145 ***
sorry, no.
- that bug says don't copy when there's no data to copy.
- this bug says, don't static read-only data even if
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
04:28 ---
(In reply to comment #4)
(In reply to comment #3)
*** This bug has been marked as a duplicate of 18145 ***
sorry, no.
oh, this is still a target bug.
--
What|Removed
--- Additional Comments From schlie at comcast dot net 2005-02-28 04:40
---
oh, this is still a target bug.
Possibly (but likely of similar concern for other small embedded targets)
The problem is that the initialization data which is linked in .data (stored in
readable flash/rom)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
04:46 ---
Yes because MOVE_RATIO is too low for avr really. But there might different
issues here really, one is
for an example MOVE_RATIO is too low which causes the addition of the .data
stuff but the other is
14 matches
Mail list logo
