avr-gcc 4.7.0 for the brave

Go To Last Post
205 posts / 0 new

Pages

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:

http://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!

Pages