Re: Git and GCC
> 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 lto visible? > Harvey > > Thanks a lot, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: GCC frontend
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 through softcode). > > What I wish to do is create my own front end outside of GCC and then send > the partly-processed code through the back end (i.e. an intermediate to > assembly code transformation would be done by GCC - the High language to > intermediate would be done by my program). > > Now, what would be ideal for me is if I could write the generated output > into a file (I presume in RTL format, judging from what I've read) and then > sending it straight into the backend. > > However, my initial research suggests that this is not possible and I will > have to define a 'dummy language' to write into GCC. > > On the compiler level, I would like the split ideally to be: > > My program:- Lexical analysis, Syntax Analysis, Semantic Analysis, > Intermediate Code Generation > GCC backend:- Code optimization, (Final) code generation. This is not currently available. There is some work on the LTO branch. Note that a stable file format is not the goal, so you would still need to link with gcc to write the file or closely track GCC development. Depending on what you want, the llvm project might be good. Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: [tuples] Branch frozen (again)
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 using --disable-bootstrap? Thanks, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: [tuples] Tuples branch frozen
> 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:
../../tuples2/gcc/omp-low.c:3341: warning: 'v_main' is used
uninitialized in this function
../../tuples2/gcc/omp-low.c:3342: warning: 'v_back' is used
uninitialized in this function
> Aldy
>
Cheers,
--
Rafael Avila de Espindola
Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland
Registered in Dublin, Ireland
Registration Number: 368047
Re: [whopr] Design/implementation alternatives for the driver and WPA
> 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 it would work on apple platforms > c) it is richer than your interface > d) it is battle tested, and exists today > e) it is completely independent of llvm (by design) > f) it is fully documented: http://llvm.org/docs/LinkTimeOptimization.html > > Is there something specific you don't like about the LLVM interface? We are still discussing how we are going to implement, so the API is still not final. Some things that have been pointed out: *) Plugins could have other uses and the naming used on the LLVM LTO interface is LTO specific. *) We have a normal symbol table on the .o files. It is not clear if we should assume that it will always be the case. If so, we don't need the API part that handles that. *) How do you handle the case of multiple symbols with the same name (say a weak and a strong one)? lto_codegen_add_must_preserve_symbol has a char* argument. How does it know which symbol we are talking about? *) To save memory, one option is to have the plugin exec WPA and WPA exec the linker again with the new objects. In this case the api should be a bit different. > -Chris > Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: [whopr] Design/implementation alternatives for the driver and WPA
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 TODOs that are now obsolete (passing all of the liker options to the plugin, passing only the symbol name). I created an abstract type ldplugin_symbol_t. We need to define some inline functions that the plugin can use to extract data from it. Thank a lot, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: [whopr] Design/implementation alternatives for the driver and WPA
> 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.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/lto.h?revision=HEAD&view=markup This is a minor comment. All the design is done based on what LTO needs, but since it could be possible to use plugins for other things the proposed API uses a generic prefix. >> *) We have a normal symbol table on the .o files. It is not clear if >> we should assume that it will always be the case. If so, we don't need >> the API part that handles that. > > This seems like a pretty minor point, but it would be easy to either: > > 1) make this an optional interface > 2) make the plugin implement the symtab interfaces, but query the ELF symbol > table instead of the LTO symbol table if possible. Sure. There is just the issue of the many function calls. Not sure how expensive this is. Maybe have the plugin construct a symbol table with everything that is on the file? >> *) How do you handle the case of multiple symbols with the same name >> (say a weak and a strong one)? lto_codegen_add_must_preserve_symbol >> has a char* argument. How does it know which symbol we are talking >> about? > > The lto_symbol_attributes enum specifies linkage. That allows the plugin to pass information to the linker. But if there are two symbols named "foo". How can the linker instruct the plugin to generate code for only one? The function that LLVM uses is lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*) right? Maybe adding a lto_symbol_attributes argument would be enough, but having an abstract object is probably better. >> *) To save memory, one option is to have the plugin exec WPA and WPA >> exec the linker again with the new objects. In this case the api >> should be a bit different. > > That's an interesting idea, but it is very unclear to me whether it would > save a significant amount of memory. Operating system VM systems are pretty > good at paging out data that isn't used (e.g. the .o files the linker loaded > into memory that exist when WPA is going on). Sure. Again, the document is in a early stage, and we listed most of the options. Restarting the linker is not a very popular option, but might be worth trying. > -Chris > Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: [whopr] Design/implementation alternatives for the driver and WPA
>> 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 c.o. I don't see how to make that work with
>> the LLVM interface.
>
> This does work. There are two parts to it. First the linker's master
> symbol
> table sees the strong definition of S in b.o and the weak in c.o and
> decides to use the strong one from b.o. Second (because of that) the linker
> calls lto_codegen_add_must_preserve_symbol("S"). The LTO engine then
> sees it has a weak global function S and it cannot inline those. Put
> together
> the LTO engine does generate a copy of S, but the linker throws it away
> and uses the one from b.o.
Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
of the opposite of what I had understood. What do you do in this case:
a.o: IL file that contains a reference to "f"
b.o: IL file that has a weak def of "f"
There is no strong definition. Can you inline f into the use in a.o?
> -Nick
>
>
Cheers,
--
Rafael Avila de Espindola
Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland
Registered in Dublin, Ireland
Registration Number: 368047
Re: [whopr] Design/implementation alternatives for the driver and WPA
> 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 Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: [lto] Bootstrap failure
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/lto-function-in.c:1984: > error: request for implicit conversion from 'void *' to 'union > tree_node **' not permitted in C++ > make[3]: *** [lto-function-in.o] Error 1 > make[3]: *** Waiting for unfinished jobs > rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod > grmic.pod gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod > gcc.pod gfortran.pod > make[3]: Leaving directory > `/usr/local/google/dnovillo/perf/sbox/lto/local.x86_64/bld/gcc' > make[2]: *** [all-stage2-gcc] Error 2 > make[2]: Leaving directory > `/usr/local/google/dnovillo/perf/sbox/lto/local.x86_64/bld' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory > `/usr/local/google/dnovillo/perf/sbox/lto/local.x86_64/bld' > make: *** [bootstrap] Error 2 > > Thanks. Diego. > Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: lto and gold
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.f90 test.f90 > /data03/vondele/binutils-2.19.1/build/bin/ld: -plugin: unknown option > /data03/vondele/binutils-2.19.1/build/bin/ld: use the --help option for > usage information > collect2: ld returned 1 exit status > > /data03/vondele/binutils-2.19.1/build/bin/ld -v > GNU gold (GNU Binutils 2.19.1) 1.7 > > I guess this is some configure flag missing, does anybody have a clue? Yes, you must build with --enable-gold --enable-plugins :-) > gcc configured as: > > /data03/vondele/gcc_lto/gcc/configure --prefix=/data03/vondele/gcc_lto/build > --with-libelf=/data03/vondele/libelf-0.8.10/build/ --enable-gold > --enable-languages=c,c++,fortran --disable-multilib -disable-bootstrap > > binutils as: > ./configure --prefix=/data03/vondele/binutils-2.19.1/build --enable-gold > > This is what collect2 sees: > /data03/vondele/gcc_lto/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/collect2 > -plugin > /data03/vondele/gcc_lto/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/liblto_plugin.so > -plugin-opt=/data03/vondele/gcc_lto/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper > -plugin-opt=gfortran -plugin-opt=-flto -flto --eh-frame-hdr -m elf_x86_64 > -dynamic-linker /lib64/ld-linux-x86-64.so.2 -use-linker-plugin > /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o > /data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtbegin.o > -L/data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0 > -L/data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64 > -L/lib/../lib64 -L/usr/lib/../lib64 > -L/data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../.. > /tmp/ccUQ7wr3.o /tmp/cczQrSMz.o -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s > -lgcc > /data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtend.o > /usr/lib/../lib64/crtn.o > > Thanks, > > Joost > > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: lto and gold
> 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 the following error: > > gfortran -flto -use-linker-plugin main.f90 test1.f90 test2.f90 > collect2: ld terminated with signal 6 [Aborted] > ld: /data03/vondele/gcc_lto/gcc/lto-plugin/lto-plugin.c:142: > parse_table_entry: Assertion `t <= 4' failed. The IL symbol table code probably got bit bit rotten. The gcc plugin is not schedule to merge during this stage1. > > Thanks, > > Joost > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: LTO and LTO Plugin Reviewers
> 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, -- Rafael Ávila de Espíndola
Re: checking for debug a plugin on a production compiler?
> 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.
>
> Regards.
>
> Note [*]: I don't pretend knowing when 4.5 will be released, and its release
> date is not the subject of that discussion!
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
Cheers,
--
Rafael Ávila de Espíndola
Re: -use-linker-plugin passed to ld
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
> symbol "se-linker-plugin". Any user unfortunate enough to link
> against a library which contains a definition of that symbol may see
> an unexpected result. Admittedly unlikely, but still.
>
> I think we need to fix this option before the release to not overlap
> with any existing linker options.
Working on it.
> Ian
>
Cheers,
--
Rafael Ávila de Espíndola
Re: -use-linker-plugin passed to ld
> 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
line.
Cheers,
--
Rafael Ávila de Espíndola
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 78e0ce8..78ffb0d 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -782,7 +782,8 @@ proper position among the other output files. */
} \
%{flto} %{fwhopr} %l " LINK_PIE_SPEC \
"%X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}\
-%{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
+%{s} %{t} %
Re: -use-linker-plugin passed to ld
> 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 I have no preferences for -fuse-linker-plugin or -use-linker-plugin. I don't like the idea of ignoring -fuse-linker-plugin on the compilers (cc1/cc1plus/...). We should probably filter it on the driver. From an implementation point of view it is easier to avoid -use-linker-plugin being passed to the linker than it is to avoid -fuse-linker-plugin being passed to the compilers. The reason is that we don't need the option after linking, so we can just use %< to filter it out. With -f I think we would have to record it in a variable and use that in the spec. BTW, a bootstrap with the original patch attached finished successfully. > Ian > Cheers, -- Rafael Ávila de Espíndola
Re: -use-linker-plugin passed to ld
> 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 b57234a..9e4cf12 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1391,6 +1391,11 @@ funwind-tables
Common Report Var(flag_unwind_tables) Optimization
Just generate unwind tables for exception handling
+fuse-linker-plugin
+Common Var(flag_use_linker_plugin)
+Ignored. Is is used by the driver, but passed to the compiler because it starts
+with an f.
+
fvar-tracking
Common Report Var(flag_var_tracking) VarExists Optimization
Perform variable tracking
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 78e0ce8..b033d62 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -770,7 +770,7 @@ proper position among the other output files. */
#define LINK_COMMAND_SPEC "\
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) \
-%{use-linker-plugin: \
+%{fuse-linker-plugin: \
-plugin %(linker_plugin_file) \
-plugin-opt=%(lto_wrapper) \
-plugin-opt=%(lto_gcc) \
@@ -7513,7 +7513,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n"
if (num_linker_inputs > 0 && error_count == 0 && print_subprocess_help < 2)
{
int tmp = execution_count;
- const char *use_linker_plugin = "use-linker-plugin";
+ const char *fuse_linker_plugin = "fuse-linker-plugin";
/* We'll use ld if we can't find collect2. */
if (! strcmp (linker_name_spec, "collect2"))
@@ -7523,14 +7523,14 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n"
linker_name_spec = "ld";
}
- if (switch_matches (use_linker_plugin,
- use_linker_plugin + strlen (use_linker_plugin), 0))
+ if (switch_matches (fuse_linker_plugin,
+ fuse_linker_plugin + strlen (fuse_linker_plugin), 0))
{
linker_plugin_file_spec = find_a_file (&exec_prefixes,
"liblto_plugin.so", X_OK,
false);
if (!linker_plugin_file_spec)
- fatal ("-use-linker-plugin, but liblto_plugin.so not found");
+ fatal ("-fuse-linker-plugin, but liblto_plugin.so not found");
lto_libgcc_spec = find_a_file (&startfile_prefixes, "libgcc.a",
R_OK, true);
Re: -use-linker-plugin passed to ld
> 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
diff --git a/gcc/common.opt b/gcc/common.opt
index b57234a..c2452b8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1391,6 +1391,9 @@ funwind-tables
Common Report Var(flag_unwind_tables) Optimization
Just generate unwind tables for exception handling
+fuse-linker-plugin
+Common Undocumented Var(flag_use_linker_plugin)
+
fvar-tracking
Common Report Var(flag_var_tracking) VarExists Optimization
Perform variable tracking
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 78e0ce8..b033d62 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -770,7 +770,7 @@ proper position among the other output files. */
#define LINK_COMMAND_SPEC "\
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) \
-%{use-linker-plugin: \
+%{fuse-linker-plugin: \
-plugin %(linker_plugin_file) \
-plugin-opt=%(lto_wrapper) \
-plugin-opt=%(lto_gcc) \
@@ -7513,7 +7513,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n"
if (num_linker_inputs > 0 && error_count == 0 && print_subprocess_help < 2)
{
int tmp = execution_count;
- const char *use_linker_plugin = "use-linker-plugin";
+ const char *fuse_linker_plugin = "fuse-linker-plugin";
/* We'll use ld if we can't find collect2. */
if (! strcmp (linker_name_spec, "collect2"))
@@ -7523,14 +7523,14 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n"
linker_name_spec = "ld";
}
- if (switch_matches (use_linker_plugin,
- use_linker_plugin + strlen (use_linker_plugin), 0))
+ if (switch_matches (fuse_linker_plugin,
+ fuse_linker_plugin + strlen (fuse_linker_plugin), 0))
{
linker_plugin_file_spec = find_a_file (&exec_prefixes,
"liblto_plugin.so", X_OK,
false);
if (!linker_plugin_file_spec)
- fatal ("-use-linker-plugin, but liblto_plugin.so not found");
+ fatal ("-fuse-linker-plugin, but liblto_plugin.so not found");
lto_libgcc_spec = find_a_file (&startfile_prefixes, "libgcc.a",
R_OK, true);
Re: -use-linker-plugin passed to ld
> 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/common.opt
index b57234a..77967f8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1391,6 +1391,9 @@ funwind-tables
Common Report Var(flag_unwind_tables) Optimization
Just generate unwind tables for exception handling
+fuse-linker-plugin
+Common Undocumented
+
fvar-tracking
Common Report Var(flag_var_tracking) VarExists Optimization
Perform variable tracking
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 78e0ce8..b033d62 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -770,7 +770,7 @@ proper position among the other output files. */
#define LINK_COMMAND_SPEC "\
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) \
-%{use-linker-plugin: \
+%{fuse-linker-plugin: \
-plugin %(linker_plugin_file) \
-plugin-opt=%(lto_wrapper) \
-plugin-opt=%(lto_gcc) \
@@ -7513,7 +7513,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n"
if (num_linker_inputs > 0 && error_count == 0 && print_subprocess_help < 2)
{
int tmp = execution_count;
- const char *use_linker_plugin = "use-linker-plugin";
+ const char *fuse_linker_plugin = "fuse-linker-plugin";
/* We'll use ld if we can't find collect2. */
if (! strcmp (linker_name_spec, "collect2"))
@@ -7523,14 +7523,14 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n"
linker_name_spec = "ld";
}
- if (switch_matches (use_linker_plugin,
- use_linker_plugin + strlen (use_linker_plugin), 0))
+ if (switch_matches (fuse_linker_plugin,
+ fuse_linker_plugin + strlen (fuse_linker_plugin), 0))
{
linker_plugin_file_spec = find_a_file (&exec_prefixes,
"liblto_plugin.so", X_OK,
false);
if (!linker_plugin_file_spec)
- fatal ("-use-linker-plugin, but liblto_plugin.so not found");
+ fatal ("-fuse-linker-plugin, but liblto_plugin.so not found");
lto_libgcc_spec = find_a_file (&startfile_prefixes, "libgcc.a",
R_OK, true);
diff --git a/gcc/opts.c b/gcc/opts.c
index 51a0cb9..72411b6 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2102,6 +2102,10 @@ common_handle_option (size_t scode, const char *arg, int value,
/* These are no-ops, preserved for backward compatibility. */
break;
+case OPT_fuse_linker_plugin:
+ /* No-op. Used by the driver and passed to us because it starts with f.*/
+ break;
+
default:
/* If the flag was handled in a standard way, assume the lack of
processing here is intentional. */
Re: -use-linker-plugin passed to ld
> 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
Re: plugin hooks
> 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 add hooks in stage 3, if they are > clearly safe and clearly needed. Sorry for being late in joining the thread. I fully agree with this. We should add hooks as someone finds a need for it. Changes like this are likely to be safe, but I am not sure if they are stage3 OK. We should probably look at it in a case by case basis. > Ian > Cheers, -- Rafael Ávila de Espíndola
Re: plugin hooks
> 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 > feel the set of hooks is blantly unsufficient. [They will either > experiment on their own GCC branch, or avoid GCC entirely, for instance > using LLVM instead]. But working on one's branch is much more painful > than coding a plugin! I don't see a chicken and egg problem. Your work on making the GC accessible to plugins is a good example why it is not :-) > I have a concrete example here: plugin-specific pragmas (see > PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for > details) > > I have two imaginary use cases here. Sorry, the point is precisely that they should be concrete :-) If you are actually coding a plugin and get to the stage "ok, now I need a new hook", please send a patch adding the hook and a description of what the plugin is trying to do. Cheers, -- Rafael Ávila de Espíndola
Re: plugin hooks
> 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
> better order (or better number of invocation) and produces better generated
> code (the tuning is done by machine learning techniques; they did run their
> modified GCC a large number of times and did build a database of measures.).
>
> I cannot explain more in details what GCC ICI is actually doing. I hope my
> ICI friends will answer here. Perhaps even Zbignew's latest patches are
> related to the answer.
We talked a bit in the summit about it. I think that the correct
solution is to make the gcc pass manager have the flexibility they
need so that their plugin can just call into the regular pass manager.
> Regards.
>
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
Cheers,
--
Rafael Ávila de Espíndola
Re: How to debug lto1 ICE?
> 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 call to lto-wrapper. > I suppose the offending process is probably > /usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/lto1 -quiet > -dumpbase interp.pic.o -mtune=generic -auxbase-strip /tmp/ccKdeyrC.lto.o -O2 > -version @/tmp/ccJMSLwC -o /tmp/ccODq2S4.s > > But I am not sure to understand correctly, in particular the @/tmp/ccJMSLwC > argument puzzles me. Apparently, some program arguments are collected in > some temporary files That is correct. This is to avoid command lines that are too large. We currently delete those files during the plugin cleanup. I will send a patch disabling cleanup if -debug is given. > So how do I run lto1 under GDB, knowing the faulty gcc invocation? Given the lto-wrapper line above, add -debug to it and it will print the lto1 invocation. > Regards. > Cheers, -- Rafael Ávila de Espíndola
Re: [plugins-ici-cloning-instrumentation] install-plugin Makefile target
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 easier. > > Second, if the version of a plugin available with the release is good enough > for the needs of a user, (s)he can try out without having to install - or > having to have installed - the plugins separately. > > Third, when someone uses an experimental plugin for a while and then > upgrades > some time later to a newer gcc release, it is useful when an updated plugin > version that works with the new gcc release comes with the new gcc > distribution. > Sound like a good idea, but I don't think we have agreed about including plugins with gcc. I would like it, but it is not the consensus. Cheers, -- Rafael Ávila de Espíndola
Re: Possible endless loop in lto-wrapper
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: deleting LTRANS file /tmp/ccWjXUv8.lto.o: No such file or
> directory
>
> error messages on the console.
>
> I've solved this by substituting 'maybe_unlink_file' with
> 'unlink_if_ordinary'
> whithin the 'lto_wrapper_exit' function.
> Not sure if this is the best fix but hope it helps.
Thanks for finding the bug!
I think that we need something similar to what was done in the linker:
Avoid trying to start a new cleanup if we are already in one.
Leandro, can you try the attached patch?
Diego, OK if it works?
2009-11-23 Rafael Avila de Espindola
* lto-wrapper.c (lto_wrapper_exit): Don't try to delete files if
being called recursively.
>
> Best Regards,
> Leandro
> --
Cheers,
--
Rafael Ávila de Espíndola
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c (revision 154452)
+++ gcc/lto-wrapper.c (working copy)
@@ -66,12 +66,20 @@
static void
lto_wrapper_exit (int status)
{
- if (ltrans_output_file)
-maybe_unlink_file (ltrans_output_file);
- if (flto_out)
-maybe_unlink_file (flto_out);
- if (args_name)
-maybe_unlink_file (args_name);
+ static bool cleanup_done = false;
+ if (!cleanup_done)
+{
+ /* Setting cleanup_done prevents an infinite loop if one of the
+ calls to maybe_unlink_file fails. */
+ cleanup_done = true;
+
+ if (ltrans_output_file)
+maybe_unlink_file (ltrans_output_file);
+ if (flto_out)
+maybe_unlink_file (flto_out);
+ if (args_name)
+maybe_unlink_file (args_name);
+}
exit (status);
}
Re: Possible endless loop in lto-wrapper
> 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 an unusual case and it is better to just give up when the first unlink fails. I have committed the patch, let me know if you see any issues. > Thank you, > Leandro > -- > Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP > autenticato? GRATIS solo con Email.it: http://www.email.it/f > Cheers, -- Rafael Ávila de Espíndola
Re: plugin issues to fix (or document) before 4.5 release
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 libiberty functions is
> IMHO not acceptable.
>
> we could take some of the following solutions
>
> a) explicitly document in plugins.texi that libiberty is not callable from
> plugins (e.g. functions like pex_execute or make_temp_file, which are not
> currently linked into cc1). This is the easiest to do. My feeling is that it
> would be very unfortunate. Libiberty is documented as a portability layer;
> if plugins cannot use it, that means that plugins will never be a way of
> experimenting code which might (much latter) be (partly) proposed into the
> trunk. So giving up libiberty in plugins is an important social decision; it
> discourage people coding plugins to try to propose (much latter, when their
> plugin has a big enough audience) their code into the trunk latter.
So, for 4.5 I think that documenting the issue might be the right thing.
For 4.6 I am not sure. Do the functions you want to use keep internal
state? If they don't, it should be safe to link a static (but PIC)
libiberty in the plugin. The objection for a libiberty.so was that we
would have to start versioning it and making sure the ABI was stable.
Was there something else?
If the only objection to using a libiberty.so is the ABI, maybe we
could install it in a non standard place and use rpaths. That way gcc
4.4 and 4.5 can use completely different and incompatible versions of
libiberty. The plugin would have to make sure that it is linked with
the correct one, but that is in line with we not making any promises
for backward compatibility.
Are rpaths as portable as shared libraries or do we support a host
architecture that has shared libraries but no equivalent to rpath?
That failing, IMHO, the best proposal is to have the build system do
its best at passing --whole-archive or equivalent when linking
libiberty in cc1.
>
> Regards.
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
Cheers,
--
Rafael Ávila de Espíndola
Re: Debugging lto1, how?
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. > > Apparently this is a known issue > (http://gcc.gnu.org/ml/gcc/2009-11/msg00047.html). > > Could someone with experience in debugging lto1 perhaps add a HOWTO > for this on the Wiki? Have you been able to get the lto1 command line? I don't think I have seen a case where a direct invocation of lto1 would fail but it would work in gdb. Sounds like a memory problem, have you tried valgrind? Getting the command line is annoying. In part because of the many layers in part because of the use of @files. gcc -v -save-temps should print you the necessary command line, no? Are you using gold + plugin or collect2? > Thanks, > > Ciao! > Steven > Cheers, -- Rafael Ávila de Espíndola
Re: Debugging lto1, how?
> 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 -save-temps should print you the necessary command line, no? > > Yes. > > >> Are you using gold + plugin or collect2? > > collect2. > > T.i.a. for any help you can give :-) > > Ciao! > Steven > Cheers, -- Rafael Ávila de Espíndola
Re: Debugging lto1, how?
> 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 debugging why -save-temps is not working. Can you try without -flto: $./xgcc -B. -O2 -c -o t.o t.c $ ./xgcc -B. -O2 -r -o t.o t.c -nostdlib -save-temps > Ciao! > Steven > Cheers, -- Rafael Ávila de Espíndola
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: Success with MinGW and AVR and LTO - almost
> 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, -- Rafael Ávila de Espíndola
anyone using svk?
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 Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: anyone using svk?
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 working. The only problem I had so far is that I had to enable overcommit in the kernel, or svk would be unable to fork before stating to commit on the depot! R. Thanks, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: Failure during bootstrap for libjava on powerpc linux
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 Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: Mercurial repository (Mirrored from SVN trunk) now publicly available
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 repository (including branches and tags)? Thanks, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: Refactoring tool
> 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 stand alone parser. Depending on what you want, these might be sufficient: http://llvm.org/cfe/ http://www.cs.berkeley.edu/~smcpeak/elkhound/sources/elsa/ > Patrick Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: PL/I for GCC version 0.0.15 released
> 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
Re: [lto] Spurious failures in lto tests with -jN
> 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 Registered in Dublin, Ireland | Registration Number: 368047
Re: Official GCC git repository
>> 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 with this. When I do "git branch lto origin/lto" the generated config entry says: [branch "lto"] remote = origin merge = refs/heads/lto and "git pull" will fail. Manually updating it to [branch "lto"] remote = origin merge = refs/remotes/lto solves the problem > > Andreas. > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Official GCC git repository
> 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 Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Official GCC git repository
> 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 > mirror/opengl > mirror/opengl-nurbs > mirror/poll-for-win32 > mirror/pool-resolution > mirror/roe > mirror/sdl > mirror/seaside > mirror/stable-2.1 > mirror/stable-2.2 > mirror/stable-2.3 > mirror/stable-3.0 > origin/HEAD > origin/master > origin/stable-2.1 > origin/stable-2.2 > origin/stable-2.3 > origin/stable-3.0 > stephen/master > stephen/pool-resolution > stephen/stable-3.0 > > You can see that it also lists branches for different remotes (with > distributed version control you need many of them, maybe one per > contributor). > > Have you tried (after changing the .git/config line for > remote.origin.fetch) doing a "git fetch origin" to refresh the list of > available branches for the origin remote? If it works now, you probably > want to remove the files in .git/refs/remotes/*. I need a new "git clone" just to be sure. It has the line you suggested. I am using fetch = +refs/remotes/*:refs/remotes/origin/* for now. A small manual edit for each new branch is not too much work. > Paolo > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Request for testing/help for the LTO branch
> 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 enabled yet (needs some changes to the build system to find the gold plugin during bootstrap). We should probably try -flto-single one day... Some initial testing with internal apps showed that the streamer is normally a problem and in some cases the performance is IO bound! This is very true if the streamer debug is enabled, since that adds some fairly large synchronization strings to the output. Cary wrote a patch to gold to ignore IL sections if not using the plugin, and it had a noticeable impact.. Diego, you tested SPEC a bit, do you know what the slowdown was? > -Chris > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Request for testing/help for the LTO branch
> 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. We can work with normal .o with the modified collect2 in the branch, but for archives we need linker support. > The only other target of interest to me is Tru64 UNIX, which uses ECOFF, > not ELF. I don't know if that format is extensible enough to store the IL, > but investigating that is low priority for me. I would suggest trying to use elf for the IL. For example, while using plugins gold doesn't care what the *input* file format is. > Thanks. >Rainer > > - > Rainer Orth, Faculty of Technology, Bielefeld University > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Request for testing/help for the LTO branch
> 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 | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Request for testing/help for the LTO branch
> 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 | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: [lto] Pass ordering and the different lto1 personalities
> 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. To make this extra clean, we can just create a execute_wpa_decisions pass that only runs in ltrans and is the first one. We will have a similar problem when we decide to implement ipa-cp in wpa. But we can solve this problem when we get there. > Honza, these three stages are all controlled by lto.c:lto_main. > > > Diego. > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
sign/zero extension of function arguments on x86-64
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
void g(short);
void f(short a) {
g(a);
}
into
f:
.LFB2:
movswl %di,%edi
jmp g
we should really be able to remove the movswl. If the caller
is required to do sign extension, who called f has
extended the argument already. If the callee is required,
then g will do it and there is no need for f to do it.
What is more interesting is the case
void g(int);
void f(short a) {
g(a);
}
Can f assume that its caller did a sign extension or
it is its responsibility to extend A?
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047
Re: sign/zero extension of function arguments on x86-64
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 test
-
void g(short);
void f(short a) {
g(a);
}
--
it avoids the extension.
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047
Re: Finding gcc plugin headers
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 find the > headers. Is there a way gcc could tell me? Alternatively, could there be > a .pc (pkg-config) file. We don't have any helpers at this moment. You can find the headers in /lib/gcc///plugin/include/ > Brad > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: plugins callbacks and data
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 some data to plugins, without any > call back functions, eg for PLUGIN_PASS_MANAGER_SETUP. > > Perhaps we could have two different functions: > > 1. register_callback like before for true callbacks > > and > > 2. register_data for registering data, like for PLUGIN_PASS_MANAGER_SETUP > or PLUGIN_INFO, declared as > void register_data (const char *plugin_name, > enum plugin_event event,, > void* user_data); > ? > > What do you think? No strong preference one way or the other. One small advantage of the current model is that we have only switch statement over all "enum plugin_event" values. The function already existed when I joined, maybe Le-Chu has some opinion about your proposal. > > Regards. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000
> 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 transparent on > linux as well, but I have no experience with it, and it is probably more > trouble than you want to take. Does gcc 4.4 include the LTO branch yet? For spec all that you (should) need is to link with a gold with plugins enabled and pass -use-gold-plugin to llvm-gcc. For software that uses static libraries you will also need the bfd plugin support (currently in code review). I am going on vacation tomorrow, but might read my mail from time to time. Ping me if you need help. The current trunk includes some patches from LTO, but not the streamer. > -Chris Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: LLVM as a gcc plugin?
> 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. There was some talk about it on #gcc. A plugin should be able to see all the GCC IL, so it should be able to convert it to LLVM. Keeping the current llvm-gcc interface would require some hacks *) The plugin will have to call exit to keep gcc's code generation from running. *) It will have to remove and recreate the .s file that is being output. Not sure if this will work. *) Gcc always produces .o files by calling the assembler, so "-c -emit-llvm" will not work. *) The plugis options will be of the form -fplugin-arg-llvm-emit-llvm One way to avoid these problems is to make llvm-gcc a gcc wrapper that runs gcc with the llvm plugin, converts command line options and in the case of -c -emit-llvm calls llvm-as. Another source of problem will be the early transformations that gcc does and that are normally disabled in llvm-gcc. The one that I remember right now is c++ thunk generation. > -Chris > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: LLVM as a gcc plugin?
> 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 clang supports only c like languages. The hope is that a plugin will be easier to maintain than llvm-gcc. > Ciao! > Steven > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: LLVM as a gcc plugin?
> 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 lists, well, you're on both lists. That is not the case here. There is already a version of gcc that uses llvm. What we are trying to find is if the GCC plugin infrastructure is generic enough to support similar use cases. In a previous mail I raised some issues in GCC that illustrate this. > So as a practical matter, it seems that LLVM lists are more suitable. > If it's ever decided that LLVM becomes a required piece of GCC, like > GMP and MPFR, that would change. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: LLVM as a gcc plugin?
> 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 plugin infrastructure can. That also goes to the more general question "should plugin development be discussed on this list?". One of the main uses of plugins will probably be adding features that are not of interest to GCC in general. > Ciao! > Steven > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: plugin callbacks after compiler errors
> 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 in the pipeline it should be ready to work with previous errors. > > Taras > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: git mirror at gcc.gnu.org
> 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 $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' $ git fetch fatal: refs/remotes/origin/gcc-4_0-branch tracks both refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch > Jason > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: diagnostics-branch merged into mainline
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 please debug this and find out what's going on? > At revision 148493 decl_one_only was changed to take 2 arguments. Looks like I missed winnt.c. Will send a patch. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: diagnostics-branch merged into mainline
> 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, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: instructions for compiling plugins?
> 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.org/wiki/plugins > > My feeling is that, at least on Linux machines, a plugin might be compiled > with e.g. a Makefile containing > > GCC=gcc-trunk > GCCPLUGINS_DIR:=$(shell $(GCC) -print-file-name=plugin) > CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC > > plugin.so: plugin.pic.o > $(GCC) -shared $^ -o $@ > > plugin.pic.o: plugin.c Something like that :-) > Should we add a section "Building plugins" in the Plugin chapter of the > documentation http://gcc.gnu.org/onlinedocs/gccint/Plugins.html ? > > > By the way, are we sure that install-plugin target in gcc/Makefile is > invoked from a toplevel sudo make install in the build dir? I feel it might > not be the case, but I am not sure.. I tried a "make install" from the top level builddir and the headers were installed correctly. > Regards. > > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: diagnostics-branch merged into mainline
> 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 Dublin, Ireland | Registration Number: 368047
Re: preprocessors & GCC plugins
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, like __COUNTER__, which > would be specific to the plugin. > > 3. a plugin could add extra CPP directives (like #ident) > > What do you think? Probably 1 is harder to implement than 2 or 3, but I am > not very familiar with libcpp/ > > The http://gcc.gnu.org/ml/gcc/2009-07/msg9.html mail suggested me the > plugins could be useful in the preprocessor. > > Currently, there is no plugin specific code inside libcpp/ It might be useful, but I would wait a bit before implementing it if is not critical. Lets first see how plugins get used. For example, whether the linux distributions will ship a 4.5 with plugins support. > Regards. > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: [plugin] Directory for plugins distributed with gcc
> 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 the code a bit more maintainable. Olatunji's work is a very nice example. For example, to make mudflap a plugin he had to remove the occurrences of "if (flag_mudflap)" and make mudflap use the existing generic varpool. > > Diego. > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
