This is the mail archive of the
mailing list for the Cygwin project.
RE: G++ for CygWin
- From: "Dave Korn" <dk at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Wed, 28 Jan 2004 11:35:27 -0000
- Subject: RE: G++ for CygWin
> -----Original Message-----
> From: cygwin-owner On Behalf Of Dylan Cuthbert
> (gnu separated out its frontend from its backend with v3.3)
Not quite sure what you're getting at here. I can't see anything in the
architecture of v3.3 that's changed from how it's always been done, or
anything that could be described as having been separated into frontend and
backend; nor could I find anything at the gcc website in the release
announcement for 3.3 that I could understand as meaning what you say there.
For reasons I'll explain later, I think you're probably misusing the terms
front- and back-end.
gcc.exe and g++.exe have always been around (or at least, for quite a long
time, waaay back into v2 days at the very least); they're driver programs
which merely parse command line options and call out and pass parameters and
filenames down to the actual compiler, assembler and linker programs.
AFAIR, the only significant difference between gcc.exe and g++.exe is that
gcc.exe assumes files are C by default, and hence calls out to the cc1.exe
compiler, whereas g++ assumes programs are C++ by default, and so calls out
to cc1plus.exe. Oh, and g++ also adds a few directories to the default
includes search path, and adds -lstdc++ to the linker line.
This is more-or-less the same thing that happens when you use the -x
language option: "gcc.exe -xc++ <files, options>" amounts to almost the same
thing as "g++.exe <files, options>", and similarly "g++.exe -xc <files,
options>" is almost the same as "gcc.exe <files, options>".
If you want to see for yourself, use the "-v" option to gcc or g++, which
causes them to output the command lines they're using to call the
subprograms with. I just gave it a quick test, and the only difference I
could see is that the -x language option doesn't alter whether libstdc++ is
linked in or not: i.e. "gcc.exe -xc++" doesn't automatically add -lstdc++
like g++.exe does, and "g++.exe -xc" still adds -lstdc++ to the link despite
calling the c rather than c++ compiler. This may actually be a minor bug or
it may be as intended; I don't know whether the -x option is meant to be
exactly equivalent to using gcc or g++.
It's probably better to refer to them as 'compiler drivers' and the actual
compiler programs themselves - cc1.exe and cc1plus.exe, which live in
/lib/gcc-lib/<host-triplet>/<gccversion>/ as 'compilers' or 'compiler
subprograms'. The terms 'frontend' and 'backend' already have a technical
meaning in gcc jargon; the frontend is the language-specific part of the
compiler, that knows how to parse C or java or fortran or whatever, and
converts it into a language-agnostic intermediate representation (known as a
tree); the backend is the target-specific part that knows how to convert the
tree into suitable assembler output for a given target machine[*].
These front- and back-ends have *not* been separated out; cc1.exe, for
example, combines the c-specific frontend and the i686-pc-cygwin backend
into one executable. It takes C as input and gives assembler as output,
combining frontend and backend into one inseparable unit. Cc1plus.exe
combines the C++-specific frontend and the same backend; jc1.exe combines
the java-specific frontend with the same backend.
Here endeth the lesson on the internal structure of gcc and compiler
terminology. Hope it was at least mildly interesting.
Can't think of a witty .sigline today....
[*] Actually, I've oversimplified here, just a little. The compiler
infrastructure calls the frontend to generate a tree; it then converts that
tree to a second internal representation known as RTL; that RTL is then
passed to the backend which generates sequences of assembler instructions
corresponding to it.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html