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
