http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |ASSIGNED
--- Comment #7 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2013-03-12
21:21:19 UTC ---
This patch implements -Waddr-space-convert and will print diagnostics for casts
to non-containing address spaces.
It's just a quick implementation in order to get the patch into 4.8.0 which
will be frozen for release withing the next few days.
Some work still to be done:
- Try to avoid warnings for casts from PSTR ("text") to const __flash char*.
PSTR is a commonly used idion from AVR-LibC's avr/progmem.h, namely
#define PSTR(s) \
(__extension__( \
{ \
static const char __c[] __attribute__((__progmem__)) = (s); \
&__c[0]; \
}))
- Try to distinguish between implicit casts and explicit casts requested
by the user
- Allow to pick a warning level for the previous kinds of casts
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> >
> > It's a shortcoming in the Embedded C paper and I agree with you that more
> > elaborate Embedded C paper would be more convenient here.
> >
> > There are two ways out of this:
> >
> > 1) Extend the Embedded C paper and propose an addendum to the ISO WG14.
> >
> > 2) Implement this extension no matter whether Embedded C comes with this
> > extension. Find someone who implements this extension, supports it and
> > makes sure there are no conflicts with the vanilla Embedded C.
> >
> > Notice that with the extension, in the following example "init" would be
> > located in flash but "assign" would still be located in RAM.
> >
> > void f_init (void)
> > {
> > const __flash char *str = "init";
> > }
> >
> > void f_assign (void)
> > {
> > const __flash char *str;
> > str = "assign";
> > }
>
> In my view, in this situation, the data must be placed in a flash ...
> Standard really needs serious improvement.
ACK. May be that is the reason for why Embedded-C did not go into C11.
However, waiting until the Embedded-C paper will be extended in that direction
is pointless. Just try to participate the ISO process; it will take years...
Maybe it's doable in the avr backend, but then we need a proper specification
and enough knowledge to decide whether or not all hooks are guaranteeing that
the BE can take the decision in every case.
> It's logical, when the right-hand and left-hand side of each other have the
> appropriate type. Moreover, for the implementation of this simple idea is not
> objective difficulties.
Sorry? I don't understand you last remark. Are you saying it is trivial to
implement in the avr backend?
Before implementing it, you'll have to specify it. What should do this code?
const __flash char* f (int i)
{
const __flash char *p = "Hallo" + i;
return p;
}
