[Bug target/56263] [avr] Provide strict address-space checking

["gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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;
}