This is the mail archive of the gcc@gcc.gnu.org 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: Dealing with compilers that pretend to be GCC


On 24/01/12 17:32, Joseph S. Myers wrote:
On Thu, 19 Jan 2012, Ludovic Courtïs wrote:

It turns out that ICC manages to build a working GCC plug-in, so after

I would say there is some conceptual confusion here (based on this sentence, without having looked at the autoconf macros you refer to). Logically there are two or three different compilers involved:

* The compiler (host-x-target) into which a plugin would be loaded.  This
is the one that needs to be GCC.

* The compiler (build-x-host) building the plugin.  There is no particular
reason it should need to be GCC, if sufficiently compatible with the
compiler that built the host-x-target compiler that will load the plugin.

Users of the dragonegg plugin (what few there are!) are often confused by this, thinking that they need to build the plugin with the compiler into which the plugin is going to be loaded, which of course is not the case. In fact if the target compiler (host-x-target) is a cross-compiler, for example running on x86 and producing code for ppc, there is no way it can be used to compile the plugin, since that needs to run on x86 not on ppc.

Ciao, Duncan.


* If you are testing a compiler for plugin support by running it in some way, that will be a build-x-target compiler that is intended to be configured in the same way as the final host-x-target compiler. Such a build-x-target compiler will be used to build target libraries in a Canadian cross build of GCC.

So always think carefully about which compiler you wish to test - and what
the relevant properties of that compiler are.



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