avr-gcc 4.7.0 for the brave

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

I just built a new avr-gcc-4.7.0 snapshot for Win32.

For hints on how to use and "install", see:

https://www.avrfreaks.net/index.p...

It contains:

  • avr-gcc-4.7.0 (C/C++) SVN 182625 with the patches in ./source
  • binutils 2.21
  • avr-libc 1.7.1
New features are:
  • Named address spaces __pgm (16 bit) and __pgmx (24 bit)
  • New built-in 24-bit types __int24 and __uint24
  • New command line options, see --help=target
    • -mbranch-cost=
    • -maccumulate-args
    • -mstrict-X
  • New built-in functions, see AVR Built-in Functions
  • Tweaks for 64-bit integers
  • Devices with 8-bit SP have their own multilibs
Again, I dropped it as ZIP at sourceforge. Just download and unpack. That't it. For the first time ever this is a avr-gcc 4.x for which I get smaller binaries compared to 3.4.6 for my test project: 13902 against 13904 (the last 4.7 snapshot built to 14242 with same sources and options).

Edit: binutils 2.21

avrfreaks does not support Opera. Profile inactive.

Last Edited: Fri. Dec 23, 2011 - 02:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am definitely not the brave one, but just for the heck of it, I tried compiling an existing project with it. Two things came up. First, it did not quite like __attribute__((always_inline)). It said "always_inline function might not be inlinable". Second, ld.exe crashed.

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

Can you be bit more precise than "ld crashed"?

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Can you be bit more precise than "ld crashed"?

avr-gcc-4.7-sp8-di-182625-mingw32\bin\avr-gcc -fwhole-program -g -Wextra -Wstrict-prototypes -Wundef -Wall -Werror  -std=gnu99 -fshort-enums -Wsign-compare  	-fno-inline-small-functions  	-Wl,--relax -Os -mmcu=atmega324p    -o main.elf main.c 

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

*** wait with pending attach
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 00400000 004ff000   d:\z2\avr-gcc-4.7-sp8-di-182625-mingw32\avr\bin\ld.exe
ModLoad: 7c900000 7c9b0000   C:\WINDOWS\system32\ntdll.dll
ModLoad: 7c800000 7c8f4000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 77c10000 77c68000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77d40000 77dd0000   C:\WINDOWS\system32\USER32.dll
ModLoad: 77f10000 77f56000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 77dd0000 77e6b000   C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f01000   C:\WINDOWS\system32\RPCRT4.dll
(790.98c): Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=00000000 ecx=0000000a edx=00000000 esi=0156e360 edi=0000000c
eip=0046af6b esp=010ffb40 ebp=010ffb88 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
*** ERROR: Module load completed but symbols could not be loaded for d:\z2\avr-gcc-4.7-sp8-di-182625-mingw32\avr\bin\ld.exe
ld+0x6af6b:
0046af6b 8b4304          mov     eax,dword ptr [ebx+4] ds:0023:00000004=????????
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ld.exe does not access violate if I remove -Wl,--relax from the command line.

Then, avr-size fails (does not seem to like the --mcu option any more):

D:\z2\avr-gcc-4.7-sp8-di-182625-mingw32\bin\avr-size --mcu=atmega324p --format=avr main.elf | grep bytes
D:\z2\avr-gcc-4.7-sp8-di-182625-mingw32\bin\avr-size: unrecognized option `--mcu=atmega324p'
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I wrote, this is a vanilla toolchain and thus avr-size is unpatched.

I also see crashing avr-ld 2.22 with --relax. So I guess binutils 2.22 are broken; I used them just as any other prerequisite for GCC.

Using binutils 2.21 fixes the problem so best will be I rebuild the tools using binutils 2.21 and update the zip from above.

avrfreaks does not support Opera. Profile inactive.

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

I would think I could point Studio 4.18 to the path for this toolchain w/o having to uninstall my Winavr, right ?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Quote:

I would think I could point Studio 4.18 to the path for this toolchain w/o having to uninstall my Winavr, right ?

Yes but it's on a per project basis so you need to Project-Configuration Options-Custom Options and set the path to avr-gcc for each project.

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

w00t, I'm taking it and will test it, with your previous 4.7.0 it was also the first time for my project to take less space, since 4.3.0, so I never used a 4.3.1+ !

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

There is a updated version now that uses binutils 2.21 instead of binutils 2.22. ZIP file name is the same.

For programs that use indirect struct access you can try -mstrict-X option. Similar for C++.

For programs that pass many parametrs on stack (printf et al.) you can try the -maccumulare-args.

I also saw that -foptimize-sibling-calls increases code size in cases when the epilogue is expensive.

avrfreaks does not support Opera. Profile inactive.

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

Does this build has LTO or not?

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

FYI, my project:

gcc4.3.0 -combine -fwhole-program with all .c on one command line:
15852 bytes

gcc4.7.0 regular makefile without combining, all .c compiled separately:
15854 bytes

gcc4.7.0 with -mstrict-X
15764 bytes

Really good :D

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

Magister wrote:
Does this build has LTO or not?
Yes.

There is no LTO and no plugins.

avrfreaks does not support Opera. Profile inactive.

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

Quote:

-maccumulare-args.

Is it really that or is it -maccumlate-args ? It's kind of unusual to have non-English command line options !

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

It's just a tippo, --help=target say -maccumulate-args

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Magister wrote:
Does this build has LTO or not?
Yes.
I see what you did there ಠ_ಠ

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

UAAA, there is a brain-dead thinko in ISR prologue. I will fix it soon...

avrfreaks does not support Opera. Profile inactive.

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

Almost everything works fine in my project. It seems the only failing place is where I multiply/divide a bunch of 32/16/8 bits variables all together. I will try to break the formula in multiple parts or cast them to see if it solves it.

EDIT: it seems my problem came from the ISR bug, I have no problem with the new version.

Last Edited: Wed. Jan 4, 2012 - 07:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ISR flaw is fixed now: Archive name is still avr-gcc-4.7-sp8-di-182625-mingw32.zip but from 2010-01-04.

avrfreaks does not support Opera. Profile inactive.

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

I have a warning I do not have with previous gcc, about an uninitialized variable put into program memory area.

I made a minimized case if you want to see it.

Attachment(s): 

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

Thanks, it's filed as PR51756. You can add yourself to CC list so that you get informed as the bug status changes.

avrfreaks does not support Opera. Profile inactive.

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

Hi,

I've been testing your build of avrgcc4.7 and got pretty good results in terms of codesize, but i encountered a weird problem:
I am using avrstudio5 and if it calls make -all there is nothing recompiled, when I change a header file on which a source file depends on.
If I use another compiler like the builtin 4.5.1 of avrstudio or the current one in winavr 4.3.3 it simply works.
Can this be a bug in avrgcc? or the make version beeing somehow incompatible with the gcc4.7!?!
or is it just a weird avrstudio flaw?

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

sebion wrote:
I am using avrstudio5 and if it calls make -all there is nothing recompiled, when I change a header file on which a source file depends on.
something is wrong with the dependencies - for whatever reason. It's not a gcc issue.

avrfreaks does not support Opera. Profile inactive.

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

But how can it be, that the error depends on the used version of avrgcc?
Is the gcc completely unenvolved in calculating dependencies between source files?

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

SprinterSB wrote:
something is wrong with the dependencies - for whatever reason. It's not a gcc issue.
Why are you so sure about that? The dependencies are often auto-generated by the -M options of gcc. Also the makefile generated by AVR-Studio 5 does that.

Stefan Ernst

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

I've now solved the issue:
When adding the path of avrgcc to the Path variable in windows, everything works fine.
But I have no clue how this is possible and why there is no error message giving a clue that the Path variable has to be changed...

EDIT: I made a mistake and somehow confused 4.7.0 with 4.3.3. The problem is still unsolved.

EDIT2: I've looked into the .d file generated by gcc and I see now that the difference between gcc4.7 and older versions is located in the first line(I've made a simple minimal avrstudio example):

avrgcc4.5.1 outputs: AVRGCC1test.d AVRGCC1test.o: .././AVRGCC1test.c \

avrgcc4.7 doesnt include the o file and thus outputs:
AVRGCC1test.d: .././AVRGCC1test.c \

any clue what is wrong? the used makefile is the same(generated by avrstudio 5)

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

I've now isolated the issue. It is caused by different behaviors of avrgcc4.7 and earlier versions:
The new gcc version substitutes the standard .o dependency by the file specified after -MT option as specified in the manual.
Older versions seem to add the target file specified after -MT to the dependency file instead of substituting it.

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

sternst wrote:
SprinterSB wrote:
something is wrong with the dependencies - for whatever reason. It's not a gcc issue.
Why are you so sure about that? The dependencies are often auto-generated by the -M options of gcc. Also the makefile generated by AVR-Studio 5 does that.
Ya, the compiler can have bugs, of course. But it's very unlikely that such an issue would stay unnoticed because it is machine-independent and commonly used.

If I understand Sebastian correctly, AStudio relies on undocumented stuff that only happened to work in specific GCC versions because of a GCC bug.

Bugs that unintentionally implement a feature are much more likely to pass unnoticed than the kind of bugs mentioned above: bugs that actually break a feature.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
But it's very unlikely that such an issue would stay unnoticed because it is machine-independent and commonly used.
Yes, of course.
Your strict "It's not a gcc issue" was what I was wondering about. To me your whole statement sounded like "in no way can it be a problem of gcc because it has nothing to do with the dependencies in a makefile".

Stefan Ernst

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

As you might already know, yesterday at GCC's 25th anniversary was GCC 4.7.0 released.

Thus, I decided to do a build of the tools from the now actual version of GCC which is 4.7.1 (prerelease). For PRs fixed in 4.7.1, see

Bugs Fixed in 4.7.1

For avr-gcc, the only changes with respect to 4.7.0 are problems related to new features: The Xmega support and the 24-bit address-space __memx.

  • avr-gcc is from 2012-03-22 4.7-branch SVN r185693,
  • Binutils is 2.23 from 2012-03-22 trunk
  • AVR-Libc is 1.8.0 from 2012-03-22 trunk r2291
There is no installer; just a zip to unpack:
avr-gcc snapshots (Win32) -> avr-gcc-4.7-185693-mingw32.zip

After unpacking, you can move, rename or delete the directory according to your needs. To use the compiler, just call it by its absolute path or add the ./bin subdirectory to your PATH.

The zip is ~30MB and inflates to ~100MB on disc.

Notice the following limitations with Link Time Optimization (LTO):

  • If you intend to use LTO, i.e. compile/link with -flto, use *nix-friendly path names without spaces or other special character.
  • LTO does not (yet) work with AVR-specific builtins like used by util/delay.h from AVR-Libc. Having __DELAY_BACKWARD_COMPATIBLE__ defined when util/delay.h is included should avoid this shortcoming (for util/delay.h at least).

avrfreaks does not support Opera. Profile inactive.

Last Edited: Fri. Mar 23, 2012 - 07:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Will test in a few minutes, thanks :)

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

with 4.7.0 : 15612 bytes
with 4.7.1 : 15698 bytes

I lost some...

Also with -flto I have:

Quote:
lto1.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper: avr-gcc returned 1 exit status
c:/avr/tools/4.7.1/bin/../lib/gcc/avr/4.7.1/../../../../avr/bin/ld.exe: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

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

Quote:

Please submit a full bug report,

That's the name of the game! ;-)

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

k.c:

int main(void) {
}
c:\tmp>"c:\Program Files\Atmel\AVRTools\Wgcc-4.7-185693-mingw32\bin\avr-gcc" k.c -Os -DF_CPU=14745600UL -mmcu=atmega2561 -Wa,-adhlns=k.lst -Wl,-Map=k.map,--cref -o k.elf

c:\tmp>


c:\tmp>"c:\Program Files\Atmel\AVRTools\Wgcc-4.7-185693-mingw32\bin\avr-gcc" k.c -Os -DF_CPU=14745600UL -mmcu=atmega2561 -Wa,-adhlns=k.lst -Wl,-Map=k.map,--cref -o k.elf -flto
c:/program files/atmel/avrtools/wgcc-4.7-185693-mingw32/bin/../lib/gcc/avr/4.7.1
/../../../../avr/bin/ld.exe: c:/program: error in plugin cleanup (ignored)
c:/program files/atmel/avrtools/wgcc-4.7-185693-mingw32/bin/../lib/gcc/avr/4.7.1
/../../../../avr/bin/ld.exe: c:/program: error loading plugin
collect2.exe: error: ld returned 1 exit status

c:\tmp>
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are these fails for 64-bit platform or 32-bit? On 32-bit platform (Win2000) it works.

avrfreaks does not support Opera. Profile inactive.

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

32 bits windows XP, I run it into a standard "command prompt" (no msys, no cygwin)

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

wek wrote:
k.c:
int main(void) {
}
c:\tmp>"c:\Program Files\Atmel\AVRTools\Wgcc-4.7-185693-mingw32\bin\avr-gcc" k.c -Os -DF_CPU=14745600UL -mmcu=atmega2561 -Wa,-adhlns=k.lst -Wl,-Map=k.map,--cref -o k.elf

This works for me (Win2000) with exace the same k.c source and command line. The only difference is the OS and that I use a non-quoted, nix-friendly path name:
U:\test>L:\gnu\install\avr-gcc-4.7-185693-mingw32\bin\avr-gcc k.c -Os -DF_CPU=14745600UL -mmcu=atmega2561 -Wa,-adhlns=k.lst -Wl,-Map=k.map,--cref -o k.elf

And I call directly from console, not through some GUI.

avrfreaks does not support Opera. Profile inactive.

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

I took the project with ATMega2561+2xATMega8 used in "benchmarking" various versions of avr-gcc previously, and with minimal changes (see below) compiled with my "production" 2007-vintage avr-gcc (slight increase of code size since last time as the project is alive and features are added all the time) and this 4.7.1 one:

avr-gcc (GCC) 4.7.1 20120322 (prerelease)
atmega2561: Program:  142753 bytes   Data:  3725 bytes
 ditto (*): Program:  141863 bytes   Data:  3725 bytes
atmega8/1:  Program:    4938 bytes   Data:   303 bytes
atmega8/2:  Program:    3042 bytes   Data:   141 bytes 

(*) with -mstrict-X and -fno-tree-loop-optimize
---------
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
atmega2561: Program:  151409 bytes   Data:  3805 bytes 
atmega8/1:  Program:    5050 bytes   Data:   352 bytes
atmega8/2:  Program:    3188 bytes   Data:   141 bytes

The "minimal changes" involved:

1. changing the poisoned SIG_xxx ISR names. A real nag, as this project has dozens of them; there is shared code between the 'M2561 and 'M8 (and also a 'M128 in a related but separately compiled project) and the ISR names are different so they had to be looked up in several .h files; and also there is some shared code with another project which is for various reasons compiled also with an even older avr-gcc (v3.x) so the old names had to be kept under conditionals. I don't quite understand the urge for the poisoning, but I apparently don't need to understand everything.

2. adding -D__PROG_TYPES_COMPAT__ (here I won't repeat my arguments for why I think it was a wrong choice to make that change in pgmspace.h); this resulted in some 800+ "deprecated" warnings :-)

There are some more warnings on type punning (localized into a piece of code written by somebody else in a probably objectionable style - I need to have a closer look).

Nevertheless, the result looks fully functional and the code size reduction is pleasant.

Many thanks for your work, Johann!

JW

Last Edited: Fri. Mar 23, 2012 - 05:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
This works for me (Win2000) with exace the same k.c source and command line. The only difference is the OS and that I use a non-quoted, nix-friendly path name:
32-bit Vista here, but using the short directory names (C:\PROGRA~1\ etc.) made difference indeed.

I know it's an annoyance, but I think that it might be worth trying to find a solution for the "unfriendly" names by the time a "real world" release occurs.

JW

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

Magister wrote:
with 4.7.0 : 15612 bytes
with 4.7.1 : 15698 bytes

I lost some...


Presumable, this is because of hack around PR52543. PR52543 lead to a split of multi-byte reads into multiple 1-byte reads which is desasterous for the address-space accesses. The mentioned hack replaces these memory accesses by "some action" which avoids the unwanted splits. Negative side effect is that no post-increment addressing will be generated; the "some action" representation is similar to a piece of inline assembler like with pgm_read.

wek wrote:
Nevertheless, the result looks fully functional and the code size reduction is pleasant.
There are some hints on avr-gcc options. In particular -mstrict-X -fno-tree-loop-optimize shows pleasant results.

Maybe that page should be moved to a more common place...

There is wiki.avrfreaks.net but that site is slloooooow so not real fun, neither for authors not for readers. People obviously prefer to drop their wikiesque texts/tutorials as thread in the forum.

avrfreaks does not support Opera. Profile inactive.

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

Quote:

Maybe that page should be moved to a more common place...

The AVR-LibC user manual perhaps?

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

wek wrote:
SprinterSB wrote:
This works for me (Win2000) with exace the same k.c source and command line. The only difference is the OS and that I use a non-quoted, nix-friendly path name:
32-bit Vista here, but using the short directory names (C:\PROGRA~1\ etc.) made difference indeed.
If it's approved that m$ish path-names cause the trouble, I'd write a line along with the links to the zip.

@Magister: Does it work if you use sane path names?

clawson wrote:
Quote:
Maybe that page should be moved to a more common place...
The AVR-LibC user manual perhaps?
so the "just drop it at AVR-Libc because there is no better place"?

For the text in question I'd very much prefer a less static, wikiesque site. I am thinking of the German mikrocontroller.net or roboternetz.de/rn-wissen.de wiki. In particular the rn-wissen.de has a much more appealing web-typography and -layout than the mikrocontroller.net

avrfreaks does not support Opera. Profile inactive.

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

Thanks Johann for the hints.

One more question on -flto, if you permit.

volatile char c;

int main(void) {
  __asm__ volatile (
    "lds  r16, c"
    :::"r16"
  );
}

results in

`c' referenced in section `.text.startup' of C:\Users\OM7ZZ\AppData\Local\Temp\cclowUTz.ltrans0.ltrans.o: defined in discarded section `COMMON' of C:\Users\OM7ZZ\AppData\Local\Temp\ccgEBL3F.o (symbol from plugin)
collect2.exe: error: ld returned 1 exit status

I roughly understand the reason; the question is, how to avoid the error.

Thanks,

JW

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

Quote:

so the "just drop it at AVR-Libc because there is no better place"?

Not at all. Put it in the one place where everyone using avr-gcc goes to learn how to use it. The precedent (for explaining command line options) is already set by this page there:

http://www.nongnu.org/avr-libc/u...

I spend my life on this message board pointing people at:

http://www.nongnu.org/avr-libc/u...

as the hub of info for using avr-gcc. It would seem a shame to water this down and splatter it across 20 different documents/web sites. If all questions can be answered by: "Visit this link and read everything there" then surely that's a good thing?

Or do the GCC developers somehow look down their noses at the lowly AVR-LibC developers and don't want to "give them the credit" or some other shit like that?

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

I agree with Cliff.

While from a systemic point of view putting gcc-specific information into libc-related documentation is "not-right thing", the avr-libc documentation *is* the defacto collection of basic wisdom, whether you like it or not.

As a matter of fact, thanks to this "improper" way of doing things, the AVR GNU *toolchain* may well be one of the best documented variant of all GNU processor targets...

JW

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

SprinterSB wrote:
In particular -mstrict-X -fno-tree-loop-optimize shows pleasant results.
Without attempting to understand the implications of these switches or their relationship to my programming habits, I added both to the experimental setup and they yielded further cca 0.6% (in fact more - maybe around 1% - the reported size includes quite some progmem data too) reduction of the code size (added the result to the "table" I posted above).

I am not going to start the "find the best combination" game - I am a firm believer of "go asm if you want absolute control" approach - but it's nice to know that there are still ways how to squeeze out more juice... :-)

I guess this is one of the things which attracts you to the playing with the compiler, isn't it... ;-)

Thanks again,

Jan.

Last Edited: Fri. Mar 23, 2012 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
One more question on -flto, if you permit.

volatile char c;

int main(void) {
  __asm__ volatile (
    "lds  r16, c"
    :::"r16"
  );
}

results in

`c' referenced in section `.text.startup' of C:\Users\OM7ZZ\AppData\Local\Temp\cclowUTz.ltrans0.ltrans.o: defined in discarded section `COMMON' of C:\Users\OM7ZZ\AppData\Local\Temp\ccgEBL3F.o (symbol from plugin)
collect2.exe: error: ld returned 1 exit status

I roughly understand the reason; the question is, how to avoid the error.

c is unused and thus may be discarded. Either compile main.c and similar modules that bypass semantics without lto-information, or use something like
char __attribute__((used)) c;

Notice that in the small program above "volatile" is void because there are no accesses to c from C.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
@Magister: Does it work if you use sane path names?
I already use sane path.

I traced down the problem to the delay function

#include 

void main(void)
{
        _delay_ms(1);
}

Quote:
avr-gcc k.c -o k.elf -Os -DF_CPU=14745600UL -mmcu=atmega2561 -Wa,-adhlns=k.lst -Wl,-Map=k.map,--cref
works fine

Quote:
avr-gcc k.c -o k.elf -Os -DF_CPU=14745600UL -mmcu=atmega2561 -Wa,-adhlns=k.lst -Wl,-Map=k.map,--cref -flto
lto1.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper: avr-gcc returned 1 exit status
c:/avr/tools/4.7.1/bin/../lib/gcc/avr/4.7.1/../../../../avr/bin/ld.exe: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
fails. If I remove the -Os it compiles.

Can you reproduce it?

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

SprinterSB wrote:

char __attribute__((used)) c;

That's it, thanks.
SprinterSB wrote:
Notice that in the small program above "volatile" is void because there are no accesses to c from C.
I would expect that.

So I threw in several dozens of attributes and the m2561 code reduced to 138581 bytes (from 141863), but the functionality is not completely OK. It probably relates to the fact that the data size was also reduced by 4 bytes - I don't think I had data to throw away :-) It probably fell over on some marginally written piece, but I am not going to investigate it at this point.

Thanks again for your work,

Jan

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

Magister wrote:
I traced down the problem to the delay function...

Can you reproduce it?

Yes, thanks! Reduced to the max:
extern void __builtin_avr_delay_cycles (unsigned long);

int main (void)
{
    __builtin_avr_delay_cycles (1000);
    return 0;
}

Without the extern decl there is a proper error message.

avrfreaks does not support Opera. Profile inactive.

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

You are welcome :)
When you fill a bugzilla entry for it, PM me the number, I'll add myself on the CC list!

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

Magister wrote:
When you fill a bugzilla entry for it, PM me the number, I'll add myself on the CC list!
It's PR52692

avrfreaks does not support Opera. Profile inactive.

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

ezharkov wrote:
[...] did not quite like __attribute__((always_inline)). It said "always_inline function might not be inlinable".
Are the functions declared as inline?

avrfreaks does not support Opera. Profile inactive.

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

Hello guys, I'm new to avr programming. I tried building avr-gcc with gcc 4.7.0 and binutils 2.22 and avrlibc 1.8 (latest releases), but I seem to be missing some microcontrollers from the available devices list. Mainly the atxmega128a3u, which I'm currently using.

What are the recommended versions for stable builds, which also include the latest microcontrollers? I don't want to be on the cutting edge, just to be stable (don't really care for size optimizations just yet)

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

SprinterSB wrote:
Magister wrote:
When you fill a bugzilla entry for it, PM me the number, I'll add myself on the CC list!
It's PR52692
Thanks for having added me :idea:

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

SprinterSB wrote:
ezharkov wrote:
[...] did not quite like __attribute__((always_inline)). It said "always_inline function might not be inlinable".
Are the functions declared as inline?
No, they were not. Adding inline helped.

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

wek wrote:

volatile char c;

int main (void) {
  __asm__ volatile ("lds  r16, c" ::: "r16");
}

Even more instructive than __attribute__((used)) with c would be to make the usage explicit:
char c;

int main (void) {
  __asm__ volatile ("lds  r16, %0" :: "i" (&c) : "r16");
}

avrfreaks does not support Opera. Profile inactive.

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

Quote:

Mainly the atxmega128a3u, which I'm currently using.

As Atmel's 4.5.1 toolchain does support that device seek out their patch set and find out what the patch that adds 128a3u actually affects. Then make similar mods. to the files in the toolchain source you are using. IOW backport the patch to 4.7.x

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

clawson wrote:
Quote:
Mainly the atxmega128a3u, which I'm currently using.
As Atmel's 4.5.1 toolchain does support that device seek out their patch set and find out what the patch that adds 128a3u actually affects.
The Atmel 4.5.1 patchset does not introduce changes for that device. What do I miss?

@admin: Could this sub-thread be broken out?

avrfreaks does not support Opera. Profile inactive.

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

Quote:

The Atmel 4.5.1 patchset does not introduce changes for that device. What do I miss?

They are violating GPL again? ;-)

(they have made several issues of 4.5.1 but I don't think they've posed the patch set for the latest one yet).

[I'll split this out later - I have to take the cats for a walk now]

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

SprinterSB wrote:

Even more instructive than __attribute__((used)) with c would be to make the usage explicit

Maybe, but it's not worth the hassle right now. In a new code I'll consider that.

In some of the inline asm pieces the direct use of address in inline asm was necessitated by running to the limit of constraints (yes they are lengthy). IIRC they are all ISRs so they might be replaced by "regular" assembler, but I'd expect that that approach would require to use the "used" attribute for -flto too.

JW

Last Edited: Fri. Apr 13, 2012 - 05:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
SprinterSB wrote:
-mstrict-X -fno-tree-loop-optimize
Without attempting to understand the implications of these switches...
At least they don't hack the ABI as opposed to -funsigned-char, -fshort-enums or -fpack-struct. These switches are 100% pure releted to optimization and don't affect the ABI.
Quote:
...or their relationship to my programming habits, I added both to the experimental setup and they yielded further [...] maybe around 1% [...] reduction of the code size.

I am a firm believer of "go asm if you want absolute control" approach - but it's nice to know that there are still ways how to squeeze out more juice...

I agree with "need of absolute control implies assembler".

What I don't agree with is "to get significantly better code absolute control is inevitable". "Getting significantly better code" is a completely different thing than "need 100% control over result". Don't confuse them with each other.

Just imagine your example from above: How many additional assembler pieces, sprincled all over the code, would you need to reduce code size by 1%? And how big would the effort be?

Setting/unsetting a compiler switch is a trivial action. What would the "stick to asm if you like to..." approach mean with respect to resources needed and maintainability of the project? It's much less paint so see if, for example, -fno-move-loop-invariants can do the same boost. And it's 100% non-intrusive to the sources.

Don't get me wrong: I also use assembler in my brojects where I want best performance and where it's clear that compiler will never be as smart as brain. But that's no "how better code? --> use asm" reflex.

wek wrote:
I guess this is one of the things which attracts you to the playing with the compiler, isn't it...
Not easy to answer that.

Some years ago, a friend pointed me to Baumann's Lichtzeitpegel clock sculpture in the Rheinturm in Düsseldorf. I decided to handicraft such a clock, but had absolutely no idea how. My Pa just mumbled "SPS" and with "SPS" I started searching until I came across a model railroader's site that used a "Microcontroller" thing. Even managed to find that site again.

The "µC thing" appeared more reasonable than the "SPS thing" and I bought some of these AT89C2051, a breadboard, a propretieary assembler and programmer and started with the clock. During the project I learned assembler programming, how to decode DCF77 time signals, drive > 40 LEDs per SPI + 74*595, program interrupts and debounce switches, implement a menu, output morse signals to find my way through the menu during setup, drive external 24C02 EEPROM and shake the "alarm", a handicraft wind chime made of aluminium tubes.

And during information minig I came across pages with Nixie tube clocks, and I decided a Nixie clock was the next project.

But the assembler was just an annoyance and the built-in editor was scrap and could not be replaced. And the license stuff was just an annoyance, too. And programming in assembler was no real fun after all, partly because it was assembler, and partly because the assembler's language features were really poor and restricted.

I found almost pin-compatible AVR AT90S2313. And I found avr-gcc readily available with WinAVR, installed it, wrote some C programs, learned how the tools work and interact and what programmer there were -- all before I even bought a single piece of AVR related hardware. The software part looked really good and was kind of deliverance compared to the former assembler IDE.

The next step was the hardware: I started with the 1€ setup: A RS232 breakout, a transistor, some Z-diodes, resistors and a AT90S2313 on a breadboard and connected all that sauerkraut circuit with my computer.

From that point on development was easier and I wasted much less wime with the tools. On the other side, I learned obout the tools and how to apply them in the best way. Knowing about what's under the surface will always enable you to get superior results and work faster and with much more ease.

The WinAVR I used was 20060421 which is avr-gcc 3.4. That compiler produced really good results, but still showed many optimization shortcomings. Thus, I tried newer versions of avr-gcc but observed from version to version that the code size went up according to the genenral rule of thumb: avr-gcc 4.x produced code size increase and thus also speed degradation of 5%-10% compared to good old 3.4.

What then drew my attention to the compiler internals was a thread that reported problems with a wrong code. I knew that source code very well as I wrote it and it float around in the net; but the error was not in my piece of code. Instead, my sorce snippet revealed a "wrong code" compiler bug. I got curious and started digging in the compiler and found the root cause of the defect.

It took me some time to figure out how all the patch and open source projects and process are organized, but finally my first patch was accepted and integrated to fix the aforementioned PR42240. That was roughly one year ago.

To keep on contributing has several reasons:

First, It's a pity to see how such a great project got worse and worse over time, accumulated more and more bugs and flaws that are not fixed.

Second, maybe it's giving something back to a great project, instead of a "expect all for nothing" attitude or a "constantly complain and nag but let others do the job" attitude.

Third, is "hack the project? or hack the compiler?". Hacking around inferior code in the source is never a good thing: It obfuscates the source. It is unstable under migration (new toolchain). It's unstable under porting (other hardware). It's costly to find the places and work out how the hack will be. It has the potential to introduce bugs. It avoids optimization if an updated toolversion actually has the flaw fixed -- you won't even notice it with the hack. And it's simply the wrong place: Fix the root cause, not the symptom! I saw code snippets that praise their use of inline assembler, where the same optimization can be achieved with straight forward C and a compiler change that is smaller than the inline assembler hack!

Fourth, disbelief of the kind "it cannot be that hard to teach the bloody compiler what's trivial and obvious to any assembler programmer". On the surface you just see trivial and obvious goal, like "this instruction is suportluous" or "this sequence could be smarter like so".

Sixth, interest in how a real-world compiler and one of the most important free software works. Solving Sudoku is boring after you solved the 3rd puzzle: They are all the same. With problems in GCC this is different.

Seventh, curiosity. For example "how many of brain's smartness can be packed into a software?". An example is the __builtin_avr_insert_bits buit-in which is rather an exercise in finding a smart solution to a problem than an important or even requested extention.

Eighth, aesthetical reasons. That are changes like code cleanup, coding rules and layout, documentation and readability of source, avoid redundancies, find smart and neat solutions instead of clumsy ones, etc.

avrfreaks does not support Opera. Profile inactive.

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

clawson wrote:
Quote:
so the "just drop it at AVR-Libc because there is no better place"?
Not at all. Put it in the one place where everyone using avr-gcc goes to learn how to use it.

I spend my life on this message board pointing people at: ... as the hub of info for using avr-gcc. It would seem a shame to water this down and splatter it across 20 different documents/web sites. If all questions can be answered by: "Visit this link and read everything there" then surely that's a good thing?

Or do the GCC developers somehow look down their noses at the lowly AVR-LibC developers and don't want to "give them the credit" or some other shit like that?

Why do you think I discredit avr-libc or its developers and write such nonsense? That's plain bullshit!

This is what I think:

Quote:
one place where everyone using avr-gcc goes to learn how to use it

Yes, it's a good thing to have a canonical place to learn about things. One place is the tool's/component's documentation.

If there is more elaborate explanation with worked out examples, description of how things interact and all these things, that's certainly a good thing.

Quote:
A "Visit this "link" and read everything there" then surely that's a good thing?

I don't think dropping anything at one place is a good thing. A good tutorial should be selective and pick instructive example and work them out.

"The more the better" does not hold IMO.

Flooding such a site will all kinds with information is not helpful at all to the beginner. For a noob there is so much new stuff that he must be overwhelmed by it: New editor environment, new hardware and all the oddities of a new language like C. And we all know C has many oddities and features that are non-intuitive. Getting the hardware settings right like baud rate, like fuse settings, like JTAG, like interrupts, like finding SFR and bit names, like finding right header. Connecting all that stuff and controlling the programmer. Learn what tools are there and how they interact. Understand what's going on under the surface and besides all the obfuscation introduced by tools. (If, for example, you don't see that an error message is from the linker or even are aware that there is something like a linker, it's much harder to understand the error message and the solution). Understanding build and make process. And many, many more.

There are so many things that are new that a noob will drown in all that information.

And I think the link/information I posted above is simply too unimportant to be dropped at such a place and distract noobs, confuse them, put focus on things that are completely irrelevant at that time.

Quote:
I spend my life on this message board pointing people at: "link"
Spend the life with "Read the fabulous manual", then? Well, if there is request like

"Urgent! I am late with my project but there is an error. Pls. give details description as soon as possible!"

then I don't even waste a single second on it. Spending the whole life for it is the other opposite...

If people don't even care for what they are actually doing, don't care for what tools that they actually use, don't care for what documentation is included. How am I supposed "link" would help them?

avr-gcc documentation links to avr-libc. WinAVR documentation comes with avr-libc documentation. Even in PDF. Even with elaborate examples. Even with detailes description of how tools interact. Even with detailes description what subpackages are included and where they are hosted.

Quote:
wiki

As I wrote, a wiki-based system is much less effort than a patch-based one.

Still can't believe and don't understand why people prefer to write "[TUT] as thread" and produce tapeworm threads with up to several hundreds of posts. And just beneath there is a wiki perfectly suitable for such information, with much better web-typographic, with categories for articles, with graphics, with chapters and sections, with table of contents, with history, with authors that can be talked to, with discussion page. How old is wiki paradigm and technique now?

But completely bypassed, ignored, deserted, for whatever reason.

@admit. Maybe the "tweak options" can be broken out?

avrfreaks does not support Opera. Profile inactive.

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

Quote:

Flooding such a site will all kinds with information is not helpful at all to the beginner.

You don't need to worry about beginners - evidence here suggests they don't read the documentation anyway. But experts know where to look and they would like all the documentation in one place.

Already this page has been growing recently:

http://www.nongnu.org/avr-libc/u...

Just adding a few more pages to articles of use does not mean that the reader is going to feel "swamped" by over-information.

Quote:

then I don't even waste a single second on it.

Well personally I do like to try and help beginners get started because I was one once and know what it's like. The great thing about GCC is that there is such a great manual (even an online copy) so that the majority of questions ("how do I use EEPROM?", "how do I store data in flash?", "why are my ISR/main variables not updated?") can be answered by it.

Oh and the Atmel Wiki failed because it is was hosted on a server powered by steam and rubber bands (anyway that was about "AVR" in general, not avr-gcc in particular).

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

clawson wrote:
Quote:
then I don't even waste a single second on it.

Well personally I do like to try and help beginners get started because I was one once and know what it's like.
Please don't put what I said into the wrong context. The "urgent help asap" it not related to beginners or noobs or experts or in any way to the degree of knowledge or expertise of the asker.

It's solely related to friendlyness and netiquette and against the "you help me a.s.a.p. because me to lazy to RTFM" attitude.

avrfreaks does not support Opera. Profile inactive.

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

Yes but 99% of the time these people are "needy" because it wasn't obvious to them where to look for the manual that would answer all their questions.

It does seem a failure of everything that installs avr-gcc in either a Windows or Linux environment that it does not make it much clearer where the installed copy of the manual (which I take to be the AVR-LibC HTML or PDF files) have been installed on the user's hard drive.

To me trying to use something as complex as a optimizing/linking compiler without at least a brief look at some over-view and a quick summary of the most often used command line options is doomed to failure (I'm always reminded of Gert Frobe flying a plane for the first time in "Those Magnificent Men In Their Flying Machines" - but at least he was reading the manual as he went along - the first landing being the most "interesting" bit - it's only when the seagull steals the manual that he really becomes unstuck).

All installation programs should as a very minimum say "if you don't do anything else at least take 5 minutes to familiarize yourself where "this" is located as you ARE going to need to refer to it at some point".

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

Quote:
Yes but 99% of the time these people are "needy" because it wasn't obvious to them where to look for the manual that would answer all their questions.

You sure, Cliff? So you just reserve a tiny 1% to reasons like
- Oh man, i can do that within 2 days, and there's a month left for the assignment
- My girl friend has just asked to go to the cinema
- I just didn't make it yet to that fancy new disco in town
- Manuals??? What's the teacher for then???
- Thinking of scheduling my project? Naaah, there's that superfreak that throws complete solutions even for the most demanding and lazy guy.

Your confidence in the average student seems to be quite high. I know, we were all novices one day, but some of us had a student life some 20 years ago as well, right?

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

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

DO1THL wrote:

- My girl friend has just asked to go to the cinema
- I just didn't make it yet to that fancy new disco in town

Cinema? Disco? LOL!

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

More findings.

1. More "unused" variables were dropped, but went unnoticed initially. This time, it was a block of data allocated to a fixed position in FLASH through a "manually" assigned section, and never used in C program. It is used as an identification for other utilities.

Johann, could you please help me locating the switch for the linker to print the "dropped" variables?

2. This was fatal: I have "reserved" registers such as (note that I am already paranoid to add the "used" attribute everywhere):

register unsigned char __attribute__((used)) _r2 asm("r2");

yet the compiler uses them throughout. As I use these in ISRs, this had various "funny" consequences (the code was mostly working though).

It appears that -ffixed-2 et co. helped on this.

If the "allocation through asm("rX") is officially non-functional now, you should perhaps submit a patch for the relevant section in avr-libc's documentation http://www.nongnu.org/avr-libc/u...

Jan

PS. I've just noticed, that with -ffixed-X in place and with no other changes, the program's size *decreased* further - from 141863 bytes reported previously, to 138827 bytes... Shall I feel disturbed? :-?

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

wek wrote:
Johann, could you please help me locating the switch for the linker to print the "dropped" variables?
Skimming ld options will take 5 minutes: http://sourceware.org/binutils/d...

I am no ld compendium, sorry ;-)

wek wrote:
I have "reserved" registers such as (note that I am already paranoid to add the "used" attribute everywhere):
register unsigned char __attribute__((used)) _r2 asm("r2");

yet the compiler uses them throughout.

Paranoia is a bad replacement for Correctness :twisted:

Be more specific and show an example, presumably you betray the compiler. Are you saying you have

register unsigned char r2 asm ("r2");

ISR (some_vect) {}

and avr-gcc allocates R2 in some_vect?

wek wrote:
I've just noticed, that with -ffixed-X in place and with no other changes, the program's size *decreased* further
Yes, it's a known paradox of the register allocator. There are still bugs open like PR52778 which won't be fixed for 4.7, maybe it's related to it but I don't know. Register allocation is much too complicated I will ever understand it...

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
wek wrote:
Johann, could you please help me locating the switch for the linker to print the "dropped" variables?
Skimming ld options will take 5 minutes: http://sourceware.org/binutils/d...
Believe me that I've spent considerably more time, to no avail. Apparently -flto being a new feature, maybe there's no such option yet - and in GNU world the sources are the best documentation anyway, aren't they... ;-)

SprinterSB wrote:
Be more specific and show an example,
I'll try later. I am not at *that* computer now. And, as could be expected, it took quite a complex routine to press the compiler to go down to r2. But I'll try to generate some example.

SprinterSB wrote:
presumably you betray the compiler.
I don't understand.

SprinterSB wrote:
Are you saying you have
register unsigned char r2 asm ("r2"); 
ISR (some_vect) {}

and avr-gcc allocates R2 in some_vect?

No, I am using r2 in inline asm in naked ISR (without store/restore of course; and without mentioning it in the clobbers, to be absolutely precise). The compiler allocated r2 in other, "plain" functions.

SprinterSB wrote:
wek wrote:
I have "reserved" registers such as (note that I am already paranoid to add the "used" attribute everywhere):
register unsigned char __attribute__((used)) _r2 asm("r2");

yet the compiler uses them throughout.

Paranoia is a bad replacement for Correctness :twisted:
The _r2 variable is not used anywhere, indeed, so after that previous experience it appeared to me that the "used" is appropriate here, too. The "asm("rX")" is a non-standard gcc extension, as well as the "used" attribute - how am I as a user supposed to know what's correct in this context?

Johann wrote:
wek wrote:
I've just noticed, that with -ffixed-X in place and with no other changes, the program's size *decreased* further
Yes, it's a known paradox of the register allocator.
Okay, I see, and am not surprised...

Jan

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

wek wrote:
[reading docs] Believe me that I've spent considerably more time, to no avail. Apparently -flto being a new feature, maybe there's no such option yet.
Ok, you didn't say it's a problem together with LTO. The first place to ask is respective binutils or gcc mailing lists like gcc-help@gcc.gnu.org. Yes, I know it's not that chatty-chatty like here and you must be specific and follow netiquette.

wek wrote:
SprinterSB wrote:
Are you saying you have
register unsigned char r2 asm ("r2"); 
ISR (some_vect) {}

and avr-gcc allocates R2 in some_vect?

No, I am using r2 in inline asm in naked ISR (without store/restore of course; and without mentioning it in the clobbers, to be absolutely precise). The compiler allocated r2 in other, "plain" functions.[...] The _r2 variable is not used anywhere.
It's not about used/unused, it's about making the register global if it's required that the compiler does not allocate it. This may even be required in modules that don't even mention R2. If you make R2 global in a.c but call functions in b.c without making R2 global in b.c, that's a bug.

If the register (one of R2..R7) is global and reserved there, it must not be used. If it's not global, the compiler may use it, of course.

Registers from R8 on might be required by the ABI. You can reserve them, but there might be clashes with the ABI. There is a warning like PR45099, fixed in 4.7.0.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
It's not about used/unused, it's about making the register global
I know that.

I spent quite some time trying to reproduce the problem, but I can't reproduce it on my home computer... The sources I have here are somewhat older, but the routine where I have seen the r2..r5 registers be used is unchanged... I don't understand.

Tomorrow at work I will get back to the problem (if time permits) and will report.

JW

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

Don't forget to remove the -ffixed- ;-)

avrfreaks does not support Opera. Profile inactive.

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

I have spent many hours trying to produce a minimal example, to no avail. Only if I compile the whole project the problem appears (registers r2-r5 are used in some functions originating in C, even if they were "forbidden" defining "register unsigned char r2 asm ("r2");" as global variable).

Findings:
- this is clearly a LTO problem in linker (during linking): the "forbidden" registers are NOT present in the assembler output from compiler, only in the linked result in .elf

- in functions where the "forbidden" registers appear in the .elf, they are properly pushed/popped in prologue/epilogue (except for main(), which appears to have stripped prologue/epilogue, but that was expected)

- I made sure that the "forbidding definitions" are present in every C source - some of the files with functions small and simple enough not to use the "low" registers ever did not have them before - no change

- could not reproduce the problem when trying to compile and link one of the smaller functions which in the big project exhibited the problem separately from the project, even if the assembler output from compiler is exactly the same (except it has one more unused label) in both cases - in the "minimal" experiment the linker maintains a small stack frame, whereas in the big project it replaces it with the "forbidden" registers

- it is enough to use -ffixed- during linking to remove the problem

- it is not sufficient to use -ffixed- during compilation (and not use it during linking) - in that case problem persists

I now can't spend more time on this. I am willing to cooperate in experiments if anybody has ideas what to try to do next.

JW

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

I saw this post from a few days ago. Has anybody tried his instructions on building?
http://maniacbug.wordpress.com/2...

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

I'm having a problem compiling for an Xmega32A4U. I'm trying to use what seems to be the latest version you linked. I'm using it from within AVR Studio 5.1, setting it as the toolchain to use for one of my projects. The error is below, that it doesn't recognize the 32A4U. iox32a4u.h is also missing from the include directory, so I guess it just isn't supported by this version of avr-gcc. It seems odd that it isn't. Do you know why?

(Some stuff stripped from here)
C:\Program Files\Atmel\AVR Studio 5.1\make\make.exe all 
kvrx_serial.cpp
		Invoking: AVR8/GNU C++ Compiler
		"C:\ProgramFiles\avr-gcc-4.7-185693-mingw32\bin\avr-g++.exe" -funsigned-char -funsigned-bitfields -DF_XOSC=16000000UL  -I"../../../../Xmega/KVRx" -I"../../../../Xmega/KVRx/libraries/xTSL2561" -I"../kvrx"  -O0 -fpack-struct -fshort-enums -g2 -Wall -c -MD -MP -MF "kvrx/kvrx_serial.d" -MT"kvrx/kvrx_serial.d"  -mmcu=atxmega32a4u   -o"kvrx/kvrx_serial.o" "../../../../Xmega/KVRx/kvrx_serial.cpp" 
avr-g++.exe(0,0): unrecognized argument in option '-mmcu=atxmega32a4u'
		avr-g++.exe: note: valid arguments to '-mmcu=' are: (long list removed, other stuff stripped.)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You must give a valid argument to -mmcu=
Otherwise you will get an error.
For a list of valid arguments read the note or the compiler output with --help=target

You can compile code for the architecture by setting -mmcu=avrxmega2 for example. But you will need startup code and header support, too.

avrfreaks does not support Opera. Profile inactive.

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

I wasn't asking why it isn't working, I was asking why that device isn't supported in the expected way. I realize it's fairly new, but my impression was that devices were often supported before they were even released. I'm more wondering about the process that gets MCUs fully supported (you seem to have some insider knowledge) than how to get it working (my current setup is working fine for me).

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

hardmanko wrote:
I was asking why that device isn't supported in the expected way.
Because noone added support for the device in GCC/binutils/AVR-LibC. Noone deemed it important enough, and it's really hard to not get puzzled by the plethora of hundreds of AVR devices, many of them 100% identical.

Quote:
my impression was that devices were often supported before they were even released.
A device is supported if it's support is added. many of the devices are 100% identical from the compiler's view who has only to care for the instruction set. Same is true for binutils.

Quote:
I'm more wondering about the process that gets MCUs fully supported (you seem to have some insider knowledge) than how to get it working.
Vast majority of changes will be to AVR-LibC: Startup-Code and non-libc changes to libc. AVR-LibC ships device support like EEprom routines not in an own device support library. Instead, it adds support functions for each device to libc and uses a device-unique name to refer to it.

Moreover, headers for SFR descriptions, device-specific prototypes like EEprom support routines and vector table definitions are needed.

Compiler and binutils support could be avoided alltogether. The device support is only about header, startup code and libc as mentioned above. The compiler driver just calls the linker with appropriate startup code.o and sets -Tdata and built-in define for the device.

Instead of compiling/assembling with -mmcu=device you just as well can use -mmcu=core -D__AVR_Device__ and add -nostartfiles -Tdata=... -m core to the linker call.

The formal process to add support for whatever feature to GCC or binutils is to provide a patch, and let it approve my respective maintainer. Moreover, you must put your GCC and binutils changes under GPL.

http://gcc.gnu.org/contribute.html

avrfreaks does not support Opera. Profile inactive.

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

That's interesting, thank you for describing the process. I kind of understood that the compiler didn't need extremely device specific information -- like specific register addresses, etc. -- that are in the header file, but I didn't realize that AVR-LibC did so much at the low level. I just assumed that it provided common C functions like printf and some stuff like delay. I should have known better, because I use interrupt.h quite a bit, but I never thought about how it fits into the rest of the toolchain.

Thanks again!

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

hardmanko wrote:
I kind of understood that the compiler didn't need extremely device specific information
There are just very few exceptions to that rule, for example with
extern char c;

void set (char x)
{
    if (x)
        c = 0;
}

Compile for AT90S8515:

set:
	tst r24
	breq .L1
	sts c,__zero_reg__
.L1:
	ret

Compile for AT90S8535:

set:
	cpse r24,__zero_reg__
	sts c,__zero_reg__
	ret

even though both devices are in architecture avr2. This because of some unnamed silicon erratum.

For devices supported by avr-gcc, see ./gcc/config/avr/avr-mcus.def.
For respective binutils list, see ./gas/config/tc-avr.c.

Quote:
I just assumed that it [AVR-LibC] provided common C functions like printf and some stuff like delay.
No, because it would be much too hard for users to add -lavr to the linker call if device-specific stuff was in a stand-alone libavr.a. Such a layout would cause tsunamis of bug reports and support requests...
Quote:
I use interrupt.h quite a bit
interrupt.h, in turn, just contains syntactic sugar, there is no library support required. Just skim the preprocessed sources with -save-temps -g3, for example, or the assembler output. There will be no library calls, it's all chewed by the compiler already.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
hardmanko wrote:
I kind of understood that the compiler didn't need extremely device specific information
There are just very few exceptions to that rule, for example with
extern char c;

void set (char x)
{
    if (x)
        c = 0;
}

Compile for AT90S8515:

set:
	tst r24
	breq .L1
	sts c,__zero_reg__
.L1:
	ret

Compile for AT90S8535:

set:
	cpse r24,__zero_reg__
	sts c,__zero_reg__
	ret

even though both devices are in architecture avr2. This because of some unnamed silicon erratum.


Minor observation:
This particular erratum is officially acknowledged in Atmel's published AT90S8515 errata sheets:
http://www.atmel.com/Images/DOC1... (rev B silicon)
http://www.atmel.com/Images/DOC2... (rev C silicon)

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

lfmorrison wrote:
This particular erratum is officially acknowledged in Atmel's published AT90S8515 errata sheets:
Yes, I know. But only after asking the Atmel support about affected devices because I observed bug-specific code/comments in binutils.

Now you can go and search what the second device is that's affected by this silicon bug...

Is there an official errata list, i.e. a map bug -> device instead of the device -> bug map?

Otherwise, you'd have to read several hundreds of data sheets to find out what devices are affected; not really applicable if you need to find out all affected devices or all core errata that need to be worked around by the tools...

avrfreaks does not support Opera. Profile inactive.

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

You're right, Atmel's current method of publishing errata is really only useful for end-users of particular devices - it's pretty horrible for people who are trying to maintain tools which apply to many different devices.

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

Johann,

in your build, http://sourceware.org/PR13410 appears to be fixed, even if the bug report says fixed for binutils 2.23 while your build contains 2.22.

Can you please confirm?

Thanks,

Jan

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

wek wrote:
in your build, http://sourceware.org/PR13410 appears to be fixed, even if the bug report says fixed for binutils 2.23 while your build contains 2.22.
My build neither contains 2.23 nor 2.22, it contains 2.22 HEAD as mentioned in the note alongside the download link.

Binutilas are not as eloquent as gcc that says 4.6.1 or 4.6.1 DATE (experimental) or 4.6.1 DATE (prerelease).

In GCC speek it would be 2.23 (experimental) I guess?

As you might know, binutils uses CVS as VCS where versioning is really confusing, at least to me...

avrfreaks does not support Opera. Profile inactive.

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

Okay, I see. Honestly, I did not go back to the post where you gave the link, sorry.

I take it as "yes", then... :-)

Thanks,

Jan

PS. This was one of the two linker bugs I came aware throughout the years here on avrfreaks. The other is related to gs() (thus 'M256x, maybe the bigger XMegas too) and *no* -relax; a quick check reveals that that one still persists.

PS2.Submitted the latter to binutils bug tracker

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

Thanks for the problem number (PR14058)

avrfreaks does not support Opera. Profile inactive.

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

FYI, GCC 4.7.1 release is scheduled for end of next week:

http://gcc.gnu.org/ml/gcc/2012-0...

avrfreaks does not support Opera. Profile inactive.

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

Nice! Cannot wait for an offical release with latest binutils and avr-libc!

GCC guys are impressive!

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

Magister wrote:
Cannot wait for [...] latest binutils
Unfortunetly, there are some open bugs in binutils. It appears that even if there are approved patches, nobody would install them...

avrfreaks does not support Opera. Profile inactive.

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

I uploaded a new snapshot "avr-gcc-4.7.1-rc1-mingw32.zip" to the same directory as the other snapshots.

  • Binutils fixes some wrong code issues with --gc-sections and --relax
  • Binutils supports XCH, LAS, LC, LAS instructions
  • Binutils supports data expression modifiers like .byte lo8 (symbol)
  • avr-gcc comes with a working -mint8.
  • For a more complete list problems fixed in 4.7.1, see Bugs Fixed in 4.7.1
The zip file is bigger (45MB inflating to 110MB) because it includes documentation (info, man, html, pdf).

For notes on how to "(un)install" the toolchain, see the notes with the previous snapshots.

Versions:

  • GCC is 4_7-branch SVN 188257 (4.7.1 release candidate)
  • Binutils is trunk (future 2.23) from today with some pending patches
  • AVR-LibC is 1.8.0 trunk SVN 2294 from today

avrfreaks does not support Opera. Profile inactive.

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

It works fine here, LTO is working too for the first time for me, gained an extra 50 bytes :)

You are the man 8)

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

Thanks SprinterSB, I would like to build that on Linux (Fedora 16 I686). Should I use just the SVN versions or are there more patches that I need to apply?

AFAIK, newer XMEGA devices are still missing (to be more specific, I look for xmega32a4u). Please correct me if I'm wrong.

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

itai_n wrote:
Thanks SprinterSB, I would like to build that on Linux (Fedora 16 I686). Should I use just the SVN versions or are there more patches that I need to apply?
Download the zip and have a look at the patches in ./source

itai_n wrote:
AFAIK, newer XMEGA devices are still missing (to be more specific, I look for xmega32a4u). Please correct me if I'm wrong.
I wrote somelines on how to support "unsupported" devices. It basically boils down to having the device header and startup-code. The blueprint for startup-code can be found in AVR-LibC and maybe also the divice headers which are plain text.

If you want to add support for a device to the tools, it's a one-lineer:

Magister wrote:
LTO is working too for the first time for me, gained an extra 50 bytes.
For my application I get -1.6% for code size so it is not too bad. LTO is just used for some modules where I want cross-module inlining.

Unfortunately, there is PR53595. I hacked around that one by combining the compiler from the march snapshot with binutils from the recent snapshot. Without that hack code size increases by 2% for PR53595 alone.

It's kind of mice-milking business...

avrfreaks does not support Opera. Profile inactive.

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

Thanks for the build, Johann.

Findings:
- you did not include the patch I posted at http://sourceware.org/bugzilla/s... , did you find any problem with that?

- with -flto, the problem with the linker using "reserved" registers I reported above persists

- with -mstrict-X, several functions won't compile, an example output:

smd_switching.c: In function 'SwitchLocalBPF':
smd_switching.c:824:14: error: can't find a register in class 'BASE_POINTER_REGS
' while reloading 'asm'
smd_switching.c:828:13: error: can't find a register in class 'BASE_POINTER_REGS
' while reloading 'asm'
smd_switching.c:841:26: error: 'asm' operand has impossible constraints
smd_switching.c:824:14: error: 'asm' operand has impossible constraints
smd_switching.c:828:13: error: 'asm' operand has impossible constraints

All lines reported above contain pgm_read_byte_far(SOME_CONSTANT_OFFSET + some_16_bit_variable). 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.

- without -flto the application I used above for the tests compiles and appears to run correctly

Jan

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

wek wrote:
you did not include the patch I posted at http://sourceware.org/bugzilla/s... , did you find any problem with that?
I simply missed that. Other patches like this one are not in a valid diff format and patch terminates with an error. You can minimize such problems if you attach the patch to the PR instead of copy-pasting it.

In easy way to get a patch is

  1. git init
  2. git add file
  3. change file
  4. git diff file > file.diff

Quote:
with -flto, the problem with the linker using "reserved" registers I reported above persists
Test case is where?

Quote:
with -mstrict-X, several functions won't compile, an example output:
error: 'asm' operand has impossible constraints

Something is wrong with your inline assembler. It's not a compiler bug.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Other patches like this one are not in a valid diff format
But you apparently managed, haven't you? :-)

IMHO that's one of the points of the plaintext and almost-human-readable format of diffs. I guess diff/patch back then started with people posted smaller changes simply by quoting the changed lines, manually adding "-" and "+" to them as appropriate; and diff/patch only "machinized" the process to allow for larger changes and automated processing.

SprinterSB wrote:
and patch terminates with an error.
That's because patch is ignorant of the DOS/UNIX line ending differences. Using -l with path alleviates this problem (although I am not sure whether it won't introduce some other). Or, you can use any de-CRLF-ier to strip the CRs before attempting to patch.

SprinterSB wrote:
You can minimize such problems if you attach the patch to the PR instead of copy-pasting it.
Certainly. I still have the original output of diff and patch does accept it without -l (and, indeed, only the CRs are the difference).

However, I found it illustrative to post the patch as part of the explaining text. I could have done both; but I was not aware of said patch's dumbness (okay we can call it *nix-centrism, if you want :-) ).

SprinterSB wrote:
Quote:
with -flto, the problem with the linker using "reserved" registers I reported above persists
Test case is where?

As I reported in https://www.avrfreaks.net/index.p... , I could not produce a minimal example. Trust me that I tried hard. For obvious reasons I am unable to post the whole project, but am willing to cooperate in experimentation, although IMHO it is not worth spending more time on it, as it is a minority problem and workaround is known - I would just suggest to mention it in documentation (should any happen).

SprinterSB wrote:
Quote:
with -mstrict-X, several functions won't compile, an example output:
error: 'asm' operand has impossible constraints

Something is wrong with your inline assembler. It's not a compiler bug.

You should start having more faith in that I know what am saying, Johann... ;-)

This is not *my* inline assembler - as I said above, all occurences involve lines with pgm_read_byte_far(). You will find it in . One example of preprocessed output of a line throwing this error:

          eep = (__extension__({ uint32_t __addr32 = (uint32_t)((uint32_t)(0x30000UL + pp + __builtin_offsetof (TCfgRot, eeRot))); uint16_t __result; __asm__ ( "out %2, %C1" "\n\t" "movw r30, %1" "\n\t" "elpm %A0, Z+" "\n\t" "elpm %B0, Z" "\n\t" : "=r" (__result) : "r" (__addr32), "I" ((((uint16_t) &((*(volatile uint8_t *)((0X3B) + 0x20)))) - 0x20)) : "r30", "r31" ); __result; }));

And I did not say it is a compiler *bug*, but it certainly is a compiler-produced, uhm, feature :-) It apparently can't resolve the register pressure in extreme cases. Again, I don't think this is worth to spend more time on this, and would simply "solve" this "problem" by mentioning it in documentation.

Jan

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

wek wrote:
SprinterSB wrote:
Other patches like this one are not in a valid diff format
But you apparently managed, haven't you?
It's still inconvenient to manually extract the changes. Better put effort in more reasonable stuff than this...

Quote:
SprinterSB wrote:
and patch terminates with an error.
That's because patch is ignorant of the DOS/UNIX line ending differences.
No. It's because the patch is invalid. Goto the bugzilla page, highlight the text and you see that there are empty lines. That is invalid.

Quote:
but I was not aware of said patch's dumbness
patch is not dump, it is strict. Better reject an invalid patch than making wrong guesses.

Quote:
SprinterSB wrote:
Quote:
with -mstrict-X, several functions won't compile, an example output:
error: 'asm' operand has impossible constraints

Something is wrong with your inline assembler. It's not a compiler bug.
"'asm' operand has impossible constraints" is definitely a user error. The compiler is not supposed to hack around user code, no matter if it comes from you or from some "official" header files.

Quote:

eep = (__extension__({ uint32_t __addr32 = (uint32_t)((uint32_t)(0x30000UL + pp + __builtin_offsetof (TCfgRot, eeRot))); uint16_t __result; __asm__ ( "out %2, %C1" "\n\t" "movw r30, %1" "\n\t" "elpm %A0, Z+" "\n\t" "elpm %B0, Z" "\n\t" : "=r" (__result) : "r" (__addr32), "I" ((((uint16_t) &((*(volatile uint8_t *)((0X3B) + 0x20)))) - 0x20)) : "r30", "r31" ); __result; }));

gives me this error:
eep.c:1:21: error: braced-group within expression allowed only inside a function

avrfreaks does not support Opera. Profile inactive.

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

with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from 20120606 : 15674 bytes

206 bytes lost :-/ I will use nm to check the functions that got bigger

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

SprinterSB wrote:
gives me this error:
eep.c:1:21: error: braced-group within expression allowed only inside a function

You might not be interested in potential problems, but that does not mean you may be rude.

JW

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

Magister wrote:
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.

wek wrote:
SprinterSB wrote:
gives me this error:
eep.c:1:21: error: braced-group within expression allowed only inside a function

You might not be interested in potential problems, but that does not mean you may be rude.
I though you were well aware that copying some lines out of context is pretty much useless in most cases, so is here:

#include 
int eep;
int pp;
typedef struct { int eeRot; } TCfgRot;
void foo (void)
{
  eep = (__extension__({ uint32_t __addr32 = (uint32_t)((uint32_t)(0x30000UL + pp + __builtin_offsetof (TCfgRot, eeRot))); uint16_t __result; __asm__ ( "out %2, %C1" "\n\t" "movw r30, %1" "\n\t" "elpm %A0, Z+" "\n\t" "elpm %B0, Z" "\n\t" : "=r" (__result) : "r" (__addr32), "I" ((((uint16_t) &((*(volatile uint8_t *)((0X3B) + 0x20)))) - 0x20)) : "r30", "r31" ); __result; }));
}

compiles without complaints with

avr-gcc -c -mmcu=avr6 -Os eep.c

Am I to be blamed because me ran out of crystal balls?

avrfreaks does not support Opera. Profile inactive.

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

...same with

avr-gcc -c -mmcu=avr6 -Os eep.c -mstrict-X

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Magister wrote:
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.

Thanks again for all your work!

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

SprinterSB wrote:
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.

JW

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

wek wrote:
SprinterSB wrote:
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.

Last Edited: Fri. Jun 8, 2012 - 07:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Magister wrote:
with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from today     : 15464 bytes
You still be interesting where that difference comes from.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
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).

What did I overlook?

JW

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

avrfreaks does not support Opera. Profile inactive.

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

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.

JW

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

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.

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

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):

#include 
#include 
#include 


register unsigned char __attribute__((used)) _r2 asm("r2");
register unsigned char __attribute__((used)) _r3 asm("r3");
register unsigned char __attribute__((used)) _r4 asm("r4");
register unsigned char __attribute__((used)) _r5 asm("r5");




#define GETItem(p)  (pgm_read_byte_far(pgm_read_word_far((p))))



#define AND &
#define ANL &&
#define SHR >>



  void foo(uint16_t p, uint16_t mask, int16_t p3, uint8_t p4) {

    int16_t a1;
    int16_t a2;
    struct __attribute__((__packed__)) {
      int16_t a3;
      uint8_t a4;
    } buf;


    if ((mask AND (mask-1)) == 0) {
      foo1( foo2(a1) , p3, GETItem(a1), (uint16_t *)pgm_read_word_far(a1));
    } else {

      if (!p4) {
        a1 = p3 - foo3((uint16_t *)pgm_read_word_far(a1));
      } else {
        a1 = 0; //
      }
      p += 1234;

      while (mask != 0) {
        uint16_t pp;

        pp = pgm_read_word_far(p);
        if (pp == 0xFFFF) {
          mask = 0;
        } else if (pp != 0) {
          uint16_t a5;
          uint8_t a6;

          a5 = pgm_read_word_far(pp);
          a6 = foo2(pp);

          if (((mask AND 0x01) != 0) ANL (a6 != 0)) {

            if (p3 == 0x7FFF) {
              buf.a3 = p3;
              buf.a4 = 0;
            } else {

              if (!p4) {
                buf.a3 = foo3((uint16_t *)a5) + a1;
              } else {
                buf.a3 = p3 + a2 - pgm_read_word_far(pp);
              }

              buf.a4 = GETItem(pp);
            }

            foo1(a6, buf.a3, buf.a4, (uint16_t *)a5);
          }

        }
        mask = mask SHR 1;
        p = p + 1234;
      }
    }
  }
c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -Os -mstrict-X
w.c: In function 'foo':
w.c:55:16: error: can't find a register in class 'BASE_POINTER_REGS' while reloa
ding 'asm'
w.c:55:16: error: 'asm' operand has impossible constraints

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -Os

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O3 -mstrict-X
w.c: In function 'foo':
w.c:55:16: error: can't find a register in class 'BASE_POINTER_REGS' while reloa
ding 'asm'
w.c:55:16: error: 'asm' operand has impossible constraints

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O2 -mstrict-X
w.c: In function 'foo':
w.c:55:16: error: can't find a register in class 'BASE_POINTER_REGS' while reloa
ding 'asm'
w.c:55:16: error: 'asm' operand has impossible constraints

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O1 -mstrict-X

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O0 -mstrict-X

c:\tmp>

The "reserved" registers are instrumental. Removing them removes both errors. Adding -ffixed-rN brings the errors back.

Enjoy! ;-)

JW

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

I 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.

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

I 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): 

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

SprinterSB wrote:
Magister wrote:
with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from today     : 15464 bytes
You still be interesting where that difference comes from.

Yup, 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:

std	Y+18, r15	; 0x12
std	Y+17, r14	; 0x11

I will upload the code to my board and run it.

Attachment(s): 

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

@Jan: I filed it as http://gcc.gnu.org/PR53615

avrfreaks does not support Opera. Profile inactive.

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

Thanks.

Quote:
And here is the source file wek.c
:-)

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

Johann,

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

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

I 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.

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

Hi,
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:

avr-size -C --mcu=atxmega128a1 main.elf
AVR Memory Usage
----------------
Device: atxmega128a1

Program:   79544 bytes (57.1% Full)
(.text + .data + .bootloader)

Data:       6974 bytes (85.1% Full)
(.data + .bss + .noinit)

new toolchain:

avr-size -C --mcu=atxmega128a1 main.elf
AVR Memory Usage
----------------
Device: atxmega128a1

Program:   73598 bytes (52.8% Full)
(.text + .data + .bootloader)

Data:       6664 bytes (81.3% Full)
(.data + .bss + .noinit)

The smaller program size IMHO is impressive, but I wonder why Data also loses that much?

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

Quote:

but I wonder why Data also loses that much?

The .map file wil tell you. (or the output of avr-nm, whichever you prefer).

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

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).

JW

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

clawson wrote:
The .map file wil tell you. (or the output of avr-nm, whichever you prefer).
I had a look at the map file. This is what I've noticed:

1. 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):

 .rodata.str1.1
                0x00000000008020af       0xd5 main.o

2. These seem to be the only missing 0x100 bytes in the 4.7.1 build:

 .data          0x0000000000802338      0x100 /opt/avr-4.3.4/bin/../lib/gcc/avr/4.3.4/avrxmega7/libgcc.a(_clz.o)
                0x0000000000802338                __clz_tab

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.

  • 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:

 .data          0x0000000000802338      0x100 /opt/avr-4.3.4/bin/../lib/gcc/avr/4.3.4/avrxmega7/libgcc.a(_clz.o)
                0x0000000000802338                __clz_tab

See http://gcc.gnu.org/PR29524

avrfreaks does not support Opera. Profile inactive.

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

The avr-gcc 4.7.1 is released officialy!!!

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

DieCore wrote:
The avr-gcc 4.7.1 is released officialy!!!

GCC 4.7.1 is released officially :P

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

salixer wrote:
I've compiled a toolchain on x86_64 Linux with:
avr-gcc (GCC) 4.7.1 20120606 (prerelease)
[...]

The smaller program size IMHO is impressive

The size might shrink even more with the following patch:

http://gcc.gnu.org/bugzilla/atta...

You can download the patch via the "View" link and then apply it like so:

cd GCC-SOURCES/gcc
patch -p0 < pr53595.diff

Does that patch has further impact on the code size?

avrfreaks does not support Opera. Profile inactive.

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

avr-gcc (GCC) 4.7.1 20120606 (prerelease)

...
Compiling C: main.c
avr-gcc -c -mmcu=atmega1281 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -pedantic -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fno-split-wide-types -flto -ffunction-sections -fdata-sections -Wl,--relax  -fno-tree-scev-cprop -finline-small-functions -fearly-inlining -Wa,-adhlns=../obj/main.lst -std=c99 -MMD -MP -MF ../obj/dep/main.o.d main.c -o ../obj/main.o 

Linking: ../bin/Paragraph5/Paragraph_PID.elf
avr-gcc -mmcu=atmega1281 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -pedantic -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fno-split-wide-types -flto -ffunction-sections -fdata-sections -Wl,--relax  -fno-tree-scev-cprop -finline-small-functions -fearly-inlining -Wa,-adhlns=../obj/spi.o -MMD -MP -MF ../obj/dep/Paragraph_PID.elf.d ../obj/spi.o ../obj/rtc_ds1390.o ../obj/rtc.o ../obj/rtc_str.o ../obj/df.o ../obj/ks108.o ../obj/lcd128x64.o ../obj/str_ascii.o ../obj/str_ml.o ../obj/lcd_str.o ../obj/lcd_str_ml.o ../obj/lcd_str_rtc.o ../obj/lcd_img.o ../obj/lcd_gfx.o ../obj/keys.o ../obj/di.o ../obj/led_keyboard.o ../obj/led7.o ../obj/crc16.o ../obj/bin_bcd.o ../obj/filter.o ../obj/gui_progress_bar.o ../obj/gui_scroll_bar.o ../obj/plot_misc.o ../obj/plot_series.o ../obj/plot_background.o ../obj/plot.o ../obj/plot_scroll.o ../obj/plot_zoom.o ../obj/plot_arch.o ../obj/plot_main.o ../obj/menu_content_items_callback.o ../obj/menu_items_rules.o ../obj/menu_items_access.o ../obj/menu_item.o ../obj/menu_item_int.o ../obj/menu_item_enum.o ../obj/menu_item_cmd.o ../obj/menu_item_rtc.o ../obj/menu_item_float.o ../obj/menu_item_submenu.o ../obj/menu_xls.o ../obj/menu_std.o ../obj/menu_plot.o ../obj/menu_arch.o ../obj/menu.o ../obj/rs485.o ../obj/modbus_buffer.o ../obj/modbus_timer.o ../obj/modbus_slave_func.o ../obj/modbus_slave.o ../obj/ad7792.o ../obj/max6627.o ../obj/adc.o ../obj/dac.o ../obj/nsc.o ../obj/ain_cj.o ../obj/ain_tc.o ../obj/ain_rtd.o ../obj/ain_unified.o ../obj/ain_logical.o ../obj/ain_demo.o ../obj/ain.o ../obj/dffs_page.o ../obj/dffs_volume.o ../obj/dffs_info.o ../obj/dffs.o ../obj/timers.o ../obj/gui_base.o ../obj/init_port.o ../obj/init_dev.o ../obj/errors.o ../obj/psychrometer.o ../obj/mathematics.o ../obj/led_misc.o ../obj/relay.o ../obj/pid_timer.o ../obj/pid.o ../obj/registrator.o ../obj/main.o --output ../bin/Paragraph5/Paragraph_PID.elf  -Wl,--gc-section   -Wl,-u,vfprintf -lprintf_flt  -lm

errors:

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!

Oh, how I miss -combine option:)

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

What 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.

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

SprinterSB wrote:
What means "W/O"?
without

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

SprinterSB wrote:
wasn't -combine removed?
Yes it was. I believe that this was done prematurely.
As I can see (LTO and enviroment) still needs to further adapt.
Thanks you for your reply!

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

demiurg_spb wrote:
SprinterSB wrote:
wasn't -combine removed?
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.

  • 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.

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

demiurg_spb wrote:
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

  1. Call the compiler driver gcc with -Wl,--sort-section=name
  2. 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.
  3. 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.

  • 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.

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

SprinterSB wrote:
-combine and -fwhole-program are noe more needed since LTO which is even more powerful.

I'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): 

Last Edited: Fri. Aug 10, 2012 - 06:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are the options for the last link, i.e. after lto proper has finished?

avrfreaks does not support Opera. Profile inactive.

  • 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
This quote is from http://gcc.gnu.org/onlinedocs/gc...

I yet only haven't try to use gold linker instead collect2.
Should I?

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

Does it work if you link with these?

    -nodefaultlibs -lm -lgcc -lc -lgcc

avrfreaks does not support Opera. Profile inactive.

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

Oh 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!!!

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

BTW maybe you know why next code compiles without any warnings and errors... If I remember, IAR makes warn in this case.

const __flash char* pcf;
const char* pc;

void test1(void) {pcf = pc;}
void test2(void) {pc = pcf;}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It'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.

  • 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?

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

Quote:

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:

struct {
  int x1;
  int x2;
  int x3; 
} eevars EEMEM;

  • 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.

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

demiurg_spb wrote:
original code of file: avr-libc/avr/boot.h [...]
error: attempt to use poisoned "SPMCR"

I guess it's avr-gcc bug.

No, it's AVR-Libc issue #36410.

avrfreaks does not support Opera. Profile inactive.

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

But how it possible?
There is no bug in boot.h

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

boot.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.

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

You are right!
I found in iom128.h:
#pragma GCC poison SPMCR

So that boot.h should be modified to fix this situation...

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

avr-gcc (GCC) 4.7.1 20120606 (prerelease)

CFLAGS += -std=gnu99
CFLAGS += -Os
CFLAGS += -pedantic
CFLAGS += -Wall
CFLAGS += -Wextra
void func(void)
{
	static const int PROGMEM x = 0;
	(void)x; // dummy
}

warning: uninitialized variable 'x' put into program memory area [-Wuninitialized]

static const int PROGMEM x = 0;

void func(void)
{
	(void)x; // dummy
}

No warning...

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

demiurg_spb wrote:
avr-gcc (GCC) 4.7.1 20120606 (prerelease)
void func(void)
{
	static const int PROGMEM x = 0;
	(void)x; // dummy
}

warning: uninitialized variable 'x' put into program memory area [-Wuninitialized]

You must do someting wrong. With the compiler version you mentioned if compile
#define PROGMEM __attribute__((progmem))
void func(void) 
{ 
   static const int PROGMEM x = 0; 
   (void)x;
}

with

    avr-gcc foo.c -Os -S -Wextra -Wall -W -std=gnu99 -pedantic
there is no warning.

avrfreaks does not support Opera. Profile inactive.

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

sry doublepost-delete this

Last Edited: Wed. Aug 29, 2012 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I was tracking one bug in gcc 4.7.0 (20.4.2012), maybe it helps somebody else to save his time.
I was working on bootloader with Xmodem download feature for ATmega88pa. Because of limited boot section space to 2kB I had to optimize a lot. This was reason why I switched from gcc 4.3.3 to 4.7.0 because it shorted code size ~150B - nice. But it introduced a bug that cause strange hang in Xmodem receiver function. I had allocaded one static Byte buffer for data and when ~30 bytes received it crashed. After hours of messing around I found it happen due to wrong .bss section position. When the buffer was not static it worked because it was placed ijn stack. Or if I made some global variables that filled section. data.
In the map file I saw, that when .data section was empty the linker placed .bss section (the buffer) at address 0x60! Instead of 0x100 - the beginning of SRAM. To prevent it I have to made just one byte global variable (that was used to prevent gcc optimizer to remove it), then .bss was correctly from 0x102 (after that glob. var.). Now you can imagine what happened when Xmodem receiver was writting to buffer at 0x60 - it completly rewite system registers - I also saw that LED flashed shortly when written to PORTB before it crashed [note: as I was debugging UART transaction I couldn't use the same UART for debug prints so I could just debug via LED]....
Also I have to note that I use -fdata-sections -ffunction-sections --gc-sections options to remove unused sections. But gcc was probably too agressive and removed whole empty data section that caused .bss shift.

Anyway when I just a hour ago started to read this thread I found there's gcc 4.7.1 RC package that has updated linker scripts and it solved this problem. It's enough to copy LDSCRIPTS dir to my 4.7.0 compiler package to fix it, so thanks for it. For users experienced with this new gcc 4.7.x what do you reccomend? Should I completly update to 4.7.1 or just the linker scripts to 4.7.0?

I also had one issue caused by avr-libC 1.8.0 at ATmega128:
when I included I got an error due to poisoned SPMCR. I found that boot.h check it's presence via #ifdef that is enough to not compile my source. I also found that this bug was reported and is still opened. My hotfix was simply to comment the poison line in
IOM128.H:
// #pragma GCC poison SPMCR // cause error in boot.h header that test this macro
I don't know better solution but as both SPMCR and SPMSCR regs are defined same way I don't care...

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

glaux wrote:
what do you reccomend? Should I completly update to 4.7.1 ...?
I think that avr-gcc-4.7.1 should be better choice.
SprinterSB wrote:
You must do someting wrong...
Maybe yes, maybe no...
I forgot to say that I use -flto as -combine like manner.
I can't produce minimal test case to show this situation.
Warning is gone if I make simple project with 2 src files main.c and module.c (this module.c is cause warning in real project). Also real project compiles without warnings if I remove -Wextra flag.

IMHO, this is not normal situation
Because next case

static const int PROGMEM x;

produces correct warning in any cases with and without -Wextra flag.

Attachment(s): 

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

glaux wrote:
when .data section was empty the linker placed .bss section (the buffer) at address 0x60! Instead of 0x100 [...] Also I have to note that I use -fdata-sections -ffunction-sections --gc-sections options to remove unused sections. But gcc was probably too agressive and removed whole empty data section
GCC does not remove empty section.

You hit binutils PR13697. To work around you can use up to date binutils, patch your default ld script as indicated by the patch along with PR13697, or put some data into .data that cannot be removed.

glaux wrote:
Anyway when I just a hour ago started to read this thread I found there's gcc 4.7.1 RC package that has updated linker scripts and it solved this problem. It's enough to copy LDSCRIPTS dir to my 4.7.0 compiler package to fix it, so thanks for it.
Yes, that will suffice to fix PR13697 but notice that 4.7.1 has more bugs fixed than yust that one. Have a look at the source directory of the 4.7.1rc1 and at GCC bugzilla.

glaux wrote:
For users experienced with this new gcc 4.7.x what do you reccomend? Should I completly update to 4.7.1 or just the linker scripts to 4.7.0?
I'd recommend to update to 4.7.1.

glaux wrote:
I also had one issue caused by avr-libC 1.8.0 at ATmega128:
when I included I got an error due to poisoned SPMCR.
This is AVR-Libc issue #36410.

avrfreaks does not support Opera. Profile inactive.

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

>SprinterSB
Thanks for info. I started to use GCC 4.7.1 and currently didn't find any problem.

>This is AVR-Libc issue #36410.
AFAIK still not solved for ~3 months...

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

demiurg_spb wrote:
compile.zip
That's just babbling from make, it's not possible to reproduce the issue from that.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
That's just babbling from make, it's not possible to reproduce the issue from that.
I understand. What should I do to make useful "bug report" in my case? Thx!

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

  1. [Try to] work out a small test case. Most code in your C files won't be needed to reproduce the warning. Remind that others don't have files that you #include.
  2. The compiler option you use
  3. The compiler version you use
  4. The compiler output/messages/diagnostics
You can get 2. 3. and 4. by adding -v to the compiler command options.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
  1. [Try to] work out a small test case. Most code in your C files won't be needed to reproduce the warning. Remind that others don't have files that you #include.
I can't do minimal case. When I exclude any module from my project I get no error :-(

May I send You my project directly?

Attachment(s): 

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

Can't you compiler with -Wno-error=uninitialized for a start?

And -fwhole-program does not look like a good idea of you use LTO.

Can't you reduce it to two or three files?

Are you sure you have extern in prototypes in the headers?

If I don't miss something that the warning is only during the LTO link, not when compiling to .o. Is that right?

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Can't you compiler with -Wno-error=uninitialized for a start?

with -Wno-error=uninitialized project compiles without any errors but with warnings.

In file included from :117:0:
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
In file included from :92:0:
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]

SprinterSB wrote:
And -fwhole-program does not look like a good idea of you use LTO.
There is no difference (I've tried to compile without whole-program).

SprinterSB wrote:
Are you sure you have extern in prototypes in the headers?
No this is local constant data:

//=============================================================================
void dac_update(uint8_t ch, float x)
{
	#define DAC_FS   (DAC_20MA - DAC_0MA) // full scale

	#define DAC_4MA  (DAC_0MA + FROUND(DAC_FS/5.0f))
	#define DAC_5MA  (DAC_0MA + FROUND(DAC_FS/4.0f))
	#define DAC_10V  (DAC_0MA + FROUND(DAC_FS))
	#define DAC_1V   (DAC_0MA + FROUND(DAC_FS/10.0f))
	#define DAC_0V   (DAC_0MA)

	typedef struct
	{
	 	uint16_t lo;
	 	uint16_t hi;
	} range_t;


	static const range_t PROGMEM dac_out_range[] =
	{
			{DAC_0MA, DAC_0MA },     // off
			{DAC_4MA, DAC_20MA}      // 4-20 mA
	
		#ifdef DAC_WITH_ALL_CURRENTS
			,
			{DAC_0MA, DAC_5MA },     // 0-5  mA
			{DAC_0MA, DAC_20MA}      // 0-20 mA
		# ifdef DAC_WITH_VOLTAGE
			,
			{DAC_0V,  DAC_10V },     // 0-10 V
			{DAC_0V,  DAC_1V  }      // 0-1  V
		#  ifdef DAC_WITH_MAN_CTL
			,
			{DAC_0V,  DAC_10V },     // 0-10 V  RS485
			{DAC_0MA, DAC_20MA}      // 0-20 mA RS485
		#  endif
		# endif
		#endif
	};
....
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would you attach a zip containing

  • all needed sources
  • a plain text file that lists the commands and options that trigger the warning
Please make sure that there are no external dependencies like missing headers that avoid that someone alse can reproduce it.

For example you can inflate zu zip into an empty directory and run the collected compile/assemble/link commands there in order to make sure it actually reproduces the issue.

avrfreaks does not support Opera. Profile inactive.

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

Hi,
I just downloaded AVR-GCC-4.7.2. Tried to compile an existing project where I have used PROGMEM. I am getting errors!!! The earlier version compiled OK. Thanks for any suggestions.

Parthasaradhi Nayani

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

in 4.7.2 you need to use __flash. I changed all reference to progmem in my code. To define string I am using:

#define _FLASH 	const __flash
#define FLASH_STR(s) ({static char _FLASH __c[] = (s); &__c[0];})

Also SprinterSB, FIY, my project with:

4.7.1 : 15700 bytes
4.7.2 : 15674 bytes
4.8.0 : 15788 bytes

PS: big thanks to you for making avr-gcc build! 8) :D

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

Hi,
const char PROGMEM ch; works. No errors are reported.

Used makefile and PN for compiling an existing project. Avr-size has thrown out error. It does not understand --mcu option. Avr-size seems to be original GCC size without the extra mcu option.

One question- what is the maximum size of a pointer that is allowed in this release? My primary interest is in having 32 bit pointers. Thank you.

Parthasaradhi Nayani

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

Magister wrote:
in 4.7.2 you need to use __flash.
Not quite. you may use __flash but there is no need to use __flash. You can just as well use attribute progmem aka. PROGMEM macro together with the pgm_read_* accessors from AVR-Libc.

Nayani P wrote:
I tried to compile an existing project where I have used PROGMEM. I am getting errors!!!
Very descriptive, really...

Presumably you are tring to put non-const data into flash. We don't know.

Nayani P wrote:
avr-size has thrown out error. It does not understand --mcu option.
avr-size is from binutils. It comes without -C kludge or similar. Read the binutils documentation or avr-size --help to learn about supported command options.

Nayani P wrote:
what is the maximum size of a pointer that is allowed in this release? My primary interest is in having 32 bit pointers.
Pointers in the impementation are 16 bits wide. There are no 32-bit pointers.

There is a 24-bit address space __memx which is a C extension. __memx linearizes flash and internal RAM. Read the compiler documentation and the GCC release notes.

avrfreaks does not support Opera. Profile inactive.

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

GCC 4.7.2 is released now and I decided to provide a build of avr-gcc 4.7.2 for MS Windows.

If you are interested, see avr-gcc 4.7 for Windows in the avr-gcc-list mailing list archive.

For questions and feedback, please follow up to that mailing list. For details like subscribing to that list, see the avr-gcc-list@nongnu.org main page.

Thanks.

avrfreaks does not support Opera. Profile inactive.

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

I am using it for a few days now, no difference with the release candidate I think.

Thanks a lot for your work, it's highly appreciated!

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

I copied avr-size.exe from AVR tool chain that comes with AVR Studio 5.1.208 to be able to use AVR GCC 4.7.2 with AVR Studio 5. I have not checked to see if the result is correct.

C option is not supported. So, how can I modify AVR Studio 5 to use original avr-size.exe that comes with avr-gcc-4.7.2-mingw32

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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

metal wrote:
So, how can I modify AVR Studio 5 to use original avr-size.exe that comes with avr-gcc-4.7.2-mingw32
avr-size that comes with avr-gcc-4.7.2-mingw32 is unpatched and don't knows avr-format (C option is not supported). Just use old (patched) avr-size.exe from WinAvr or AvrStudio.
You can check path and version of avr-size by next two commands:
"which avr-size.exe"
"avr-size.exe --v"
Magister wrote:
I am using it for a few days now, no difference with the release candidate I think.
I see different to previous version (-18 bytes on 70 KB project) :-).

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

what is the reason for not patching avr-size.exe to have the required options.

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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

Quote:

what is the reason for not patching avr-size.exe to have the required options.

It was a patch developed by Eric Weddington. While the source may be open (I think it has to be as avr-size is likely GPL) the fact is that it would require maintenance as modern tool chains cover a whole load of new AVRs. So only if someone's willing to invest the time/effort (which I guess wouldn't be THAT complex) can a version that matches the device support in a typical 4.6/4.7/4.8 build be produced.

I think I looked at this before and as you may guess it's just a table of device names together with their flash, RAM and EEPROM sizes so -C can show percentages.

As Atmel have taken on the gauntlet of new device additions (in their private branch) you might hope that they would have thought of doing this work. However their choice was to run the vanilla avr-size then run their own post-processor that digests the output then fails to show percentages correctly. Ho hum.

(I think Atmel may have done it that way as they wanted a common mechanism that could work with AVR32 and SAM3/4 too).

EDIT:

E:\WinAVR-20100110\source\avr\binutils\2.19>dir 30*
 Volume in drive E is VBOX_windows
 Volume Serial Number is 0000-0801

 Directory of E:\WinAVR-20100110\source\avr\binutils\2.19

19/01/2010  19:08            16,260 30-binutils-2.19-avr-size.patch

Clearly that needs to be brought up from 2.19 to 2.22 or whatever.

EDIT2: hey I'm famous. I was searching for "{"atmega164p", AVR16K, AVR1K, AVR512}" online to see if I could find a maintained copy of the patch and it hit this site:

https://build.opensuse.org/packa...

So they named the package after my internet persona!

Oh and I did find a 2.20 version:

http://fbsdmon.org/ports/devel/a...

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

I asked on the 1st pg. if this toolchain could be used with Studio 4.18, and from Clawson's reply I tried adding its path, for avr-gcc-4.7.2.exe, in Custom Options. I'm confused about MAKE.exe, since it's not in the chain. I assume then that I can use the same one from Winavr, so that path's unchanged.

I tested it on my MP3 pjt, using FATFS and this is the output:
1st warning in ff.c:347:3( the return line )

	case FS_FAT16 :
		if (move_window(fs, fsect + (clst / (SS(fs) / 2)))) break;
		return LD_WORD(&fs->win[((WORD)clst * 2) & (SS(fs) - 1)]);
Build started 18.10.2012 at 12:29:06
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT ff.o -MF dep/ff.o.d  -c  ../ff.c

../ff.c: In function 'get_fat':
../ff.c:347:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:351:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c: In function 'check_fs':
../ff.c:1445:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1448:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1450:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c: In function 'chk_mounted':
../ff.c:1531:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1535:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1536:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1540:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1542:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1543:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1544:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1546:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1554:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT LCD.o -MF dep/LCD.o.d  -c  ../LCD.c

avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT vs1011.o -MF dep/vs1011.o.d  -c  ../vs1011.c

../vs1011.c: In function 'sd_cmd':
../vs1011.c:39:2: warning: right shift count >= width of type [enabled by default]
../vs1011.c: In function 'VS_sci_rd':
../vs1011.c:247:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT diskio.o -MF dep/diskio.o.d  -c  ../diskio.c

../diskio.c:187:6: warning: 'select' defined but not used [-Wunused-function]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT mp3.o -MF dep/mp3.o.d  -c  ../mp3.c

avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sectio
ns  -mcall-prologues                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT ccp.o -MF dep/ccp.o.d  -x assembler-with-cpp -Wa,-gdwarf2 -c  ../ccp.S

avr-gcc-4.7.2 -mmcu=atxmega16a4 -Wl,--relax -Wl,--gc-sections -Wl,-Map=My_MP3.map ff.o LCD.o vs1011.o diskio.o mp3.o ccp.o   -L"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\MY_LIBS"  -lm  -o My_MP3.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  My_MP3.elf My_MP3.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex My_MP3.elf My_MP3.eep || exit 0
avr-objdump -h -S My_MP3.elf > My_MP3.lss

avr-size: invalid option -- C
Usage: avr-size [option(s)] [file(s)]
 Displays the sizes of sections inside binary files
 If no input file(s) are specified, a.out is assumed
 The options are:
  -A|-B     --format={sysv|berkeley}  Select output style (default is berkeley)
  -o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
  -t        --totals                  Display the total sizes (Berkeley only)
            --common                  Display total size for *COM* syms
            --target=        Set the binary file format
            @                   Read options from 
  -h        --help                    Display this information
  -v        --version                 Display the program's version

avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
make: *** [size] Error 1
Build failed with 1 errors and 17 warnings...

It's fine with the latest Winavr and I'm missing something(s)...

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Sprinter is building a plain-vanilla avr-gcc.

avr-size (Binutils) hasn't been patched with the "Atmel patches"

Just skip the "Atmel specific option -C" avr-size step , or apply the Atmel patch called something like 30-binutils-avr-size.patch

/Bingo

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

Bingo600 wrote:
Sprinter is building a plain-vanilla avr-gcc.

avr-size (Binutils) hasn't been patched with the "Atmel patches"

Just skip the "Atmel specific option -C" avr-size step , or apply the Atmel patch called something like 30-binutils-avr-size.patch

/Bingo

1) Skipping -C option...how, that's in Atmel's MAKEFILE isn't it ?

OR

2) Patch option... I don't have a clue how to apply it. I can find it. I'm running 'Doze XP.

Thanks for the help.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

If you have no clue on using patch ...

I'd select option 1 , and find the place in the makefile where avr-size gets called.
Then either comment it out , or at least remove the -C

/Bingo

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

Bingo600 wrote:
If you have no clue on using patch ...

/Bingo

Yeah, I found the patch on their site, but nothing on how to install it in 'Doze XP. Much easier in Linux, I bet. It looks like just a C file, I was thinking it would be a *.exe file to integrate into the toolchain.

Quote:
I'd select option 1 , and find the place in the makefile where avr-size gets called.
Then either comment it out , or at least remove the -C
When I comment out the line or even take out just the option, MAKEFILE doesn't keep the saved changed . I edit Atmel's MAKEFILE, save it and rebuild...original line's back ( what voodoo is this ??! ). All the warnings go away, though.

Jerome

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Last Edited: Wed. Oct 24, 2012 - 05:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read freaky member demiurg_spb's reply above on this pg. , thanks man, and so I just copied Winavr's avr-size.exe in place of 4.7.2's and it complies now, but the same 17 warnings are back.

Xmega16A4, -Os

Winavr compile: 7218 bytes

AVR-GCC 4.7.2 compile: 6914

Thanks Sprinter for all your work.

Edit: This switch used to turn those warnings off, produced from FATFS code ( must be a harmless warning in this case ):

-fno-strict-aliasing

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Johann,

Now that https://www.avrfreaks.net/index.p... has been solved through http://sourceware.org/bugzilla/s... , could you please provide a binary build which removes the initializer problem described under "Limitations and caveats" in http://gcc.gnu.org/onlinedocs/gc... ?

Thanks,

Jan

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

There is avr-gcc-4.7.1-rc1-mingw32.zip that comes with a backport of PR53344 to 4.7, see the source directory for respective patchset.

avrfreaks does not support Opera. Profile inactive.

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

Yes, but that in turn has not included the binutils PR13503 fix.

an1.s: Assembler messages:
an1.s:23: Error: junk at end of line, first unrecognized character is `('
an1.s:24: Error: junk at end of line, first unrecognized character is `('
an1.s:25: Error: junk at end of line, first unrecognized character is `('
.global	pfoo
	.section	.progmem.data,"a",@progbits
	.type	pfoo, @object
	.size	pfoo, 3
pfoo:
	.byte	lo8(foo) ; need binutils PR13503
	.byte	hi8(foo) ; need binutils PR13503
	.byte	hh8(foo) ; need binutils PR13503

I know it is possible to compile using the 4.7.1 and assemble and link using the tools from the 4.7.2 build, but if it is not a big hassle for you, it would be nice to have it as a single bundle working "out-of-the-box".

The 4.7.2 bundle has seen already a couple of dozens of downloads. There *is* a need for this stuff, in lack of a WinAVR-style package.

Thanks,

Jan

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

Does 4.7.2 work for you and instead of compiling / assembling in "one" step

avr-gcc -c file.c $(options)

you do two steps like so?

avr-gcc -S file.c $(options)
sed file.s -e 's:\.byte.*hh8:.byte hlo8:g' > file-2.s
avr-gcc -c file-2.s -Wa,--no-warn $(options)

Notice PR53344 won't be backported to 4.7 because the avr port maintainers did not approve a backport which is in accordance with GCC policies:

    Bug fixes and documentation changes only.

avrfreaks does not support Opera. Profile inactive.

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

Apart from the aesthetical drawback that the warning remains, it also simply fails, because:

#include 

const __memx char dummy1[32767];
const __memx char dummy2[32767];
const __memx char dummy3[32767];
const __memx char dummy4[32767];
const __memx char foo;
const __memx char * const __flash pfoo = &dummy1[0];

int main(void) {
}

results in

an12.s: Assembler messages:
an12.s:24: Warning: assembling 24-bit address needs binutils extension for hh8(d
ummy1)
an12.s:23: Error: value of 98305 too large for field of 2 bytes at 0

(line 23 is .word dummy1 )

I (and presumably others too) would be obliged if you could find time to produce a working set of binaries.

(Just wondering, how does "does not produce assemblable code" fail short of the official definition of "bug").

Thanks,

Jan

PS. Johann, could you please also comment on https://www.avrfreaks.net/index.p... ? Thanks.

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

How does the assembler code look like?
And how did you assemble that?

At the moment all the time I can spend on avr-gcc is consumed by other stuff.

I will come back toi this as soon I have some time left.

Thanks for your patience.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
How does the assembler code look like?
And how did you assemble that?
In attachment; see an1.bat (there's a bit more in that than absolutely needed, but the point should be clear).

SprinterSB wrote:
At the moment all the time I can spend on avr-gcc is consumed by other stuff.

I will come back toi this as soon I have some time left.

That's OK of course.

Thanks,

Jan

Attachment(s): 

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

What about the 4.8.0 snapshot?

avrfreaks does not support Opera. Profile inactive.

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

Why not?

You tell what could be a gotcha.

JW

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

Fixed-Point support is broken by design.

Slighly inefficient reloading because of outdated constraint cost (PR54815).

@@@ A CAPTCHA for this post???

avrfreaks does not support Opera. Profile inactive.

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

Okay, but aren't both already present in 4.7.x? If so, that's no real gotcha in using a 4.8 snapshot rather than a 4.7.whatever release.

I mean, users presumably would try 4.7+ mainly to test the new features, of which IMO __flash and kin are the most interesting and worth more thorough testing and further discussion.

I did not mention it, but I now started asking for these things just because somebody else asked for string literals in high FLASH (pointers to) arrays also in high FLASH (*), in a local mailing list. I in answer recommended the newest development in 4.7+ just to be told that it does not work...

JW

(*) I tried to keep the C type declaration style :-)

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

It work for me with __flash1 etc.

Notice one segment cannot hold more than 64KiB and you need a liker script as explaned in the GCC docs. Ther is no one-fits-all-memory-arrangements script, at least I failed in finding one. Maybe just because my very limited knowledge on binutils and a wizard finds an nea solution...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#pragma pack(push, 4)
typedef struct
{
	uint8_t a;
	uint8_t b;
	uint8_t c;
} abc_t;
#pragma pack(pop)

abc_t x, y, z;

STATIC_ASSERT(sizeof(abc_t)==3); // true (should be false IMHO)

something is broken in avr-gcc 4.7.2
and in 4.3.3
and in 4.4.3 too :-(

Structures x,y,z and their fields are placed in memory without any gaps.

It seems to be very old bug:https://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=65874&start=0

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

please solution
After update gcc from 4.3 to 4.7.2 I cant compile my code some unseen error appeared

Build started 22.1.2013 at 10:44:14
avr-gcc -I"C:\Mariaus\myproject\EEPROM_flasher\."  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                      -DF_CPU=14740000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT EEPROM_fl
asher.o -MF dep/EEPROM_flasher.o.d  -c  ../EEPROM_flasher.c

In file included from ../EEPROM_flasher.c:6:0:
../spi.c: In function 'read_sector_prtct_stat':
../spi.c:206:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
avr-gcc -mmcu=atmega644 -Wl,--defsym=__stack=0x1000 -Wl,-Map=EEPROM_flasher.map EEPROM_flasher.o     -o EEPROM_flasher.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  EEPROM_flasher.elf EEPROM_flasher.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex EEPROM_flasher.elf EEPROM_flasher.eep || exit 0
avr-objdump -h -S EEPROM_flasher.elf > EEPROM_flasher.lss

avr-size: invalid option -- C
Usage: avr-size [option(s)] [file(s)]
 Displays the sizes of sections inside binary files
 If no input file(s) are specified, a.out is assumed
 The options are:
  -A|-B     --format={sysv|berkeley}  Select output style (default is berkeley)
  -o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
  -t        --totals                  Display the total sizes (Berkeley only)
            --common                  Display total size for *COM* syms
            --target=        Set the binary file format
            @                   Read options from 
  -h        --help                    Display this information
  -v        --version                 Display the program's version

avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
make: *** [size] Error 1
Build failed with 1 errors and 1 warnings...

may somebody knows the solution or need some more information...

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

Quote:

may somebody knows the solution

The only error there is the attempt to use -C on avr-size. The fact is that in WinAVR Eric Weddington developed/applied a patch to avr-size utility so that as well as the normal -A and -B that the generic "size" program accepts it would now accept -C along with an additional --mcu= so it could produce a much more readable output display that even included % of flash and data figures. It does this as it has a large table of all the known AVR models along with their flash, RAM and EEPROM sizes. The version of avr-size you are using does not have this patch. So edit the Makefile you are using and stop it attempting to use -C and --mcu=.

Alternatively find out what version of avr-size is now being used and temporarily replace it with the avr-size.exe copied from WinAVR as the old version should still work on "modern" .elf files.