* GSOC - Student Rondup
@ 2011-06-30 10:14 Philip Herron
2011-07-05 16:59 ` GSOC - Student Roundup Dimitrios Apostolou
2011-07-17 13:54 ` Franck Z
0 siblings, 2 replies; 12+ messages in thread
From: Philip Herron @ 2011-06-30 10:14 UTC (permalink / raw)
To: gcc
Hey all,
I was talking on IRC the other day with others and we thought this
would be a nice idea, to ask all GSOC students how were all getting on
working within GCC. As i am sure you have noticed GCC is a pretty big
piece of code and it can be hard to get to grips with it all. I am
kind of lucky because i was on GSOC last year and spent most of the
summer if not all just getting comfortable with it.
So i thought we could use this as a thread to introduce us a students
to each other I'll go first!
My name is Philip Herron I'm from Ireland and i got inspired by Paul
Biggars work into PHC http://www.phpcompiler.org/ to implement a
python front-end to gcc. Its hard but just something i find
interesting more than anything. I'm am getting on quite well with my
project, spent last week after the GCC meet-up in London cleaning up
my IL and now i am implementing my own pass system as i have to
iterate several passes over my IL (for various reasons) before i
generate GENERIC.
As i was on GCC last year i thought i would share things i found to be
helpful when you encounter a problem:
1 - Work at it for max 1 day on your own but definitely try to join
our irc on irc.oftc.net #gcc and ask. If you still find no help send a
mail to gcc-help
2 - gcc -save-temps can be helpful now and again when working with
alot of macros
3 - ack-grep is very helpful: http://betterthangrep.com/ makes
searching though code much easier than learning to use grep properly
:P
4 - Don't be afraid to ask questions as often as possible on irc and
to your mentor I've bugged my mentor Ian with alot of really stupid
small things all the time :) but they don't bite.
And just finally i thought i would ask what aspects have you found
within gcc hard to get to grips with if at all, it could be
interesting to see if there is any correlation between areas.
Personally i found getting to grips with Makefiles properly was hard i
used to rely on automake for everything before. And learning to figure
out how to use the generic tree api was confusing but in the end its
very simple. We've found not all students are on irc its a really
great platform to ask questions very informally its worth getting used
to you can use web clients like mibbet irc or firefox extensions, i
use irssi but those clients are much more friendly.
Hope everyone's project is going well and your comfortable or getting
more comfortable with what your doing! :)
Happy Coding!
--Phil
PS: what do you think of the idea if we have a thread like this every
few weeks or sooner (maybe on irc)? Just to see if we can help each
other etc?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-06-30 10:14 GSOC - Student Rondup Philip Herron
@ 2011-07-05 16:59 ` Dimitrios Apostolou
2011-07-05 19:08 ` Daniel Carrera
2011-07-07 15:53 ` Paolo Bonzini
2011-07-17 13:54 ` Franck Z
1 sibling, 2 replies; 12+ messages in thread
From: Dimitrios Apostolou @ 2011-07-05 16:59 UTC (permalink / raw)
To: Philip Herron; +Cc: gcc
Hi Philip,
thanks for writing your experiences, I found it very useful. I certainly
like the idea of having such a thread every once in a while, just to keep
everyone updated about our projects. I'm also curious to learn about the
experiences of other students that are writing code for GCC for the first
time. Here goes mine:
I am Dimitrios Apostolou (jimis on IRC) and I live in Heraklion-Crete,
Greece. My project concerns making GCC leaner and faster.
Reading GCC codebase has been a hard exercise for me. In fact it's the
only project I know of that becomes more and more difficult as time
passes... I will try to describe some of the major hurdles I've faced so
far.
I started by profiling the execution of cc1, the C compiler. In general I
could find no big hot-spot, it was in good shape, but I could see 3-4
areas that could make some difference if improved (for example hash
tables, assembly output, C parser, bitmaps). But diving in and trying to
change things is a completely different story.
Minor tweaks are easy to make, but usually have minor impact. If you want
to see bigger speedup you have to break the interface of functions being
used in hundreds of places, and that is hard. Sometimes it was impossible
for me, I was getting crashes in places far away of code I had changed,
so I ended up reverting to original versions.
Spending some time with a specific part of GCC's codebase gives you
the ability to dive deeper and work more efficiently. But that is the
point when I usually have achieved something and I must move on to some
other part. And the whole GCC codebase is so huge, that understanding one
part means nothing when you move to another. My advice here is that if
your project permits that, touch as little code as possible in GCC, and
be really proficient with that. Treat the rest as a black box, or you'll
spend too much time trying to understand everything.
Another hurdle is the usage of too many macros. Even if they exist for
making the code easier to read, I can't see how they achieve this in a few
extreme cases. I have had gdb expand 20 full-lines macros on a wide
screen. Plus the profiler can't actually profile code in macros, so the
impact of some data structures in performance is hidden that way. My
moments of greatest awe/horror so far have been while changing things in
vectors (vec.[ch]), which is actually a fully templated structure
implemented in CPP!
Finally I believe that some parts of the compiler should have a big
NO-ENTRY flag for beginners. In my case, after having improved little
stuff in assembly output and hash tables, I decided -driven by profiler's
output- to try improving things in dataflow analysis part of GCC. It's
true that there is much to be improved there but it requires a good
understanding of this complex part. Three weeks later I am still striving
to change simple stuff and jump to the next part, but regressions I've
introduced don't allow me to do so yet. The level of my understanding of
this part is still basic, I've now only scratched the surface of Dataflow
Analysis. If I had this knowledge in the beginning I'd probably leave that
part for the end of the summer, if at all. My plans included visiting IRA
(register allocator) next, but I think I'll skip directly to the c-parser
which I understand more.
These are my major difficulties with GCC, I'm curious to learn about other
students experience so far. Of course don't get the wrong impression, my
general feeling on GCC development is positive, the community is helpful
and really friendly inspite of my daily spamming on the IRC. :-p
In the end I feel the fact that GCC is a multi-headed monster makes it
even more exciting to try and tame it.
Good luck in everyone's project,
Dimitris
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-05 16:59 ` GSOC - Student Roundup Dimitrios Apostolou
@ 2011-07-05 19:08 ` Daniel Carrera
2011-07-06 9:39 ` Pierre Vittet
2011-07-07 15:53 ` Paolo Bonzini
1 sibling, 1 reply; 12+ messages in thread
From: Daniel Carrera @ 2011-07-05 19:08 UTC (permalink / raw)
To: gcc
Hello Philip + Dimitrios
Thanks for your posts. I am another GSOC student. I am working on the
Fortran front-end of GCC (gfortran). Like most GFortran developers, my
background is more in the natural sciences (astrophysics in my case)
rather than computer science.
My project is to help add coarray support for GFortran. Coarrays are a
cool new feature in the Fortran 2008 standard that give Fortran native
support for parallel programming (as opposed to using MPI or OpenMP).
Scientific simulations (especially in parallel clusters) are the bread
and butter of Fortran.
Learning how GCC works has been difficult but rewarding. My work is
split between the libgfortran library, which is straight forward enough,
and the Fortran front-end, which at first looked like gobbledygook.
Today I can actually understand most front-end functions when I read
them, but it took a long time to get to this point. GCC has a scary
learning curve.
The libgfortran library is more forgiving for the beginner. We are using
MPI as the backend to implement coarrays and I have very much enjoyed
learning MPI.
So far my contributions have been modest, but now that I've crossed much
of the learning curve, I feel optimistic. To an extent the progress has
to be a bit slow because we are looking at the new Fortran standard and
thinking about the best way to add features.
Cheers,
Daniel.
--
I'm not overweight, I'm undertall.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-05 19:08 ` Daniel Carrera
@ 2011-07-06 9:39 ` Pierre Vittet
2011-07-06 15:10 ` Dimitrios Apostolou
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Pierre Vittet @ 2011-07-06 9:39 UTC (permalink / raw)
To: gcc
Hi,
I am Pierre Vittet, one of the GSOC students. I am writing a plugin
which is a simple statical analysis tools. The idea is to write some
tests (like testing that a function call is tested to return somethings
(not) null, or testing that a call to a given function is followed by a
call to another function.), that can be parametrized by the user (to be
run on the functions he wants to check). I feel it can be a useful tool
(however I am ready to fight with false positives).
I am using MELT (http://gcc-melt.org/) for this, I know that is quite a
hot topic in the community and it is not much considered. MELT aims at
abstracting GCC internal with a higher level language. I think that it
can be a good way to enter into GCC, because it permits to parse quite
quikly the GCC internal, gimple especially. The major feature of MELT is
his pattern matching on tree ability.
Part of my work is to improve MELT (as I need some features which were
not implemented), such as having handling pragma in MELT plugins or
gluing some GCC dominance functions (from gcc/dominance.c)
However, like the others students which answered to this thread, the
main difficulty is understanding and eventually modifying GCC itself.
That is quite time consumming, as you can have, even to write a simple
patch, to know well several parts of GCC (I am often grepping for a
given struct or function). I also thing that each pass could be more
detailled. Sometimes, it is hard to find a pass in the code from it's
dump file name.
I had to write a patch for the trunk, to add a data field to pragma
handlers, this was quite a simple patch, however, I had to make it
compatible with the fact that one of the function I was modifying was
used many times in differents parts of GCC.
Currently, I need to understand how works C++ mangling if I want my
plugin to work with C++ (I am going to write a new mail about this), as
I need to convert the string given by the user into the function(s) that
it represents.
About the state of my plugin, I have written the core of the module.
It can use user's input from different entries (I have already written
an entrie using the pragma, and an entrie using direct argument (given
when invoking GCC), searchs if it matchs a corresponding test and
generate a new GCC Pass from this. This new pass is inserted after ssa
pass, as I got a representation which suits to me (I can find the
information my tests need). But the choice of inserting here is quite
empirical (would have you choice another pass?). The plugin is mainly
tested for C code, even if I would like to have C++ working too.
I have started implementing tests, for the moment I use a test which
checks that there is a test checking for a NULL pointer (if resCall ==
NULL for exemple) after a given function call, and return a warning if
there is no test.
I have also started implementing a test checking that a given is
immediatly followed by another given function. I would also try to add a
test checking that a call to a given function is followed by a call to
another function in the same function bodies, I know that I will have to
handle the basic block hierarchie, that why I glued dominance functions
into MELT.
I think, I am in time, however, this is sometimes hard to evaluate: for
exemple, I don't know really how much time, I will take to manage C++
function in my plugin.
I feel sad, not being able to use IRC from my web access (in my
school)... and so only communicating by mail with the GCC community.
However, I thanks the community for their answer and support. The point
to improve, I guess, is having more people reviewing patchs (even if, I
understand that it requires a lot of time and skills).
Thanks
Pierre Vittet
On 05/07/2011 21:08, Daniel Carrera wrote:
> Hello Philip + Dimitrios
>
> Thanks for your posts. I am another GSOC student. I am working on the
> Fortran front-end of GCC (gfortran). Like most GFortran developers, my
> background is more in the natural sciences (astrophysics in my case)
> rather than computer science.
>
> My project is to help add coarray support for GFortran. Coarrays are a
> cool new feature in the Fortran 2008 standard that give Fortran native
> support for parallel programming (as opposed to using MPI or OpenMP).
> Scientific simulations (especially in parallel clusters) are the bread
> and butter of Fortran.
>
>
> Learning how GCC works has been difficult but rewarding. My work is
> split between the libgfortran library, which is straight forward enough,
> and the Fortran front-end, which at first looked like gobbledygook.
> Today I can actually understand most front-end functions when I read
> them, but it took a long time to get to this point. GCC has a scary
> learning curve.
>
> The libgfortran library is more forgiving for the beginner. We are using
> MPI as the backend to implement coarrays and I have very much enjoyed
> learning MPI.
>
> So far my contributions have been modest, but now that I've crossed much
> of the learning curve, I feel optimistic. To an extent the progress has
> to be a bit slow because we are looking at the new Fortran standard and
> thinking about the best way to add features.
>
> Cheers,
> Daniel.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-06 9:39 ` Pierre Vittet
@ 2011-07-06 15:10 ` Dimitrios Apostolou
2011-07-10 22:32 ` Ismail
2011-07-16 22:42 ` Gerald Pfeifer
2 siblings, 0 replies; 12+ messages in thread
From: Dimitrios Apostolou @ 2011-07-06 15:10 UTC (permalink / raw)
To: Pierre Vittet; +Cc: gcc
Hi Pierre,
regarding your IRC problems, try a web-based client, for example
http://chat.mibbit.com
Dimitris
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-05 16:59 ` GSOC - Student Roundup Dimitrios Apostolou
2011-07-05 19:08 ` Daniel Carrera
@ 2011-07-07 15:53 ` Paolo Bonzini
[not found] ` <CABck2NNXWNKCRbC9kv8TkNvgpgOcE_cjg-NKqO3=pb-x_okAqQ@mail.gmail.com>
1 sibling, 1 reply; 12+ messages in thread
From: Paolo Bonzini @ 2011-07-07 15:53 UTC (permalink / raw)
To: Dimitrios Apostolou; +Cc: Philip Herron, gcc
On 07/05/2011 06:58 PM, Dimitrios Apostolou wrote:
> The level of my understanding of this part is still basic, I've now only
> scratched the surface of Dataflow Analysis.
Well you're not looking at df proper, which is mostly a textbook
implementation with some quirks; you're looking at RTL operand scanning,
which should indeed have a big "here be dragons" sign on it. But you're
doing fine. :)
Paolo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-06 9:39 ` Pierre Vittet
2011-07-06 15:10 ` Dimitrios Apostolou
@ 2011-07-10 22:32 ` Ismail
2011-07-16 22:42 ` Gerald Pfeifer
2 siblings, 0 replies; 12+ messages in thread
From: Ismail @ 2011-07-10 22:32 UTC (permalink / raw)
To: gcc
On 06.07.2011 11:39, Pierre Vittet wrote:
> Hi,
>
> I am Pierre Vittet, one of the GSOC students. I am writing a plugin
> which is a simple statical analysis tools. The idea is to write some
> tests (like testing that a function call is tested to return
> somethings (not) null, or testing that a call to a given function is
> followed by a call to another function.), that can be parametrized by
> the user (to be run on the functions he wants to check). I feel it can
> be a useful tool (however I am ready to fight with false positives).
>
> I am using MELT (http://gcc-melt.org/) for this, I know that is quite
> a hot topic in the community and it is not much considered. MELT aims
> at abstracting GCC internal with a higher level language. I think that
> it can be a good way to enter into GCC, because it permits to parse
> quite quikly the GCC internal, gimple especially. The major feature of
> MELT is his pattern matching on tree ability.
>
> Part of my work is to improve MELT (as I need some features which were
> not implemented), such as having handling pragma in MELT plugins or
> gluing some GCC dominance functions (from gcc/dominance.c)
>
> However, like the others students which answered to this thread, the
> main difficulty is understanding and eventually modifying GCC itself.
> That is quite time consumming, as you can have, even to write a simple
> patch, to know well several parts of GCC (I am often grepping for a
> given struct or function). I also thing that each pass could be more
> detailled. Sometimes, it is hard to find a pass in the code from it's
> dump file name.
>
> I had to write a patch for the trunk, to add a data field to pragma
> handlers, this was quite a simple patch, however, I had to make it
> compatible with the fact that one of the function I was modifying was
> used many times in differents parts of GCC.
>
> Currently, I need to understand how works C++ mangling if I want my
> plugin to work with C++ (I am going to write a new mail about this),
> as I need to convert the string given by the user into the function(s)
> that it represents.
>
> About the state of my plugin, I have written the core of the module.
> It can use user's input from different entries (I have already written
> an entrie using the pragma, and an entrie using direct argument (given
> when invoking GCC), searchs if it matchs a corresponding test and
> generate a new GCC Pass from this. This new pass is inserted after ssa
> pass, as I got a representation which suits to me (I can find the
> information my tests need). But the choice of inserting here is quite
> empirical (would have you choice another pass?). The plugin is mainly
> tested for C code, even if I would like to have C++ working too.
>
> I have started implementing tests, for the moment I use a test which
> checks that there is a test checking for a NULL pointer (if resCall ==
> NULL for exemple) after a given function call, and return a warning if
> there is no test.
>
> I have also started implementing a test checking that a given is
> immediatly followed by another given function. I would also try to add
> a test checking that a call to a given function is followed by a call
> to another function in the same function bodies, I know that I will
> have to handle the basic block hierarchie, that why I glued dominance
> functions into MELT.
>
> I think, I am in time, however, this is sometimes hard to evaluate:
> for exemple, I don't know really how much time, I will take to manage
> C++ function in my plugin.
>
> I feel sad, not being able to use IRC from my web access (in my
> school)... and so only communicating by mail with the GCC community.
> However, I thanks the community for their answer and support. The
> point to improve, I guess, is having more people reviewing patchs
> (even if, I understand that it requires a lot of time and skills).
>
> Thanks
>
> Pierre Vittet
>
>
> On 05/07/2011 21:08, Daniel Carrera wrote:
>> Hello Philip + Dimitrios
>>
>> Thanks for your posts. I am another GSOC student. I am working on the
>> Fortran front-end of GCC (gfortran). Like most GFortran developers, my
>> background is more in the natural sciences (astrophysics in my case)
>> rather than computer science.
>>
>> My project is to help add coarray support for GFortran. Coarrays are a
>> cool new feature in the Fortran 2008 standard that give Fortran native
>> support for parallel programming (as opposed to using MPI or OpenMP).
>> Scientific simulations (especially in parallel clusters) are the bread
>> and butter of Fortran.
>>
>>
>> Learning how GCC works has been difficult but rewarding. My work is
>> split between the libgfortran library, which is straight forward enough,
>> and the Fortran front-end, which at first looked like gobbledygook.
>> Today I can actually understand most front-end functions when I read
>> them, but it took a long time to get to this point. GCC has a scary
>> learning curve.
>>
>> The libgfortran library is more forgiving for the beginner. We are using
>> MPI as the backend to implement coarrays and I have very much enjoyed
>> learning MPI.
>>
>> So far my contributions have been modest, but now that I've crossed much
>> of the learning curve, I feel optimistic. To an extent the progress has
>> to be a bit slow because we are looking at the new Fortran standard and
>> thinking about the best way to add features.
>>
>> Cheers,
>> Daniel.
Hi all,
I am one of GSOC students. We have started the project with doing some
experiments for checking the compatibility of OpenMP threads with
[trans-mem] branch of GCC.
We made a presentation
(http://www.gsd.inesc-id.pt/~mcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf
<http://www.gsd.inesc-id.pt/%7Emcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf>)
at EuroTM meeting at Paris
(http://www.eurotm.org/1st-plenary-meeting-in-paris/program). It was
very useful for project's future perspective.
However, I got accepted as a PhD and I have lots of urgent
organizational and administrative issues and pre-requisite exams for
PhD program to completed before the mid of August so I have no chance
to go on with project until mid of August.
But I am optimistic for the project and contribution to GCC even if I
do not have an overlapping time-schedule with GSOC.
Best Regards
Ismail KURU
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
[not found] ` <CABck2NNXWNKCRbC9kv8TkNvgpgOcE_cjg-NKqO3=pb-x_okAqQ@mail.gmail.com>
@ 2011-07-12 17:29 ` Philip Herron
0 siblings, 0 replies; 12+ messages in thread
From: Philip Herron @ 2011-07-12 17:29 UTC (permalink / raw)
To: ismail kuru; +Cc: Paolo Bonzini, Dimitrios Apostolou, gcc
On 10 July 2011 22:42, ismail kuru <aptaliso@gmail.com> wrote:
> Hi all,
> I am one of GSOC students. We have started the project with doing some
> experiments for checking the compatibility of
> OpenMP threads with [trans-mem] branch of GCC.
> We made a presentation
> (http://www.gsd.inesc-id.pt/~mcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf)
> at EuroTM meeting at Paris
> (http://www.eurotm.org/1st-plenary-meeting-in-paris/program). It was very
> useful for project's future perspective.
> However, I got accepted as a PhD and I have lots of urgent organizational
> and administrative issues to complete before the mid of August so I have
> no chance to go on with project until mid of August.
> But I am optimistic for the project even if I do not have a overlapping
> time-schedule with GSOC.
>
Yeah my last years Gsoc time management i found hard mostly because i
had a really bad sleeping pattern and i would grind out and work way
too much for like 2 weeks then spend 2 days sleeping and then same
thing again.
It was kind of stupid but this year i treat it like 9-5 but i can seem
myself working on a lot more once i get to parts when its mostly a
grind at the moment i am filling in and fixing lots of awkward pieces
which takes time.
But Gsoc is very flexible so i wouldn't worry about having to do
things in RL if you feel your are on track in your own time frame then
your ok.
--Phil
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-06 9:39 ` Pierre Vittet
2011-07-06 15:10 ` Dimitrios Apostolou
2011-07-10 22:32 ` Ismail
@ 2011-07-16 22:42 ` Gerald Pfeifer
2 siblings, 0 replies; 12+ messages in thread
From: Gerald Pfeifer @ 2011-07-16 22:42 UTC (permalink / raw)
To: Pierre Vittet; +Cc: gcc
Pierre,
On Wed, 6 Jul 2011, Pierre Vittet wrote:
> I feel sad, not being able to use IRC from my web access (in my
> school)... and so only communicating by mail with the GCC community.
are you aware of http://www.mibbit.com/ and similar clients, that just
use plain http, or are you saying that, too, is being blocked by your
school? (I just tried the above, and it works fine for me.)
Gerald
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-06-30 10:14 GSOC - Student Rondup Philip Herron
2011-07-05 16:59 ` GSOC - Student Roundup Dimitrios Apostolou
@ 2011-07-17 13:54 ` Franck Z
2011-07-17 16:30 ` Philip Herron
1 sibling, 1 reply; 12+ messages in thread
From: Franck Z @ 2011-07-17 13:54 UTC (permalink / raw)
To: Philip Herron; +Cc: gcc
Hello!
Technically, I'm not a GSOC Student, but I've also started delving recently
into the depths of gcc's source code.
Would you mind I if joined your IRC Chat in case I'm stuck somewhere in my
understanding of the source ?
There are indeed occasional questions that I don't dare to ask here, given
that I'm not as an accomplished programmer as any one of you is.
I hope you'll indulge me if I here introduce myself to you, although I
surely wouldn't meet GSOC's application criteria.
My name is Franck (Z is not my last name initial, I keep using a pseudo
because I've been using it on other social websites, where it is advocated
not to give any personal information, mainly Yahoo Answers). For now, it
doesn't hurt, as I'm far from proposing any patch! I'll meet FSF
requirements whenever I'm asked to.
I'm French. I graduated in the 90's and have been keeping occasional links
with computer sciences, following my curiosity, but never really tackled on
an industrial programming project on my own.
The fact is that, a few months ago, I eventually dared to download gcc's
source and subscribe to the gcc list, again out of curiosity, after reading
a post from Walt Brian about C/C++ compilers being much slower than
compilers for other programming languages.
I skimmed up was I'm leaning toward in a former message here:
http://gcc.gnu.org/ml/gcc/2011-06/msg00141.html
In fact, I may opt for another way of doing, using event programming
techniques between "make" and "gcc". Namely, instead of having "make" call
"gcc" through several jobs, I consider having "gcc" being launched only once
by "make" and then ask "make" about the tasks he should do, up to the
numbers of jobs allowed when "make -j..." was invoked.
It seems to me that this would allow, besides the original aspect of how
disk is accessed throughout a compilation session, to include a
task-oriented parallelism in compilation tasks, with Intel's TBB library,
based on the "natural" organisation of a compilation around *.c (or such)
files.
Actually, my main issue with respect to understanding gcc's source, is that
my knowledge of C isn't precise enough to meet gcc's writing standards, for
instance what I suspect to be workarounds to silent out some spurious
warning messages in the compilation.
I keep to the front-end part, so it's easier for now. Still, I'm *slightly*
overwhelmed by the numerous tools and libraries I need to get precisely
acquainted with, before I'm able to hack in (git, autogen, ...). Don't mock
me, but, as a matter of fact, gcc's source being gigantic is part of my
pleasure! I've enjoyed browsing similarly wide and intricated sources in the
past years (for instance OCaml or TBB) and I relished learning from these.
I hope I don't put too much hope in what I can do and that one day, I'll
help a little teeny bit. :-)
Franck Z
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-17 13:54 ` Franck Z
@ 2011-07-17 16:30 ` Philip Herron
2011-07-18 18:01 ` Franck Z
0 siblings, 1 reply; 12+ messages in thread
From: Philip Herron @ 2011-07-17 16:30 UTC (permalink / raw)
To: Franck Z; +Cc: gcc
On 17 July 2011 13:21, Franck Z <franck.z.gcc@orange.fr> wrote:
> Hello!
>
> Technically, I'm not a GSOC Student, but I've also started delving recently
> into the depths of gcc's source code.
>
> Would you mind I if joined your IRC Chat in case I'm stuck somewhere in my
> understanding of the source ?
Yeah of course its very friendly. The gcc-help or this list is also
great for help where maybe someone wasn't able to help in the irc
channel.
>
> There are indeed occasional questions that I don't dare to ask here, given
> that I'm not as an accomplished programmer as any one of you is.
>
> I hope you'll indulge me if I here introduce myself to you, although I
> surely wouldn't meet GSOC's application criteria.
Dont worry.
>
> My name is Franck (Z is not my last name initial, I keep using a pseudo
> because I've been using it on other social websites, where it is advocated
> not to give any personal information, mainly Yahoo Answers). For now, it
> doesn't hurt, as I'm far from proposing any patch! I'll meet FSF
> requirements whenever I'm asked to.
>
> I'm French. I graduated in the 90's and have been keeping occasional links
> with computer sciences, following my curiosity, but never really tackled on
> an industrial programming project on my own.
>
> The fact is that, a few months ago, I eventually dared to download gcc's
> source and subscribe to the gcc list, again out of curiosity, after reading
> a post from Walt Brian about C/C++ compilers being much slower than
> compilers for other programming languages.
>
> I skimmed up was I'm leaning toward in a former message here:
> http://gcc.gnu.org/ml/gcc/2011-06/msg00141.html
>
> In fact, I may opt for another way of doing, using event programming
> techniques between "make" and "gcc". Namely, instead of having "make" call
> "gcc" through several jobs, I consider having "gcc" being launched only once
> by "make" and then ask "make" about the tasks he should do, up to the
> numbers of jobs allowed when "make -j..." was invoked.
Interesting idea i have a feeling i read something about this recently
I'm not really sure how it could work in how you could query make to
get the next source, but at the same time sounds like it could be a
niche piece of tech although you could maybe just have it as a switch
in the front-end. It could possibly be handled at compiler driver
level.
> It seems to me that this would allow, besides the original aspect of how
> disk is accessed throughout a compilation session, to include a
> task-oriented parallelism in compilation tasks, with Intel's TBB library,
> based on the "natural" organisation of a compilation around *.c (or such)
> files.
>
> Actually, my main issue with respect to understanding gcc's source, is that
> my knowledge of C isn't precise enough to meet gcc's writing standards, for
> instance what I suspect to be workarounds to silent out some spurious
> warning messages in the compilation.
>
> I keep to the front-end part, so it's easier for now. Still, I'm *slightly*
> overwhelmed by the numerous tools and libraries I need to get precisely
> acquainted with, before I'm able to hack in (git, autogen, ...). Don't mock
> me, but, as a matter of fact, gcc's source being gigantic is part of my
> pleasure! I've enjoyed browsing similarly wide and intricated sources in the
> past years (for instance OCaml or TBB) and I relished learning from these.
>
> I hope I don't put too much hope in what I can do and that one day, I'll
> help a little teeny bit. :-)
Cool, happy hacking
--Phil
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GSOC - Student Roundup
2011-07-17 16:30 ` Philip Herron
@ 2011-07-18 18:01 ` Franck Z
0 siblings, 0 replies; 12+ messages in thread
From: Franck Z @ 2011-07-18 18:01 UTC (permalink / raw)
To: Philip Herron; +Cc: gcc
> Cool, happy hacking
>
> --Phil
Thank you very much!
Apparently, it's best to communicate&contribute here with one's real name.
So, here it is: Franck Louarn.
I'm trying to update my e-mail accounts so that I'm no longer identified
here as Franck Z. If I fail, I'll start again with another address.
Cheers.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-07-18 17:31 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-30 10:14 GSOC - Student Rondup Philip Herron
2011-07-05 16:59 ` GSOC - Student Roundup Dimitrios Apostolou
2011-07-05 19:08 ` Daniel Carrera
2011-07-06 9:39 ` Pierre Vittet
2011-07-06 15:10 ` Dimitrios Apostolou
2011-07-10 22:32 ` Ismail
2011-07-16 22:42 ` Gerald Pfeifer
2011-07-07 15:53 ` Paolo Bonzini
[not found] ` <CABck2NNXWNKCRbC9kv8TkNvgpgOcE_cjg-NKqO3=pb-x_okAqQ@mail.gmail.com>
2011-07-12 17:29 ` Philip Herron
2011-07-17 13:54 ` Franck Z
2011-07-17 16:30 ` Philip Herron
2011-07-18 18:01 ` Franck Z
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).