View topic - avr-gcc 4.6.1 and Link Time Optimization on Windows

Search

avr-gcc 4.6.1 and Link Time Optimization on Windows
Previous 1, 2, 3, 4, 5 All

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

Author

Message

sternst

Posted: Nov 02, 2011 - 12:29 PM

Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

Quote:

The avr-gcc currently in widest use is the 4.3.3 in WinAVR so surely it's still there in that?

Yes, but this thread is about 4.6 and LTO.

Melbourne asked: why not using the old fashioned portable way as an alternative to LTO
You say: use --combine instead
I say: --combine does not exist as an alternative to LTO (because it is replaced by LTO)
Wink

_________________
Stefan Ernst

clawson

Posted: Nov 02, 2011 - 12:45 PM

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

Oh right I get your point - I was simply responding to the recent posts without taking into account the thread title (or previous contents). Sorry about that Embarassed

_________________

SprinterSB

Posted: Nov 02, 2011 - 12:50 PM

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

melbourne wrote:

At the risk of being repetitive, if you want smaller binaries through smarter linking, just use standard C.

LTO/non-LTO does not affect the C standard. From the users' side it pretty much like any other optimization option.

Quote:

That is, #include your source files into a single compilation unit.

This mechanism is standard, cross-platform, portable, and has worked for the past 30+ years: R included the mechanism in the first versions of C, K& wrote about it. It works with all versions of WinAVR.

No, it does not work for library code. You do not want to drag in libraries like libc or libm as source.

And encapsulation is was not on topic 30 years ago but might be on-topic today.

Quote:

Personally, I'm a little irritated when I see people using non-standard, platform specific work-arounds for something that is already well supported in standard C: it makes my work as a cross-platform maintenance programmer just that extra bit more difficult.

It's not non-standard. It's just a feature that don't affect the language standard or you build scheme.

Moreover, you need not change the sources (which you will do when dragging them into one source file just to mimic LTO).

You do not want to hack sources to emulate each and every optimization feature.

If you mean by standard "use paradigms popular in stone age and never think about or change them" you correct, of course.

Magister

Posted: Nov 02, 2011 - 01:06 PM

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

I tested zillions of parameters and tricks to reduce the size, and using one big .C or the --combine does not give the best results for my project (~16K binary). So YMMV.

melbourne

Posted: Nov 17, 2011 - 08:04 AM

Joined: Aug 18, 2006
Posts: 137

clawson wrote:

Quote:

That is, #include your source files into a single compilation unit.

Why do that when --combine -fwhole-program exists?

Please refer to the original post. If there is something you do not understand, please post here again.

SprinterSB wrote:

Moreover, you need not change the sources (which you will do when dragging them into one source file just to mimic LTO).

I'm staggered at the suggestion that you would drag sources into one source file, and by the accompanying suggestions that you would change/hack sources.

The whole point is to use the standard C "include" mechanism, which was designed for the purpose, to include portable code.

SprinterSB wrote:

If you mean by standard "use paradigms popular in stone age and never think about or change them" you correct, of course.

If you think LTO (and encapsulation) is more modern than "include", you've never understood Pascal. Your ignorance explains, but does not justify, your childish insult.

Thank you both for your thoughtful and insightful responses. It's good to see the level of maturity and care that you bring to your contributions here.

ninevoltz9

Posted: Nov 23, 2011 - 05:01 PM

Joined: Feb 28, 2004
Posts: 976
Location: Ohio

Okay, can someone fill me in with what's going on with avr-gcc? I exchanged an email with Thibault North who maintains the package for the Fedora project, he didn't know why or when the XMEGA support was pulled from the upstream (FSF) release of gcc. He told me other Linux distros use these patches against gcc 4.5.1. I thought the AVR patches were already in the upstream. Fedora's policy is to use upstream code exclusively. I've tried to bring those patches forward into 4.6.1, but so far I am unsuccessful. Does anyone have a working patch set for 4.6.1 they can share?

_________________
I like cats, too. Let's exchange recipes.

SprinterSB

Posted: Nov 23, 2011 - 11:28 PM

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

melbourne wrote:

The whole point is to use the standard C "include" mechanism, which was designed for the purpose, to include portable code.

The original question it *not* about some AVR application, it's about building avr-gcc as canadian cross.

How can you think it's even possible to include all files? The compiler gets what it gets, it's up to the user if he wants to include all headers, it's no choice for the compiler.

SprinterSB

Posted: Jun 05, 2012 - 10:26 PM

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

ninevoltz9 wrote:

I exchanged an email with Thibault North who maintains the package for the Fedora project, he didn't know why or when the XMEGA support was pulled from the upstream (FSF) release of gcc.

What means "pulled from"? "Removed"? If so: xmega support went upstream for 4.7.0, see PR52261 and the GCC 4.7 Release Notes. At no point in time xmega support was removed from GCC.

Quote:

I've tried to bring those patches forward into 4.6.1, but so far I am unsuccessful.

What is the problem?

lfmorrison

Posted: Jun 06, 2012 - 01:26 PM

Joined: Dec 08, 2004
Posts: 4719
Location: Nova Scotia, Canada

Those patches relate to a previous version of Atmel's AVR Toolchain (3.3.x or less) which is derived from avr-gcc 4.5.1.

I wouldn't be surprised at all to discover that patches originally targeting 4.5.1 would be difficult to graft onto 4.6.1 -- especially for a target audience that doesn't have any interest in hacking the internals of the compiler, but rather wants a compiler that "just works".

The newest version of Atmel's AVR Toolchain (3.4.0) is derived from avr-gcc 4.6.x. Currently, it is only possible to obtain Atmel's AVR toolchain 3.4.0 integrated within Atmel Studio 6. All the necessary source code patches are included inside that binary distribution.

I haven't downloaded and installed Atmel Studio 6, so I do not have a copy of those patches myself. Otherwise, I would have been perfectly willing to post a copy of them for you to use.

ninevoltz9

Posted: Jun 06, 2012 - 02:00 PM

Joined: Feb 28, 2004
Posts: 976
Location: Ohio

Thanks for the updates, and for anyone looking for those patches in Studio 6, they are located here: C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\source\avr

_________________
I like cats, too. Let's exchange recipes.

SprinterSB

Posted: Jun 06, 2012 - 03:07 PM

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

lfmorrison wrote:

The newest version of Atmel's AVR Toolchain (3.4.0) is derived from avr-gcc 4.6.x. Currently, it is only possible to obtain Atmel's AVR toolchain 3.4.0 integrated within Atmel Studio 6. All the necessary source code patches are included inside that binary distribution.

I haven't downloaded and installed Atmel Studio 6, so I do not have a copy of those patches myself. Otherwise, I would have been perfectly willing to post a copy of them for you to use.

The patches are supplied here:
http://www.avrfreaks.net/index.php?name ... 947#959947

ninevoltz9

Posted: Jun 06, 2012 - 06:00 PM

Joined: Feb 28, 2004
Posts: 976
Location: Ohio

Fedora 17 still does not have XMEGA support in the avr-gcc package: (I built the Fedora source RPM on EL6)

_________________
I like cats, too. Let's exchange recipes.

Last edited by ninevoltz9 on Jun 06, 2012 - 06:21 PM; edited 1 time in total

clawson

Posted: Jun 06, 2012 - 06:07 PM

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

You have applied all these?

Code:

C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\source\avr\gcc>dir | grep xmega

10/05/2012  16:51            28,668 301-gcc-xmega-v14.patch

10/05/2012  16:51             7,830 404-gcc-atxmega_16_32_a4u.patch

10/05/2012  16:51             3,069 405-gcc-atxmega64_128_192_256a3u.patch

10/05/2012  16:51             2,202 408-gcc-atxmega384c3.patch

10/05/2012  16:51             1,304 410-gcc-atxmega128a4u.patch

10/05/2012  16:51             1,339 411-gcc-atxmega64d4.patch

10/05/2012  16:51             2,343 413-gcc-atxmega64_128_b3.patch

10/05/2012  16:51             1,375 414-gcc-atxmega64b1.patch

10/05/2012  16:51             1,376 416-gcc-atxmega64a4u.patch

10/05/2012  16:51             1,390 417-gcc-atxmega128d4.patch

10/05/2012  16:51             3,745 419-gcc-atxmega16c4_32c4_128c3_256c3.patch

10/05/2012  16:51             1,344 420-gcc-atxmega384d3.patch

10/05/2012  16:51             1,391 424-gcc-atxmega192c3.patch

10/05/2012  16:51             1,335 426-gcc-atxmega64c3.patch

Code:

=================================================================================

_________________

ninevoltz9

Posted: Jun 06, 2012 - 06:39 PM

Joined: Feb 28, 2004
Posts: 976
Location: Ohio

binutils won't build for me with the patches applied, it fails on gas/config/tc-avr.c and bfd/elf32-avr.c with

Quote:

‘BFD_RELOC_AVR_7_LDS16’ undeclared

Something appears to be wrong with the patch 503-binutils-avrtc193-tiny.patch. It builds fine if I omit that patch.

_________________
I like cats, too. Let's exchange recipes.

SprinterSB

Posted: Jun 06, 2012 - 08:25 PM

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

ninevoltz9 wrote:

binutils won't build for me with the patches applied, it fails on gas/config/tc-avr.c and bfd/elf32-avr.c with

Quote:

‘BFD_RELOC_AVR_7_LDS16’ undeclared

Something appears to be wrong with the patch 503-binutils-avrtc193-tiny.patch. It builds fine if I omit that patch.

The patch is incomplete: It adds new relocs in bfd/reloc.c but does not supply the induced changes to the auto-generated files. Notice that the new relocs are introduced in comments (sic!) that must be parsed by the generator tools!

Run make headers in bfd.

ninevoltz9

Posted: Jun 07, 2012 - 12:53 PM

Joined: Feb 28, 2004
Posts: 976
Location: Ohio

That fixed it. Here's an updated binutils patch that fixes the issue.

_________________
I like cats, too. Let's exchange recipes.

ninevoltz9

Posted: Jun 07, 2012 - 01:09 PM

Joined: Feb 28, 2004
Posts: 976
Location: Ohio

Here are the complete Linux toolchain packages I built for Fedora/RHEL6 with source RPMS and source archives, for anyone who's interested.

https://www.hindleyelectronics.com/AVR_linux_toolchain/

_________________
I like cats, too. Let's exchange recipes.

Jump to:

All times are GMT + 1 Hour

Previous 1, 2, 3, 4, 5 All

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

AVRFreaks.net

Search