On 15/05/18 22:03, Freddie Chopin wrote:
>
> I cannot reproduce this here ); Don't get me wrong - if there's a
> "free" way to improve code size/speed with some compiler flags which I
> did not use previously, then I'm very much interested, however in my
> particular case the best result (size-wi
On May 15, 2018 10:12:45 PM GMT+02:00, Freddie Chopin
wrote:
>On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
>> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
>> > As to a workaround for the ld bug you can try keeping all .debug_*
>> > sections. IIRC 2.30 has the bug fixed (on
On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> > As to a workaround for the ld bug you can try keeping all .debug_*
> > sections. IIRC 2.30 has the bug fixed (on the branch).
>
> Indeed - "keeping" all the debug sections is a
On Mon, 2018-05-14 at 16:34 +0200, David Brown wrote:
> Interesting. Making these sections and then using gc-sections should
> only remove code that is not used - LTO should do that anyway.
My guess - expressed in the other e-mail to the list - is that the
things LTO cannot remove but --gc-sectio
On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> That's an interesting result. Do you have any non-LTO objects?
> Basically I'm curious what ld eliminates that gcc with LTO doesn't.
Whole project is compiled with LTO, part of the project is provided as
a library (which is archived with
On 11/05/18 17:49, Freddie Chopin wrote:
> On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
>> For the Cortex-M devices (and probably many other RISC targets),
>> -fdata-sections comes at a big cost - it effectively blocks
>> -fsection-anchors and makes access to file-static data a lot bigger.
On May 11, 2018 5:49:44 PM GMT+02:00, Freddie Chopin
wrote:
>On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
>> For the Cortex-M devices (and probably many other RISC targets),
>> -fdata-sections comes at a big cost - it effectively blocks
>> -fsection-anchors and makes access to file-stati
On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
> For the Cortex-M devices (and probably many other RISC targets),
> -fdata-sections comes at a big cost - it effectively blocks
> -fsection-anchors and makes access to file-static data a lot bigger.
> People often use -fdata-sections and -ffunc
On Fri, 2018-05-11 at 11:19 +0200, Richard Biener wrote:
> Hmm, can you try without --gc-sections? "Old" GNU ld versions have
> a bug that wrecks debug info (sourceware PR20882).
Yes - you are right. Without --gc-sections the errors are gone. The bug
was marked as resolved and fixed a year ago, h
On 11/05/18 11:19, Richard Biener wrote:
> On Thu, May 10, 2018 at 11:32 PM, Freddie Chopin wrote:
>> Hi!
>>
>> In one of my embedded projects I have an option to enable LTO. This was
>> working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0
>> (and binutils 2.30) - with the same set
On Thu, May 10, 2018 at 11:32 PM, Freddie Chopin wrote:
> Hi!
>
> In one of my embedded projects I have an option to enable LTO. This was
> working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0
> (and binutils 2.30) - with the same set of options - I see something
> like this
>
> --
11 matches
Mail list logo
