g++ specific bug with prog_uchar in 4.3.0 ?

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a known bug in g++ 4.3.0 with respect to atributes that are a part of a typedef or something? I have this trivial program pgmspace.c:

BillW-MacOSX<1059> cat pgmspace.c
#include 

prog_uchar foo [10][10] = { 0 };
BillW-MacOSX<1060>

When compiled with gcc, it does what I expect:

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> 

But when compiled with g++, the data is NOT put in program memory:

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

(Yes, this is the pre-built macos binary distributed with the Arduino environment. Can someone try it with a more normal distribution?)

I can't tell whether this is related or not:
http://gcc.gnu.org/bugzilla/show...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can confirm this:

j@uriah 197% avr-gcc-4.3.1 -mmcu=atmega168 -c foo.C; avr-size foo.o
   text    data     bss     dec     hex filename
      0       0     100     100      64 foo.o
j@uriah 198% avr-gcc-4.2.2 -mmcu=atmega168 -c foo.C ; avr-size foo.o
   text    data     bss     dec     hex filename
    100       0       0     100      64 foo.o

No, bug 34734 appears to be unrelated. First, it already applies to
GCC 4.2.x, and then, it's a warning only but the generated code is
fine there.

I'd say file a GCC bug report for it.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Is there a known bug in g++ 4.3.0 with respect to atributes that are a part of a typedef or something? I have this trivial program pgmspace.c:

#include 

prog_uchar foo [10][10] = { 0 };

But when compiled with g++, the data is NOT put in program memory:

Please, point me to the documentation of avr-gcc/avr-g++ that mentions attributes of types.

progmem is documented as attribute of a declaration, attribute in a type is undocumented and unspecified.

The flaw is that avr-gcc accepts attributes on types like "prog_char" at all; it should error on that.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI, I closed PR38342 as WON'T FIX.

That means that attribute 'progmem' might not work as expected/intended in typedefs like 'prog_char'.

Attribute 'progmem' in typedef has never been documented except maybe in some antique versions < 3.0.

It's an undocumented feature and will not be supported consistently in the near future as decided by avr port maintainers, i.e. there will be neither support of that feature nor diagnostic message on non-robust code.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was assuming that since the avr-libc authors had used this, that it was supposed to work. I guess not.
Thank you for the definitive answer.