Bug 38342 - [4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from typedef to data
[4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from...
Status: RESOLVED WONTFIX
Product: gcc
Classification: Unclassified
Component: target
4.3.0
: P5 normal
: 4.4.7
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-01 09:14 UTC by Bill Westfield
Modified: 2012-02-06 13:55 UTC (History)
4 users (show)

See Also:
Host:
Target: avr
Build:
Known to work: 4.0.2, 4.2.2
Known to fail: 4.3.0
Last reconfirmed: 2009-01-24 16:20:54


Attachments
output from g++ -v (3.96 KB, text/plain)
2008-12-01 09:16 UTC, Bill Westfield
Details
pgmspace.ii for the failing g++ compilation (8.78 KB, text/plain)
2008-12-01 09:18 UTC, Bill Westfield
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Westfield 2008-12-01 09:14:36 UTC
The program source is trivial (yes, I've attached the .ii file as well):
   #include <avr/pgmspace.h>
   prog_uchar foo [10][10] = { 0 };
When compiled with g++ 4.3.0, this does not actually put the data in program space.
BillW-MacOSX<1063> /Downloads/arduino-0012/hardware/tools/avr/bin/avr-g++ pgmspace.c -mmcu=atmega168 -c -o pgmspace43c++.o --version
avr-g++ (GCC) 4.3.0
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

BillW-MacOSX<1064> /Downloads/arduino-0012/hardware/tools/avr/bin/avr-g++ pgmspace.c -mmcu=atmega168 -c -o pgmspace43c++.o         
BillW-MacOSX<1065> /Downloads/arduino-0012/hardware/tools/avr/bin/avr-size pgmspace43c++.o
   text    data     bss     dec     hex filename
      0       0     100     100      64 pgmspace43c++.o 

It works correctly with gcc 4.3.0 (from the same distribution), and it works correctly with g++ 4.1

BillW-MacOSX<1060> /Downloads/arduino-0012/hardware/tools/avr/bin/avr-gcc pgmspace.c -mmcu=atmega168 -c -o pgmspace43cc.o --version
avr-gcc (GCC) 4.3.0
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

BillW-MacOSX<1061> /Downloads/arduino-0012/hardware/tools/avr/bin/avr-gcc pgmspace.c -mmcu=atmega168 -c -o pgmspace43cc.o
BillW-MacOSX<1062> /Downloads/arduino-0012/hardware/tools/avr/bin/avr-size pgmspace43cc.o
   text    data     bss     dec     hex filename
    100       0       0     100      64 pgmspace43cc.o
BillW-MacOSX<1063>
Comment 1 Bill Westfield 2008-12-01 09:16:13 UTC
Created attachment 16797 [details]
output from g++ -v
Comment 2 Bill Westfield 2008-12-01 09:18:14 UTC
Created attachment 16798 [details]
pgmspace.ii for the failing g++ compilation

Actual compile command:

/Downloads/arduino-0012/hardware/tools/avr/bin/avr-g++ pgmspace.c -mmcu=atmega168 -c -o pgmspace43c++.o -save-temps -v >&foo.out
Comment 3 Bill Westfield 2008-12-01 09:20:17 UTC
Bug has been reproduced on at least two hosts.
See also avrfreaks discussion: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=515859#515859
Comment 4 Joerg Wunsch 2008-12-01 10:37:55 UTC
Note that this is a GCC 4.3.x regression; GCC 4.2.x compiled the code the
way expected.
Comment 5 Richard Biener 2009-01-24 10:20:59 UTC
GCC 4.3.3 is being released, adjusting target milestone.
Comment 6 Richard Biener 2009-08-04 12:29:35 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 7 Richard Biener 2010-05-22 18:12:51 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 8 Richard Biener 2011-06-27 12:12:37 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 9 Georg-Johann Lay 2011-07-03 20:55:42 UTC
Closed as WON'T FIX.

Please don't use undocumented features and read chapter "Specifying Attributes of Types" in you user manual. There's nothing like a type attribute for AVR. Read the documented AVR part of "Specifying Attributes of Variables" to use __attribute__((progmem)) appropriately.

Current:
http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type-Attributes

4.3.0:
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Type-Attributes.html#Type-Attributes
Comment 10 Bill Westfield 2011-07-05 00:22:58 UTC
I was using documented avr-libc features.  Does that mean that this is an avr-libc bug rather than a gcc bug?  Neither of the web pages you reference mention "progmem" or even AVR at all...
Comment 11 Georg-Johann Lay 2011-07-05 08:43:17 UTC
(In reply to comment #10)
> I was using documented avr-libc features.  Does that mean that this is an
> avr-libc bug rather than a gcc bug?  Neither of the web pages you reference
> mention "progmem" or even AVR at all...

As I wrote, the linked pages show that progmem is not documented for types.
For progmem on variables, you have to switch to the "Specifying Attributes of Variables" section of user manual:

trunk:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes

or, e.g. 4.5.2:
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Variable-Attributes.html#Variable-Attributes

The AVR section is at the end of the page, dunno why the ordering is not correct.

I just can speculate about the reason why these types are defined in avr-libc, I guess it's for historical reasons and legacy code.

avr-libc cannot ensure a feature that avr-gcc does not provide.

It's agreed by the avr maintainers to do nothing about that, so the only thing that could help you to find respective flaces in your sources would be a typedef like

typedef char __attribute__((progmem,deprecated("attribute 'progmem' in typedef is an undocumented feature"))) prog_char;

in avr-libc that triggered a diagnostic:

foo.c:4:17: warning: 'prog_char' is deprecated (declared at foo.c:2): attribute 'progmem' in typedef is an undocumented feature [-Wdeprecated-declarations]

However, that won't help with your own typedefs.

At current, progmem for types appears to work for C and not to work for C++, but that can change in the future.
Comment 12 Bill Westfield 2011-07-06 21:18:26 UTC
Ah.  So this is the same compiler behavior that results in C++ overloading not being able to tell the difference between a RAM pointer and a progmem pointer; the attribute ends up only associated with the variable and not with the types at all...  Consistency is good, and I think I can see how having too many type modifiers would end up being dangerous.  Thanks for the explanations!
Comment 13 Georg-Johann Lay 2012-02-06 13:55:09 UTC
For avr-libc users, please f'up to
http://savannah.nongnu.org/bugs/?33716