Re: Update LTO plugin interface

On Wed, Dec 1, 2010 at 11:44 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor wrote: >>> "H.J. Lu" writes: For linker script, archive, DSO and object file without IR, *claimed will return 0 and plugin will save and pass it back to >

Old gcc documentation (Was: Re: Updated: RFA: Fix microblaze ada --enable-werror-always build)

Quoting "Joseph S. Myers" : On Thu, 2 Dec 2010, Joern Rennecke wrote: Oops, I forgot, we can use documentation from svn://gcc.gnu.org/svn/gcc/trunk/gcc/tm.t...@41699 - that text was both licensed under GPL and GFDL. Why do you think that? It appears to me that it was under ... which is a

Re: Update LTO plugin interface

"H.J. Lu" writes: > On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor wrote: > >> Or I'll rephrase: are there any cases for which using -pass-through for >> the set of libraries that the gcc driver automatically adds to the end >> of the link line would not be a complete solution? >> >> I'm not s

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 6:52 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor wrote: >> >>> Or I'll rephrase: are there any cases for which using -pass-through for >>> the set of libraries that the gcc driver automatically adds to the end >>> o

Re: Old gcc documentation (Was: Re: Updated: RFA: Fix microblaze ada --enable-werror-always build)

On Thu, 2 Dec 2010, Joern Rennecke wrote: > Actually, according to svn, the .texi files and ChangeLogs sprang into being > in 1997 when the egcs project started. Is there a copy of the RCS/CVS > repository around? Yes:

Re: Update LTO plugin interface

"H.J. Lu" writes: > I am not saying we should go with 2 stage linking. Just for clarification. > In 2 stage linking, the first stage only does symbol resolution. The complete > linking starts at the second stage. So we don't do really complete relink > in 2 stage linking. Understood. But you s

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> I am not saying we should go with 2 stage linking. Just for clarification. >> In 2 stage linking, the first stage only does symbol resolution. The complete >> linking starts at the second stage.  So we don't do reall

Re: Update LTO plugin interface

"H.J. Lu" writes: > On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote: >> "H.J. Lu" writes: >> >>> I am not saying we should go with 2 stage linking. Just for clarification. >>> In 2 stage linking, the first stage only does symbol resolution. The >>> complete >>> linking starts at the sec

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 9:20 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote: >>> "H.J. Lu" writes: >>> I am not saying we should go with 2 stage linking. Just for clarification. In 2 stage linking, the first stage only does s

Re: Update LTO plugin interface

"H.J. Lu" writes: > How do you deal with -lm: I believe we have agreed that LTO can only introduce new symbol references that are satisfied by -lc and -lgcc. Under those conditions, I believe my proposal will work just fine. Again, my proposal is this: I propose that we add a new linker o

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> How do you deal with -lm: > > I believe we have agreed that LTO can only introduce new symbol > references that are satisfied by -lc and -lgcc.  Under those conditions, Have you looked my testcase? The assumption of

Re: Update LTO plugin interface

"H.J. Lu" writes: > On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote: >> "H.J. Lu" writes: >> >>> How do you deal with -lm: >> >> I believe we have agreed that LTO can only introduce new symbol >> references that are satisfied by -lc and -lgcc.  Under those conditions, > > Have you looked

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 10:37 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote: >>> "H.J. Lu" writes: >>> How do you deal with -lm: >>> >>> I believe we have agreed that LTO can only introduce new symbol >>> references that are sati

Re: Old gcc documentation (Was: Re: Updated: RFA: Fix microblaze ada --enable-werror-always build)

Joern Rennecke writes: > Actually, according to svn, the .texi files and ChangeLogs sprang into being > in 1997 when the egcs project started. Is there a copy of the RCS/CVS > repository around? For your purposes, I think you will do better to look at old releases anyhow, e.g., ftp://gcc.gnu.or

Re: Old gcc documentation (Was: Re: Updated: RFA: Fix microblaze ada --enable-werror-always build)

Quoting Ian Lance Taylor : For your purposes, I think you will do better to look at old releases anyhow, e.g., ftp://gcc.gnu.org/pub/gcc/old-releases/gcc-[123] . Yes, I found what I was looking for in d30v.h of gcc 3.0 .

Re: Update LTO plugin interface

"H.J. Lu" writes: > g++ adds -lm since libstdc++ uses libm. If we do it in gcc, we may > add run-time dependency on libm.so to all C programs even if they > don't use libm at all. No. All the gcc driver has to do is: *if* -lm is used on the link line, also add it after the use of --plugin-call

libstdc++ gets configure error in cross builds

Gents, I'm trying to do a cross-build of gcc 4.5.1. It works fine until I get to libstdc++v3, where configure blows up with a message saying "Link tests are not allowed after GCC_NO_EXECUTABLES". This happens on the "checking for shl_load" step (line 11221 in configure). I looked at configur

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 11:37 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> g++ adds -lm since libstdc++ uses libm.  If we do it in gcc, we may >> add run-time dependency on libm.so to all C programs even if they >> don't use libm at all. > > No.  All the gcc driver has to do is: *if* -lm i

Re: Update LTO plugin interface

"H.J. Lu" writes: > On Thu, Dec 2, 2010 at 11:37 AM, Ian Lance Taylor wrote: >> "H.J. Lu" writes: >> >>> g++ adds -lm since libstdc++ uses libm.  If we do it in gcc, we may >>> add run-time dependency on libm.so to all C programs even if they >>> don't use libm at all. >> >> No.  All the gcc dr

Re: libstdc++ gets configure error in cross builds

On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: > Paul Koning writes: > >> I'm trying to do a cross-build of gcc 4.5.1. It works fine until I >> get to libstdc++v3, where configure blows up with a message saying >> "Link tests are not allowed after GCC_NO_EXECUTABLES". This happens >> on

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 11:53 AM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Thu, Dec 2, 2010 at 11:37 AM, Ian Lance Taylor wrote: >>> "H.J. Lu" writes: >>> g++ adds -lm since libstdc++ uses libm.  If we do it in gcc, we may add run-time dependency on libm.so to all C programs

Re: libstdc++ gets configure error in cross builds

Paul Koning writes: > I'm trying to do a cross-build of gcc 4.5.1. It works fine until I > get to libstdc++v3, where configure blows up with a message saying > "Link tests are not allowed after GCC_NO_EXECUTABLES". This happens > on the "checking for shl_load" step (line 11221 in configure). >

Re: libstdc++ gets configure error in cross builds

On Thu, Dec 2, 2010 at 11:59 AM, Paul Koning wrote: > > On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: > >> Paul Koning writes: >> >>> I'm trying to do a cross-build of gcc 4.5.1.  It works fine until I >>> get to libstdc++v3, where configure blows up with a message saying >>> "Link tests ar

Re: libstdc++ gets configure error in cross builds

Paul Koning writes: > On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: > >> Paul Koning writes: >> >>> I'm trying to do a cross-build of gcc 4.5.1. It works fine until I >>> get to libstdc++v3, where configure blows up with a message saying >>> "Link tests are not allowed after GCC_NO_EXECU

Re: Method to disable code SSE2 generation but still use -msse2

On Mon, Nov 22, 2010 at 02:33:32PM -0800, David Mathog wrote: > My software implementation of SSE2 now passes all the testsuite > programs. In case anybody else ever needs this, it is here: > > http://saf.bio.caltech.edu/pub/software/linux_or_unix_tools/soft_emmintrin.h > > I compiled that with

Re: Update LTO plugin interface

"H.J. Lu" writes: >> As far as I can tell at this point, the complete set of libraries we >> need to check is: -lc -lm -lgcc -lgcc_s. > > It isn't a complete list. At least, we need -lgcov and may be others. Only to the extent that we feel that it is important to permit the user to specify -lgco

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 12:10 PM, Ian Lance Taylor wrote: > > Anyhow, I have a proposal on the table which I think can do the job.  If > you want to instead advocate for a complete relink approach, then we > should significantly change and simplify the plugin interface.  The > plugin support in gol

Re: operator new[] overflow (PR 19351)

On Wed, Dec 01, 2010 at 10:26:58PM -0800, Florian Weimer wrote: > * Chris Lattner: > > > On overflow it just forces the size passed in to operator new to > > -1ULL, which throws bad_alloc. > > This is also what my patch tries to implement. Yes, but Chris's code just checks the overflow of the mu

Re: Update LTO plugin interface

On 02/12/2010 20:10, Ian Lance Taylor wrote: > Anyhow, I have a proposal on the table which I think can do the job. If > you want to instead advocate for a complete relink approach, then we > should significantly change and simplify the plugin interface. The > plugin support in gold will need to

installing & testing gengtype?

Hello All, References: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02562.html http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02565.html As you know, gengtype is becoming a user visible program [it is needed to people coding GCC plugins which uses GTY], probably to be installed in the same director

Re: libstdc++ gets configure error in cross builds

On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: > Paul Koning writes: > >> On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: >> >>> Paul Koning writes: >>> I'm trying to do a cross-build of gcc 4.5.1. It works fine until I get to libstdc++v3, where configure blows up with a

Re: Update LTO plugin interface

Dave Korn writes: > On 02/12/2010 20:10, Ian Lance Taylor wrote: > >> Anyhow, I have a proposal on the table which I think can do the job. If >> you want to instead advocate for a complete relink approach, then we >> should significantly change and simplify the plugin interface. The >> plugin s

Re: libstdc++ gets configure error in cross builds

On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning wrote: > > On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: > >> Paul Koning writes: >> >>> On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: >>> Paul Koning writes: > I'm trying to do a cross-build of gcc 4.5.1.  It works fine unti

Re: libstdc++ gets configure error in cross builds

On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote: > On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning wrote: >> >> On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: >> >>> Paul Koning writes: >>> On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: > Paul Koning writes: > >> I'

Re: Update LTO plugin interface

>  I'm wondering if the linker shouldn't just gather the plugin-contributed > object files, substitute them into appropriate places on the original > command-line, and re-exec itself. That's not effectively different from the collect2 approach that we had before the linker plugin interface. The on

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 1:01 PM, Cary Coutant wrote: >>  I'm wondering if the linker shouldn't just gather the plugin-contributed >> object files, substitute them into appropriate places on the original >> command-line, and re-exec itself. > > That's not effectively different from the collect2 appr

Re: libstdc++ gets configure error in cross builds

On Thu, Dec 2, 2010 at 1:01 PM, Paul Koning wrote: > > On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote: > >> On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning wrote: >>> >>> On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: >>> Paul Koning writes: > On Dec 2, 2010, at 2:55 PM, Ian Lance Tay

Re: Update LTO plugin interface

> I propose that we add a new linker option: --plugin-callback.  At each > point where this option appears on the command line, the linker will > call a new plugin callback entry point.  The LTO plugin will replace the > all_symbols_read callback with this one.  We will have the gcc driver > run th

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 1:10 PM, Cary Coutant wrote: >> I propose that we add a new linker option: --plugin-callback.  At each >> point where this option appears on the command line, the linker will >> call a new plugin callback entry point.  The LTO plugin will replace the >> all_symbols_read call

Re: Update LTO plugin interface

Cary Coutant writes: >> I propose that we add a new linker option: --plugin-callback.  At each >> point where this option appears on the command line, the linker will >> call a new plugin callback entry point.  The LTO plugin will replace the >> all_symbols_read callback with this one.  We will h

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 1:28 PM, H.J. Lu wrote: >> For every new routine that the gcc backend generates a new call to, it >> ought to know which library that routine is defined in, and should be >> able to add that library after the generated object(s) during the >> all-symbols-read callback. We re

RFA: patch to prohibit IRA undoing sched1 [was IRA undoing sched1]

On 12/01/2010 02:14 PM, Paul Koning wrote: On Nov 29, 2010, at 9:51 PM, Vladimir Makarov wrote: On 11/29/2010 08:52 PM, Paul Koning wrote: I'm doing some experiments to get to know GCC better, and something is puzzling me. I have defined an md file with DFA and costs describing the fact that

Re: operator new[] overflow (PR 19351)

On Thu, Dec 2, 2010 at 2:20 PM, Joe Buck wrote: > On Wed, Dec 01, 2010 at 10:26:58PM -0800, Florian Weimer wrote: >> * Chris Lattner: >> >> > On overflow it just forces the size passed in to operator new to >> > -1ULL, which throws bad_alloc. >> >> This is also what my patch tries to implement. >

gcc-4.5-20101202 is now available

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

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 1:10 PM, Cary Coutant wrote: > > For every new routine that the gcc backend generates a new call to, it > ought to know which library that routine is defined in, and should be > able to add that library after the generated object(s) during the > all-symbols-read callback. We

Re: Update LTO plugin interface

> For each libcall, we need to decorate > > 1. Which library it comes from. It is OS/target dependent. > 2. The dynamic and static library names.  In most cases,  they > are the same.  For glibc, they are different. Is there a relatively painless way to enumerate all the possible libcalls? We coul

Re: Update LTO plugin interface

On 02/12/2010 23:29, Cary Coutant wrote: > For the crtend files we could add a linker option that makes them > known as endcaps, and the linker could make sure they get laid out > last: > >ld ... -lc -lgcc ... --endcap crtend.o crtn.o > > That puts the special knowledge about those files bac

Re: Update LTO plugin interface

Cary Coutant writes: >> For each libcall, we need to decorate >> >> 1. Which library it comes from. It is OS/target dependent. >> 2. The dynamic and static library names.  In most cases,  they >> are the same.  For glibc, they are different. > > Is there a relatively painless way to enumerate all

Re: Update LTO plugin interface

>> For the crtend files we could add a linker option that makes them >> known as endcaps, and the linker could make sure they get laid out >> last: >> >>    ld ... -lc -lgcc ... --endcap crtend.o crtn.o >> >> That puts the special knowledge about those files back in the gcc driver. > >  Hmm, yes.  

Re: Update LTO plugin interface

> This isn't quite what should happen, though.  If the user does not > specify -lm on the link line, then we should not add -lm, even if LTO > somehow introduces a function that is defined in libm.  Automatically > adding -lm would introduce a surprising dynamic dependency in some > cases.  The use

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 4:04 PM, Cary Coutant wrote: >> This isn't quite what should happen, though.  If the user does not >> specify -lm on the link line, then we should not add -lm, even if LTO >> somehow introduces a function that is defined in libm.  Automatically >> adding -lm would introduce

Re: RFD: inline hooks

Quoting "Joseph S. Myers" : I think we want to move *away* from inline functions in headers and towards link-time inlining, in the interests of modularity: if one component of GCC cannot see the internals of another component at compile time, it cannot use them but must use the actual interface

Re: RFD: inline hooks

On Thu, 2 Dec 2010, Joern Rennecke wrote: > The intended use for inline hooks would be macros that we are currently > reluctant to fully convert to hooks because of concerns about performance. Those can clearly be low priority. Convert the others, see after that what LTO is like for hook devirt

Re: Update LTO plugin interface

Cary Coutant writes: >> This isn't quite what should happen, though.  If the user does not >> specify -lm on the link line, then we should not add -lm, even if LTO >> somehow introduces a function that is defined in libm.  Automatically >> adding -lm would introduce a surprising dynamic dependenc

Re: Update LTO plugin interface

On Thu, Dec 2, 2010 at 5:39 PM, Ian Lance Taylor wrote: > Cary Coutant writes: > >>> This isn't quite what should happen, though.  If the user does not >>> specify -lm on the link line, then we should not add -lm, even if LTO >>> somehow introduces a function that is defined in libm.  Automatical

Re: Update LTO plugin interface

>> I wouldn't expect the compiler to introduce a call to anything in libm >> when -lm isn't already specified on the command line (that would break >> even without LTO). > > Right--that would break without LTO, but it doesn't follow that we > should make it work with LTO. That's my point, too. >>

Re: Update LTO plugin interface

Cary Coutant writes: > My suggestion was to have the plugin give the linker a list of > libcalls, and the linker would note where it found each symbol during > its normal library scanning. Ah, I see. OK, that makes sense. > Right. The gcc driver would have to have some concept of which > libra

Re: gcc-4.5-20101125: minor bug & test results

On Wed, 1 Dec 2010, Jonathan Wakely wrote: On 1 December 2010 02:45, Russell Whitaker wrote: Minor build bug: The cpp sanity check fails because it is looking for cpp in /lib instead of /usr/bin Like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950 ? In that case it was because there was

HP-UX/PA_RISC gcc-4.4.5 multiple libgomp failures, help please

Hi, We built gcc-4.4.5 on all our systems, but on hppa2.0w-hp-hpux11.31 (a 32 bit build of gcc) we found that, though the compiler was able to build perl-5.12.2, the resulting perl did not pass its tests. So, we ran the gcc testsuite, and it passed nearly everything until it came to libgomp: Runn

Committed Go frontend

As I just mentioned on the gcc-patches mailing list, I have just committed the Go frontend to mainline. I expect that I will use the gccgo branch going forward as a set of tested sources for generating Go code. In the next few days I will complete the final items on the frontend checklist at http

Re: Committed Go frontend

On Thu, Dec 2, 2010 at 8:41 PM, Ian Lance Taylor wrote: > The Go language is not built by default, so this should not have a > significant effect on most developers. Hmm, but it looks like it is currently. Or at least that is how I understand to read the build failure at http://gcc.gnu.org/ml/gc

Re: Committed Go frontend

Quoting Andrew Pinski : On Thu, Dec 2, 2010 at 8:41 PM, Ian Lance Taylor wrote: The Go language is not built by default, so this should not have a significant effect on most developers. Hmm, but it looks like it is currently. Indeed, as of r167408, --enable-languages=all includes go.