[Bug c++/38342] New: __attribute__((__progmem__)) not propagated from typedef to data
The program source is trivial (yes, I've attached the .ii file as well):
#include
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
textdata 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
textdata bss dec hex filename
100 0 0 100 64 pgmspace43cc.o
BillW-MacOSX<1063>
--
Summary: __attribute__((__progmem__)) not propagated from typedef
to data
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: westfw at yahoo dot com
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c++/38342] __attribute__((__progmem__)) not propagated from typedef to data
--- Comment #1 from westfw at yahoo dot com 2008-12-01 09:16 --- Created an attachment (id=16797) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16797&action=view) output from g++ -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c++/38342] __attribute__((__progmem__)) not propagated from typedef to data
--- Comment #2 from westfw at yahoo dot com 2008-12-01 09:18 --- Created an attachment (id=16798) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16798&action=view) 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c++/38342] __attribute__((__progmem__)) not propagated from typedef to data
--- Comment #3 from westfw at yahoo dot com 2008-12-01 09:20 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c/65740] New: spectacularly bad inlinining decisions with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65740 Bug ID: 65740 Summary: spectacularly bad inlinining decisions with -Os Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: westfw at yahoo dot com Created attachment 35298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35298&action=edit preprocessed source code example. Compiling a module with 4.8.1 and -Os results in a binary more than triple the size of compiling the same module with 4.3.2, due to bad decisions about inlining a function. Dumping inline debug info (-fdump-ipa-inline) shows that the compiler is coming up with a negative "badness" for the especially-bad function (move3Servos), and the number is "suspicious" (0xBFF8) (without understanding what the badness is supposed to be.) Considering void move3Servos(Servo, float, Servo, float, Servo, float, float) with 87 size to be inlined into void loop() in oiOSoul.ino:325 Estimated growth after inlined into all is +412 insns. Estimated badness is -1073741824, frequency 0.01. Inlined into void loop() which now has time 351 and size 628,net change of +0. (also not that that was about the 40th call of move3Servos() from loop() analyzed, each with "growth" ~400 insns, and it now thinks the total size is 628, which is ridiculous.) Might be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57218 Except that that seems to describe a more trivial and less awful ocurrence. Originally noticed withing Arduino (avr-g++), but NOT cpu specific, and not C++ specific. The attached example is x86 gcc 4.7.2: /sw/lib/gcc4.7/bin/gcc-fsf-4.7 -c -Os -w foo.ii -v -saveemps -fdump-ipa-inline Using built-in specs. COLLECT_GCC=/sw/lib/gcc4.7/bin/gcc-fsf-4.7 Target: x86_64-apple-darwin11.4.2 Configured with: ../gcc-4.7.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-cloog-backend=isl Thread model: posix gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-c' '-Os' '-w' '-v' '-save-temps' '-fdump-ipa-inline' '-mtune=core2' /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1plus -fpreprocessed foo.ii -fPIC -quiet -dumpbase foo.ii -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase foo -Os -w -version -fdump-ipa-inline -o foo.s GNU C++ (GCC) version 4.7.2 (x86_64-apple-darwin11.4.2) compiled by GNU C version 4.7.2, GMP version 5.1.0, MPFR version 3.1.1, MPC version 1.0.1 warning: GMP header version 5.1.0 differs from library version 5.1.1. warning: MPFR header version 3.1.1 differs from library version 3.1.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.7.2 (x86_64-apple-darwin11.4.2) compiled by GNU C version 4.7.2, GMP version 5.1.0, MPFR version 3.1.1, MPC version 1.0.1 warning: GMP header version 5.1.0 differs from library version 5.1.1. warning: MPFR header version 3.1.1 differs from library version 3.1.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 712698abe851e71eccb1a409a1351965 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-c' '-Os' '-w' '-v' '-save-temps' '-fdump-ipa-inline' '-mtune=core2' as -arch x86_64 -force_cpusubtype_ALL -o foo.o foo.s COMPILER_PATH=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/:/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/ LIBRARY_PATH=/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/:/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.4.2/4.7.2/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-c' '-Os' '-w' '-v' '-save-temps' '-fdump-ipa-inline' '-mtune=core2' BillW-MacOSX-2<10422> size foo.o __TEXT __DATA __OBJC others dec hex 29936 209 0 0 30145 75c1 #(without inlining) BillW-MacOSX-2<10423> /sw/lib/gcc4.7/bin/gcc-fsf-4.7 -c -Os -w foo.ii -fno-inline-small-functions BillW-MacOSX-2<10424> size foo.o __TEXT __DATA __OBJC others dec hex 8725209 0 0 893422e6
[Bug target/44617] Serial Output on the atmega1280 does not work
--- Comment #11 from westfw at yahoo dot com 2010-08-22 07:18 --- Created an attachment (id=21541) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21541&action=view) Suggested patch Tested with the example. Not thoroughly tested, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
[Bug target/44617] Serial Output on the atmega1280 does not work
--- Comment #12 from westfw at yahoo dot com 2010-08-22 07:21 --- See http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=736616 This is (IMO) a bug in the __do_global_ctors in gcc/config/avr/libgcc.S When support for 24-bit flash pointers was added in edit http://gcc.gnu.org/viewcvs?view=revision&revision=143306 R20 was used to hold the extra 8 bits of address. But R20 is NOT preserved by called functions according to the AVR C calling conventions, and indeed the class initialization code ends up using R20 if there are sufficient fields to initialize. The attached patch uses R15 instead, and appears to work, but I'm not sure of the implications... I tried to change the summary, but of course it won't let me. I think this is a more serious problem than the initial problem indicates... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
[Bug target/45263] registers used in __do_global_ctors can get clobbered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263 --- Comment #9 from Bill Westfield 2010-12-04 03:11:23 UTC --- This is essentially identical to the patch I provided for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617 so it looks good to me. I had two worries: Is R15 used anywhere else in startup code that might not obey the register save conventions (ie does do_global_ctors need to preserve R15) The AVR has a lot of opcodes that are not valid on registers less than 16. It doesn't look like any of these are used here, but I wasn't 100% positive that using R15 wouldn't cause problems...
[Bug target/38342] [4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from typedef to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342 --- Comment #10 from 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...
[Bug target/38342] [4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from typedef to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342 --- Comment #12 from 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!
