Re: Backporting the 4.5 plugin framework to 3.4.5

On 1/21/2011 4:12 PM, Kyle Girard wrote: Hello, I currently have a plugin for gcc 4.5 that works great. However, the need has arisen to have the same plugin run on gcc 3.4.5. Knowing that the plugin api wasn't added until 4.5 I was wondering if anyone could tell me how much pain i would be in

Re: Massive performance regression from switching to gcc 4.5

On 6/24/10 3:06 PM, Andrew Pinski wrote: Most of the code is compiled with -fPIC -fno-rtti -fno-exceptions -Os Stop right there. You are compiling at -Os, that is tuned for size and not speed. So the question is did the size go down? Not the speed decreased. Try at -O2 and report back. I

Re: C++ Plugins

On 10/11/09 12:13 PM, Terrence Miller wrote: (Version 4.5.0) There are plugin callbacks which trigger at the end of processing types and C++ functions, but I can not find a clean way for plugin code to notice a top-level variable declaration. I'm hoping that the answer does not require

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

Re: gcc emit wrong symbols in multiple inheritance case

Ian Lance Taylor wrote: Bo Yang [EMAIL PROTECTED] writes: Could anybody give some advice on this? Thanks! The mailing list gcc@gcc.gnu.org is for gcc developers, who mostly do not use cygwin. Try asking on [EMAIL PROTECTED] and/or [EMAIL PROTECTED] For what it's worth, Bo is my intern in

Re: gcc emit wrong symbols in multiple inheritance case

Brian Dessent wrote: Benjamin Smedberg wrote: For what it's worth, Bo is my intern in the Google SoC and has traced this back to being a code-generation error (missed stdcall mangling) in the mingw backend. I will work with him to narrow the problem and reformulate the question.. Isn't

Re: How to determine if a decl is a class member in GCC

Le-Chun Wu wrote: Hi, I haven't heard anything back on my questions. Can any of C++ frontend maintainers please shed some light (or comment on my proposed patch)? Thanks a lot. Le-chun On Fri, Jul 18, 2008 at 10:22 AM, Le-Chun Wu [EMAIL PROTECTED] wrote: Hi, In my attribute handlers that

Re: How to determine if a decl is a class member in GCC

Le-Chun Wu wrote: Benjamin, Thanks for looking into this issue. I see what's going on here. It's basically a phase ordering problem. I am trying to determine whether a declaration is a class member when attributes are parsed and handled (in c-common.c), which happens earlier than where the

4.3 regression: -frtti and #pragma visibility

somewhere that represents __class_type_info and needs default-visibility to be explicitly set on it. - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG

Re: Progress on GCC plugins ?

allocated on the heap are only written through this particular writebarrier pattern... so arguments about whether we want the code to be integrated into GCC itself are irrelevant. - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN

Re: Progress on GCC plugins ?

/libmozstaticanalysis.so... in many cases we could even pre-compile this file for common versions of GCC. - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using

Re: RFH: GPLv3

entirely or leave it Doug GPLv2. Then there are no surprises for anyone. Leaving released branches as GPLv2 is not an option. That definitely would be the path of least surprise. Why is it not an option? - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED

Re: RFH: GPLv3

separately? - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

dynamic_castvoid* broken on GCC trunk

The patch for GCC bug 10891 changed the behavior of dynamic_castvoid* when RTTI is disabled. The new behavior is too restrictive for certain types of dynamic_cast that can be reliably performed without any RTTI information: If you have a class with virtual functions: class A { virtual

Re: gcc visibility used by moz

Jason Merrill wrote: OK, you've convinced me that the compiler shouldn't override or complain about explicit visibility attributes. Do you have a problem with implicit propagation of visibility in the absence of an attribute? Specifically: Do you agree with implicitly giving template

Re: gcc visibility used by moz

Jason Merrill wrote: OK, you've convinced me that the compiler shouldn't override or complain about explicit visibility attributes. Do you have a problem with implicit propagation of visibility in the absence of an attribute? Specifically: Do you agree with implicitly giving template