C++ compilers and back/front ends

Hello.

for my own education I am curious what compilers use which C++ front-end and backend. Can you enlighten me where the following technologies are used and what hallmarks/advantages they have if any?

Open64 - is it backend, front-end, or both? Which compilers use it? I encounter it in cuda compiler.
EDG - as far as I can tell this is a frontend use by Intel compilers and Comeau. do other compilers use it? I found quite a few references to it in boost source code.
ANTLR - this is general parser. Do any common compilers use it?

Regarding compilers:

with front-end/backend does gcc compiler suite uses? does it have common heritage with any other compiler?
what front-end/backend PGI and PathScale compilers use?
what front-end/backend XL compiler uses (IBM offering).

in-depth links on the Internet or your personal know-how would be great. I did some Google searching, but information I generally encountered was rather superficial.

Thanks.

EDG is a front-end used by Intel and Comeau. See EDG's list of customers for other users.

ANTLR is a parser generator. I'm not aware of any C++ compiler built around a parser that was built with ANTLR (that doesn't mean it couldn't exist though).

Gcc is a suite of compilers, with front ends for C, C++, Fortran, Ada, Java, etc., and back-ends for more processors than I'd care to think about.

Open64 is also a suite of compilers including several front-ends (for C, C++, Fortran, and possibly others I don't remember at the moment) and back-ends (targeting X64, Itanium, ARM, and, again, probably others I don't remember and/or don't know about). I believe its origin (pun noted by not intended) is SGI's compiler(s). I seem to remember reading something hinting that Open64 was derived from some version of the gcc front end(s), but offhand I don't know 1) how similar it remains to gcc internally, or 2) the version of gcc from which it derived -- but it's been around long enough that I'd guess it was gcc 3.x at the most recent, and quite possibly gcc 2.x.

I believe PathScale has created at least one compiler derived from Open64, but they may have others as well.

As far as I know, IBM's compiler is entirely their own creation. I'd guess IBM's (now discontinued) VisualAge for C++ shared some heritage/development/code with XL C++, but don't know that for sure, and can't even begin to guess at the extent of it, even assuming it's true.

thanks .With nvcc (open 64) I get major problems when trying to use boost type traits (or anything that includes it). hopefully I will have some reference when looking for compiler workarounds

aaa 2010-04-11 20:42:17

C++ isn't LALR, so that's why (name your favorite parser generator) isn't used for the front end. ANTLR works based on LL(*) instead of LALR, but I stink that also isn't sufficient for some of C++'s trickier syntax. C++ grammar isn't context-free, which is a requirement for most generalized parser generators.

Ben Voigt 2010-04-12 06:41:17

@Ben:While that's pretty accurate with respect to most parser generators, there are a few that should be able to handle C++. I'm reasonably certain C++ should fit within the (few) constraints of a GLR grammar. A few generators can deal with GLR grammars (e.g., Elkhound).

Jerry Coffin 2010-04-12 14:24:13

@Jerry: From http://scottmcpeak.com/elkhound/: <quote>GLR works with any context-free grammar</quote> C++ isn't context-free, so not even Elkhound can parse it. Not to say that it isn't a useful part of the task, but I believe you end up with lexed tokens parsed down to a set of possible meanings, and then the contextual analyzer finishes the parsing process as it builds symbol tables, etc.

Ben Voigt 2010-04-12 14:42:30

@Ben:Yes and no -- C++ has context-dependent semantics (e.g. the infamous "most vexing parse"), but a parser doesn't *need* to deal with that -- it only has to accept well formed code and reject malformed code. From that perspective, C++ is (or can be treated as) context free -- though you have to "sort out" more later in the compiler if you do that.

Jerry Coffin 2010-04-12 15:11:39

A parser that doesn't distinguish "most vexing parse" isn't a complete parser. Like I said, such a quasi-parser is still very useful, but the output still isn't fully parsed, the contextual analyzer has to finish the job.

Ben Voigt 2010-04-12 23:34:29

@Ben:not really true -- determining meaning is the domain of semantic analysis. Yes, we'd generally *prefer* that a parser make the semantic analysis easy, but it's not required for a parser to qualify as a parser.

Jerry Coffin 2010-04-13 01:16:26

A parser is supposed to determine what "part of speech" each word has in a sentence, or what function each token has in source code. See http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-2 and http://www.merriam-webster.com/dictionary/parse

Ben Voigt 2010-04-13 02:43:45

@Ben:quoting Yossi Kreinin as an authority hardly does your cause any good. In any case, it simply comes down to a question of how you choose to define "parser". Frankly, I just don't much care -- if you prefer to think of cfront (for one example) as not having had a parser because it was developed using yacc, so be it.

Jerry Coffin 2010-04-13 03:10:44

@Jerry: In general, that page in full of FUD. But it does have several good examples of context-dependent parse. And he's absolutely right that the abstract syntax tree is totally different in those cases. Really, I think we're in agreement on this issue: a parser generator can be very helpful in processing C++ but the contextual parts of the grammar have to be more fully processed by later steps.

Ben Voigt 2010-04-13 16:36:22

@Ben:well put, and quite right.

Jerry Coffin 2010-04-13 17:03:20

ansaurus

tags:

views:

answers:

C++ compilers and back/front ends

related questions