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
Cheers,
--
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
2009/12/29 Steven Bosscher stevenb@gmail.com:
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
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.
gcc -v
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
2009/11/29 Basile STARYNKEVITCH bas...@starynkevitch.net:
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
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 this is
2009/11/22 Leandro Nini drfiem...@email.it:
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
2009/11/18 Joern Rennecke amyl...@spamcop.net:
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
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
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 to
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 they
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 some
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
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
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
2009/10/23 Ian Lance Taylor i...@google.com:
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
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 espind...@google.com
* gcc.c (LINK_COMMAND_SPEC): Remove -use-linker-plugin
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 view
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.
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
Cheers,
--
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 get
2009/8/15 VandeVondele Joost vond...@pci.uzh.ch:
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
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/7/6 Basile STARYNKEVITCH bas...@starynkevitch.net:
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
2009/6/15 Aldy Hernandez al...@redhat.com:
../../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.
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 espind...@google.com
* config/i386/winnt.c (i386_pe_encode_section_info): Update call to
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
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
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 with
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
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
both
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
2009/5/12 Basile STARYNKEVITCH bas...@starynkevitch.net:
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
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
2009/5/8 Brad Hards br...@frogmouth.net:
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
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
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
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 |
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 libraries.
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 |
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 | Barrow
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/omnibrowser
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 have
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
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.
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 de
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 symbol from
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 plugin and
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 the
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?
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:
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 are
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 program
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
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 use 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
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
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
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
63 matches
Mail list logo
