Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: Subject: RE: G++ for CygWin Date: Wed, 28 Jan 2004 11:35:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: X-OriginalArrivalTime: 28 Jan 2004 11:35:27.0421 (UTC) FILETIME=[D39466D0:01C3E592] > -----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++ " amounts to almost the same thing as "g++.exe ", and similarly "g++.exe -xc " is almost the same as "gcc.exe ". 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/// 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. cheers, DaveK -- 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 Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/