Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

On Thu, 29 Mar 2012 23:29:40 +0200 Romain Geissler wrote: > > You've made a typo will copy/pasting part of the line. Look at the dollar $ > char > near '=$ (shell)', the space is misplaced. It should be '= $(shell'. Thanks! Corrected. -- Basile STARYNKEVITCH http://starynkevitch.net

Re: Proposed plugin API for GCC

David Malcolm writes: > I had a go at writing a possible plugin API for GCC, and porting parts > of my python plugin to it: > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e Seems like a good start. > I initially attempted an unde

Re: Backends with no exception handling on GCC47

"Paulo J. Matos" writes: > Is there anything documenting porting backend between GCC major versions > (GCC4.6 - GCC4.7), in order to avoid these questions? Basically, everything related to library code should move from gcc/config/CPU to libgcc/config/CPU. I don't know of any specific documenta

Re: unwind and type support in GCC47

"Paulo J. Matos" writes: > I am porting my backend to GCC47 and have been jumping through some > hurdles. libgcc is trying to compile unwind*.c files which I can't > remember being there for GCC46. They were there. In 4.6 they were in the gcc subdirectory. For 4.7 they moved to the libgcc di

Re: Proposed plugin API for GCC

David Malcolm writes: > I initially attempted an underscore_based_naming_convention but quickly > found it difficult to get concise function names, so I switched to a > CamelCaseBased_NamingConvention with an underscore separating a notional > namespace element from a secondary element, which save

Re: GSoC proposal: Provide optimizations feedback through post-compilation messages

On Tue, 27 Mar 2012 22:33:39 + Thibault Raffaillac wrote: > Hello all, > > My name is Thibault Raffaillac, CS degree student at Kungliga Tekniska > Högskolan, > Stockholm, Sweden (in double-degree partnership with Ecole Centrale Marseille, > France). > GCC currently provides no concise way

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

Le 29 mars 2012 à 23:03, Basile Starynkevitch a écrit : > On Thu, 29 Mar 2012 22:45:27 +0200 > Romain Geissler wrote: > >> MELTGCC_BUILD_WITH_CXX = $(shell grep -q >> 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \ >> `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

On Thu, 29 Mar 2012 22:45:27 +0200 Romain Geissler wrote: > MELTGCC_BUILD_WITH_CXX = $(shell grep -q > 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \ > `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes) > Thanks; I applied that patch with 2012-03-29 Romain G

Proposed plugin API for GCC

I had a go at writing a possible plugin API for GCC, and porting parts of my python plugin to it: http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e It's very much at the "crude early prototype" stage - all I've wrapped is part of CFG-h

Re: [GCC-MELT-386] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

Le 29 mars 2012 à 22:02, Basile Starynkevitch a écrit : > > Hello All, > > The pre-release candidate 1 of MELT 0.9.5 is available for testing on > http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz > as a gzipped tar archive of 4473286 bytes and md5sum > ae00b9bd31f481e1bbc40671

Re: C++: Letting compiler know asm block can call function that can throw?

> non-call-exceptions is a relatively big hammer. It marks _all_ > non-trivial instructions as throwing. The "all" goes against the "relatively" here, and "relatively" is more correct. Not all non-trivial instructions are marked as throwing, e.g. loads and stores from/to the stack aren't. -- E

Re: gcc extensibility

On Thu, 29 Mar 2012 15:22:28 -0400 Diego Novillo wrote: > On 3/29/12 3:01 PM, Basile Starynkevitch wrote: > > > But I feel I don't wear the same hat as a plugin developer and as a GCC > > contributor. > > Yes, you do. You are both a GCC contributor and a plugin developer. As > such, you are

pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

Hello All, The pre-release candidate 1 of MELT 0.9.5 is available for testing on http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz as a gzipped tar archive of 4473286 bytes and md5sum ae00b9bd31f481e1bbc406711ca4c2f4. extracted from MELT branch 185969, march 29th 2012 You coul

Re: gcc extensibility

Le 29 mars 2012 à 21:01, Gabriel Dos Reis a écrit : > On Thu, Mar 29, 2012 at 12:39 PM, Romain Geissler > wrote: >> Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit : >> >>> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler >>> wrote: Hi Le 29 mars 2012 à 14:34, Niels Möller a

Re: gcc extensibility

On 3/29/12 3:01 PM, Basile Starynkevitch wrote: But I feel I don't wear the same hat as a plugin developer and as a GCC contributor. Yes, you do. You are both a GCC contributor and a plugin developer. As such, you are in a unique position to know the needs of both sides. Cleaning up the

Re: gcc extensibility

On 03/29/2012 05:52 PM, Basile Starynkevitch wrote: > On Thu, 29 Mar 2012 11:42:30 -0500 > Gabriel Dos Reis wrote: >> I suspect that if plugins people want to make progress on this >> recurring theme, they >> will have to come up with a specification and an API. Otherwise, they have >> only >>

Re: gcc extensibility

On Thu, Mar 29, 2012 at 1:31 PM, Niels Möller wrote: > Gabriel Dos Reis writes: > >> It is a false equality.  The needs of plugins authors are not necessarily >> the same as the need of GCC development itself. > > I'm not so sure of that. To be concrete, can you give some examples of > things tha

Re: gcc extensibility

On Thu, 29 Mar 2012 19:41:07 +0100 Jonathan Wakely wrote: > But plugins in GCC are still new and still evolving, if plugin authors > won't help shape the API and offer their advice now then they the API > will never be useful. > > Don't expect people who don't care about plugins to do all the wo

Re: gcc extensibility

On Thu, Mar 29, 2012 at 12:39 PM, Romain Geissler wrote: > Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit : > >> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler >> wrote: >>> Hi >>> >>> Le 29 mars 2012 à 14:34, Niels Möller a écrit : >>> 1. I imagine the plugin API ought to stay in plai

Re: gcc extensibility

On 29 March 2012 17:52, Basile Starynkevitch wrote: > On Thu, 29 Mar 2012 11:42:30 -0500 > Gabriel Dos Reis wrote: >> I suspect that if plugins people want to make progress on this >> recurring theme, they >> will have to come up with a specification and an API.  Otherwise, they have >> only >> t

Re: C++: Letting compiler know asm block can call function that can throw?

On 03/29/2012 01:16 PM, Jan Hubicka wrote: >> Of course, there's still the problem of getting the unwind data correct at >> the point of the asm. I commented about that in the PR you filed. > > I think i386 still has the problem that it is small register class target and > if you > set rdi/rax a

Re: gcc extensibility

Gabriel Dos Reis writes: > It is a false equality. The needs of plugins authors are not necessarily > the same as the need of GCC development itself. I'm not so sure of that. To be concrete, can you give some examples of things that a plugin might want to do with an interface to the tree-abstra

Re: gcc extensibility

Le 29 mars 2012 à 15:14, Richard Guenther a écrit : > On Thu, Mar 29, 2012 at 2:34 PM, Niels Möller wrote: >> I originally wrote this email as a reply to Ian Lance Taylor on a >> different list, and he suggested that I send it also to the gcc list. >> Please cc me on replies, since I'm not subscr

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

On 29-Mar-2012 03:20, David Brown wrote: On 29/03/2012 00:52, mathog wrote: A better solution for the aesthetics would have been (it is a bit late now) to implement the missing unary negation operator: !!b; //T->F, F->T You can't do that, because "!!" is already a useful operator on integ

Re: gcc 4.7: -march=corei7-avx bug?

On Thu, 29 Mar 2012 10:26:47 +0200 Jakub Jelinek wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762 > Build with debug info, try to understand why it crashed, build > a minimal testcase out of it, attach it to the PR. > Or you could use a brute force method, if -march=corei7 works, > b

Re: gcc extensibility

Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit : > On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler > wrote: >> Hi >> >> Le 29 mars 2012 à 14:34, Niels Möller a écrit : >> >>> 1. I imagine the plugin API ought to stay in plain C, right? >> >> I don't know if this was already discussed and

Re: C++: Letting compiler know asm block can call function that can throw?

> On 03/29/2012 03:05 AM, Stephan Bergmann wrote: > > Hi all, > > > > In LibreOffice's ever-beloved low-level code to synthesize calls to > > C++ virtual functions, I'm having the following problem (on Linux > > x86_64). The function callVirtualMethod at > >

Re: gcc extensibility

On 03/29/2012 12:52 PM, Basile Starynkevitch wrote: They blame nobody if their plugins break from one release to the next. They take this incompatibility of GCC as part of their plugins developer's work. Again, a plugin writer by definition uses whatever interface is given to him. Cheers. T

Re: gcc extensibility

On Thu, Mar 29, 2012 at 11:52 AM, Basile Starynkevitch wrote: > They blame nobody if their plugins break from one release to the next. They > take this > incompatibility of GCC as part of their plugins developer's work. Great! Problem solved. -- Gaby

Re: gcc extensibility

On Thu, 29 Mar 2012 11:42:30 -0500 Gabriel Dos Reis wrote: > I suspect that if plugins people want to make progress on this > recurring theme, they > will have to come up with a specification and an API. Otherwise, they have > only > themselves to blame if their plugins break from release to rel

Re: gcc extensibility

On Thu, Mar 29, 2012 at 11:27 AM, Basile Starynkevitch wrote: > On Thu, 29 Mar 2012 11:06:11 -0500 > Gabriel Dos Reis wrote: > >> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler >> wrote: >> > Hi >> > >> > Le 29 mars 2012 à 14:34, Niels Möller a écrit : >> > >> >> 1. I imagine the plugin API o

Re: gcc extensibility

On Thu, 29 Mar 2012 11:06:11 -0500 Gabriel Dos Reis wrote: > On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler > wrote: > > Hi > > > > Le 29 mars 2012 à 14:34, Niels Möller a écrit : > > > >> 1. I imagine the plugin API ought to stay in plain C, right? > > > > I don't know if this was already di

Re: C++: Letting compiler know asm block can call function that can throw?

On 03/29/2012 03:05 AM, Stephan Bergmann wrote: > Hi all, > > In LibreOffice's ever-beloved low-level code to synthesize calls to > C++ virtual functions, I'm having the following problem (on Linux > x86_64). The function callVirtualMethod at >

Re: gcc extensibility

On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler wrote: > Hi > > Le 29 mars 2012 à 14:34, Niels Möller a écrit : > >> 1. I imagine the plugin API ought to stay in plain C, right? > > I don't know if this was already discussed and if the community > ended up with a clear answer for this question.

Re: C++: Letting compiler know asm block can call function that can throw?

Hi, On Thu, 29 Mar 2012, Andrew Haley wrote: > On 03/29/2012 02:59 PM, Michael Matz wrote: > > Actually, with -fnon-call-exceptions volatile asms are already supposed to > > be throwing. It's just that this got lost with tree-ssa. With the patch > > and -fnon-call-exceptions a simple "__asm__

Re: gcc extensibility

Hi Le 29 mars 2012 à 14:34, Niels Möller a écrit : > 1. I imagine the plugin API ought to stay in plain C, right? I don't know if this was already discussed and if the community ended up with a clear answer for this question. If it's not the case i would prefer a plugin interface in C++, for the

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: >> On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther >> wrote: >>> On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng wrote: Hi, Following is the tree dump of 094t.pre for a test pro

Re: C++: Letting compiler know asm block can call function that can throw?

On 03/29/2012 04:12 PM, Andrew Haley wrote: On 03/29/2012 02:59 PM, Michael Matz wrote: Actually, with -fnon-call-exceptions volatile asms are already supposed to be throwing. It's just that this got lost with tree-ssa. With the patch and -fnon-call-exceptions a simple "__asm__ volatile (...)"

Re: gcc extensibility

On Thu, Mar 29, 2012 at 7:34 AM, Niels Möller wrote: > 1. I imagine the plugin API ought to stay in plain C, right? > > 2. Then there are at least two ways to think about the plugin API to, >   e.g., the gcc tree abstraction. > >   Either one can define a C API one think the plugins will like, an

Re: Backends with no exception handling on GCC47

On Mon, 26 Mar 2012 11:10:11 -0700, Ian Lance Taylor wrote: > >> *** Configuration xap-local-xap not supported > > You will have to find out where that last error message is coming from. > It's not happening because of errors in configure tests. It's most > likely coming from libgcc/config.host

unwind and type support in GCC47

Hi, I am porting my backend to GCC47 and have been jumping through some hurdles. libgcc is trying to compile unwind*.c files which I can't remember being there for GCC46. I deduce this files have to do with exception support GCC47 seems to want to make exceptions mandatory even though my backe

Re: C++: Letting compiler know asm block can call function that can throw?

On 03/29/2012 02:59 PM, Michael Matz wrote: > Actually, with -fnon-call-exceptions volatile asms are already supposed to > be throwing. It's just that this got lost with tree-ssa. With the patch > and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as > possibly throwing. >

Re: C++: Letting compiler know asm block can call function that can throw?

Hi, On Thu, 29 Mar 2012, Stephan Bergmann wrote: > > > Anyway, would it be worthwhile filing an RFE for an asm annotation > > > telling the compiler that it contains code that can throw? > > > > I suppose yes. > > "RFE: Letting > compiler kno

Re: gcc extensibility

On Thu, Mar 29, 2012 at 2:34 PM, Niels Möller wrote: > I originally wrote this email as a reply to Ian Lance Taylor on a > different list, and he suggested that I send it also to the gcc list. > Please cc me on replies, since I'm not subscribed to the list. I hope > I'm not being too off-topic or

Re: C++: Letting compiler know asm block can call function that can throw?

On 03/29/2012 11:16 AM, Richard Guenther wrote: On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmann wrote: So an explicit -fnon-call-exceptions on the command line seems to indeed help. Unfortunately, moving that into a #pragma GCC optimize ("non-call-exceptions") at the top of the source f

gcc extensibility

I originally wrote this email as a reply to Ian Lance Taylor on a different list, and he suggested that I send it also to the gcc list. Please cc me on replies, since I'm not subscribed to the list. I hope I'm not being too off-topic or off-the-mark. Let me write down some reflections on gcc exten

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

On 29/03/2012 00:52, mathog wrote: On 28-Mar-2012 15:20, Michael Witten wrote: However, it seems to me that toggling the value with the idiom: --b; is aesthetically preferable to the more elaborate: b = !b; Aesthetically, not logically. Neither of these makes the least bit of sense: one l

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: >> On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther >> wrote: >>> On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng wrote: Hi, Following is the tree dump of 094t.pre for a test pro

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: > On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther > wrote: >> On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng wrote: >>> Hi, >>> Following is the tree dump of 094t.pre for a test program. >>> Question is loads of D.5375_12/D.5375_14 are redundant

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng wrote: >> Hi, >> Following is the tree dump of 094t.pre for a test program. >> Question is loads of D.5375_12/D.5375_14 are redundant on path > bb7, bb5, bb6>, >> but why not lowered into basic

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng wrote: > Hi, > Following is the tree dump of 094t.pre for a test program. > Question is loads of D.5375_12/D.5375_14 are redundant on path bb7, bb5, bb6>, > but why not lowered into basic block 3, where it is used. > > BTW, seems no tree pass handles th

Missed optimization in PRE?

Hi, Following is the tree dump of 094t.pre for a test program. Question is loads of D.5375_12/D.5375_14 are redundant on path , but why not lowered into basic block 3, where it is used. BTW, seems no tree pass handles this case currently. Any idea? Thanks int z$imag; int z$real; int D.5378

Re: C++: Letting compiler know asm block can call function that can throw?

On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmann wrote: > On 03/29/2012 09:44 AM, Jakub Jelinek wrote: >> >> On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote: >>> >>> In LibreOffice's ever-beloved low-level code to synthesize calls to >>> C++ virtual functions, I'm having the fol

Re: C++: Letting compiler know asm block can call function that can throw?

On 03/29/2012 09:44 AM, Jakub Jelinek wrote: On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote: In LibreOffice's ever-beloved low-level code to synthesize calls to C++ virtual functions, I'm having the following problem (on Linux x86_64). The function callVirtualMethod at

Re: gcc 4.7: -march=corei7-avx bug?

On Thu, Mar 29, 2012 at 04:53:45AM -0300, Dâniel Fraga wrote: > I tried to compile Firefox 11 with gcc 4.7 optimized with: > > -O3 -march=corei7-avx (I have a core i7 2700k) > > But Firefox segfaults (backtrace provided, although it seems > not very useful): > > http://gcc.gnu.org/bu

[ANN] StarPU 1.0.0, hybrid CPU/GPU task programming

We are pleased to announce StarPU 1.0.0, a GCC extension and run-time support library for hybrid CPU/GPU task programming, available from the following sites: https://gforge.inria.fr/frs/?group_id=1570 http://runtime.bordeaux.inria.fr/StarPU/files/ Home page: http://runtime.bordeaux.inria.

gcc 4.7: -march=corei7-avx bug?

I tried to compile Firefox 11 with gcc 4.7 optimized with: -O3 -march=corei7-avx (I have a core i7 2700k) But Firefox segfaults (backtrace provided, although it seems not very useful): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762 If I compile with -march=corei7 it r

Re: C++: Letting compiler know asm block can call function that can throw?

On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote: > In LibreOffice's ever-beloved low-level code to synthesize calls to > C++ virtual functions, I'm having the following problem (on Linux > x86_64). The function callVirtualMethod at >

C++: Letting compiler know asm block can call function that can throw?

Hi all, In LibreOffice's ever-beloved low-level code to synthesize calls to C++ virtual functions, I'm having the following problem (on Linux x86_64). The function callVirtualMethod at