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.
