GSOC - Student Roundup

[Franck Z]

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