Re: gfortran / gdb question
actually, I just find out that this seems a 4.4 issue, compiled with 4.3 the gdb session just goes fine... I also seem to be able to debug small examples with either 4.3 or 4.4, just CP2K seems to cause troubles (as usual ;-) I've filed PR39073 for this, somehow hope this can be solved before release (ugh.. show it is not Fortran (I've made it debug) and declare it P1?) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
Stack traces and sections in PE/COFF
I would like to add stack traces to my program (Cygwin/MinGW, Windows XP). I've already implemented a stack walker, but there is an open problem with symbol name/line lookup. The compiler (GCC 4.4-trunk) emits DWARF2-compatible debug information, but I don't know how to reach the appropriate sections (especially ".debug_info") within the executable. The PE header walker is able to dump PE sections, but they have strange, numeric names, e.g.: sec[0]: name = .text sec[1]: name = .data sec[2]: name = .rdata sec[3]: name = .bss sec[4]: name = .idata sec[5]: name = /4 sec[6]: name = /19 sec[7]: name = /35 sec[8]: name = /47 sec[9]: name = /61 sec[10]: name = /73 sec[11]: name = /86 sec[12]: name = /97 sec[13]: name = /108 On the other hand, the DWARF sections are available in the file -- a hexdump viewer can locate them, as well as objdump. Could somebody please tell me what should I do in order to get to the DWARF sections from this point? Any documentation will be appreciated. Best regards, Piotr Wyderski
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Sean Callanan wrote: 1- Agree on a common API and document it in http://gcc.gnu.org/wiki/GCC_PluginAPI So to get the ball rolling, here are some comments on the API as documented: - (1) register_callback is an unnecessary API. It's already possible to use dlsym() to get a pointer to a symbol in a plug-in. A plug-in could export a function symbol corresponding to each hook it is interested in; that way a plug-in would simply have things like void HOOK_PASS_MANAGER_SETUP(...) instead of needing to register that callback. Equivalently, a global data structure in the plug-in could map hook UIDs to function pointers, giving the same effect. This latter approach would provide very elegant hook versioning. Sounds good to me. (2) It would be very nice to be able to store trees between passes; right now, our custom version of GCC has a separate garbage-collection root for plug-ins so that they can store data between passes. Cool, we'd like that too. (3) The -fplugin-arg argument is one way to do arguments. We do it as -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:... We also have a magic argument called FILE that lets you load arguments from a file. I think it's a little more convenient to use a separate argument for plugin arguments. However we still end up having to split that up into multiple arguments in many case, so you are probably right here too. (4) We strongly support the user () GCC attribute. - As a second note, we have some debugging tools we could contribute as soon as an API is fixed, including a GIMPLE visualizer with GDB integration. We also have a file (called parameter.def) which formalizes the macros that are valid for each type of GIMPLE tree node. We use this .def file extensively when handling trees in a generic way (such as for pretty-printing). Interesting. I took a completely opposite way of using GTY tags to reflect GIMPLE into JavaScript, which then pretty-prints GIMPLE(among other things) by porting the said macros to JS. https://developer.mozilla.org/en/Treehydra However any formalization should make my life easier. Sean, I agree with you and I think others will too, so please go ahead and make your API modifications on the wiki Taras
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/09 10:06 PM, Sean Callanan wrote: > (1) register_callback is an unnecessary API. It's already possible to > use dlsym() to get a pointer to a symbol in a plug-in. A plug-in could > export a function symbol corresponding to each hook it is interested in; > that way a plug-in would simply have things like > > void HOOK_PASS_MANAGER_SETUP(...) Mozilla currently uses only dlsym, and it's limiting. We have several unrelated analysis scripts loaded throught the same binary plugin. The binary plugin doesn't know in advance which passes the plugin wants to see. To implement this properly, we'd have to have which want to use the same callback. It's possible for the plugin to implement every possible dlsym entry point and then farm the calls out to each individual script pass internally, but since GCC is already going to have to maintain a list of callbacks, it seems better to piggyback on the list GCC already maintains. I agree that the current callback proposal seems overly generic. Perhaps registering specific hooks into the pass manager and other plugin targets makes more sense? typedef (void pluginpasshook)(tree t, void *data); /* implemented in the pass manager */ register_plugin_event_after_pass(enum tree_pass, pluginpasshook fn, void* data) Then, plugins would implement only a single entry point. GCC would inform the plugin of the arguments passed to it, and the plugin would register callbacks to perform its actual work. /* implemented in the plugin */ void gcc_plugin(const char *arguments); > instead of needing to register that callback. Equivalently, a global > data structure in the plug-in could map hook UIDs to function pointers, > giving the same effect. This latter approach would provide very elegant > hook versioning. What kind of verisioning? I don't think that having a single compiled plugin work with multiple versions of GCC should be a goal. > (3) The -fplugin-arg argument is one way to do arguments. We do it as > > -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:... > > We also have a magic argument called FILE that lets you load arguments > from a file. I like this better than the current solution: with the current proposal it's hard to tell which -fplugin-arg is supposed to go with which -fplugin. I'm a little worried about the colon separator. Windows file paths may legally have colons. Is there some separator character (semicolon?) which is not part of a path on any platform? Perhaps we shouldn't worry about it since -rdynamic doesn't work on Windows anyway. - --BDS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFJh0ZOSSwGp5sTYNkRAkn6AJ9e4zMwlZIrpdX7XUPDCfR0+56EYACfQW9f vMxuuIrJyP6O4hjo9b+fVwo= =OxHa -END PGP SIGNATURE-
gcc 4.5 ... && 32 build on 64
Two quick questions: (1) Is the feature roadmap for 4.5, 4.6 ... published anywhere (2) What is the recommended way to force 32 bit build on 64 eg 86_64 and will it work with libtool and all. I have a solution but its very ugly! -- Greetings, Brian
Re: help needed on gcc instruction scheduling with unspec_volatile()
raja.sal...@iap-online.com writes: > In gcc, while instruction scheduling can it be possible to suspend the > scheduling for some instructions ? or No. You can turn off instruction scheduling for the entire compilation. You can use #pragma GCC optimize to turn scheduling off for a specific function. But there is no way to turn it off for some instructions within a function but not others. > Is there a way to make the instruction has to allocate to run without > using the scheduler for particular instruction ? I don't understand the question. > Currently there is RTL template in machine description unspec_volatile(). > If the instruction is scheduled using this, does this make the instruction > out of scope of scheduler ? Nothing is out of scope of the scheduler. Using unspec_volatile in the RTL template makes the instruction a scheduling barrier and a memory barrier. Ian
Re: Stack traces and sections in PE/COFF
Piotr Wyderski writes: > The PE header walker is able to > dump PE sections, > but they have strange, numeric names, e.g.: > > sec[5]: name = /4 That strange numeric name is used when the section name is more than 8 characters long. The value after the '/' is an offset into the string table. Ian
Re: New GCC Runtime Library Exception
* Ian Lance Taylor: >>> Your argument here seems to be that linking against libgcc makes a >>> program be covered by the definition of "GCC" in the runtime library >>> license. >> >> Right. Why do you think this would not be the case? libgcc is part >> of GCC, so a program linking to libgcc is a derivative work of libgcc, >> and therefore GCC. That's precisely why we need an exception in the >> first place because this outcome is not desired (a free operating >> system could not distribute compiled binaries of C++ programs using >> OpenSSL, for instance--in contrast to proprietary operating systems, >> the system library exception cannot be used). > > That is the cycle which the runtime library license is intended to > break, so now I'm just confused. For the self-hosting compiler linking against libgcc, the exception basically says that the compiler qualifies for the linking exception if it qualifies for the linking exception. I think this *is* confusing, and I don't know what it means for the status of the compiler (e.g., if a hypothetical QPL-licensed ocamlopt.opt compiler linking against libgcc would be legal to redistribute or not).
Re: GCC Runtime Library Exception
* Ian Lance Taylor: > After the e-mail flurry, here is my personal summary of the issues > regarding the GCC Runtime Library Exception > (http://www.gnu.org/licenses/gcc-exception.html). Thanks! > One way to resolve this might be to say that a compilation process > is Eligible so long as the input to GCC was produced exclusively > using programs which are not themselves derived from GCC. I don't > think that this approach would weaken the goals of the runtime > library exception. This is still somewhat unclear as long as it's not clearly said that for the purpose of determing eligibility in this way, portions of GCC which are potentially covered by this exception are not taken into account. This addition would break the vicious circle on self-hosting, GNU-like systems.
Re: GCC Runtime Library Exception
On Mon, Feb 02, 2009 at 02:00:33PM -0800, Florian Weimer wrote: > * Ian Lance Taylor: > > > After the e-mail flurry, here is my personal summary of the issues > > regarding the GCC Runtime Library Exception > > (http://www.gnu.org/licenses/gcc-exception.html). > > Thanks! > > > One way to resolve this might be to say that a compilation process > > is Eligible so long as the input to GCC was produced exclusively > > using programs which are not themselves derived from GCC. I don't > > think that this approach would weaken the goals of the runtime > > library exception. > > This is still somewhat unclear as long as it's not clearly said that > for the purpose of determing eligibility in this way, portions of GCC > which are potentially covered by this exception are not taken into > account. This addition would break the vicious circle on > self-hosting, GNU-like systems. Ian's summary of the issues has been passed on to the SC, FSF and SFLC, to determine whether any fixes are appropriate. Since legal issues are involved, it might take a while, but they are paying attention to the concerns raised.
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
I updated the page http://gcc.gnu.org/wiki/GCC_PluginAPI. I cleaned up the formatting and added syntax coloring where appropriate. I also changed the API to reflect the comments so far, making it easier to register many callbacks at once while preserving the ability to register callbacks dynamically as needed. I volunteer to maintain this page. (That isn't to say no-one should edit it, just that I'll keep it neat and make threads if there are problems with the API.) Sean On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/09 10:06 PM, Sean Callanan wrote: (1) register_callback is an unnecessary API. It's already possible to use dlsym() to get a pointer to a symbol in a plug-in. A plug-in could export a function symbol corresponding to each hook it is interested in; that way a plug-in would simply have things like void HOOK_PASS_MANAGER_SETUP(...) Mozilla currently uses only dlsym, and it's limiting. We have several unrelated analysis scripts loaded throught the same binary plugin. The binary plugin doesn't know in advance which passes the plugin wants to see. To implement this properly, we'd have to have which want to use the same callback. It's possible for the plugin to implement every possible dlsym entry point and then farm the calls out to each individual script pass internally, but since GCC is already going to have to maintain a list of callbacks, it seems better to piggyback on the list GCC already maintains. I agree that the current callback proposal seems overly generic. Perhaps registering specific hooks into the pass manager and other plugin targets makes more sense? typedef (void pluginpasshook)(tree t, void *data); /* implemented in the pass manager */ register_plugin_event_after_pass(enum tree_pass, pluginpasshook fn, void* data) Then, plugins would implement only a single entry point. GCC would inform the plugin of the arguments passed to it, and the plugin would register callbacks to perform its actual work. /* implemented in the plugin */ void gcc_plugin(const char *arguments); instead of needing to register that callback. Equivalently, a global data structure in the plug-in could map hook UIDs to function pointers, giving the same effect. This latter approach would provide very elegant hook versioning. What kind of verisioning? I don't think that having a single compiled plugin work with multiple versions of GCC should be a goal. (3) The -fplugin-arg argument is one way to do arguments. We do it as -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:... We also have a magic argument called FILE that lets you load arguments from a file. I like this better than the current solution: with the current proposal it's hard to tell which -fplugin-arg is supposed to go with which -fplugin. I'm a little worried about the colon separator. Windows file paths may legally have colons. Is there some separator character (semicolon?) which is not part of a path on any platform? Perhaps we shouldn't worry about it since -rdynamic doesn't work on Windows anyway. - --BDS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFJh0ZOSSwGp5sTYNkRAkn6AJ9e4zMwlZIrpdX7XUPDCfR0+56EYACfQW9f vMxuuIrJyP6O4hjo9b+fVwo= =OxHa -END PGP SIGNATURE-
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
2009/2/2 Sean Callanan : > I updated the page http://gcc.gnu.org/wiki/GCC_PluginAPI. > Is there a reason for not using just -plugin=? What is with the -f*? Cheers, Manuel.
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Benjamin, On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote: It's possible for the plugin to implement every possible dlsym entry point and then farm the calls out to each individual script pass internally, but since GCC is already going to have to maintain a list of callbacks, it seems better to piggyback on the list GCC already maintains. You've got a very good point. I agree that the current callback proposal seems overly generic. Perhaps registering specific hooks into the pass manager and other plugin targets makes more sense? typedef (void pluginpasshook)(tree t, void *data); /* implemented in the pass manager */ register_plugin_event_after_pass(enum tree_pass, pluginpasshook fn, void* data) Hmmm, so could we unify tree_pass with the plugin_event structure from the API? Like, we'd add a special "virtual" pass for GCC entry and shutdown, that sort of thing. Then, plugins would implement only a single entry point. GCC would inform the plugin of the arguments passed to it, and the plugin would register callbacks to perform its actual work. /* implemented in the plugin */ void gcc_plugin(const char *arguments); This is nice. One thing we do in our system is separate the arguments into (non-unique) key-value pairs. This makes arguments as close to regular arguments as possible, in that they have both names and values. What kind of verisioning? I don't think that having a single compiled plugin work with multiple versions of GCC should be a goal. I mean versioning in the sense of "this hook used to provide one tree, now it provides two." I'm not talking about versioning the entire GCC API. I'm a little worried about the colon separator. Windows file paths may legally have colons. Is there some separator character (semicolon?) which is not part of a path on any platform? Perhaps we shouldn't worry about it since -rdynamic doesn't work on Windows anyway. Agreed. OS X paths can include semicolons, though. This is something we need to think about. Sean
Re: MIPS64 -msym32 and DWARF2_ADDR_SIZE
Eric Christopher writes: >>> So my question is whether the saving in the size of the debug info with >>> -msym32 is really worth the trouble here or should we just start generating >>> 64-bit addresses with -msym32? >> >> Generating 64-bit addresses would be fine with me FWIW. I'm not sure >> the current behaviour is exactly deliberate; it was probably just >> something I overlooked when adding -msym32. >> >> How about the patch below? I'll apply it in the next couple of days >> if there are no objections. >> > > Looks good to me. OK, thanks to you and Adam for the comments. Now applied. Richard
help needed on gcc instruction scheduling with unspec_volatile()
Hi, In gcc, while instruction scheduling can it be possible to suspend the scheduling for some instructions ? or Is there a way to make the instruction has to allocate to run without using the scheduler for particular instruction ? Currently there is RTL template in machine description unspec_volatile(). If the instruction is scheduled using this, does this make the instruction out of scope of scheduler ? Please help us to understand the above. Thanks in advance Raja Saleru
Re: GCC & OpenCL ?
Michael Meissner wrote: > I am just starting to think about adding OpenCL support into future versions > of > GCC, as it looks like a useful way of programming highly parallel type > systems, > particularly with hetrogeneous processors. At this point, I am wondering what > kind of interest people have in working together on OpenCL in the GCC > compiler? We (CodeSourcery) have been talking to our commercial partners about implementing OpenCL in GCC and trying to develop/assess the level of interest. As others have stated, our theory of operation here would be to have the compiler depend on a library API that could be implemented for GPUs or for ordinary multi-core CPUs. (Just as the libgomp API could be provided to the compiler without depending on POSIX threads.) Certainly, if there are others on this list interested in working on this, we'd be interested in talking to them. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
RFA: union with long double doesn't follow x86-64 psABI
Hi,
Gcc doesn't follow x86-64 psABI when passing and returing
union with long double:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
Gcc converts X87UP to SSE if X87UP is not preceded by X87.
I don't believe x86-64 psABI calls for it. I think psABI should
be updated with:
Index: low-level-sys-info.tex
===
--- low-level-sys-info.tex (revision 5122)
+++ low-level-sys-info.tex (working copy)
@@ -452,7 +452,9 @@ types works as follows:
\item Then a post merger cleanup is done:
\begin{enumerate}
\item If one of the classes is MEMORY, the whole argument is passed
in memory.
- \item If SSEUP is not preceeded by SSE, it is converted to SSE.
+ \item If X87UP is not preceded by X87, the whole argument is passed in
+memory.
+ \item If SSEUP is not preceded by SSE, it is converted to SSE.
\end{enumerate}
\end{enumerate}
The gcc patch is:
--- ./i386.c.x872009-02-02 15:36:01.0 -0800
+++ ./i386.c2009-02-02 15:58:57.0 -0800
@@ -4988,10 +4988,15 @@ classify_argument (enum machine_mode mod
&& (i == 0 || classes[i - 1] != X86_64_SSE_CLASS))
classes[i] = X86_64_SSE_CLASS;
- /* X86_64_X87UP_CLASS should be preceded by X86_64_X87_CLASS. */
+ /* If X86_64_X87UP_CLASS isn't preceded by X86_64_X87_CLASS,
+ everything should be passed in memory. */
if (classes[i] == X86_64_X87UP_CLASS
- && (i == 0 || classes[i - 1] != X86_64_X87_CLASS))
- classes[i] = X86_64_SSE_CLASS;
+ && (classes[i - 1] != X86_64_X87_CLASS))
+ {
+ /* The first one should never be X86_64_X87UP_CLASS. */
+ gcc_assert (i != 0);
+ return 0;
+ }
}
return words;
}
--
H.J.
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Sean Callanan wrote: Benjamin, On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote: It's possible for the plugin to implement every possible dlsym entry point and then farm the calls out to each individual script pass internally, but since GCC is already going to have to maintain a list of callbacks, it seems better to piggyback on the list GCC already maintains. You've got a very good point. I agree that the current callback proposal seems overly generic. Perhaps registering specific hooks into the pass manager and other plugin targets makes more sense? typedef (void pluginpasshook)(tree t, void *data); /* implemented in the pass manager */ register_plugin_event_after_pass(enum tree_pass, pluginpasshook fn, void* data) Hmmm, so could we unify tree_pass with the plugin_event structure from the API? Like, we'd add a special "virtual" pass for GCC entry and shutdown, that sort of thing. I'd like to warn against mixing pass manager passes and plugin callbacks. The pass manager needs a host of API improvements to be able to enumerate/reorder/remove/etc passes. However, the task of the plugin api should be to load outside code into GCC. The rest of the API improvements are general GCC improvements that happen to mainly benefit plugins. Once a plugin is loaded, then it could setup the necessary pass-manager configuration. Regarding versions: I think it's crazy to be passing a version in every single function call. The plugin should check the gcc version it is being loaded into on startup and bail if it doesn't match. Taras
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
On Mon, Feb 2, 2009 at 19:34, Taras Glek wrote: > Regarding versions: I think it's crazy to be passing a version in every > single function call. The plugin should check the gcc version it is being > loaded into on startup and bail if it doesn't match. Agreed. Let's start with simpler mechanisms and increase complexity progressively. Diego.
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Taras, On Feb 2, 2009, at 7:34 PM, Taras Glek wrote: Regarding versions: I think it's crazy to be passing a version in every single function call. The plugin should check the gcc version it is being loaded into on startup and bail if it doesn't match. Since you and Diego seem to be of one mind on this, we can just strip versions. It might be useful to have an API inside GCC for picking apart version_string for purposes of comparison, but we can add that to "Nice to have" since it is in no way plugin-specific. I'll go ahead and strip the hook versioning API out of the draft. Sean
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
On Mon, 2 Feb 2009, Taras Glek wrote: > Regarding versions: I think it's crazy to be passing a version in every single > function call. The plugin should check the gcc version it is being loaded > into on startup and bail if it doesn't match. I agree with checking once at startup, but that should be GCC's job, not the plugin's. The plugin should export the exact version string and target triplet (and maybe configure options) of the compiler it was built to be plugged into (the configure macros / build support provided for use of plugins should make this automatic). GCC should check these at startup. (OK, there's not much difference between GCC checking data automatically exported from a plugin and the build support code automatically putting checks in the plugin itself, but I think having the checks in GCC is safer for ensuring they are always done.) -- Joseph S. Myers jos...@codesourcery.com
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Joseph S. Myers wrote: > I agree with checking once at startup, but that should be GCC's job, not > the plugin's. Yes. > The plugin should export the exact version string and > target triplet (and maybe configure options) of the compiler it was built > to be plugged into (the configure macros / build support provided for use > of plugins should make this automatic). GCC should check these at > startup. Unless we have a lot more stability in plugin API than I expect we're actually going to have at first, I suggest we check something like the md5sum of the GCC binary itself. (Yes, I see the recursive problem in building such a binary.) The chances that my plugin will work with your compiler seem near-zero, and the failure modes will be ugly. But, plugins for a popular compiler binary (e.g., that associated with a GNU/Linux distribution, or with a compiler distribution) would make sense. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: help needed on gcc instruction scheduling with unspec_volatile()
Dear Ian, Thanks the reply. >> Is there a way to make the instruction has to allocate to run without >> using the scheduler for particular instruction ? > > I don't understand the question. The target we are using supports parallel instruction execution, Max 7. For one cycle, one instruction packet is executed. one packet has max 7 instructions. so the scheduler is enabled. However, the scheduler enabling is not required for some packets. so how we can disable the instruction scheduling for particular packets ? > Nothing is out of scope of the scheduler. Using unspec_volatile in > the RTL template makes the instruction a scheduling barrier and a > memory barrier. Can you give more information or link to understand more about unspec_volatile ? The information available in gcc internals is not sufficient. Thanks and Regards Raja Saleru > raja.sal...@iap-online.com writes: > >> In gcc, while instruction scheduling can it be possible to suspend the >> scheduling for some instructions ? or > > No. You can turn off instruction scheduling for the entire > compilation. You can use #pragma GCC optimize to turn scheduling off > for a specific function. But there is no way to turn it off for some > instructions within a function but not others. > > >> Is there a way to make the instruction has to allocate to run without >> using the scheduler for particular instruction ? > > I don't understand the question. > > >> Currently there is RTL template in machine description >> unspec_volatile(). >> If the instruction is scheduled using this, does this make the >> instruction >> out of scope of scheduler ? > > Nothing is out of scope of the scheduler. Using unspec_volatile in > the RTL template makes the instruction a scheduling barrier and a > memory barrier. > > Ian >
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
On Feb 2, 2009, at 9:15 PM, Mark Mitchell wrote: Unless we have a lot more stability in plugin API than I expect we're actually going to have at first, I suggest we check something like the md5sum of the GCC binary itself. (Yes, I see the recursive problem in building such a binary.) The chances that my plugin will work with your compiler seem near-zero, and the failure modes will be ugly. But, plugins for a popular compiler binary (e.g., that associated with a GNU/Linux distribution, or with a compiler distribution) would make sense. The MD5 idea would hurt us because we have cc1 binaries compiled with - O0 -g3 -gdwarf2 and with normal optimization, and swap them out on occasion. In shops that deal with large source bases, I suspect this is not unheard-of. Our plugins do not break when switching compiler binaries. In fact, I have had plug-in binaries that perform very simple tasks work fine when switching (minor!) compiler releases. Perhaps if there is an ICE or GCC issues a warning / error, GCC could simply append "The plugin /path/to/plugin.so is not compatible with this GCC" to the message. Alternatively, GCC could always complain and you could have a flag -fforce-incompatible-plugins. Since the contents of enum machine_mode change based on target, I think it might be appropriate to check against the target as well as the version number and vendor patch level. Is there anything else we need to check? Sean
