with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from 20120606 : 15674 bytes
It's likely because of PR53595.
Just uploaded a new avr-gcc-4.7.1-rc1-mingw32.zip stamped 2012-06-07 with a tentative fix for that PR
with 4.7.1 prerelease from today : 15464 bytes
Problem seems corrected, I will have to test the code on the unit, but the one from 20120322 is running for months now, and as there is only 2 bytes diff, I guess it will be ok.
I though you were well aware that copying some lines [...]
I posted the "some lines" (which is actually ONE line) as a response to:
SprinterSB wrote:
Something is wrong with your inline assembler. It's not a compiler bug.
where you accused specifically the inline assembler - thus I provided it for you to inspect.
SprinterSB wrote:
out of context is pretty much useless in most cases
I have hinted about the context already:
I wrote:
The functions are lengthy (which is IMO expected for the kind of error above), which is why I can't provide a minimal example at the moment, but am willing to discuss/cooperate if you are interested.
I am still willing to discuss/cooperate, if you choose professional discussion rather than attempts to ridicule me.
But I understand also if you are not interested in the apparently laborious path to finding the source of the problem. As I said above, one of the viable options is simply to notify the user through documentation of potential problems when the switch in question is used in conjunction with inline assembler.
I though you were well aware that copying some lines [...]
I posted the "some lines" (which is actually ONE line) as a response to:
SprinterSB wrote:
Something is wrong with your inline assembler. It's not a compiler bug.
where you accused specifically the inline assembler - thus I provided it for you to inspect.
Some lines above you wrote that you use pgm_read_byte_far. Consulting avr/progmem.h from AVR-LibC tells that it expands to inline assembler that uses constraint "p".
Using "p" is wrong, wrong, wrong!
Your copy of pgm_read_byte_far does not use "p". How am I supposed to know how your local copy of some code looks like?
If you use other code than you state, then please don't be unfriendly if that leads to wrong or funny conclusions.
wek wrote:
SprinterSB wrote:
[...] out of context is pretty much useless in most cases
I have hinted about the context already:
I wrote:
The functions are lengthy (which is IMO expected for the kind of error above), which is why I can't provide a minimal example at the moment, but am willing to discuss/cooperate if you are interested.
All I can say is:
Again and again: 'asm' operand has impossible constraints is an application error. You abuse inline assembler. Fix that.
The splill fail is not related to -mstrict-X. Any option that affects cdoe generation up to and including register allogacion might make appear/disapperar that bug.
The spill fail is not related to the impossible constraint error! They are two disctinct artifacts.
There is already a spill fail reportd: PR50925. This bug is present in all supported versions of gcc and the attached test case #26765 also shreds 4.7.1 if compiled with -Os. Notice that compilation passes if -mstrict-X is added. Or if compiled -O2.
wek wrote:
But I understand also if you are not interested in the apparently laborious path to finding the source of the problem.
If you expect that I guess what source triggered the problem and maybe waste hours, days, or weeks trying around without hitting that bug: Then yes, I am not interested in that.
You abviously have an example that triggers the problem. I undestand the reasons why you are not allowed to post the test case.
However, that does not help. Source code is the interface to communicate. Source code of a test case or source code of the compiler.
You can try to minimize the test case by techniques/tools like delta-debugging to get it under the critical size so that you are allowed to show it.
Or you can explain the compiler sources and where they are wrong: If the test case is secret, then you can debug the compiler or review the sources and get in touch with the GCC developers (I am none of them).
avrfreaks does not support Opera. Profile inactive.
Some lines above you wrote that you use pgm_read_byte_far. Consulting avr/progmem.h from AVR-LibC tells that it expands to inline assembler that uses constraint "p".
Using "p" is wrong, wrong, wrong!
But that would mean that you were aware that it is NOT *my* asm which is wrong, wrong, wrong; yet accused me of it.
Moreover, if you are aware of that a library function is wrong, wrong, wrong, why don't you post an avr-libc bug report then?
But let's just take one step back. Which avr/progmem.h did you look into? I just had a look into c:\Program Files\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-mingw32\avr\include\avr\pgmspace.h, which comes directly from your bundle - and as far as I know, I used that particular pgmspace.h without modifications.
pgm_read_byte_far() "translates" into __ELPM() and that in turn for atmega2561 into __ELPM_enhanced__(). I see no "p" there. (The posted snippet in fact contained pgm_read_word_far(), but the above text is valid for that one too; and I have a function also with pgm_read_byte_far() which throws the same error).
That's not pgm_read_byte_far() but pgm_get_far_address(var).
I *am* interested in discussing [EDIT]here[/EDIT] why is using "p" constraint in that one wrong, wrong, wrong, but that's irrelevant for our discussion in this thread.
Sorry for guessing what your code might do. I should really wait until there is a test case. Just skimmed the far stuff and that line fit perfectly with an error like impossible constraint.
avrfreaks does not support Opera. Profile inactive.
I found the shortest function exhibiting the problem, spent nice two hours sectioning it from the project and reducing it somewhat. Here you are (w.c):
I added -v -save-temps -dp -fverbose-asm to the command options and attached the log, the C-file and the generated assembler for reference.
It also works if "-ffixed-2 -ffixed-3 -ffixed-4 -ffixed-5" is added to the command line, with and without the verbose flags, with and without the global register definitions.
Does it work with nix-friendly path names?
If not I'd guess it's a host problem or some buffer overflow or similar somewhere. If so, the artifact might come or go depending on computer, host, history, other programs running etc...
If you add -fdump-tree-all -fdump-rtl-all how far do the dumps get?
In my case, I could attribute the difference to better handling of compound literals (things which look like a typecast initializer, can be used e.g. to assign to structs or other complex data).
Originally, each occurence of any compound literal involved one instance of it in .data; in 471 compound literals of the same value in one module (source file) are "compressed" to one instance.
(I just realized it was not a good idea to use compound literals to assign values to struct because of the RAM usage, but the code is quite involved so I am not going to change it now just make a mental note not to do it again).
The same may have occured for string literals, if you keep them in RAM (again a bad idea generally).
Posted by SprinterSB: Wed. Jun 13, 2012 - 02:29 PM
1
2
3
4
5
Total votes: 0
salixer wrote:
1. constants are moved from .data to .rodate.
Not really a "move". It's different input sections but they go into the same output section. I don't know how size works, but I'd guess it looks at output sections.
salixer wrote:
Also some other stuff is splitted from .data to .data and .rodata, e.g. what does this mean (4.7.1):
.rodata.str1.1
0x00000000008020af 0xd5 main.o
It means that module main.o defines an object in section .rodata.str1.1. Presumably it is a string literal, aligned to 1 byte and with section flags "aMS", i.e. it can be merged with other strings.
salixer wrote:
2. These seem to be the only missing 0x100 bytes in the 4.7.1 build:
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(ceil.o):../../../../../source/avr-libc-1.8/libm/fplib/ceil.S:57:(.text.avr-libc.fplib+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_szero' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_zero.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:53:(.text.avr-libc.fplib+0x4): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_inf' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_inf.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:54:(.text.avr-libc.fplib+0x6): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_zero' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_zero.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:55:(.text.avr-libc.fplib+0x8): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_nan' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_nan.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:59:(.text.avr-libc.fplib+0xa): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_splitA' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_split3.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:72:(.text.avr-libc.fplib+0x20): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3_pse' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(mulsf3x.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(floor.o):../../../../../source/avr-libc-1.8/libm/fplib/floor.S:56:(.text.avr-libc.fplib+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_szero' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_zero.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fma.o):../../../../../source/avr-libc-1.8/libm/fplib/fma.S:48:(.text.avr-libc.fplib+0x0): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3x' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(mulsf3x.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fma.o):../../../../../source/avr-libc-1.8/libm/fplib/fma.S:53:(.text.avr-libc.fplib+0xa): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_round' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_round.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_powser.o):../../../../../source/avr-libc-1.8/libm/fplib/fp_powser.S:79:(.text.avr-libc.fplib+0x1a): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3x' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(mulsf3x.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_rempio2.o):../../../../../source/avr-libc-1.8/libm/fplib/fp_rempio2.S:50:(.text.avr-libc.fplib+0x0): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status
make: *** [../bin/Paragraph5/Paragraph_PID.elf] Error 1
W/O LTO everything is Ok.
Any suggestions are welcome!
Yes it was. I believe that this was done prematurely.
As I can see (LTO and enviroment) still needs to further adapt.
-combine and -fwhole-program are noe more needed since LTO which is even more powerful.
Even projects as big as Mozilla FireFox or GCC itself build fine with LTO.
There were some issues with linux→mingw32 canadian cross built compiler (PR50616) and AVR-specific built-ins together with LTO (PR52692) but they are fixed now.
avrfreaks does not support Opera. Profile inactive.
Posted by demiurg_spb: Mon. Aug 6, 2012 - 05:49 AM
1
2
3
4
5
Total votes: 0
So, you tell me that gcc+LTO is good enougth to build itself. It's great (realy)!
But avr-libc project is not compliant with LTO for now (maybe I wrong).
Please suggest me what approach should I follow to buld my not so big avr-project with fast-math and LTO?
I can't do it since -combine and -fwhole-program were marked as deprecated and dissapeared ~1.5 years ago.
But avr-libc project is not compliant with LTO for now (maybe I wrong).
AVR-Libc makes an assumption that does ot hold: That all bits in the same input section are located close together in their respective output section.
As discussed in abovementioned #33698 that assumption does not hold because the default linker script does ot come with a SORT directive.
Consequently, if you need AVR-Libc and LTO, you can
Call the compiler driver gcc with -Wl,--sort-section=name
Fix the malicious explicit RJMP/RCALL in AVR-Libc and use XJMP/XCALL macros instead, recompile the library (which is straight forward) and use the fixed library.
Use an ld script with sort directive as discussed in #33698 instead of the default ld script which comes without such a directive.
AFAIK Jörg is preparing the AVR-Libc 1.8.1 release that will come with this issue fixed.
@admin: Still greedy for CAPTCHA??
avrfreaks does not support Opera. Profile inactive.
Posted by demiurg_spb: Mon. Aug 6, 2012 - 10:18 AM
1
2
3
4
5
Total votes: 0
Thanks! I will try.
Let's start:
SprinterSB wrote:
Call the compiler driver gcc with -Wl,--sort-section=name
I've gotten other similar errors
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(inverse.o):../../../../../source/avr-libc-1.8/libm/fplib/inverse.S:50:(.text.avr-libc.fplib+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `__divsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_div_sf.o)
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(log.o):../../../../../source/avr-libc-1.8/libm/fplib/log.S:96:(.text.avr-libc.fplib+0x46): relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_addsub_sf.o)
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(log.o):../../../../../source/avr-libc-1.8/libm/fplib/log.S:100:(.text.avr-libc.fplib+0x4e): relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_addsub_sf.o)
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(modf.o):../../../../../source/avr-libc-1.8/libm/fplib/modf.S:90:(.text.avr-libc.fplib+0x3e): relocation truncated to fit: R_AVR_13_PCREL against symbol `__subsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_addsub_sf.o)
collect2.exe: error: ld returned 1 exit status
make: *** [../bin/Paragraph5/Paragraph_PID.elf] Error 1
Number of errors have reduced to 4.
It's good but not enough:)
Should I use only gnu99 instead of c99 in case of __flash usage?
With PROGMEM attributes I was able to use c99 and it was habitually.
Posted by demiurg_spb: Fri. Aug 10, 2012 - 06:32 PM
1
2
3
4
5
Total votes: 0
English is not my native language, and maybe I don't understand what you are asking me for..
Please look attached files in my previous post, all options is here.
Compilation with LTO ends successfully only if project size is <16K and almost without math (because of avr-libc rjmps and rcalls).
Only difference what I see is: last times I've called compiler with all *.c files at once:
Quote:
Another (simpler) way to enable link-time optimization is:
gcc -o myprog -flto -O2 foo.c bar.c
Posted by demiurg_spb: Wed. Aug 15, 2012 - 08:18 AM
1
2
3
4
5
Total votes: 0
1)
I found an annoying problem:(
The EEPROM data are sorted in reverse order in target hex-file.
I.E. in my src file:
EEMEM int x1;
EEMEM int x2;
EEMEM int x3;
in map and hex files:
EEMEM int x3;
EEMEM int x2;
EEMEM int x1;
2)
And if only lto is turned on all dummy EEPROM variables are disappeared.
I understand if I put all EEPROM data in one structure everything should be ok. But I want to know: other approach is possible?
The EEPROM data are sorted in reverse order in target hex-file.
But this was always a possibility. C gives no guarantee about the order of data in memory. As you say, if you want to guarantee such an ordering then use a struct:
Posted by demiurg_spb: Fri. Aug 17, 2012 - 06:54 AM
1
2
3
4
5
Total votes: 0
It's me again.
New error appears if target mcu is mega128
original code of file: avr-libc/avr/boot.h
#if defined (SPMCSR)
# define __SPM_REG SPMCSR
#elif defined (SPMCR)
# define __SPM_REG SPMCR
#else
# error AVR processor does not provide bootloader support!
#endif
error: attempt to use poisoned "SPMCR"
modified code (compiles without any errors):
#if defined(SPMCSR)
# define __SPM_REG SPMCSR
#elif !defined (__AVR_ATmega128__)
# if defined(SPMCR)
# define __SPM_REG SPMCR
# endif
#endif
#if !defined(__SPM_REG)
# error error AVR processor does not provide bootloader support!
#endif
I guess it's avr-gcc bug.
Original avr-libc code is correct.
JW
- Log in or register to post comments
TopJust uploaded a new avr-gcc-4.7.1-rc1-mingw32.zip stamped 2012-06-07 with a tentative fix for that PR.
compiles without complaints with
Am I to be blamed because me ran out of crystal balls?
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Top...same with
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Topwith 4.7.1 prerelease from today : 15464 bytes
Problem seems corrected, I will have to test the code on the unit, but the one from 20120322 is running for months now, and as there is only 2 bytes diff, I guess it will be ok.
Thanks again for all your work!
- Log in or register to post comments
TopI posted the "some lines" (which is actually ONE line) as a response to:
But I understand also if you are not interested in the apparently laborious path to finding the source of the problem. As I said above, one of the viable options is simply to notify the user through documentation of potential problems when the switch in question is used in conjunction with inline assembler.
JW
- Log in or register to post comments
TopUsing "p" is wrong, wrong, wrong!
Your copy of pgm_read_byte_far does not use "p". How am I supposed to know how your local copy of some code looks like?
If you use other code than you state, then please don't be unfriendly if that leads to wrong or funny conclusions.
You abviously have an example that triggers the problem. I undestand the reasons why you are not allowed to post the test case.
However, that does not help. Source code is the interface to communicate. Source code of a test case or source code of the compiler.
You can try to minimize the test case by techniques/tools like delta-debugging to get it under the critical size so that you are allowed to show it.
Or you can explain the compiler sources and where they are wrong: If the test case is secret, then you can debug the compiler or review the sources and get in touch with the GCC developers (I am none of them).
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Topavrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopMoreover, if you are aware of that a library function is wrong, wrong, wrong, why don't you post an avr-libc bug report then?
But let's just take one step back. Which avr/progmem.h did you look into? I just had a look into c:\Program Files\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-mingw32\avr\include\avr\pgmspace.h, which comes directly from your bundle - and as far as I know, I used that particular pgmspace.h without modifications.
pgm_read_byte_far() "translates" into __ELPM() and that in turn for atmega2561 into __ELPM_enhanced__(). I see no "p" there. (The posted snippet in fact contained pgm_read_word_far(), but the above text is valid for that one too; and I have a function also with pgm_read_byte_far() which throws the same error).
What did I overlook?
JW
- Log in or register to post comments
TopAVR-LibC: SVN trunk 2294: include/avr/pgmspace.h:1030
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopI *am* interested in discussing [EDIT]here[/EDIT] why is using "p" constraint in that one wrong, wrong, wrong, but that's irrelevant for our discussion in this thread.
JW
- Log in or register to post comments
TopSorry for guessing what your code might do. I should really wait until there is a test case. Just skimmed the far stuff and that line fit perfectly with an error like impossible constraint.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopI found the shortest function exhibiting the problem, spent nice two hours sectioning it from the project and reducing it somewhat. Here you are (w.c):
The "reserved" registers are instrumental. Removing them removes both errors. Adding -ffixed-rN brings the errors back.
Enjoy! ;-)
JW
- Log in or register to post comments
TopI can compile that code without problem.
I added -v -save-temps -dp -fverbose-asm to the command options and attached the log, the C-file and the generated assembler for reference.
It also works if "-ffixed-2 -ffixed-3 -ffixed-4 -ffixed-5" is added to the command line, with and without the verbose flags, with and without the global register definitions.
Does it work with nix-friendly path names?
If not I'd guess it's a host problem or some buffer overflow or similar somewhere. If so, the artifact might come or go depending on computer, host, history, other programs running etc...
If you add -fdump-tree-all -fdump-rtl-all how far do the dumps get?
Attachment(s):
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopI now downloaded the newer version of your bundle (to the same directory, so paths did not change), and the problem is gone.
Does that ring some bells?
JW
[EDIT] added the logs from the failing run with the older version
Attachment(s):
- Log in or register to post comments
TopYup, it comes from a single function, file is attached if you want to check
options are:
-mmcu=atmega168 -I. -ffreestanding -fno-move-loop-invariants -fno-tree-loop-optimize -funsigned-char -funsigned-bitfields -fshort-enums -fpack-struct -ffunction-sections -fdata-sections -Wl,--relax,--gc-sections -mcall-prologues -mstrict-X -flto -gstabs -DF_CPU=16000000 -Os -Wall -Wstrict-prototypes -std=gnu99
Compiler removed 4 bytes, these 2 lines:
I will upload the code to my board and run it.
Attachment(s):
- Log in or register to post comments
Top@Jan: I filed it as http://gcc.gnu.org/PR53615
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopThanks.
- Log in or register to post comments
TopJohann,
When trying to compile http://gcc.gnu.org/bugzilla/atta... with the "first" bundle, it fails even if the shorter version of CODE32 is used.
Why?
JW
- Log in or register to post comments
TopI don't know the root cause of the problem. A reason might be as speculated in the PR.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopHi,
I've compiled a toolchain on x86_64 Linux with:
avr-gcc (GCC) 4.7.1 20120606 (prerelease)
binutils 2.22.52
avr-libc 1.8.0
The results of avr-size look like this:
my old GCC 4.3.4, binutils 2.20.1, libc 1.7.1:
new toolchain:
The smaller program size IMHO is impressive, but I wonder why Data also loses that much?
- Log in or register to post comments
TopThe .map file wil tell you. (or the output of avr-nm, whichever you prefer).
- Log in or register to post comments
TopIn my case, I could attribute the difference to better handling of compound literals (things which look like a typecast initializer, can be used e.g. to assign to structs or other complex data).
Originally, each occurence of any compound literal involved one instance of it in .data; in 471 compound literals of the same value in one module (source file) are "compressed" to one instance.
(I just realized it was not a good idea to use compound literals to assign values to struct because of the RAM usage, but the code is quite involved so I am not going to change it now just make a mental note not to do it again).
The same may have occured for string literals, if you keep them in RAM (again a bad idea generally).
JW
- Log in or register to post comments
Top1. constants are moved from .data to .rodate. Also some other stuff is splitted from .data to .data and .rodata, e.g. what does this mean (4.7.1):
2. These seem to be the only missing 0x100 bytes in the 4.7.1 build:
3. sizes in .bss are identical
PS: Adding "-flto" also saves some more space. At least it strips global variables from .bss that are not used anywhere.
- Log in or register to post comments
Topavrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopThe avr-gcc 4.7.1 is released officialy!!!
- Log in or register to post comments
TopGCC 4.7.1 is released officially :P
- Log in or register to post comments
Tophttp://gcc.gnu.org/bugzilla/atta...
You can download the patch via the "View" link and then apply it like so:
Does that patch has further impact on the code size?
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Topavr-gcc (GCC) 4.7.1 20120606 (prerelease)
errors:
W/O LTO everything is Ok.
Any suggestions are welcome!
Oh, how I miss -combine option:)
- Log in or register to post comments
TopWhat means "W/O"?
Looks like a known AVR-Libc issue, see
http://savannah.nongnu.org/bugs/...
I don't think you need -combine with LTO, wasn't -combine removed?
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Top- Log in or register to post comments
TopAs I can see (LTO and enviroment) still needs to further adapt.
Thanks you for your reply!
- Log in or register to post comments
TopEven projects as big as Mozilla FireFox or GCC itself build fine with LTO.
There were some issues with linux→mingw32 canadian cross built compiler (PR50616) and AVR-specific built-ins together with LTO (PR52692) but they are fixed now.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopSo, you tell me that gcc+LTO is good enougth to build itself. It's great (realy)!
But avr-libc project is not compliant with LTO for now (maybe I wrong).
Please suggest me what approach should I follow to buld my not so big avr-project with fast-math and LTO?
I can't do it since -combine and -fwhole-program were marked as deprecated and dissapeared ~1.5 years ago.
- Log in or register to post comments
TopAs discussed in abovementioned #33698 that assumption does not hold because the default linker script does ot come with a SORT directive.
Consequently, if you need AVR-Libc and LTO, you can
- Call the compiler driver gcc with -Wl,--sort-section=name
- Fix the malicious explicit RJMP/RCALL in AVR-Libc and use XJMP/XCALL macros instead, recompile the library (which is straight forward) and use the fixed library.
- Use an ld script with sort directive as discussed in #33698 instead of the default ld script which comes without such a directive.
AFAIK Jörg is preparing the AVR-Libc 1.8.1 release that will come with this issue fixed.@admin: Still greedy for CAPTCHA??
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopThanks! I will try.
Let's start:
Number of errors have reduced to 4.
It's good but not enough:)
Should I use only gnu99 instead of c99 in case of __flash usage?
With PROGMEM attributes I was able to use c99 and it was habitually.
- Log in or register to post comments
TopI've just made test [LTO vs combine] with other little project and ... :shock:
avr-gcc (WinAVR 20100110) 4.3.3 [with combine]
Program: 13778 bytes (84.1% Full)
Data: 513 bytes (50.1% Full)
EEPROM: 82 bytes (16.0% Full)
avr-gcc (GCC) 4.7.1 20120606 (prerelease) [with lto]
Program: 15860 bytes (96.8% Full) <--------------- +2000bytes !!!
Data: 521 bytes (50.9% Full)
EEPROM: 83 bytes (16.2% Full) <--------------- +1byte ???
I have played with different optimisation parameters... and this is the best result.
Something is wrong. But I can't see it.
Attached files:
Attachment(s):
- Log in or register to post comments
TopHow are the options for the last link, i.e. after lto proper has finished?
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopEnglish is not my native language, and maybe I don't understand what you are asking me for..
Please look attached files in my previous post, all options is here.
Compilation with LTO ends successfully only if project size is <16K and almost without math (because of avr-libc rjmps and rcalls).
Only difference what I see is: last times I've called compiler with all *.c files at once:
I yet only haven't try to use gold linker instead collect2.
Should I?
- Log in or register to post comments
TopDoes it work if you link with these?
-nodefaultlibs -lm -lgcc -lc -lgcc
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopOh eeeeeeeee!!!
avr-gcc (GCC) 4.7.1 20120606 (prerelease) [with lto and -nodefaultlibs -lm -lgcc -lc]
Program: 13530 bytes (82.6% Full)
Data: 513 bytes (50.1% Full)
EEPROM: 83 bytes (16.2% Full) <--------------- +1byte ???
It's perfect!!! Thank you very much!!!
- Log in or register to post comments
TopBTW maybe you know why next code compiles without any warnings and errors... If I remember, IAR makes warn in this case.
- Log in or register to post comments
TopIt's odd and I don't understand why the eeprom usage does up.
The -flto -lm issue is discussed in avr-gcc-list: binutils 2.22 blow up program size with -flto. It's an old AVR-Libc issue that's cast into stone...
For the missing warning you can file a GCC problem report.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Top1)
I found an annoying problem:(
The EEPROM data are sorted in reverse order in target hex-file.
I.E. in my src file:
EEMEM int x1;
EEMEM int x2;
EEMEM int x3;
in map and hex files:
EEMEM int x3;
EEMEM int x2;
EEMEM int x1;
2)
And if only lto is turned on all dummy EEPROM variables are disappeared.
I understand if I put all EEPROM data in one structure everything should be ok. But I want to know: other approach is possible?
- Log in or register to post comments
TopBut this was always a possibility. C gives no guarantee about the order of data in memory. As you say, if you want to guarantee such an ordering then use a struct:
- Log in or register to post comments
TopIt's me again.
New error appears if target mcu is mega128
original code of file: avr-libc/avr/boot.h
error: attempt to use poisoned "SPMCR"
modified code (compiles without any errors):
I guess it's avr-gcc bug.
Original avr-libc code is correct.
- Log in or register to post comments
Topavrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopBut how it possible?
There is no bug in boot.h
- Log in or register to post comments
Topboot.h uses a poisoned macro, namely SPMCR. AVR-Libc poisons it elsewhere, but missed to update the use site.
Or are you saying that AVR-Libc is not poisoning SPMCR anywhere, and the poisoning is out of the blue and a GCC artifact?
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopYou are right!
I found in iom128.h:
#pragma GCC poison SPMCR
So that boot.h should be modified to fix this situation...
- Log in or register to post comments
Topavr-gcc (GCC) 4.7.1 20120606 (prerelease)
warning: uninitialized variable 'x' put into program memory area [-Wuninitialized]
No warning...
- Log in or register to post comments
TopPages