Is anyone using svk? I tried to create a local depot by updating the
one pointed on the wiki. Unfortunately it is trying to use too much
ram and crashing.
I crashes just after stating to work on revision 121126.
Cheers,
--
Rafael Avila de Espindola
Google Ireland Ltd.
Gordon House
Barrow Street
There are a number of memory leaks in various SVK 1.x releases[1]. SVK
2.0.1 should fix most (all?) of those, plus it has a much more efficient
method available that can be used to mirror the gcc repo (using svn
replay).
I am giving svk 2.0.1 a try. Compiling it was a bit painful, but now
it is
> In general I think spinning off modules/passes that are not used very
> frequently (e.g. the tree browser) is a good idea since it reduces the
> size of our code base.
I would go a bit further.
One nice properties of plugins is that they have a more restrictive
API. That should help us to get
2009/8/15 VandeVondele Joost :
>
>
> I'd like to test lto on a project where objects first go through an archive,
> and so wanted to follow http://gcc.gnu.org/wiki/LinkTimeOptimization
> using 'gcc -use-linker-plugin'
> However, I can't get this to work.
>
> gfortran -use-linker-plugin -flto main
> Is that for gcc or for binutils (neither documents this in ./configure
> --help) ?
just binutils.
> I used it for both, but only get this to work with binutils CVS, is that
> correct ?
I don't know if there has been any release of binutils with plugin
support. I use CVS.
> Now, however, I ge
> It sounds to me like this confusion comes from "LTO plugins". Isn't
> it just "LTO plugin"? That is, a specific plugin?
There is one GCC plugin. LLVM has another one. The fully qualified
name is probably something like "gold plugin for gcc lto".
> --
> Daniel Jacobowitz
> CodeSourcery
>
Chee
> a plugin foo.c is compiled as foo.so for that gcc-4.5, but since the plugin
> is probably buggy, it is compiled with ENABLE_CHECKING.
How would you do this? :-)
The plugin should get the ENABLE_CHECKING definition from the
auto-host.h used by the compiler, so they should always agree.
>
> Rega
2009/10/23 Ian Lance Taylor :
> I noticed that the -use-linker-plugin option seems to be passed to the
> linker. This is because LINK_COMMAND_SPEC includes %{u*}. And that
> is because -uSYMBOL is a documented linker option.
>
> The effect is that the linker creates an undefined reference to the
> Working on it.
The attached patch solves the problem. It is not very elegant to
remove -use-linker-plugin from the command line, but it is not used after
linking.
2009-10-23 Rafael Avila de Espindola
* gcc.c (LINK_COMMAND_SPEC): Remove -use-linker-plugin from the command
> I thought about that too, but a -f flag would be passed to the
> middle-end, where it does not make any sense. We could make it a -f
> flag anyhow, of course, and just explicitly ignore it in the
> middle-end.
>
> Any opinions on the best user interface for this?
From an user interface point of
> I agree with H-P.
The attached patch implements that. Tested that it is ignored by cc1
and not passed to the linker. OK with a CL entry if bootstrap finishes
OK?
> --
> Daniel Jacobowitz
> CodeSourcery
>
Cheers,
--
Rafael Ávila de Espíndola
diff --git a/gcc/common.opt b/gcc/common.opt
index b
> Perhaps this should be an Undocumented option. I don't think you need a
> Var anyway.
Without the Var it fails with
cc1: internal compiler error: in common_handle_option, at opts.c:2108
The attached patch changes the option to Undocumented.
> Andreas.
>
Cheers,
--
Rafael Ávila de Espíndola
> Without the Var it fails with
>
> cc1: internal compiler error: in common_handle_option, at opts.c:2108
Which can also be fixed by explicitly ignoring
OPT_fuse_linker_plugin. The attached patch does that. Any preferences?
Cheers,
--
Rafael Ávila de Espíndola
diff --git a/gcc/common.opt b/gcc/c
> Then what about adding to that switch statement that it is already handled
> by the specs?
That is what the last version does.
Cheers,
--
Rafael Ávila de Espíndola
> We should add hooks as we find plugins that need them. Simply adding
> a laundry list of hooks that we think might be needed will most likely
> cause us to overdesign. We know that we can write interesting plugins
> today, so we're not missing anything critical.
>
> I agree that it should be OK
> I believe there is a strong chicken & egg issue here. Ian is suggesting that
> hooks should be added only when an existing plugin would need them, but I
> believe that on the contrary plugins won't appear if they don't have a
> sufficient set of hooks. People won't even bother to make plugins if
> From several face to face discussions with ICI CTuning people (that it
> Grigori Fursin, Albert Cohen, Zbignew Chamski; all 3 are in CC of this
> reply) I understood that GCC ICI is exactly doing that: it has replaced GCC
> pass manager by its own, which invokes all the existing GCC passes in som
> But with the above details, how can I figure out how to run gdb, ie what
> arguments to give to gdb --args?
This is an area that needs some improvement :-(
What I do is pass -Wl,-debug to gcc. That will make collect2 print the
call to ld. Add a -plugin-opt=-debug to it and it should print the
ca
2009/11/18 Joern Rennecke :
> What do people think about making install-plugin not only install
> headers to build new plugins, but also install all plugins that
> have been contributed up to the code freeze for the release.
>
> First, it would make testing the plugin interface and the plugins easi
2009/11/22 Leandro Nini :
> Hi,
>
> in gcc-4.5 lto-wrapper may end up in an endless loop in case of error:
>
> if for example a 'maybe_unlink_file' call from 'lto_wrapper_exit' fails it
> calls 'fatal_perror' which in turn calls 'lto_wrapper_exit' again causing
> an infinity of
>
> lto-wrapper: del
> Hi Rafael,
>
> I'm sorry I cannot try the patch until next weekend.
> However, from a first look, it should work but I wonder: if the first
> maybe_unlink_file fails the others are never reached, leaving some
> temporary files in place. Is this ok?
>
Yes, I talked with Diego and he thinks that t
2009/11/29 Basile STARYNKEVITCH :
> Hello All,
>
> I believe there are several plugin issues to fix before 4.5 releases:
>
> 1. use of libiberty from plugins.
>
> As several patches recently sent demonstrated, the current state of the
> trunk does not work with plugins calling some of the libibert
2009/12/29 Steven Bosscher :
> Hi,
>
> I am trying to see what is going on in lto1 for PR lto/42534. I can
> reproduce the reported ICE but I can't reproduce it inside gdb to see
> what is happening. Debugging lto1 is not trivial - just getting the
> arguments and input files right is hard.
>
> App
> I have the lto1 command line, yes. But that gives a different failure.
> When run from gcc, lto1 crashes with an ICE, and when I run lto1
> standalone, it crashes with an error reading a hex number.
Do you have a backtrace of that?
You can also copy the gcc line and pass -wrapper to it.
>
>
>>
> Hope this helps...
Looks like something is getting really messed up in the argument parsing :-(
The error for the hexadecimal number pursing is from the code that
should handle things like
fil...@offset
This is probably from some @file not being expanded.
What I would recommend is first debu
> 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_colle
> I hacked fopen/open calls in lto.c and lto-elf.c to use O_BINARY and "rb"
> and compilation with -flto was then successful!
>
> I am not sure how this should be fixed properly.
Using O_BINARY and "rb" should be a nop on unix, no? Is it wrong to
use them on any arch we care about?
> Andy
Cheer
> Yes. AFAICT, it's intra .exp concurrency that's causing this.
>
Now that I think of it, maybe the problem is that file foo_0.c is
going to one job and foo_1.c is going to another?
> Diego.
>
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Reg
>> git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
>
> This will put the remote branch heads in refs/remotes, you might want to
> put them in refs/remotes/origin instead.
>
> $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
One small problem I ha
> Because the right one should have been
>
> $ git config --add remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
>
That is what "git clone" adds, but with that "git branch -r" will not
list the remote branches.
>
> Paolo
>
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | B
> Uhm, it does here (I don't have a GCC repo, it's another one):
I think the problem is that the GCC repo is set up in some unusual way.
> $ git branch -r
> mirror/cpp
> mirror/exc-handling-alternate-fix
> mirror/filesystem
> mirror/ipv6
> mirror/magritte
> mirror/master
> mirror/omnibrows
> Hi Diego,
>
> Thanks for the summary, it's great to see the progress of the project. Do
> you have any compile time numbers for LTO so far? If you pick a mid-sided
> program from spec or even a bootstrap, how much slower is LTO than compiling
> at -O3?
We haven't tried a bootstrap with LTO ena
> I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets
> (just not Linux, so using the system linker, not GNU ld). If I understand
> you correctly, they might just work (modulo bugs)?
That should work. You still might need to extend the linker to
support IL in static librarie
> Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)?
We need ELF for storing the IL files. In theory that is only a
container format and you could crate a plugin for the IRIX linker to
read it.
>Rainer
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House
> Is it IO bound because the LTO files are abnormally large? What kinds of
> file sizes are you seeing?
With the streamer debug enable we had over 40x the normal object size.
Without it, it looks to be 4 or 5 times if I remember correctly.
> -Chris
Cheers,
--
Rafael Avila de Espindola
Google
> The problem here is that LTRANS will run the standard pipeline
> over a callgraph that hasn't been "settled" (i.e., no inlining
> decisions have been applied yet). Perhaps the first thing LTRANS
> should do is just call execute_all_ipa_transforms() and then
> proceed with the regular pipeline.
This is similar to the discussion that happened some time ago about
extending return values. The decisions for that was that the callee
could just leave the higher bits undefined and the caller would
extent the result if it needed to.
We have a similar issue with function arguments. We compile
vo
I got mixed results with icc
for
--
short a;
void g(short);
void f(void)
{ g(a); }
--
it produces a movswl. For
---
void g(int);
void f(short a) {
g(a);
}
--
it produces a movswq.
For the original tes
2009/5/8 Brad Hards :
> Hi,
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40004 was a bug report that I
> filed on the missing plugin headers.
>
> That is now resolved - the headers are installed. I've closed the bug report.
>
> However I'm not sure how my application / buildsystem is meant to fi
2009/5/12 Basile STARYNKEVITCH :
> Hello All
>
> In the current plugin API, the function register_callback is used to
> register callback routines (eg PLUGIN_FINISH_UNIT) in which case the
> callback is expected to be a routine. But this same function
> register_callback is used also to register so
> It would also be very interesting to include LLVM's LTO support, which gives
> a pretty dramatic win on SPEC. However, I don't know how difficult it is to
> use on linux (on the mac, you just pass -O4 at compile time, and everything
> works). I've heard that Gold has a new plugin to make LTO tr
> I'd love to see this, but I can't contribute to it directly. I think the
> plugin interfaces would need small extensions, but there are no specific
> technical issues preventing it from happening. LLVM has certainly
> progressed a lot since that (really old) email went out :)
I can help a bit.
> Excuse me if this is a stupid question, but eh -- why would you want
> to make an LLVM plugin? Aren't LLVM and GCC doing just fine as
> competing compilers?
LLVM is a toolkit. There is a patched version of GCC that uses LLVM
(llvm-gcc). This is particularly important for fortran and ada since
c
> GMP and MPFR are required components of GCC, and every developer has to
> deal with them. For interfacing between GCC and LLVM, the experts who'll
> be able to answer the questions are generally going to be found on the
> LLVM lists, not the gcc list, and those (like you) who participate on
> bo
> I'd turn that around: There is already a version of LLVM that uses
> GCC. I don't see any way in which the FSF GCC benefits from this. And
> since this list concerns the FSF GCC...
That is not a valid turn around. We know that the existing LLVM can handle
this. We are not sure if the existing p
> As I said, it's a minor polish issue. It may be sufficient to just have a
> note in the documentation as Basil suggested.
I would prefer just changing the documentation too. In general I think
that plugins
should see gcc the same way a builtin pass does. If a plugin needs to
look at the
IL early
> Mine are. I ignore all heads in gcc.git, and just map its remotes into my
> remotes by manually specifying remote.origin.fetch. Not very pretty, but it
> seems to produce the optimal result. See my stuff in the lower section of
> http://gcc.gnu.org/wiki/GitMirror for more details.
It fails wi
2009/6/15 Aldy Hernandez :
>> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>> function ?make_decl_one_only?
>
> make_decl_one_only expects one argument, and that's what's being fed.
> Could you pl
> At revision 148493 decl_one_only was changed to take 2 arguments.
> Looks like I missed winnt.c.
148492 actually. Fixed in revision 148523:
2009-06-16 Rafael Avila de Espindola
* config/i386/winnt.c (i386_pe_encode_section_info): Update call to
make_decl_one_only.
Cheers,
> Apparently, the goal is to be able to compile (at least some) plugins
> without having the GCC source tree or build tree.
Correct.
> However, I believe we don't have any documentation stating that. At least
> not in http://gcc.gnu.org/onlinedocs/gccint/Plugins.html and not in
> http://gcc.gnu.o
> This is ok, too. I assume you have done a regression test? ;)
On the fix patch? The file would not build without it
I did test the original patch, but missed the winnt file.
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dubl
2009/7/6 Basile STARYNKEVITCH :
> Hello All
>
> I would suppose that the preprocessor (ie libcpp) might be enhanced to use
> plugins. I can see several scenarii for them:
>
> 1. a plugin could enhance the way #include directives are processed
>
> 2. a plugin could add additional builtin macros, lik
On 07/02/2008, Doug84 <[EMAIL PROTECTED]> wrote:
>
> Hi folks,
>
> I've been looking at the documentation for writing a GCC front end and the
> common thing I believe I'm seeing is that the GCC front ends are all run
> through GCC (i.e. you're efficiently adding a new section of coding to the
> GCC
2008/3/5 Diego Novillo <[EMAIL PROTECTED]>:
> cc1 had failed to build because of invalid C90 declarations. Fixed with
> this patch.
Strange. This was a problem with mainline bootstrap (see rev 132886)
but I don't understand why it failed on the test machine but not on my
workstation when both a
> Grrr. I hope it wasn't me. I didn't enable any new code paths that
> weren't already gcc_unreachable(). Besides, my tests returned a couple
> hundred less failures. If for some reason it was me, we can disable
> execute_{expand,lower}_omp again.
Looks like 133658 broke the build:
../../
> Is there a specific reason you don't use the LLVM LTO interface? It seems
> to be roughly the same as your proposed interface:
>
> a) it has a simple C interface like your proposed one
> b) it is already implemented in one system linker (Apple's), so GCC would
> just provide its own linker plugi
2008/6/4 Ian Lance Taylor <[EMAIL PROTECTED]>:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
> I have a feeling that the comments I wrote within Google about the
> linker interface were lost. I am going to try to recreate them here.
I have added them to the gcc wiki.
I have also removed some of
> Hey Rafael!
Hello!
>> *) Plugins could have other uses and the naming used on the LLVM LTO
>> interface is LTO specific.
>
> The LLVM interface uses an lto_ prefix. This interface is used by nm/ar/etc
> as well as the linker. Is there something specific about lto_ that is bad?
> http://llvm.or
>> In ELF you have to think about symbol overriding. Let's say you link
>> a.o b.o c.o. a.o has a reference to symbol S. b.o has a strong
>> definition. c.o has a weak definition. a.o and c.o have LTO
>> information, b.o does not. ELF requires that a.o call the symbol from
>> b.o, not the sym
> I've updated the WHOPR Driver wiki page with our latest thoughts on
> the plug-in interface:
>
> http://gcc.gnu.org/wiki/whopr/driver
Very nice! Just one comment:
On the "claim file", can you also pass the "file" size in the case it
is inside an archive?
> -cary
>
Cheers,
--
Rafael Avila
2008/7/10 Diego Novillo <[EMAIL PROTECTED]>:
> Is this the bootstrap failure that you folks were discussing in
> another thread? Is anyone fixing this?
I just committed Bill's patch with some small modifications. Should be
bootstrapping now.
>
> /home/dnovillo/perf/sbox/lto/local.x86_64/src/gcc/l
On 5/27/07, Razya Ladelsky <[EMAIL PROTECTED]> wrote:
Hi,
Getting failure during bootstrap for libjava on powerpc linux:
configure: error: `CXX' has changed since the previous run:
configure: former value: /home2/razya/matrix_copy/build/./gcc/xgcc
Same problem on linux x86_64
--
Rafael A
On 5/27/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Oh, some more details for those who want them:
The repo contains the complete history of gcc trunk (125000 svn revisions).
It takes roughly 350 meg of disk space (450 on mac due to inode size).
Curiosity, any plans to convert the full gcc r
> Having spent some time looking at the code for gcc it seems reasonably
> easy(with some suggestions) to traverse the tree generated and
> write the relevant information to a file. Any suggestions or pointers to
> related work would be much appreciated.
For C and C++, it might be easier to us
> PL/I for GCC is released under the terms of the
> GNU Public License; version 2.
The GCC at trunk uses GPL version 3 or newer ...
--
Rafael Avila de Espindola
Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland
Registered in Dublin, Ireland
Registration Number: 368047
> Yes, everything, by default you only get the more modern branches/tags,
> but it's all in there. If there is interest I can work with Bernardo
> and get the rest publically exposed.
I decided to give it a try, but could not find the tuples branch. Is
it too hard to make gimple-tuples-branch and
66 matches
Mail list logo
