Thank you for the BZ link. Actually my problem was configuring GCC build
with
--with-build-config=bootstrap-lto and --enable-lto. I'm researching
compiler theory (reading the Dragon book now) and I would like to contribute
to our
lovely compiler(s), specially gfortran.
On Mon, Sep 16, 2024 at 10:0
On Sun, 2024-09-15 at 15:20 +0330, Ghorban M. Tavakoly via Gcc wrote:
> Hi
>
> On Sun, Sep 15, 2024 at 11:59 AM Jan Hubicka wrote:
>
> > > On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> > > wrote:
> > > >
> > > > > > Is there any change to have some LTO progress indicator
> > >
"Ghorban M. Tavakoly via Gcc" writes:
>
> I need LTO. Is there a way to have LTO in GCC, without LTOing the GCC
> itself? This way my builds will be many times faster.
LTO can be used without LTOing gcc itself. It is normally built by
default if the target supports it.
-Andi
Hi, and thank you for your answer.
Is there an option to have LTO in the final GCC, but without using LTO in
compiling GCC itself?
On Sun, Sep 15, 2024 at 9:00 AM Richard Biener
wrote:
> On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> wrote:
> >
> > >> Is there any change to have
Hi
On Sun, Sep 15, 2024 at 11:59 AM Jan Hubicka wrote:
> > On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> > wrote:
> > >
> > > >> Is there any change to have some LTO progress indicator information
> in
> > > upstream GCC output? Do I need to report a bug?
> > > Is there any chan
> On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> wrote:
> >
> > >> Is there any change to have some LTO progress indicator information in
> > upstream GCC output? Do I need to report a bug?
> > Is there any chance ... (sorry for typo)
>
> You can add -Q to the command line which ma
On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
wrote:
>
> >> Is there any change to have some LTO progress indicator information in
> upstream GCC output? Do I need to report a bug?
> Is there any chance ... (sorry for typo)
You can add -Q to the command line which makes GCC output s
>> Is there any change to have some LTO progress indicator information in
upstream GCC output? Do I need to report a bug?
Is there any chance ... (sorry for typo)
On Sat, Sep 14, 2024 at 2:41 PM Ghorban M. Tavakoly
wrote:
> I build GCC from git repo regularly. Unfortunately my system is old and
On Fri, Jan 13, 2023 at 08:15:34AM +0100, Richard Biener wrote:
> On Thu, Jan 12, 2023 at 5:35 PM Richard Biener
> wrote:
> >
> >
> >
> > > Am 12.01.2023 um 17:18 schrieb Paul Iannetta via Gcc :
> > >
> > > Hi,
> > >
> > > I was investigating an ICE (in our yet to be upstreamed back-end which
> >
On Thu, Jan 12, 2023 at 5:35 PM Richard Biener
wrote:
>
>
>
> > Am 12.01.2023 um 17:18 schrieb Paul Iannetta via Gcc :
> >
> > Hi,
> >
> > I was investigating an ICE (in our yet to be upstreamed back-end which
> > has native support for float16), on "gcc.dg/torture/float16-complex.c"
> > when com
> Am 12.01.2023 um 17:18 schrieb Paul Iannetta via Gcc :
>
> Hi,
>
> I was investigating an ICE (in our yet to be upstreamed back-end which
> has native support for float16), on "gcc.dg/torture/float16-complex.c"
> when compiled with lto:
>
> ./gcc/build/gcc/xgcc -B./gcc/build/gcc/
> ./gcc/
On Wed, 21 Oct 2020 at 16:10, Richard Biener wrote:
>
> On Wed, Oct 21, 2020 at 12:04 PM Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 24 Sep 2020 at 16:44, Richard Biener
> > wrote:
> > >
> > > On Thu, Sep 24, 2020 at 12:36 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Wed, 23 Sep 202
On Wed, Oct 21, 2020 at 12:04 PM Prathamesh Kulkarni
wrote:
>
> On Thu, 24 Sep 2020 at 16:44, Richard Biener
> wrote:
> >
> > On Thu, Sep 24, 2020 at 12:36 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 23 Sep 2020 at 16:40, Richard Biener
> > > wrote:
> > > >
> > > > On Wed, Sep 23, 2
On Thu, 24 Sep 2020 at 16:44, Richard Biener wrote:
>
> On Thu, Sep 24, 2020 at 12:36 PM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 23 Sep 2020 at 16:40, Richard Biener
> > wrote:
> > >
> > > On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Wed, 23 Sep 202
On Thu, Sep 24, 2020 at 12:36 PM Prathamesh Kulkarni
wrote:
>
> On Wed, 23 Sep 2020 at 16:40, Richard Biener
> wrote:
> >
> > On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 23 Sep 2020 at 13:22, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Sep 22, 2
On Wed, 23 Sep 2020 at 16:40, Richard Biener wrote:
>
> On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 23 Sep 2020 at 13:22, Richard Biener
> > wrote:
> > >
> > > On Tue, Sep 22, 2020 at 6:25 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Tue, 22 Sep 2020
On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni
wrote:
>
> On Wed, 23 Sep 2020 at 13:22, Richard Biener
> wrote:
> >
> > On Tue, Sep 22, 2020 at 6:25 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Tue, 22 Sep 2020 at 16:36, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Sep 22, 20
On Wed, 23 Sep 2020 at 13:22, Richard Biener wrote:
>
> On Tue, Sep 22, 2020 at 6:25 PM Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 22 Sep 2020 at 16:36, Richard Biener
> > wrote:
> > >
> > > On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Tue, 22 Sep 2020
On Tue, Sep 22, 2020 at 6:25 PM Prathamesh Kulkarni
wrote:
>
> On Tue, 22 Sep 2020 at 16:36, Richard Biener
> wrote:
> >
> > On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Tue, 22 Sep 2020 at 12:56, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Sep 22, 20
On Tue, 22 Sep 2020 at 16:36, Richard Biener wrote:
>
> On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 22 Sep 2020 at 12:56, Richard Biener
> > wrote:
> > >
> > > On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 21 Sep 2020
On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni
wrote:
>
> On Tue, 22 Sep 2020 at 12:56, Richard Biener
> wrote:
> >
> > On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 21 Sep
On Tue, 22 Sep 2020 at 12:56, Richard Biener wrote:
>
> On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 21 Sep 2020 at 15:19, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Fri, 4 Sep 2020
On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
wrote:
>
> On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 21 Sep 2020 at 15:19, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Fri, 4 Sep 2020 at 17:08, Alexander Monakov wrote:
> > > >
> > > > > I obtained perf stat
On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni
wrote:
>
> On Mon, 21 Sep 2020 at 15:19, Prathamesh Kulkarni
> wrote:
> >
> > On Fri, 4 Sep 2020 at 17:08, Alexander Monakov wrote:
> > >
> > > > I obtained perf stat results for following benchmark runs:
> > > >
> > > > -O2:
> > > >
> > > >
On Mon, 21 Sep 2020 at 15:19, Prathamesh Kulkarni
wrote:
>
> On Fri, 4 Sep 2020 at 17:08, Alexander Monakov wrote:
> >
> > > I obtained perf stat results for following benchmark runs:
> > >
> > > -O2:
> > >
> > > 7856832.692380 task-clock (msec) #1.000 CPUs utilized
> > >
On Fri, 4 Sep 2020 at 17:08, Alexander Monakov wrote:
>
> > I obtained perf stat results for following benchmark runs:
> >
> > -O2:
> >
> > 7856832.692380 task-clock (msec) #1.000 CPUs utilized
> > 3758 context-switches #0.000 K/sec
> >
> I obtained perf stat results for following benchmark runs:
>
> -O2:
>
> 7856832.692380 task-clock (msec) #1.000 CPUs utilized
> 3758 context-switches #0.000 K/sec
> 40 cpu-migrations #0
On Mon, 31 Aug 2020 at 16:53, Prathamesh Kulkarni
wrote:
>
> On Fri, 28 Aug 2020 at 17:33, Alexander Monakov wrote:
> >
> > On Fri, 28 Aug 2020, Prathamesh Kulkarni via Gcc wrote:
> >
> > > I wonder if that's (one of) the main factor(s) behind slowdown or it's
> > > not too relevant ?
> >
> > Pro
> Thanks for the suggestions.
> Is it possible to modify assembly files emitted after ltrans phase ?
> IIUC, the linker invokes lto1 twice, for wpa and ltrans,and then links
> the obtained object files which doesn't make it possible to hand edit
> assembly files post ltrans ?
> In particular, I wan
On Fri, 28 Aug 2020 at 17:33, Alexander Monakov wrote:
>
> On Fri, 28 Aug 2020, Prathamesh Kulkarni via Gcc wrote:
>
> > I wonder if that's (one of) the main factor(s) behind slowdown or it's
> > not too relevant ?
>
> Probably not. Some advice to make your search more directed:
>
> Pass '-n' to '
On Fri, 28 Aug 2020 at 17:27, Richard Biener wrote:
>
> On Fri, Aug 28, 2020 at 1:17 PM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 26 Aug 2020 at 16:50, Richard Biener
> > wrote:
> > >
> > > On Wed, Aug 26, 2020 at 12:34 PM Prathamesh Kulkarni via Gcc
> > > wrote:
> > > >
> > > > Hi,
> > > >
On Fri, 28 Aug 2020, Prathamesh Kulkarni via Gcc wrote:
> I wonder if that's (one of) the main factor(s) behind slowdown or it's
> not too relevant ?
Probably not. Some advice to make your search more directed:
Pass '-n' to 'perf report'. Relative sample ratios are hard to reason about
when they
On Fri, Aug 28, 2020 at 1:17 PM Prathamesh Kulkarni
wrote:
>
> On Wed, 26 Aug 2020 at 16:50, Richard Biener
> wrote:
> >
> > On Wed, Aug 26, 2020 at 12:34 PM Prathamesh Kulkarni via Gcc
> > wrote:
> > >
> > > Hi,
> > > We're seeing a consistent regression >10% on calculix with -O2 -flto vs
> >
On Wed, 26 Aug 2020 at 16:50, Richard Biener wrote:
>
> On Wed, Aug 26, 2020 at 12:34 PM Prathamesh Kulkarni via Gcc
> wrote:
> >
> > Hi,
> > We're seeing a consistent regression >10% on calculix with -O2 -flto vs -O2
> > on aarch64 in our validation CI. I tried to investigate this issue a
> > bi
On Wed, Aug 26, 2020 at 12:34 PM Prathamesh Kulkarni via Gcc
wrote:
>
> Hi,
> We're seeing a consistent regression >10% on calculix with -O2 -flto vs -O2
> on aarch64 in our validation CI. I tried to investigate this issue a
> bit, and it seems the regression comes from inlining of orthonl into
>
On 24/07/2020 17:43, Erick Ochoa wrote:
> This patchset brings back struct reorg to GCC.
>
> We’ve been working on improving cache utilization recently and would
> like to share our current implementation to receive some feedback on it.
>
> Essentially, we’ve implemented the following components:
On Mon, Jul 27, 2020 at 9:03 AM Christoph Müllner
wrote:
>
> Hi Richard,
>
> On 7/27/20 2:36 PM, Richard Biener wrote:
> > On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
> > wrote:
> >>
> >> This patchset brings back struct reorg to GCC.
> >>
> >> We’ve been working on improving cache utilization re
On Mon, Jul 27, 2020 at 2:59 PM Christoph Müllner
wrote:
>
> Hi Richard,
>
> On 7/27/20 2:36 PM, Richard Biener wrote:
> > On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
> > wrote:
> >>
> >> This patchset brings back struct reorg to GCC.
> >>
> >> We’ve been working on improving cache utilization re
On Mon, Jul 27, 2020 at 02:52:21PM +0200, Erick Ochoa wrote:
> I will work on making this more readable. I understand your comments and you
> are right. I am currently in the process of writing a human-readable PDF
> with an overview of this. There is already a (somewhat hurried) version of
> this
Hi Richard,
On 7/27/20 2:36 PM, Richard Biener wrote:
> On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
> wrote:
>>
>> This patchset brings back struct reorg to GCC.
>>
>> We’ve been working on improving cache utilization recently and would
>> like to share our current implementation to receive some
On 27/07/2020 14:36, Richard Biener wrote:
On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
wrote:
This patchset brings back struct reorg to GCC.
We’ve been working on improving cache utilization recently and would
like to share our current implementation to receive some feedback on it.
Essent
On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
wrote:
>
> This patchset brings back struct reorg to GCC.
>
> We’ve been working on improving cache utilization recently and would
> like to share our current implementation to receive some feedback on it.
>
> Essentially, we’ve implemented the following
On December 6, 2019 5:46:25 PM GMT+01:00, Erick Ochoa
wrote:
>
>
>On 2019-12-06 5:50 a.m., Richard Biener wrote:
>> On Wed, Dec 4, 2019 at 6:03 PM Erick Ochoa
>> wrote:
>>>
>>>
>>>
>>> On 2019-12-04 7:52 a.m., Richard Biener wrote:
On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
wrote:
>>
On 2019-12-06 5:50 a.m., Richard Biener wrote:
> On Wed, Dec 4, 2019 at 6:03 PM Erick Ochoa
> wrote:
>>
>>
>>
>> On 2019-12-04 7:52 a.m., Richard Biener wrote:
>>> On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
>>> wrote:
Hi,
I am trying to use the function: `cgraph_node::get_
On Wed, Dec 4, 2019 at 6:03 PM Erick Ochoa
wrote:
>
>
>
> On 2019-12-04 7:52 a.m., Richard Biener wrote:
> > On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
> > wrote:
> >>
> >> Hi,
> >>
> >> I am trying to use the function: `cgraph_node::get_untransformed_body`
> >> during
> >> the wpa stage of a S
On 2019-12-04 7:52 a.m., Richard Biener wrote:
> On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
> wrote:
>>
>> Hi,
>>
>> I am trying to use the function: `cgraph_node::get_untransformed_body` during
>> the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function
>
> I think SIMPL
On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
wrote:
>
> Hi,
>
> I am trying to use the function: `cgraph_node::get_untransformed_body` during
> the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function
I think SIMPLE_IPA_PASSes have no "WPA" stage but run at LTRANS time
(WPA tr
CC'ing Honza and Martin.
Have you had a chance to try this?
On Sat, Sep 14, 2019 at 2:39 PM Jason Merrill wrote:
>
> How does this do for you?
>
> On Thu, Jul 4, 2019 at 7:15 AM Matthias Klose wrote:
> >
> > I'm running into some issues building LTO+profiled enabled configurations in
> > some constrained build environme
How does this do for you?
On Thu, Jul 4, 2019 at 7:15 AM Matthias Klose wrote:
>
> I'm running into some issues building LTO+profiled enabled configurations in
> some constrained build environment called buildds, having four cores and 16GB
> of
> RAM.
>
> configured for all frontends (maximum nu
Hi,
On Wed, Dec 05 2018, Michael Ploujnikov wrote:
> Hi,
>
> I'm trying to write a testcase to reproduce duplicate clone symbols
> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 I
> started with a testcase that is known to have constprop clones and
> split it into two object files:
On 2018-12-05 2:38 p.m., Michael Ploujnikov wrote:
> Hi,
>
> I'm trying to write a testcase to reproduce duplicate clone symbols
> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 I
> started with a testcase that is known to have constprop clones and
> split it into two object files:
On 06/19/2018 04:37 AM, Thomas Schwinge wrote:
Hi!
In case that you have not yet found it:
On Mon, 11 Jun 2018 12:19:23 -0600, Martin Sebor wrote:
I've been noticing a number of failures in LTO (and some other)
tests in my x86_64-builds most of which don't appear in results
reported on gcc-te
On Mon, 2018-06-18 at 10:22 -0600, Martin Sebor wrote:
> David,
>
> Have you been able to reproduce the jit test failures below on
> tor? Is there some information I can get you from my builds to
> help you debug it?
Thanks for pointing it out. I've started seeing it on my machine.
They appear
Hi!
In case that you have not yet found it:
On Mon, 11 Jun 2018 12:19:23 -0600, Martin Sebor wrote:
> I've been noticing a number of failures in LTO (and some other)
> tests in my x86_64-builds most of which don't appear in results
> reported on gcc-testresults (all those on lines that start wit
David,
Have you been able to reproduce the jit test failures below on
tor? Is there some information I can get you from my builds to
help you debug it?
Thanks
Martin
On 06/11/2018 01:20 PM, Martin Sebor wrote:
On 06/11/2018 12:34 PM, David Malcolm wrote:
On Mon, 2018-06-11 at 12:19 -0600, Ma
On 06/11/2018 01:20 PM, Martin Sebor wrote:
> On 06/11/2018 12:34 PM, David Malcolm wrote:
>> On Mon, 2018-06-11 at 12:19 -0600, Martin Sebor wrote:
>>> I've been noticing a number of failures in LTO (and some other)
>>> tests in my x86_64-builds most of which don't appear in results
>>> reported o
On 06/11/2018 12:34 PM, David Malcolm wrote:
On Mon, 2018-06-11 at 12:19 -0600, Martin Sebor wrote:
I've been noticing a number of failures in LTO (and some other)
tests in my x86_64-builds most of which don't appear in results
reported on gcc-testresults (all those on lines that start with
with
On Mon, 2018-06-11 at 12:19 -0600, Martin Sebor wrote:
> I've been noticing a number of failures in LTO (and some other)
> tests in my x86_64-builds most of which don't appear in results
> reported on gcc-testresults (all those on lines that start with
> with the '!' below) and that I don't recall
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
>
> --
On Sun, Jan 15, 2017 at 4:15 PM, Andrew Pinski wrote:
> On Sun, Jan 15, 2017 at 4:09 PM, kugan
> wrote:
>>
>>
>> On 15/01/17 15:57, Andrew Pinski wrote:
>>>
>>> Just this is just an FYI until I reduce the testcases but 5 benchmarks
>>> in SPEC CPU 2006 with fortran code is causing an ICE on
>>> a
On Sun, Jan 15, 2017 at 4:09 PM, kugan
wrote:
>
>
> On 15/01/17 15:57, Andrew Pinski wrote:
>>
>> Just this is just an FYI until I reduce the testcases but 5 benchmarks
>> in SPEC CPU 2006 with fortran code is causing an ICE on
>> aarch64-linux-gnu with -Ofast -flto -mcpu=thunderx2t99
>> -fno-aggr
On 15/01/17 15:57, Andrew Pinski wrote:
Just this is just an FYI until I reduce the testcases but 5 benchmarks
in SPEC CPU 2006 with fortran code is causing an ICE on
aarch64-linux-gnu with -Ofast -flto -mcpu=thunderx2t99
-fno-aggressive-loop-optimizations -funroll-loops:
lto1: internal compile
On Wed, 11 Jan 2017, Richard Biener wrote:
> > WPA re-streams packed function bodies as-is, so anything referred to
> > from within just the body won't be subject to mode remapping; I think
> > only modes of toplevel declarations and functions' arguments will be
> > remapped. And I believe it woul
On Tue, 10 Jan 2017, Alexander Monakov wrote:
> On Tue, 10 Jan 2017, Richard Biener wrote:
> > In general I think they should match. But without seeing concrete
> > examples of where they do not I can't comment on whether such exceptions
> > make sense. For example if you adjust a DECLs alignme
Hi
In general I think they should match. But without seeing concrete
examples of where they do not I can't comment on whether such
exceptions
make sense. For example if you adjust a DECLs alignment and then
re-layout it I'd expect you might get a non-BLKmode mode for an
aggregate in some cir
On Tue, 10 Jan 2017, Richard Biener wrote:
> In general I think they should match. But without seeing concrete
> examples of where they do not I can't comment on whether such exceptions
> make sense. For example if you adjust a DECLs alignment and then
> re-layout it I'd expect you might get a n
On Mon, 9 Jan 2017, Alexander Monakov wrote:
> On Wed, 4 Jan 2017, Richard Biener wrote:
> > My suggestion at that time isn't likely working in practice due to the
> > limitations Jakub outlines below. The situation is a bit unfortunate
> > but expect to run into more host(!) dependences in the L
On Wed, 4 Jan 2017, Richard Biener wrote:
> My suggestion at that time isn't likely working in practice due to the
> limitations Jakub outlines below. The situation is a bit unfortunate
> but expect to run into more host(!) dependences in the LTO bytecode.
> Yes, while it would be nice to LTO x86_
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> On Mon, Jan 02, 2017 at 09:49:55PM +0300, Alexander Monakov wrote:
> > On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> > > If the host has long double the same as double, sure, PTX can use its
> > > native
> > > DFmode even for long double. But otherwise, th
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> On Fri, Dec 30, 2016 at 08:40:11PM +0300, Alexander Monakov wrote:
> > Hello, Richard, Jakub, community,
> >
> > May I join/restart the old discussion about machine mode remapping at LTO
> > stream-in time. To recap, when offloading to NVPTX was introdu
On Mon, Jan 02, 2017 at 10:38:54PM +0300, Alexander Monakov wrote:
> On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> > On Mon, Jan 02, 2017 at 09:49:55PM +0300, Alexander Monakov wrote:
> > > On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> > > > If the host has long double the same as double, sure, PTX can u
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> On Mon, Jan 02, 2017 at 09:49:55PM +0300, Alexander Monakov wrote:
> > On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> > > If the host has long double the same as double, sure, PTX can use its
> > > native
> > > DFmode even for long double. But otherwise, the
On Mon, Jan 02, 2017 at 09:49:55PM +0300, Alexander Monakov wrote:
> On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> > If the host has long double the same as double, sure, PTX can use its native
> > DFmode even for long double. But otherwise, the storage must be
> > transferable between accelerator an
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> If the host has long double the same as double, sure, PTX can use its native
> DFmode even for long double. But otherwise, the storage must be
> transferable between accelerator and host.
Hm, sorry, the 'must' is not obvious to me: is it known that the O
On Mon, Jan 02, 2017 at 06:38:28PM +0300, Alexander Monakov wrote:
> I wonder if it's possible to have a small tag in tree types to distinguish
> between binary/decimal/fixed-point types. For prototyping, I was thinking
> about just looking at the type name, because non-ieee-binary types have an
>
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> In my view mode is essential part of the type system. It (sadly, but still)
> participates in many ABI decisions, but more importantly especially for
> floating point types it is the main source of information of what the type
> actually is, as just size
On Fri, Dec 30, 2016 at 08:40:11PM +0300, Alexander Monakov wrote:
> Hello, Richard, Jakub, community,
>
> May I join/restart the old discussion about machine mode remapping at LTO
> stream-in time. To recap, when offloading to NVPTX was introduced, there
> was a problem due to differences in the
Hi,
I have the same error while compiling complex project with private backend.
Are there some patches for this? Some advices where to dig?
Context is the following: there is foo that is external and
bar.constprop that is internal, but is in foo's comdat list. When
add_symbol_to_partitition recu
> >
> > typeinfo seems to be a weak object symbol
> > which is known to be broken with lto, so
> > this may be related to:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271
This PR is about quite speicfic use of weak symbols, the way weaks are used
in C++ (to unify multiple defintions) sh
On 23/05/16 14:24, MM wrote:
> On 23 May 2016 at 12:53, Szabolcs Nagy wrote:
>> On 23/05/16 12:36, MM wrote:
>>> Hello,
>>>
>>> g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
>>> GNU gold (version 2.25-17.fc23) 1.11
>>> I successfully link a executable in debug mode (-std=c++11 -g) but not in
>>> rele
On 23 May 2016 at 12:53, Szabolcs Nagy wrote:
> On 23/05/16 12:36, MM wrote:
>> Hello,
>>
>> g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
>> GNU gold (version 2.25-17.fc23) 1.11
>> I successfully link a executable in debug mode (-std=c++11 -g) but not in
>> release mode (-std=c++11 -flto -O3). All s
On 23/05/16 12:36, MM wrote:
> Hello,
>
> g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
> GNU gold (version 2.25-17.fc23) 1.11
> I successfully link a executable in debug mode (-std=c++11 -g) but not in
> release mode (-std=c++11 -flto -O3). All sources are compiled with the same
> option. Shared lib
On 04/17/2015 10:49 AM, Richard Biener wrote:
On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene wrote:
See:
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksu
On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene wrote:
> See:
>
> https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html
>
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Bootstrap comparison f
On Mon, 13 Apr 2015, Jakub Jelinek wrote:
> On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote:
> > [ Patch elided ]
> >
> > The patch applied cleanly - this is what I got as a result:
> >
> > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html
> >
> > I hope this is useful.
>
On 04/13/2015 06:00 PM, Trevor Saunders wrote:
On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote:
On 04/11/2015 01:33 AM, Jan Hubicka wrote:
On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote:
On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote:
Like this:
https
On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote:
> [ Patch elided ]
>
> The patch applied cleanly - this is what I got as a result:
>
> https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html
>
> I hope this is useful.
Looks like the http://gcc.gnu.org/ml/gcc-patches/2014-08/msg
On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote:
> On 04/11/2015 01:33 AM, Jan Hubicka wrote:
>
> >>On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote:
> >>>On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote:
> Like this:
>
> https://gcc.gnu.org/ml/gcc-
On 04/11/2015 01:33 AM, Jan Hubicka wrote:
On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote:
On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote:
Like this:
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html
ODR rears its head again ...
huh, why is c/c-lan
1 - 100 of 588 matches
Mail list logo
