View topic - avr-gcc 4.7.0 for the brave

Search

avr-gcc 4.7.0 for the brave
Previous 1, 2, 3, 4, 5, 6 ... 11 Next All

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum

Author

Message

clawson

Posted: Mar 23, 2012 - 04:38 PM

Joined: Jul 18, 2005
Posts: 62281
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

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

The AVR-LibC user manual perhaps?

_________________

SprinterSB

Posted: Mar 23, 2012 - 05:04 PM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

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

wek

Posted: Mar 23, 2012 - 05:21 PM

Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia

Thanks Johann for the hints.

One more question on -flto, if you permit.

Code:

volatile char c;

int main(void) {

  __asm__ volatile (

    "lds  r16, c"

    :::"r16"

  );

}

results in

Code:

`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

clawson

Posted: Mar 23, 2012 - 05:25 PM

Joined: Jul 18, 2005
Posts: 62281
Location: (using avr-gcc in) Finchingfield, Essex, England

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/user-man ... tools.html

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

http://www.nongnu.org/avr-libc/user-manual/index.html

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 * like that?

_________________

wek

Posted: Mar 23, 2012 - 05:34 PM

Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia

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

wek

Posted: Mar 23, 2012 - 05:45 PM

Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia

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

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

Thanks again,

Jan.

Last edited by wek on Mar 23, 2012 - 05:46 PM; edited 1 time in total

SprinterSB

Posted: Mar 23, 2012 - 05:45 PM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

wek wrote:

One more question on -flto, if you permit.

Code:

volatile char c;

int main(void) {

  __asm__ volatile (

    "lds  r16, c"

    :::"r16"

  );

}

results in

Code:

`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

Code:

char __attribute__((used)) c;

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

Magister

Posted: Mar 23, 2012 - 05:47 PM

Joined: Aug 06, 2008
Posts: 141
Location: Montréal, QC

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

Code:

#include <util/delay.h>

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 <http://gcc.gnu.org/bugs.html> 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?

wek

Posted: Mar 23, 2012 - 06:21 PM

Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia

SprinterSB wrote:

Code:

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 Smile

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

SprinterSB

Posted: Mar 23, 2012 - 06:22 PM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

Magister wrote:

I traced down the problem to the delay function...

Can you reproduce it?

Yes, thanks! Reduced to the max:

Code:

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.

Magister

Posted: Mar 23, 2012 - 06:34 PM

Joined: Aug 06, 2008
Posts: 141
Location: Montréal, QC

You are welcome Smile

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

SprinterSB

Posted: Mar 23, 2012 - 08:45 PM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

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

SprinterSB

Posted: Mar 23, 2012 - 09:31 PM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

ezharkov wrote:

[...] did not quite like __attribute__((always_inline)). It said "always_inline function might not be inlinable".

Are the functions declared as inline?

sergiocampama

Posted: Mar 24, 2012 - 09:10 PM

Joined: Mar 24, 2012
Posts: 1

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)

Magister

Posted: Mar 24, 2012 - 10:19 PM

Joined: Aug 06, 2008
Posts: 141
Location: Montréal, QC

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

ezharkov

Posted: Mar 24, 2012 - 10:29 PM

Joined: Jun 21, 2005
Posts: 882
Location: Chicago area, USA

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.

SprinterSB

Posted: Mar 25, 2012 - 11:56 AM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

wek wrote:

Code:

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:

Code:

char c;

int main (void) {

  __asm__ volatile ("lds  r16, %0" :: "i" (&c) : "r16");

}

clawson

Posted: Mar 25, 2012 - 01:44 PM

Joined: Jul 18, 2005
Posts: 62281
Location: (using avr-gcc in) Finchingfield, Essex, England

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

_________________

SprinterSB

Posted: Mar 25, 2012 - 02:00 PM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

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?

clawson

Posted: Mar 25, 2012 - 02:16 PM

Joined: Jul 18, 2005
Posts: 62281
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

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

They are violating GPL again? Wink

(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]

_________________

Jump to:

All times are GMT + 1 Hour

Previous 1, 2, 3, 4, 5, 6 ... 11 Next All

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum

AVRFreaks.net

Search