Re: Problem while configuring gcc3.2
2009/12/28 Pardis Beikzadeh: > Hi, This question should be asked on the gcc-help mailing list, not this one. > I'm having a problem while installing gcc3.2. I'm trying to install > gcc3.2 for my installation of cygwin because anything higher than that > won't work if I try to compile mex files for Matlab. Unfortunately > when I try to configure gcc3.2 (before getting to the bootstrap step), > I get an error because no proper cc is found. This is of course > because I uninstalled my gcc3.4 in order to install gcc3.2 from > scratch according to the suggestion in the email below from the gcc > mailing list. Could you please tell me how to solve this problem? I don't see any suggestion in the mail you quoted that says to uninstall gcc3.4 I suggest you don't uninstall gcc3.4 and instead configure gcc3.2 so it installs to a different path. That way you will have two versions installed in separate locations. > Where can I get an installation of cc that will work with gcc3.2? It > seems like I'm stuck with a chicken and egg problem because it seems > like I need gcc before I can install gcc. > > Also 'make bootstrap' doesn't work without running configure, so I'm > not sure what the "recommended way" mentioned in the email below > means. It means following the usual installation instructions given on the gcc website, which say to run configure first. Once you've configured you can run 'make bootstrap'
AVR gives weird error with LTO
When AVR target is built, without explicitly disabling LTO, it will produce 1000's of testsuite failures of -LTO -WHOPR tests with this compilation error: "ld: -f may not be used without -shared" Any idea what is wrong or how to make LTO work correctly here? Andy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42483
Re: AVR gives weird error with LTO
Andrew Hutchinson wrote: > When AVR target is built, without explicitly disabling LTO, it will > produce 1000's of testsuite failures of -LTO -WHOPR tests with this > compilation error: > > "ld: -f may not be used without -shared" > > Any idea what is wrong or how to make LTO work correctly here? The standard way to be proceed would be: add -v to the command-line in the PR; find out what is actually getting passed to ld; figure out what kind of specs-processing accident (most likely) is causing ld to receive a -f option. cheers, DaveK
Re: AVR gives weird error with LTO
I used "v" and progressed a little The problem seems to be that linker is called with -fwhopr or -flto as command line option. ld -fwhopr . Linker find '-f' and complains. I assume this is not a valid option for ld? Or is my linker wrong version or something? Note this is cross compile toolchain. Andy Dave Korn wrote: Andrew Hutchinson wrote: When AVR target is built, without explicitly disabling LTO, it will produce 1000's of testsuite failures of -LTO -WHOPR tests with this compilation error: "ld: -f may not be used without -shared" Any idea what is wrong or how to make LTO work correctly here? The standard way to be proceed would be: add -v to the command-line in the PR; find out what is actually getting passed to ld; figure out what kind of specs-processing accident (most likely) is causing ld to receive a -f option. cheers, DaveK
Re: AVR gives weird error with LTO
Andrew Hutchinson wrote: > I used "v" and progressed a little > > The problem seems to be that linker is called with -fwhopr or -flto as > command line option. > > ld -fwhopr . > > Linker find '-f' and complains. > > I assume this is not a valid option for ld? Or is my linker wrong > version or something? It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc cheers, DaveK
Re: target hooks / plugins
On Thu, Dec 24, 2009 at 1:32 AM, Joern Rennecke wrote: > Quoting Joern Rennecke : >> >> Right now, to make a new target hook, you have to add a new field in >> target.h, define a new default in target-def.h, place the new macro >> in exactly the right position there of the right initializer macro, >> describe the new hook in tm.texi, and if you need a new function with >> a bunch of parameters returning a constant, you have to add this to >> hooks.c . >> >> I would like to be able to do all this by adding a single entry in a >> new definition file; and the information should also be usable by >> plugin sources so that they can automatically make wrappers for all >> function-type hooks. > > I've attached what I have so far. > There is an issue that the struct gcc_target member names don't always agree > with the TARGET_* macro names. > > Should I rather change one or the other to make them agree, or add an extra > parameter in the definition file macros to specify these names > independently? I didn't look at the patch yet but I'd simply change one or the other to make the names consistent. Richard. > >
Re: ping^2 [rfc][patch] Document RETURN_EXPR better
On Sat, Dec 26, 2009 at 1:14 AM, Jerry Quinn wrote: > http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00690.html > > [cc'ing gcc since it might be the better forum for this] > Ok. Thanks, Richard.
Re: Unnecessary PRE optimization
On Sat, Dec 26, 2009 at 2:07 AM, Daniel Berlin wrote: >> In general it will be tricky for latter passes to clean up the messes. >> The fundamental problem is that the address computation is exposed to >> PRE prematurely (for a given target ) at GIMPLE level. > > > Yeah, i'm not sure PRE can really do anything different here. > I also think you would have a very hard time trying to stop everything > from moving invariant computations around at the tree level. > Might make more sense to finish the tree level with a global code > motion pass that is target sensitive or something. And you also need to deal with the case where the address computation is already commoned in the original source. Btw, a optimization option to trigger fwprop and initializing it differently for different targets would work for me as a temporary workaround (not that this address cost issue is new ...) Richard.
Re: AVR gives weird error with LTO
> It's not a valid option for ld. It *is* a valid option for the collect2 > driver/wrapper executable that gcc uses to invoke ld, which suggests to me > that the AVR port must be configured not to build collect2, but that it is > going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in > gcc/config.gcc Or you could port gold to AVR and use the plugin :-) > cheers, > DaveK > Cheers, -- Rafael Ávila de Espíndola
Re: AVR gives weird error with LTO
Rafael Espindola wrote: >> It's not a valid option for ld. It *is* a valid option for the collect2 >> driver/wrapper executable that gcc uses to invoke ld, which suggests to me >> that the AVR port must be configured not to build collect2, but that it is >> going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in >> gcc/config.gcc > > Or you could port gold to AVR and use the plugin :-) I hadn't checked, but yeah, since AVR is an ELF platform, that's a nice solution too. There might still be reason to build a collect2, for interop with older binutils. cheers, DaveK
Re: AVR gives weird error with LTO
Dave Korn wrote: Rafael Espindola wrote: It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc Or you could port gold to AVR and use the plugin :-) I hadn't checked, but yeah, since AVR is an ELF platform, that's a nice solution too. There might still be reason to build a collect2, for interop with older binutils. cheers, DaveK Thank you David and Rafel I will dig further into collect2. I had noted that avr.h has the following: /* This is undefined macro for collect2 disabling */ #define LINKER_NAME "ld" Also, the MINGW host is the most significant for the AVR target - and problems with collect2 may be related to maintaining compatibility to that. Andy
Re: AVR gives weird error with LTO
On Thu, Dec 31, 2009 at 12:04 AM, Andrew Hutchinson wrote: > > Dave Korn wrote: >> >> Rafael Espindola wrote: >> It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc >>> >>> Or you could port gold to AVR and use the plugin :-) >>> >> >> I hadn't checked, but yeah, since AVR is an ELF platform, that's a nice >> solution too. There might still be reason to build a collect2, for >> interop >> with older binutils. >> >> cheers, >> DaveK >> >> >> > > Thank you David and Rafel > > I will dig further into collect2. I had noted that avr.h has the following: > > > /* This is undefined macro for collect2 disabling */ > #define LINKER_NAME "ld" That's indeed going to break LTO. Richard. > Also, the MINGW host is the most significant for the AVR target - and > problems with collect2 may be related to maintaining compatibility to that. > > Andy > >
Re: AVR gives weird error with LTO
Thank you David and Rafel I will dig further into collect2. I had noted that avr.h has the following: /* This is undefined macro for collect2 disabling */ #define LINKER_NAME "ld" That's indeed going to break LTO. Richard. That seems to be the key issue. Without #define LINKER_NAME, AVR is running LTO/WHOPR tests ok ! (No idea if it does anything useful though) Now to figure out why it was added in 2000 (rth). Hopefully Eric Weddington or Denis might have some idea and perhaps know if it still has a purpose. Andy
RE: AVR gives weird error with LTO
> -Original Message- > From: Andrew Hutchinson [mailto:andrewhutchin...@cox.net] > Sent: Wednesday, December 30, 2009 4:34 PM > To: Richard Guenther > Cc: Dave Korn; Rafael Espindola; GCC Development; Weddington, > Eric; Denis Chertykov > Subject: Re: AVR gives weird error with LTO > > > >> Thank you David and Rafel > >> > >> I will dig further into collect2. I had noted that avr.h > has the following: > >> > >> > >> /* This is undefined macro for collect2 disabling */ > >> #define LINKER_NAME "ld" > >> > > > > That's indeed going to break LTO. > > > > Richard. > > > > > That seems to be the key issue. > Without #define LINKER_NAME, AVR is running LTO/WHOPR tests ok ! (No > idea if it does anything useful though) > > Now to figure out why it was added in 2000 (rth). Hopefully Eric > Weddington or Denis might have some idea and perhaps know if it still > has a purpose. That was before my time. I didn't get involved (peripherally) until 2002. So it's either Denis Chertykov or Marek Michalkiewicz (CCed). Eric Weddington
RE: target hooks / plugins
Hi Joseph, cTuning-discussions is an open public mailing list - I have been moderating lots of spam there recently and mixed up some settings but it is fixed now ... Cheers, Grigori > -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Thursday, December 24, 2009 1:26 PM > To: Joern Rennecke > Cc: 'GCC Mailing List'; Grigori Fursin; 'Yuanjie Huang'; 'Liang Peng'; > 'Zbigniew Chamski'; > 'Yuri Kashnikoff'; 'Diego Novillo' > Subject: Re: target hooks / plugins > > It appears you CC:ed your message to a closed mailing list > ctuning-discussi...@googlegroups.com that bounces messages from > non-subscribers. Please avoid doing this; messages to public lists should > not be CC:ed to any list that will send bounces or other automatic replies > to non-subscribers. You are free to forward GCC list messages manually to > such a list, of course. > > -- > Joseph S. Myers > jos...@codesourcery.com
