This is the mail archive of the
mailing list for the GCC project.
Re: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 1:08 PM, Jeff Law <email@example.com> wrote:
> On 01/24/2013 10:23 AM, Alexandre Oliva wrote:
>> On Jan 23, 2013, Aldy Hernandez <firstname.lastname@example.org> wrote:
>>> an internal training program Jeff Law devised over a decade ago (*)
>>> [Before anybody asks, the training program is probably no longer
>>> relevant. So no fair bugging Jeff about it :)].
>> Yeah. It was focused on the RTL/md part of GCC, with a few simple
>> assignments that amounted to implementing changes in the mn10300-elf
>> port. That was before AM33/2.0 came up; before gimple and SSA, long
>> before tuples and mode iterators. GCC was a very different beast then.
>> The course made me more of an RTL person, which still makes me hope this
>> tree-based stuff a fad and that some day we'll get back to our senses
>> and do SSA in RTL ;-)
> And the thing to remember about that training program is that it was geared
> strictly towards backend porting. ie, new version of the frob chip comes
> out with some new instructions, we need to support them. That was a
> significant component of Cygnus's business back then.
> As Alex notes, GCC today is dramatically different and hacking new
> instructions into existing backends isn't nearly as important as it was 10+
> years ago. Training around GCC's implementation of SSA, how GCC's
> optimization pipeline works, plugins, the propagation engine would be far
> more interesting and useful.
> When we made the change from RTL centric to gimple, one of the goals was to
> make GCC more approachable. I would argue to some degree that was
> successful, but not nearly as much as I'd hoped.
> Of course that was over 10 years ago and we're at another point where some
> significant architectural changes to GCC are needed. Google has kicked some
> stuff around and Red Hat is kicking stuff around toward that goal.
> I believe the ultimate focus will be on improving modularity for passes
> prior to gimple->rtl expansion and to make any notable progress we're going
> to have to tackle the type system problems. It won't be sexy or fun, but to
> keep GCC relevant, it's one of the things we need to tackle.
I do see, however, a few areas where Clang/LLVM have gone that I do
not think GCC is currently thinking of entering: "toolability" (for
the lack of a better term). Clang's design follows a different path
than g++. It's not just a code generating parser, it is a pure parser
that also generates code. The difference makes it suitable for any
kind of tool that needs to understand C++: static analyzers, code
re-formatters, syntax highlighters, and other similar tools.
Additionally, it is designed as a library, so it can be embedded into
That is a need that g++ cannot currently satisfy. With plugins, one
could do something along those lines, but they are heavier, and are at
the mercy of the full compiler. Additionally, g++ has very low
fidelity wrt the input program; it breaks down the original C++ input
That is not necessarily a bad thing for g++. But, to effectively
compete in those areas, it will need to be significantly re-organized.
LLVM has similar properties, at least as far as the middle end of the
compiler is concerned. GCC still has an edge wrt backend portability.