my experience with
> Linux kernel and CPython APIs may come of use in integrating the checker
> there.
>
> I’m hence looking into both for now, and intend to decide as per the
> information I get for LTO hereon.
Thank you for your interest!
>
> Thanks and regards,
> Yatindra Indoria
the GCC codebase. And my experience with
Linux kernel and CPython APIs may come of use in integrating the checker
there.
I’m hence looking into both for now, and intend to decide as per the
information I get for LTO hereon.
Thanks and regards,
Yatindra Indoria
Hi all,
I'd like to continue the discussion on teaching GCC to optimise code layout
for locality between callees and callers. This is work that we've been doing
at NVIDIA, primarily Prachi Godbole (CC'ed) and myself.
This is a follow-up to the discussion we had at GNU Cauldron at
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
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:
> > > >
> > > > >
"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
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 outpu
> 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)
>
>
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 whic
>> 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 i
I build GCC from git repo regularly. Unfortunately my system is old and a
full GCC build takes about 30 hours. I learnt that the maximum build time
spent is in LTO. I wrote a simple shell script to check LTO progress:
#!/bin/sh
AWKP='
BEGIN { RS=" " ; w = COLS - 19 }
END { prog
On 28/09/2023 20:59, Toon Moene wrote:
On 9/28/23 21:26, Jakub Jelinek wrote:
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a
year) and
at other times as well.
Though, admittedly GCC is the single
Hi Jakub,
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Hm, that makes LTO not very well suited for libraries...
Though, admittedly GCC is the single package that
On Thu, Sep 28, 2023 at 4:00 PM Toon Moene wrote:
> On 9/28/23 21:26, Jakub Jelinek wrote:
>
> > It is worse than that, usually the LTO format changes e.g. any time any
> > option or parameter is added on a release branch (several times a year)
> and
> > at othe
On 9/28/23 21:26, Jakub Jelinek wrote:
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Though, admittedly GCC is the single package that actually could get away
with LTO
On Thu, Sep 28, 2023 at 09:03:39PM +0200, Toon Moene wrote:
> > > The full question of "lto-ing" run time libraries is more
> > > complicated than just "whether it works" as those who attended the
> > > BoF will recall.
> >
> > I didn
On 9/28/23 07:33, Thomas Koenig wrote:
Hi Toon,
[ I wrote: ]
The full question of "lto-ing" run time libraries is more complicated
than just "whether it works" as those who attended the BoF will recall.
I didn't attend the Cauldron (but that discussion would h
On Thu, Sep 28, 2023 at 09:29:02AM +0200, Tobias Burnus wrote:
> the following works for me. I have only tried a normal build (where it
> does silence the same warning) and not an LTO build and I just believed
> the comment - see attached patch. Comments?
>
> On 28.09.23 08:25, Ric
Hi all,
the following works for me. I have only tried a normal build (where it
does silence the same warning) and not an LTO build and I just believed
the comment - see attached patch. Comments?
On 28.09.23 08:25, Richard Biener via Fortran wrote:
This particular place in libgfortran has
On Wed, Sep 27, 2023 at 11:28 PM Richard Biener via Fortran
wrote:
>
> On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran
> wrote:
> >
> >
> >
> > On 9/27/23 12:21, Toon Moene wrote:
> >
> > >
> > > The lto-ing of libgfortran did succe
On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran
wrote:
>
>
>
> On 9/27/23 12:21, Toon Moene wrote:
>
> >
> > The lto-ing of libgfortran did succeed, because I did get a new warning:
> >
> > gfortran -O3 -flto -flto-partition=none -static -o xlint
Hi Toon,
During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the
possibility (and hazards) of building the run time libraries for various
compilers with -flto, enabling an -flto -static linking of programs with
the run time library available during link time optimizat
On 9/27/23 12:21, Toon Moene wrote:
The lto-ing of libgfortran did succeed, because I did get a new warning:
gfortran -O3 -flto -flto-partition=none -static -o xlintstrfz zchkrfp.o
zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o
zlaipd.o zlarhs.o zsbmv.o zget04.o
Hi all,
During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the
possibility (and hazards) of building the run time libraries for various
compilers with -flto, enabling an -flto -static linking of programs with
the run time library available during link time optimizat
Hi!
Four things:
On 2023-09-10T23:25:06+0200, Jan Hubicka via Gcc wrote:
>> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote:
>> > I noticed that adding incremental LTO was a GSoC project that was not
>> > claimed this cycle (
>> > https://summerof
> Hi!
>
> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote:
> > I noticed that adding incremental LTO was a GSoC project that was not
> > claimed this cycle (
> > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
> &g
Ah, I see. I was interested as a contributor but outside of the official
GSoC program. But I'm assuming that because there is a talk on incremental
LTO, it has already been implemented, correct? Other than that, thanks for
your help!
On Fri, Sep 8, 2023 at 3:20 AM Thomas Schwinge
wrote:
Hi!
On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote:
> I noticed that adding incremental LTO was a GSoC project that was not
> claimed this cycle (
> https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
> I was curious about working on
Hi,
I noticed that adding incremental LTO was a GSoC project that was not
claimed this cycle (
https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
I was curious about working on this project, but wanted to check on the
state of the project. Has it already
ere are few comments on the proposal:
> >
> > > The current Implementation of GCC first write the IL representation
> > along with other section in an assembly file and then the assembler is used
> > to convert it into LTO object files. Sections containing different IL
> &
ogle.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing
>
> Here are few comments on the proposal:
>
> > The current Implementation of GCC first write the IL representation
> along with other section in an assembly file and then the assembler is used
>
DpwFUtts/edit?usp=sharing
Here are few comments on the proposal:
> The current Implementation of GCC first write the IL representation along
> with other section in an assembly file and then the assembler is used to
> convert it into LTO object files. Sections containing different I
od that the
>> > file simple-object.c is used to handle the object file format. However,
>> > this file does not contain all the architecture information required for
>> > LTO object files, so the workaround used in the patch is to read the
>> > crtbegin.o file a
Sorry, I messed subject in my previous two emails :( so I am sending it
again.
I have completed a draft proposal for this project. I will appreciate Jan,
Martin, or anybody else feedback on the same.
Here is the link to my proposal
https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs
g through the patch and simple-object.c I understood that the
> > file simple-object.c is used to handle the object file format. However,
> > this file does not contain all the architecture information required for
> > LTO object files, so the workaround used in the patch is to read
Tue, 4 Apr 2023 at 04:35, Jan Hubicka wrote:
> Hello,
> > While going through the patch and simple-object.c I understood that the
> > file simple-object.c is used to handle the object file format. However,
> > this file does not contain all the architecture information requir
Hello,
> While going through the patch and simple-object.c I understood that the
> file simple-object.c is used to handle the object file format. However,
> this file does not contain all the architecture information required for
> LTO object files, so the workaround used in the patc
While going through the patch and simple-object.c I understood that the
file simple-object.c is used to handle the object file format. However,
this file does not contain all the architecture information required for
LTO object files, so the workaround used in the patch is to read the
crtbegin.o
Hii Everyone,
I had already expressed my interest in the " Bypass assembler when
generating LTO object files" project and making a proposal for the same. I
know I should have done it earlier but I was admitted to the hospital for
past few days :(.
I have a few doubts.
1)
"One prob
Hello,
we are delighted you found contributing to GCC interesting.
On Tue, Mar 28 2023, Hathik H via Gcc wrote:
> Dear Jan Hubicka,
>
> My name is Hathik , and I'm a student . I'm writing to express my interest
> in the GCC LTO , and to ask for your guidance as I prepare
Dear Jan Hubicka,
My name is Hathik , and I'm a student . I'm writing to express my interest
in the GCC LTO , and to ask for your guidance as I prepare my application.
I have some experience in C/C++ programming and a strong interest in
low-level systems programming, and I believe
>
> On Tue, Mar 14, 2023 at 10:48 PM Martin Jambor wrote:
>
>> Hello,
>>
>> We are delighted you found looking into GCC interesting.
>>
>> On Thu, Mar 09 2023, Madhu patel via Gcc wrote:
>> > Hi Jan,
>> >
>> > I'm interested in work
Hello,
We are delighted you found looking into GCC interesting.
On Thu, Mar 09 2023, Madhu patel via Gcc wrote:
> Hi Jan,
>
> I'm interested in working on the project `Bypass assembler when generating
> LTO object files` in the GCC organization through GSoC'2023.
Great
Hi Jan,
I'm interested in working on the project `Bypass assembler when generating
LTO object files` in the GCC organization through GSoC'2023.
I am Madhu Patel, a fourth-year B.Tech. student in Computer Science at
IGDTUW, with a CGPA of 8.7/10. I have previously interned at Adobe Ind
On Fri, 2023-03-03 at 19:28 +0100, Jan Hubicka via Gcc wrote:
> Hello,
> > Hi! I've been interested in compiler development for a while, and
> > would love to
> > work with any of you as part of GSoC, or even just as a side-
> > project on my own.
> >
> > I'm an 18 year-old student going into univ
working on larger projects, as
> well
> as getting into real compilers.
>
> Of particular interest to me is the project idea labelled "Bypass assembler
> when
> generating LTO object files." I see that the project was taken last year, but
> I can find no sign of any cha
On 2/22/23 01:18, Florian Weimer via Gcc wrote:
Can we use the COMMON symbol __gnu_lto_slim to detect
-fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
plugin)?
We currently build the distribution with -ffat-lto-objects, and I want
to switch away from that. Packages will
dea labelled "Bypass assembler when
generating LTO object files." I see that the project was taken last year, but
I can find no sign of any changes committed to trunk
(`git shortlog --after=2022-01-01 | grep -i -E "lto|assembl(er|y)"` shows
nothing
related to this project) and
On 2/22/23 09:28, Florian Weimer via Gcc wrote:
> * Richard Biener:
>
>> On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc
>> wrote:
>>>
>>> Can we use the COMMON symbol __gnu_lto_slim to detect
>>> -fno-fat-lto-objects on contemporary GNU/Linu
On Wed, Feb 22, 2023 at 9:28 AM Florian Weimer wrote:
>
> * Richard Biener:
>
> > On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc
> > wrote:
> >>
> >> Can we use the COMMON symbol __gnu_lto_slim to detect
> >> -fno-fat-lto-object
* Richard Biener:
> On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc
> wrote:
>>
>> Can we use the COMMON symbol __gnu_lto_slim to detect
>> -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
>> plugin)?
>
> Yes.
Great, thanks.
&g
On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc wrote:
>
> Can we use the COMMON symbol __gnu_lto_slim to detect
> -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
> plugin)?
Yes.
> We currently build the distribution with -ffat-lto-objects, and I want
&
Can we use the COMMON symbol __gnu_lto_slim to detect
-fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
plugin)?
We currently build the distribution with -ffat-lto-objects, and I want
to switch away from that. Packages will need to opt in to
-ffat-lto-objects if static objects
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/
> > &g
n "gcc.dg/torture/float16-complex.c"
> > when compiled with lto:
> >
> > ./gcc/build/gcc/xgcc -B./gcc/build/gcc/
> > ./gcc/gcc/testsuite/gcc.dg/torture/float16-complex.c \
> > -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o
> > ./float16
> 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
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/gcc/testsuite/gcc.dg/torture/float16-complex.c \
-O2 -flto -fno-
ere that are
still valid and relevant, but I would be actually a bit careful with
that content.
If you're looking for high-level overview of LTO, unfortunately I can
only recommend videos:
- Honza's "Building openSUSE with GCC's link time optimization"
https://events.o
Hello,
I am interested in working in this project during my free time, is
understanding this https://gcc.gnu.org/wiki/LinkTimeOptimization
A good starting point
Mohamed
Hi everyone,
> > >
> > > Currently I'm looking into a wrong-code bug and would like to understand
> > > a certain optimization done by combine during local transformation.
> > > Without LTO I would simply debug cc1 and step through combine. However,
> > &
tand
> > a certain optimization done by combine during local transformation.
> > Without LTO I would simply debug cc1 and step through combine. However,
> > with LTO enabled AFAIK I have to debug lto1 instead. In order to get
> > the lto1 command line of interest according to
> Am 24.11.2022 um 17:28 schrieb Stefan Schulze Frielinghaus via Gcc
> :
>
> Hi everyone,
>
> Currently I'm looking into a wrong-code bug and would like to understand
> a certain optimization done by combine during local transformation.
> Without LTO I wo
Hi everyone,
Currently I'm looking into a wrong-code bug and would like to understand
a certain optimization done by combine during local transformation.
Without LTO I would simply debug cc1 and step through combine. However,
with LTO enabled AFAIK I have to debug lto1 instead. In order t
Hi Martin,
thanks a lot for your help! You were right! I am now able to call
make_edge_direct_to_target during WPA.
-Erick
Hi Erick,,
On Thu, Jul 07 2022, Erick Ochoa wrote:
> On Fri, 1 Jul 2022 at 14:48, Martin Jambor wrote:
>
>> Why so late, why not as part of number 4?
>>
> Thanks for the feedback. The original reason why the call to
> make_edge_direct_to_target was done so late is because of the lack of
> functio
On Fri, 1 Jul 2022 at 14:48, Martin Jambor wrote:
> Why so late, why not as part of number 4?
>
Hi Martin,
Thanks for the feedback. The original reason why the call to
make_edge_direct_to_target was done so late is because of the lack of
function bodies during WPA, summaries with insufficient i
Hi,
On Fri, Jul 01 2022, Erick Ochoa via Gcc wrote:
> Hi,
>
> I have a pass that is able to speculate the target of indirect function
> calls. This pass is an IPA_PASS. It:
>
> 1. generates summaries with the possible targets.
> 2. writes analysis summary
> 3. reads analysis summary
> 4. combines
Hi,
I have a pass that is able to speculate the target of indirect function
calls. This pass is an IPA_PASS. It:
1. generates summaries with the possible targets.
2. writes analysis summary
3. reads analysis summary
4. combines the results from multiple partitions and if needed fixes the
targets
On 15/6/22 7:56 pm, Richard Biener wrote:
> On Wed, Jun 15, 2022 at 11:27 AM Chris Johns
> wrote:
>>
>> Hi,
>>
>> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
>> chip vendor is using it when building controller software tha
On Wed, Jun 15, 2022 at 11:27 AM Chris Johns wrote:
>
> Hi,
>
> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
> chip vendor is using it when building controller software that is part of a
> system.
>
> The build I am using symlinks gmp, mp
Hi,
I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
chip vendor is using it when building controller software that is part of a
system.
The build I am using symlinks gmp, mpfr etc as source so they are built as part
of the gcc build.
The mpfr package is reporting
ght place to store such pass-specific
>> information, for reasons you described and more (especially simple
>> memory use efficiency).
>>
>> Instead they should be placed into an "edge summary" (also sometimes
>> called "call summary"), a structure simil
use efficiency).
>
> Instead they should be placed into an "edge summary" (also sometimes
> called "call summary"), a structure similar to ipa_edge_args_sum (in
> ipa-prop.h and ipa-prop.cc). Unlike ipa_edge_args_sum, which is
> allocated at analysis phase, th
ple
memory use efficiency).
Instead they should be placed into an "edge summary" (also sometimes
called "call summary"), a structure similar to ipa_edge_args_sum (in
ipa-prop.h and ipa-prop.cc). Unlike ipa_edge_args_sum, which is
allocated at analysis phase, then streamed ou
Hi,
I'm working on a pass that looks into the estimated values during ipa-cp
and stores them for a later analyses/pass. I would like to store the real
arguments' estimates in a cgraph_edge::call_stmt or somewhere else that
makes similar sense. (Note, this is different from the formal parameters'
e
Hi Ankur,
> On 8 May 2022, at 15:29, Ankur Saini via Gcc wrote:
>
> I have been fiddling around with the patch regarding "bypassing assmebler
> while generating slim lto files" and managed to make it build with the
> current trunk. Though the patch seems to be wor
Hi,
I have been fiddling around with the patch regarding "bypassing assmebler
while generating slim lto files" and managed to make it build with the
current trunk. Though the patch seems to be working on Linux machine, it
causes an ICE on macOS (it crashes in langhooks.cc while
version of gmake do you have?
% gmake --version
GNU Make 4.3
Built for amd64-portbld-freebsd13.0
It's the version from FreeBSD port collection.
I just started a new bootstrap with LTO enabled
without any patches in my gcc tree to try to get
a baseline. It will take a bit.
--
Steve
On Tue, 12 Apr 2022 at 18:32, Steve Kargl wrote:
> Well, I determined what the problem is. On FreeBSD,
> GNU make is gmake. make(1) on FreeBSD is BSD make.
>
> % gmake -j7 check-c
>
> Does not pass down the name of the invoking command
> to sub-make jobs.
That suggests some makefile is using 'ma
> > > ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran \
> > > --enable-bootstrap --disable-nls --enable-checking --disable-multilib \
> > > --disable-libsanitizer --disable-lto.
> > >
> > > then bootstrap gcc, why do I see 1000s of
gt;>> Hi,
> >>>>
> >>>>
> >>>>> On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
> >>>>>
> >>>>> Ankur,
> >>>>>> I was browsing the list of submitted GSoC projects this year and the
>
an Hubicka wrote:
>>>>>
>>>>> Ankur,
>>>>>> I was browsing the list of submitted GSoC projects this year and the
>>>>>> project regarding bypassing assembler when generating LTO object files
>>>>>> caught my eye.
>&
On 4/12/22 11:58, Richard Biener wrote:
On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc wrote:
Hi,
On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
Ankur,
I was browsing the list of submitted GSoC projects this year and the
project regarding bypassing assembler when generating LTO
On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc wrote:
>
> Hi,
> >
> >
> > > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
> > >
> > > Ankur,
> > >> I was browsing the list of submitted GSoC projects this year and the
> > >
Hi,
>
>
> > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
> >
> > Ankur,
> >> I was browsing the list of submitted GSoC projects this year and the
> >> project regarding bypassing assembler when generating LTO object files
> >> caught my ey
On Apr 11 2022, Steve Kargl via Gcc wrote:
> Should the testsuite recognize that gcc is built without LTO support?
Yes, we have check_effective_target_lto for that.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And
ble-bootstrap --disable-nls --enable-checking --disable-multilib \
> > --disable-libsanitizer --disable-lto.
> >
> > then bootstrap gcc, why do I see 1000s of failures with
> >
> > % cd gcc
> > % gmake -j7 check-c
> > ...
> > FAIL: gcc.dg/torture/pr64
On Tue, Apr 12, 2022 at 1:53 AM Steve Kargl via Gcc wrote:
>
> If I configure gcc with the following
>
> ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran \
> --enable-bootstrap --disable-nls --enable-checking --disable-multilib \
> --disable-libsanit
> On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
>
> Ankur,
>> I was browsing the list of submitted GSoC projects this year and the
>> project regarding bypassing assembler when generating LTO object files
>> caught my eye.
> I apologize for late reply. I woul
If I configure gcc with the following
../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran \
--enable-bootstrap --disable-nls --enable-checking --disable-multilib \
--disable-libsanitizer --disable-lto.
then bootstrap gcc, why do I see 1000s of failures with
% cd gcc
Ankur,
> I was browsing the list of submitted GSoC projects this year and the
> project regarding bypassing assembler when generating LTO object files
> caught my eye.
I apologize for late reply. I would be very happy to mentor this
project.
>
> I already have a gcc built from
Hi all,
I am a student from Bangalore, India. I'd like to participate in GSoC 2022.
The idea about incremental LTO caught my eye.
> At the moment, LTO re-optimizes and generates code for the whole program
or library if just one object file changes, even an insignificant way. The
con
Hi GCC community,
I have a few questions that I am struggling to find an answer for:
a. Why does LTO generates a new symbol?
b. Why it does not replace the existing symbol, instead of creating a new one
with "lto_priv.%d" at the end of it [1]?
c. Can we assume the original symbol a
Hi,
I was browsing the list of submitted GSoC projects this year and the
project regarding bypassing assembler when generating LTO object files
caught my eye.
I already have a gcc built from source (sync-ed with trunk/master) and
launched the test-suite on it.
I am currently in process of
7;s passes. So, I
> can imagine something like, create an ASSERT_EXPR and let other passes
> change the CFG, and remove dead code, fold constants, etc.
>
> At the moment I am only prototyping it, and so I have created a
> SIMPLE_IPA_PASS during LTO that finds the variables of inte
asses
change the CFG, and remove dead code, fold constants, etc.
At the moment I am only prototyping it, and so I have created a
SIMPLE_IPA_PASS during LTO that finds the variables of interest and then
creates an ASSERT_EXPR which contains the static information of interest.
This looks to be wo
On Tue, Oct 12, 2021 at 8:58 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I have an LTO pass which stores information collected during "generate
> function summary" in a map which is symtab_node* -> data*. I know that
> the symtab_node*s are encoded by an lto encoder a
Hi,
I have an LTO pass which stores information collected during "generate
function summary" in a map which is symtab_node* -> data*. I know that
the symtab_node*s are encoded by an lto encoder and can be decoded
back during the "read function summary". I also am aware t
Eugene Rozenfeld
Cc: gcc@gcc.gnu.org
Subject: [EXTERNAL] Re: Reporting lto bugs
On Fri, Sep 24, 2021 at 3:45 AM Eugene Rozenfeld via Gcc
wrote:
>
> I ran into a bug with lto: no line number info gets emitted when building my
> project with -flto and -g (with gcc 8.2). I'd like to p
1 - 100 of 1795 matches
Mail list logo
