GSOC

GSOC

[Siddhartha Sen]

I am Siddhartha Sen,currently pursuing my B.Tech degree in Information
Science and Engineering,2nd year. I have taken a keen interest in your
projects and have some ideas of my own as well. I am really interested in
working with you in G-SOC 2019. I am proficient in C and C++ and am eager
to work on brushing my skills in whichever field required. I have already
checked out the GCC trunk source-code and am being able to build GCC from
it.I have run the testsuite and saved the results. However, upon building
it and saving it again, the results don't match. I apologise for my lack of
knowledge but any help on your part would be great.
Thank You.

Re: [GSOC] variations in testsuite results

[Martin Jambor]

Hi Siddhartha,

On Tue, Nov 27 2018, Siddhartha Sen wrote:
> I am Siddhartha Sen,currently pursuing my B.Tech degree in Information
> Science and Engineering,2nd year. I have taken a keen interest in your
> projects and have some ideas of my own as well. I am really interested in
> working with you in G-SOC 2019.

We are delighted.

> I am proficient in C and C++ and am eager
> to work on brushing my skills in whichever field required. I have already
> checked out the GCC trunk source-code and am being able to build GCC from
> it.I have run the testsuite and saved the results.

Great, those are all the essential first steps, it seems like you are
ready to work on your first patch.

> However, upon building
> it and saving it again, the results don't match. I apologise for my lack of
> knowledge but any help on your part would be great.

How did you compare the test results and which tests behaved
differently?  How did you configure GCC?  Was it on an x86_64?

Unfortunately, this sometimes happens.  As far as I can tell, the libgo
testsuite is very flaky and I basically ignore its results.  In the
past, I believe that also some guality tests sometimes passed and
sometimes did not, but I have not heard such reports recently.  These
tests however also depend on the GDB (version) you have installed on
your system.

Martin

Fwd: [GSOC] variations in testsuite results

[Siddhartha Sen]

---------- Forwarded message ---------
From: Siddhartha Sen <siddhartha99.sen@gmail.com>
Date: Sat 1 Dec, 2018, 2:01 AM
Subject: Re: [GSOC] variations in testsuite results
To: <mjambor@suse.cz>


Hi Martin,
                I apologise for the late reply.My semester end exams are
currently going on and I am finding it a bit difficult to devote time for
this. However, this time I have taken a bit different approach and it has
worked perfectly fine. I don't know what went wrong the last time,but this
is what I did this time:

Firstly,I use an x86_64(Ubuntu 18.04) since you asked,although I am not
sure whether that was a big factor or not. Anyways, I checked out the
source code. I checked on the internet to find that a few missing libraries
were required to compile gcc. Initially I was going to install them by hand
but then I realised it woud be a long process, considering I had to get
each one of those as well as check each of their versions,etc. So I used
the script that has been bundled with the source about which,to be honest,
I was unaware of until very recently. Then, I initially unset everything
and then enabled 'langages' and 'gold' and disabled 'libquadmath'(the quad
math library),werror' and 'bootstrap'.(A quick question:Did I also need to
disable the support for quadmath as well?).I thought of using the default
ld linker instead of the gold linker, but then I read somewhere gold linker
worked faster for c++ projects. Finally I compiled it(which took a bit
longer than it should have) and installed it for usage.I was actually
experimenting a bit and went a bit further and added it as an environment
variable through the export command. And that was all. Please let me know
what you thought and tell me what to do next.
Thank You.

On Wed, Nov 28, 2018 at 10:46 PM Martin Jambor <mjambor@suse.cz> wrote:

> Hi Siddhartha,
>
> On Tue, Nov 27 2018, Siddhartha Sen wrote:
> > I am Siddhartha Sen,currently pursuing my B.Tech degree in Information
> > Science and Engineering,2nd year. I have taken a keen interest in your
> > projects and have some ideas of my own as well. I am really interested in
> > working with you in G-SOC 2019.
>
> We are delighted.
>
> > I am proficient in C and C++ and am eager
> > to work on brushing my skills in whichever field required. I have already
> > checked out the GCC trunk source-code and am being able to build GCC from
> > it.I have run the testsuite and saved the results.
>
> Great, those are all the essential first steps, it seems like you are
> ready to work on your first patch.
>
> > However, upon building
> > it and saving it again, the results don't match. I apologise for my lack
> of
> > knowledge but any help on your part would be great.
>
> How did you compare the test results and which tests behaved
> differently?  How did you configure GCC?  Was it on an x86_64?
>
> Unfortunately, this sometimes happens.  As far as I can tell, the libgo
> testsuite is very flaky and I basically ignore its results.  In the
> past, I believe that also some guality tests sometimes passed and
> sometimes did not, but I have not heard such reports recently.  These
> tests however also depend on the GDB (version) you have installed on
> your system.
>
> Martin
>

Re: [GSOC] variations in testsuite results

[Martin Jambor]

Hello Siddhartha,

first and foremost, I'd like to apologize for replying so late.  I have
accidently marked your messages as only needing attention when the new
GSoC year is about to start.

On Sat, Dec 01 2018, Siddhartha Sen wrote:
> Hi Martin,
>
> Firstly,I use an x86_64(Ubuntu 18.04) since you asked,although I am not
> sure whether that was a big factor or not. Anyways, I checked out the
> source code. I checked on the internet to find that a few missing libraries
> were required to compile gcc. Initially I was going to install them by hand
> but then I realised it woud be a long process, considering I had to get
> each one of those as well as check each of their versions,etc.

On Ubuntu and other Debian-based distributions it should be enough to
just install libgmp-dev, libmpfr-dev and libmpc-dev through apt or
aptitude.

> So I used
> the script that has been bundled with the source about which,to be
> honest,

That works too.

> I was unaware of until very recently. Then, I initially unset everything
> and then enabled 'langages' and 'gold' and disabled 'libquadmath'(the quad
> math library),werror' and 'bootstrap'.

Being able to bootstrap the compiler is essential so that you can test
your changes (they have to pass bootstrap).  For development, you
definitely want to have bootstrap disabled.

> (A quick question:Did I also need to
> disable the support for quadmath as well?).

I personally don't care about it and it gets automatically enabled.

> I thought of using the default
> ld linker instead of the gold linker, but then I read somewhere gold linker
> worked faster for c++ projects.

Unless you have specific need for one or the other, I don't think it
matters which one you choose (it might make a difference in LTO projects
but because of bugs of one or the other rather than anything else).

> Finally I compiled it(which took a bit longer than it should have)

That is most certainly because of enable bootstrap.

> and installed it for usage.I was actually
> experimenting a bit and went a bit further and added it as an environment
> variable through the export command. And that was all.

Good, it looks like you are all set up.  I'm not sure I understand the
bit about the environment variable though.

>  Please let me know what you thought and tell me what to do next.

I'm not sure I understand this question well either.  But I'd suggest
looking at https://gcc.gnu.org/wiki/GettingStarted and especially at
https://gcc.gnu.org/wiki/DebuggingGCC and
https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html.  Compile a
simple but non-trivial program with -O3 -S -fdump-tree-all
-fdump-ipa-all -fdump-rtl-all and look through the generated files.
Look at the the source code, especially in the `gcc` subdirectory and
try to set a breakpoint somewhere and hit it.  Then look around in gdb.

And then it is really up to you what you want to focus on, it depends on
what attracts you most, what you are most interested in.  As far as GSoC
is concerned, we are in the process of finalizing an "official" list of
project ideas for this year at https://gcc.gnu.org/wiki/GettingStarted
but it will not be finished for at least a few more days, possibly even
a week.

If you have any further specific questions, please feel free to ask,
I'll make my best to be more diligent with replying.

Martin


> Thank You.
>
> On Wed, Nov 28, 2018 at 10:46 PM Martin Jambor <mjambor@suse.cz> wrote:
>
>> Hi Siddhartha,
>>
>> On Tue, Nov 27 2018, Siddhartha Sen wrote:
>> > I am Siddhartha Sen,currently pursuing my B.Tech degree in Information
>> > Science and Engineering,2nd year. I have taken a keen interest in your
>> > projects and have some ideas of my own as well. I am really interested in
>> > working with you in G-SOC 2019.
>>
>> We are delighted.
>>
>> > I am proficient in C and C++ and am eager
>> > to work on brushing my skills in whichever field required. I have already
>> > checked out the GCC trunk source-code and am being able to build GCC from
>> > it.I have run the testsuite and saved the results.
>>
>> Great, those are all the essential first steps, it seems like you are
>> ready to work on your first patch.
>>
>> > However, upon building
>> > it and saving it again, the results don't match. I apologise for my lack
>> of
>> > knowledge but any help on your part would be great.
>>
>> How did you compare the test results and which tests behaved
>> differently?  How did you configure GCC?  Was it on an x86_64?
>>
>> Unfortunately, this sometimes happens.  As far as I can tell, the libgo
>> testsuite is very flaky and I basically ignore its results.  In the
>> past, I believe that also some guality tests sometimes passed and
>> sometimes did not, but I have not heard such reports recently.  These
>> tests however also depend on the GDB (version) you have installed on
>> your system.
>>
>> Martin
>>

Re: [GSOC] Simple things to play with (Was: variations in testsuite results)

[Martin Jambor]

Hi Siddhartha,

On Sat, Feb 02 2019, Siddhartha Sen wrote:
> Hey Marting,
>                     I have disabled the boottrap and am able to bootstrap
> the compiler on my own. I have done as you said and have experimented a bit
> with gdb as well. I was facing trivial problems but nothing that the
> internet did not have answers for. I have done most of the things on the
> list - I have built,compiled,debugged as well as tested variations in gcc.
> However, I am unable to understand the project ideas here
> https://gcc.gnu.org/wiki/GettingStarted. Could you suggest something
> trivial before I look into these in order to get a proper understanding?
> Like any microproject or miniproject would be alright.
> Thanks

I apologize for my late reply again.  One reason is that my TODO list
kind of exploded last week but another is that it is difficult to think
of an easy project in GCC.  Easy things usually get immediately done,
starting to contribute to GCC is unfortunately usually a bit hard.  On
the other hand, it is better to ask such questions on the mailing list
(CCed) in the future, it can well happen someone else will be able to
help you (faster).

In any event, I guess it now mostly comes down to selecting a specific
part of GCC you want to look into.  At this point I'd recommend looking
at the "Bypass assembler when generating LTO object files" project idea
from our wiki page (the likely mentor, Honza, is also in CC).  What you
want to do as the first step is to compile some simple (almost
hello-world-like), program with options "-flto -save-temps -v" and
examine the compiler output (especially the command lines invoking the
various steps of LTO compilation, some of which you will want to re-run
within gdb) and the various file it keeps around, especially the *.s
ones that are not called ltrans-something, which you'd eventually want
to eliminate.

Most of the data writing/reading is done in the libiberty library so
look at that, along with code in gcc/lto/*.[ch] which invokes it.  IIUC,
the project basically means implementing direct output of ELF-format
field, from libiberty instead of the assembler one, so look into ELF
format too.  And perhaps Honza can suggest some further exploratory
steps for you too.

Good luck,

Martin


>
> On Mon, Jan 28, 2019 at 11:03 PM Martin Jambor <mjambor@suse.cz> wrote:
>
>> Hello Siddhartha,
>>
>> first and foremost, I'd like to apologize for replying so late.  I have
>> accidently marked your messages as only needing attention when the new
>> GSoC year is about to start.
>>
>> On Sat, Dec 01 2018, Siddhartha Sen wrote:
>> > Hi Martin,
>> >
>> > Firstly,I use an x86_64(Ubuntu 18.04) since you asked,although I am not
>> > sure whether that was a big factor or not. Anyways, I checked out the
>> > source code. I checked on the internet to find that a few missing
>> libraries
>> > were required to compile gcc. Initially I was going to install them by
>> hand
>> > but then I realised it woud be a long process, considering I had to get
>> > each one of those as well as check each of their versions,etc.
>>
>> On Ubuntu and other Debian-based distributions it should be enough to
>> just install libgmp-dev, libmpfr-dev and libmpc-dev through apt or
>> aptitude.
>>
>> > So I used
>> > the script that has been bundled with the source about which,to be
>> > honest,
>>
>> That works too.
>>
>> > I was unaware of until very recently. Then, I initially unset everything
>> > and then enabled 'langages' and 'gold' and disabled 'libquadmath'(the
>> quad
>> > math library),werror' and 'bootstrap'.
>>
>> Being able to bootstrap the compiler is essential so that you can test
>> your changes (they have to pass bootstrap).  For development, you
>> definitely want to have bootstrap disabled.
>>
>> > (A quick question:Did I also need to
>> > disable the support for quadmath as well?).
>>
>> I personally don't care about it and it gets automatically enabled.
>>
>> > I thought of using the default
>> > ld linker instead of the gold linker, but then I read somewhere gold
>> linker
>> > worked faster for c++ projects.
>>
>> Unless you have specific need for one or the other, I don't think it
>> matters which one you choose (it might make a difference in LTO projects
>> but because of bugs of one or the other rather than anything else).
>>
>> > Finally I compiled it(which took a bit longer than it should have)
>>
>> That is most certainly because of enable bootstrap.
>>
>> > and installed it for usage.I was actually
>> > experimenting a bit and went a bit further and added it as an environment
>> > variable through the export command. And that was all.
>>
>> Good, it looks like you are all set up.  I'm not sure I understand the
>> bit about the environment variable though.
>>
>> >  Please let me know what you thought and tell me what to do next.
>>
>> I'm not sure I understand this question well either.  But I'd suggest
>> looking at https://gcc.gnu.org/wiki/GettingStarted and especially at
>> https://gcc.gnu.org/wiki/DebuggingGCC and
>> https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html.  Compile a
>> simple but non-trivial program with -O3 -S -fdump-tree-all
>> -fdump-ipa-all -fdump-rtl-all and look through the generated files.
>> Look at the the source code, especially in the `gcc` subdirectory and
>> try to set a breakpoint somewhere and hit it.  Then look around in gdb.
>>
>> And then it is really up to you what you want to focus on, it depends on
>> what attracts you most, what you are most interested in.  As far as GSoC
>> is concerned, we are in the process of finalizing an "official" list of
>> project ideas for this year at https://gcc.gnu.org/wiki/GettingStarted
>> but it will not be finished for at least a few more days, possibly even
>> a week.
>>
>> If you have any further specific questions, please feel free to ask,
>> I'll make my best to be more diligent with replying.
>>
>> Martin
>>
>>
>> > Thank You.
>> >
>> > On Wed, Nov 28, 2018 at 10:46 PM Martin Jambor <mjambor@suse.cz> wrote:
>> >
>> >> Hi Siddhartha,
>> >>
>> >> On Tue, Nov 27 2018, Siddhartha Sen wrote:
>> >> > I am Siddhartha Sen,currently pursuing my B.Tech degree in Information
>> >> > Science and Engineering,2nd year. I have taken a keen interest in your
>> >> > projects and have some ideas of my own as well. I am really
>> interested in
>> >> > working with you in G-SOC 2019.
>> >>
>> >> We are delighted.
>> >>
>> >> > I am proficient in C and C++ and am eager
>> >> > to work on brushing my skills in whichever field required. I have
>> already
>> >> > checked out the GCC trunk source-code and am being able to build GCC
>> from
>> >> > it.I have run the testsuite and saved the results.
>> >>
>> >> Great, those are all the essential first steps, it seems like you are
>> >> ready to work on your first patch.
>> >>
>> >> > However, upon building
>> >> > it and saving it again, the results don't match. I apologise for my
>> lack
>> >> of
>> >> > knowledge but any help on your part would be great.
>> >>
>> >> How did you compare the test results and which tests behaved
>> >> differently?  How did you configure GCC?  Was it on an x86_64?
>> >>
>> >> Unfortunately, this sometimes happens.  As far as I can tell, the libgo
>> >> testsuite is very flaky and I basically ignore its results.  In the
>> >> past, I believe that also some guality tests sometimes passed and
>> >> sometimes did not, but I have not heard such reports recently.  These
>> >> tests however also depend on the GDB (version) you have installed on
>> >> your system.
>> >>
>> >> Martin
>> >>
>>