This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC - Student Roundup

On 17 July 2011 13:21, Franck Z <> 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

> 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:
> 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

> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]