Why can't copy renaming capture this assignment?

Hi, For this small case, char garr[100]; void f(void) { unsigned short h, s; s = 20; for (h = 1; h < (s-1); h++) { garr[h] = 0; } } After copyrename3, we have the following dump, f () { short unsigned int h; int D.4066; : D.4066_

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm wrote: > Here's another proposal then: actually use GObject introspection - > provide a GObject-based API to GCC. > > In this approach, GCC would gain a dependency on glib and gobject, and > expose its API via a .gir file. I greatly prefer the other

Re: gcc extensibility

Bernd Schmidt writes: >> No, that means would be using the old tool named 'patch' before building >> GCC. > > Or even the new tool named 'git'. [... and note that "git apply" doesn't actually require a git repo, and is a great (generally rather better behaved) replacement for the "patch" command.

Re: Proposed plugin API for GCC

On Fri, 2012-03-30 at 15:08 +0200, Basile Starynkevitch wrote: > On Fri, Mar 30, 2012 at 02:14:31PM +0200, Richard Guenther wrote: > > > > Btw, how ugly is it to make this API grokable by swig? Would that serve > > the python plugin? > > > An alternative would be to have either some easily pars

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

Le 30 mars 2012 à 11:40, Basile Starynkevitch a écrit : > Hello > > If you want to help me on the makefile issues for the next MELT plugin > release 0.9.5, please extract the MELT plugin from the svn repository, since > I am making small changes (which still don't work) since 0.9.5rc1 > > The pr

Re: Proposed plugin API for GCC

On Fri, 2012-03-30 at 14:14 +0200, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm wrote: > > 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=

Re: Proposed plugin API for GCC

On Fri, 2012-03-30 at 09:05 +0900, Miles Bader wrote: > 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 not

gcc-4.6-20120330 is now available

Snapshot gcc-4.6-20120330 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120330/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: GCC 4.7.0 as a AVR cross compiler

stuart writes: > I am not sure this is the right place to ask this It's not. The right place is gcc-h...@gcc.gnu.org. Please take any followups there. Thanks. > I can not seem to get gcc 4.7.0 to compile; it will not complete the > configuration stage complaining about missing packages (GMP

Re: Proposed plugin API for GCC

Le 30 mars 2012 à 15:48, Ian Lance Taylor a écrit : > Romain Geissler writes: > >> Using structs with some sets of function pointers may break compatibility >> between minor release. > > Yes, but fortunately we have a good understanding of how not to do that. > > We could also go the even safe

lrzip: extreme compression (but beware its slow decompression speed)

In case you're evaluating what compression programs to use... This started off as a comparison of xz and lzip, but then I added lzrip to the mix. Sometimes it's useful to have an idea of how far from "ideal" a compression program is. I'm not claiming to have the answer, but merely sharing my sur

GCC 4.7.0 as a AVR cross compiler

Hi, I am not sure this is the right place to ask this, but how do I get gcc 4.7.0 to compile as a cross compiler for the Atmel AVR series? The native host is an x86 IA32 box running Slackware, gcc 3.3.6. I have successfully compiled and installed (in /usr/local/avr) binutils 2.22 and set my path

C++ va_list wromng code generation in class::method(...,va_list args) only

hello there is a C++ game called dunelegacy which work on other GCC architecture ok On G++ 68k it compile ok, but produce wrong code, because there seem something diffrent in va_list. The value of SDL_RWops is transfer wrong. I do not understand what backend problem is possible to cause this. Pl

About ARM-cross-compile

Hi everyone, I am a grad student at UW-Madison who asked a question before about gcc-cross compiler. I got stuck on a problem. Actually, I could install "arm-eabi" cross-compiler for c, c++. The problem is about "arm-eabi-gcj" (i.e. for Java). "arm-elf" version cross-compiler was successfully in

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

> > Motion across hardreg sets/uses are not restricted. And I would not expect > an optimizing compiler to do that (it's your own fault to use hardregs in > complex C code). Well, the syscall sequence is an example of somehting that should be inlined into arbitrary code w/o potential risk of ICE

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 9:48 AM, Ludovic Courtès wrote: > Ian Lance Taylor skribis: > >> We do not want plugins to constrain internal development.  So if we >> adopted your approach, the only honest option would be to mark >> everything as internal.  And that would leave us where we are today. >

Re: Proposed plugin API for GCC

Ian Lance Taylor skribis: > We do not want plugins to constrain internal development. So if we > adopted your approach, the only honest option would be to mark > everything as internal. And that would leave us where we are today. My (limited) experience suggests that things aren’t that bad bet

Re: how to generate 64 bit relocations with gcc 3.3.3

"张翀(Zhang Chong)" writes: > Hi, gcc-help, Please never send e-mail to both gcc-h...@gcc.gnu.org and gcc@gcc.gnu.org. Please send any followups only to gcc-help. Thanks. > Can anyone tell me that how to generate only 64bit relocations binary > with gcc 3.3? Thanks for the help I don't unders

Re: Proposed plugin API for GCC

ludovic.cour...@inria.fr (Ludovic Courtès) writes: > What about sticking to the current “API” instead, and explicitly marking > as internal those parts that core developers know are still in flux? > > For instance, I would expect a large subset of and > to be stable (it’s been the case in my exp

Re: Proposed plugin API for GCC

Gabriel Dos Reis skribis: > On Fri, Mar 30, 2012 at 4:45 AM, Ludovic Courtès > wrote: > >> I find it important to help such unanticipated uses of GCC spread. > > It is hard to design for things you do not know. Indeed, that’s the whole point. Offer a ten-function stable API and watch “plug-in

Re: Proposed plugin API for GCC

Romain Geissler writes: > Using structs with some sets of function pointers may break compatibility > between minor release. Yes, but fortunately we have a good understanding of how not to do that. We could also go the even safer route used for linker plugins, in which the plugin is invoked wit

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 02:14:31PM +0200, Richard Guenther wrote: > > Btw, how ugly is it to make this API grokable by swig? Would that serve > the python plugin? An alternative would be to have either some easily parsable API definition (wwhich might be sort-of offered by Swig, but I'll bet th

Re: FSF Legal Documentation

On 3/30/12 8:52 AM, Subrata Biswas wrote: Dear All, I want to contribute GCC during this summer as my GSoC project and even after this summer as an active member of GCC community. I have heard about the essential legal documentation process and I also send a request mail to assignme...@gnu.org ye

how to generate 64 bit relocations with gcc 3.3.3

Hi, gcc-help, Can anyone tell me that how to generate only 64bit relocations binary with gcc 3.3? Thanks for the help Regards, Zhang,Chong

FSF Legal Documentation

Dear All, I want to contribute GCC during this summer as my GSoC project and even after this summer as an active member of GCC community. I have heard about the essential legal documentation process and I also send a request mail to assignme...@gnu.org yesterday. But I did not get any response from

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

2012/3/30 Jan Hubicka : >> On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson wrote: >> > 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. >

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

> On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson wrote: > > 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

Re: Proposed plugin API for GCC

On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm wrote: > 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

Re: gcc extensibility

On Fri, Mar 30, 2012 at 2:14 AM, Ludovic Courtès wrote: > Hi, > > Gabriel Dos Reis skribis: > >> I do not think people working on plugins have come up with a >> specification and an API they agree on. > > I think it’s wrong to consider plug-ins as second-class citizens. Nobody has made that asse

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 6:59 AM, Richard Guenther wrote: > On Fri, Mar 30, 2012 at 1:54 PM, Gabriel Dos Reis > wrote: >> On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès >> wrote: >> >>> What about sticking to the current “API” instead, and explicitly marking >>> as internal those parts that cor

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 4:45 AM, Ludovic Courtès wrote: > I find it important to help such unanticipated uses of GCC spread. It is hard to design for things you do not know. How about starting with things you do know? A possible path to progress on this issue, no? -- Gaby

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 1:54 PM, Gabriel Dos Reis wrote: > On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès > wrote: > >> What about sticking to the current “API” instead, and explicitly marking >> as internal those parts that core developers know are still in flux? > > A guarantee of perpetual d

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 4:33 AM, Basile Starynkevitch wrote: > I entirely agree with the above statements. More generally, we cannot > predict what plugins will be written for GCC, and what part of the API they > will use, and for what purposes they will be written. I believe somethings is being

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès wrote: > What about sticking to the current “API” instead, and explicitly marking > as internal those parts that core developers know are still in flux? A guarantee of perpetual discussions of the same topic, over and over. (meh, GCC-x.y.z just br

Re: gcc extensibility

On 03/30/2012 10:37 AM, Richard Guenther wrote: > On Fri, Mar 30, 2012 at 9:14 AM, Ludovic Courtès > wrote: >> Hi, >> >> Gabriel Dos Reis skribis: >> >>> I do not think people working on plugins have come up with a >>> specification and an API they agree on. >> >> I think it’s wrong to consider p

Re: Proposed plugin API for GCC

Hi Richard, Richard Guenther skribis: > On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès [...] >> The needs of plug-ins cannot be anticipated; artificially restricting >> what plug-ins can do is likely to hinder wider extension of GCC. > > Extension of GCC should happen within the GCC codebas

Re: Missed optimization in PRE?

On Fri, Mar 30, 2012 at 4:15 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: >> 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:

MELT 0.9.5rc1 etc...

Hello If you want to help me on the makefile issues for the next MELT plugin release 0.9.5, please extract the MELT plugin from the svn repository, since I am making small changes (which still don't work) since 0.9.5rc1 The procedure to extract the MELT plugin from the MELT brannch is: Retrieve

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 10:23:16AM +0200, Ludovic Courtès wrote: > Hi, > > David Malcolm skribis: > > > How do other plugin authors feel about the API? > > I think this approach would lead to a duplication of each GCC API. > > The needs of plug-ins cannot be anticipated; artificially restricti

Re: Proposed plugin API for GCC

Hi Le 30 mars 2012 à 06:18, Ian Lance Taylor a écrit : > I would recommend grouping functions by category, and making each > category be a struct with a set of function pointers. That will give > you a namespace, and will greatly reduce the number of external names in > the API. > > Ian Using

Re: gcc extensibility

On Fri, Mar 30, 2012 at 9:14 AM, Ludovic Courtès wrote: > Hi, > > Gabriel Dos Reis skribis: > >> I do not think people working on plugins have come up with a >> specification and an API they agree on. > > I think it’s wrong to consider plug-ins as second-class citizens. > > The plug-in mechanism

Re: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès wrote: > Hi, > > David Malcolm skribis: > >> How do other plugin authors feel about the API? > > I think this approach would lead to a duplication of each GCC API. I would call it an abstraction of GCC internals (disclaimer: I did not look at the

Re: Proposed plugin API for GCC

Hi, David Malcolm skribis: > How do other plugin authors feel about the API? I think this approach would lead to a duplication of each GCC API. The needs of plug-ins cannot be anticipated; artificially restricting what plug-ins can do is likely to hinder wider extension of GCC. As an example,

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

On Thu, Mar 29, 2012 at 3:59 PM, Michael Matz wrote: > 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. >> >>

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

On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson wrote: > 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

Re: Missed optimization in PRE?

On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: > 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

Re: gcc extensibility

Hi, Gabriel Dos Reis skribis: > I do not think people working on plugins have come up with a > specification and an API they agree on. I think it’s wrong to consider plug-ins as second-class citizens. The plug-in mechanism is just a technical means to allow people to extend the compiler withou