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

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263

--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2013-02-11 15:09:40 UTC ---
Created attachment 29418
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29418
draft patch

    PR target/56263
    * config/avr/avr.opt (-mstrict-addr-space-subsets): New option and...
    (avr_strict_addr_space_subsets)... attached variable.
    * config/avr/avr.c (avr_addr_space_subset_p): Use it to determine
    whether of not an address spaces are subsets.
    * doc/invoke.texi (AVR Options) <-mstrict-addr-space-subsets>:
    Document it.


I had a look at this.

With strict address spaces, GCC will emit zeroes as result of casts across
address spaces.  This means that code like

char read_char (const char *address, int data_in_flash)
{
    if (data_in_flash)
        return *(const __flash char*) address;
    else
        return *address;
}

will no more operate correctly.  For the same reason, it is no more possible to
use PSTR from AVR-LibC with functions that get an address space pointer because
PSTR puts (and must put) the literal in generic space.

(In reply to comment #1)
> I think the next test case should also be considered.
> 
> const char __flash* const __flash names[] =
> {
>     "flash_str1",
>     "flash_str2"

This cannot work because ISO/IEC TR18037 forces these literals into generic
space.

> };
> 
> const char __flash* name1 = names[0]; // ok
> const char*         name2 = names[1]; // error

Attached is the draft patch that I used.  This means that in order to make this
work, the compiler proper has to be extended and the feature cannot be
implemented in the avr backend alone.  Thus suspending for now and for an other
stage.