libiberty should be a shared library when cc1 has plugin enabled.
Hello All,
Perhaps libiberty should be a shared library, not a static one, linked from
cc1, when GCC has plugin enabled.
I noticed the following in the MELT branch (while trying to build MELT as a
GCC-Trunk plugin).
Some functions of libiberty.h are not linked in cc1 (because cc1 don't call
them, and libliberty.a is a static library, not a shared one). A concrete
example is make_temp_file. It is used in gcc.c but not in the entire cc1,
and one could imagine a plugin might want it. But if a plugin calls it, the
dlopen of that plugin fails with undefined symbol: make_temp_file.
Of course, for that simple case a workaround is possible (at least on
Linux): use a standard temporary file function like tmpfile() instead of
make_temp_file.
But it seems to me that a plugin can call a libliberty function only if that
function is already referenced (e.g. called) from cc1. This is not the case
of all libiberty functions.
We might also artificially add a reference to each libiberty function from
cc1. Or we should at least document (perhaps as a comment in libiberty.h)
that all these functions are not available from plugins.
Linking statically libiberty.a into a plugin is not recommended (because
*.so should not contain non PIC code on many platforms).
If we did link dynamically libiberty.so:
* execution time (of cc1) might suffer a bit, because perhaps calling a
function in a dynamic library could be slower than calling it in a static
library.
* every plugin could use all of libliberty.so
* the Makefile.in files should be changed.
Comments are welcome.
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} ***
how to optimize address offset assignment
Hi, everyone: The address mode in my my RISC chip is like (BaseReg) + 8bit offset, or (BaseReg) + indexReg. And there a 16 general register from R0 to R15 which can be used as Base register or Index Regster. So you can see that if the frame space is larger than 255, there will be a problem. For a single Load/Store Operation, there should be an additional insn to force the immediate into index register. But this will cause some redundancy code, especially assessing some adjacent area. Like the following code(this is the assemble code generated by my cc1): MOVI#1084 -L ;; Load a immediate to R0 register ADD R5 R0 R14 ;; R14 is regarded as frame pointer STOREH R4 (R5) #0 -PRI ;;load a half word from memory at (R5 + 0). R4 = (R5 + 0) MOVI#1086 -L ADD R4 R0 R14 STOREH R5 (R4) #0 -PRI MOVI#1088 -L ADD R5 R0 R14 STOREH R4 (R5) #0 -PRI You can see the offset loaded three times. But they abut. It can be optimized. I read a paper named ”Optimal Stack Slot Assignment in GCC”. There is an option to enable the stack reorganization. But I didn’t find it in Internal Document. (The SH machine seems to use this method, how do I trigger it?) So I need your guys give me some advices. Thank you very much. ___ Best Regards Daniel Tian Mavrix Technology, Inc. Address：200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech Park, Shanghai, P.R.China (201204) Tel:86(21)51095958 - 8125 Fax:86(21)50277658 email：daniel.t...@mavrixtech.com.cn www.mavrixtech.com
Re: libiberty should be a shared library when cc1 has plugin enabled.
Basile Starynkevitch wrote: > Hello All, > > Perhaps libiberty should be a shared library, not a static one, linked from > cc1, when GCC has plugin enabled. > We might also artificially add a reference to each libiberty function from > cc1. Or link it into cc1 et al. using "--whole-archive". > If we did link dynamically libiberty.so: We would also have to install it, and start worrying about library API versioning and backward compatibility, or at any rate I think that's the main reason why this has not been done in the pasy (cf. libbfd). cheers, DaveK
[SH] ICE compiling pr34330 testcase for sh-linux-gnu
I'm having trouble with an ICE, and I'm hoping somebody can enlighten me.
Given the following command:
cc1 -fpreprocessed ../pr34330.i -quiet -dumpbase pr34330.c -da -mb
-auxbase-strip pr34330.c -Os -version -ftree-parallelize-loops=4
-ftree-vectorize -o pr34330.s -fschedule-insns
I get an internal compiler error:
GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR
version 2.4.1-p5, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR
version 2.4.1-p5, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c91a929a0209c0670a3ae8b8067b9f9a
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:
In function 'foo':
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
error: insn does not satisfy its constraints:
(insn 171 170 172 4
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:17
(set (reg:SI 9 r9)
(plus:SI (reg:SI 8 r8)
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) 35
{*addsi3_compact} (nil))
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The problem is that r8 != r9 but SH requires that it is.
The problem insn is created by gen_reload when it is given the following
rtl as input:
(plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:192 a ] [192])
(const_int 2 [0x2]))
(reg:SI 0 r0 [orig:188 ivtmp.24 ] [188]))
The problem appears to be that the nested plus does not match any of the
patterns it recognizes so it falls through to the final else clause:
/* Otherwise, just write (set OUT IN) and hope for the best. */
else
emit_insn (gen_rtx_SET (VOIDmode, out, in));
... which doesn't even attempt to check the constraints.
Is this an unexpected corner case for reload? Or is the input RTL
mal-formed somehow?
This case fails in both GCC 4.4 and SVN trunk (although the latter has
disabled -fschedule-insns by default so it needs to be re-enabled
explicitly).
Thanks for an help.
Andrew
Re: libiberty should be a shared library when cc1 has plugin enabled.
Dave Korn wrote:
We might also artificially add a reference to each libiberty function from
cc1.
Or link it into cc1 et al. using "--whole-archive".
Sorry, I am not aware of this option. And are we sure it works on all
the systems GCC is supposed to run on?
If we did link dynamically libiberty.so:
We would also have to install it, ..
Agreed.
Anyway, we really should have all of libiberty inside cc1. What is the
best way to achieve that so that it works on all the systems GCC wants?
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} ***
Re: libiberty should be a shared library when cc1 has plugin enabled.
Basile STARYNKEVITCH wrote: > Dave Korn wrote: >> >>> We might also artificially add a reference to each libiberty function >>> from >>> cc1. >> >> Or link it into cc1 et al. using "--whole-archive". >> >> > Sorry, I am not aware of this option. And are we sure it works on all > the systems GCC is supposed to run on? Ach. It requires GNU ld, of course. We could just link the objects from the libiberty/ dir into cc1 (etc.) instead of the lib .a archive. cheers, DaveK
Re: libiberty should be a shared library when cc1 has plugin enabled.
Dave Korn wrote:
Basile STARYNKEVITCH wrote:
Dave Korn wrote:
We might also artificially add a reference to each libiberty function
from
cc1.
Or link it into cc1 et al. using "--whole-archive".
Sorry, I am not aware of this option. And are we sure it works on all
the systems GCC is supposed to run on?
Ach. It requires GNU ld, of course. We could just link the objects from
the libiberty/ dir into cc1 (etc.) instead of the lib .a archive.
Anyway, I am not able to do that well. The point is that libiberty is
designed to provide a common interface to all the many systems GCC is
supposed to run on, and even if restricting ourselves to those having
ELF & a working dlopen, that makes a lot. In other words, I am
unfamiliar with libiberty (and I am not sure to understand why in 2009,
with the existing Posix & OpenGroup standards, it is still required. I
suppose it is a legacy).
Also, I don't know if we should patch libiberty or gcc/ directory to
solve that (I am not sure if libiberty is legally a part of GCC; ie does
the legal right to patch GCC is enough for libliberty, which is perhaps
shared with other stuff like binutils).
The quick & dirty fix would be to add inside eg gcc-plugin.c a table of
function pointers, or perhaps some code, referencing most (or preferably
all) of libiberty functions.
While pluginifying MELT I have to add a lot of dirty patches to avoid
(i.e. circumvent them) libiberty functions. This is a pity!
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} ***
Re: libiberty should be a shared library when cc1 has plugin enabled.
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote: > But it seems to me that a plugin can call a libliberty function only if that > function is already referenced (e.g. called) from cc1. This is not the case > of all libiberty functions. So... link libiberty into your plugin and get make_temp_file that way. -- Daniel Jacobowitz CodeSourcery
Re: libiberty should be a shared library when cc1 has plugin enabled.
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
But it seems to me that a plugin can call a libliberty function only if that
function is already referenced (e.g. called) from cc1. This is not the case
of all libiberty functions.
So... link libiberty into your plugin and get make_temp_file that way.
As far as I understand ELF shared objects, it is not recommended to link
a static library into a dynamic plugin (i.e. an ELF shared object),
because the static library is not compiled with -fPIC.
(if you do that, the resulting plugin is getting a huge lot of
relocation information).
In simpler words, *.so have to be compiled with -fPIC, and libiberty is
not compiled with -fPIC.
I am clear enough or should I explain more?
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} ***
Re: libiberty should be a shared library when cc1 has plugin enabled.
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 02:50:04PM CEST: > On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote: > > But it seems to me that a plugin can call a libliberty function only if that > > function is already referenced (e.g. called) from cc1. This is not the case > > of all libiberty functions. > > So... link libiberty into your plugin and get make_temp_file that way. Ahh, another opportunity for subtle bugs stemming from multiple entities of static data, such as random numbers used in a plugin being suspiciously correlated to random numbers used in cc1 proper, setenv in cc1 segfaulting because a plugin used it too, invalidating cc1's copy of the last_environ pointer ... Cheers, Ralf
Re: libiberty should be a shared library when cc1 has plugin enabled.
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: > In simpler words, *.so have to be compiled with -fPIC, and libiberty > is not compiled with -fPIC. We build a PIC libiberty already. While Ralf's point about static data is valid, the functions likely to be in libiberty on any platform supporting plugins should not suffer from this problem. If you're concerned about it, then build a subset. I've considered a separation of libiberty into replacements and utilities, anyway. -- Daniel Jacobowitz CodeSourcery
Re: libiberty should be a shared library when cc1 has plugin enabled.
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with -fPIC.
We build a PIC libiberty already.
Thanks!
Where and how is it built? I cannot find any *iberty*.so in my build tree!
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} ***
Re: libiberty should be a shared library when cc1 has plugin enabled.
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote: > Daniel Jacobowitz wrote: > >On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: > >>In simpler words, *.so have to be compiled with -fPIC, and libiberty > >>is not compiled with -fPIC. > > > >We build a PIC libiberty already. > > > > Thanks! > > Where and how is it built? I cannot find any *iberty*.so in my build tree! It's an archive, not a shared library. It's probably in libiberty/pic/ but there's configury involved. -- Daniel Jacobowitz CodeSourcery
Re: libiberty should be a shared library when cc1 has plugin enabled.
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote:
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with -fPIC.
We build a PIC libiberty already.
Thanks!
Where and how is it built? I cannot find any *iberty*.so in my build tree!
It's an archive, not a shared library. It's probably in
libiberty/pic/ but there's configury involved.
Perhaps we should document that in gcc/docs/plugin.texi?
--
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} ***
Strange Performance Hit on 2D-Loop
Hey guys,
I noticed a strange performance hit in one of our stencil codes,
causing it to run twice as long.
To nail down the error, I reduced our code to the two attached demo
programs. Basically they take two matrices and average each matrix
element with its four direct neighbors. Depending on how these
matrices are allocated, the performance hit occurs -- or does not.
Here is the diff of the two files:
@@ -17,8 +17,7 @@
void test(double (*grid)[GRID_WIDTH])
{
-double (*gridOld)[GRID_WIDTH] =
-malloc(GRID_WIDTH * GRID_HEIGHT * sizeof(double));
+double (*gridOld)[GRID_WIDTH] = gridOldArray;
double (*gridNew)[GRID_WIDTH] = gridNewArray;
printAddress(&gridNew[0][0]);
printAddress(&gridOld[0][0]);
where gridOldArray is a statically allocated array. Depending on the
machines processor the performance hit varies from negligible to
dramatic:
Processor GCC Version Time(slow) Time(fast) Performance Hit
-- --- -- -- ---
Core 2 Quad Q9550 4.3.3 12.19s 5.11s 138%
Athlon 64 X2 3800+ 4.3.37.34s 6.61s 11%
Opteron 2378 4.3.26.13s 5.60s 9%
Opteron 2352 4.3.38.16s 7.96s 2%
Xeon 3.00GHz 4.3.3 18.98s 14.67s 29%
Apparently Intel systems are more susceptible to this effect.
Can anyone reproduce these results?
And could anyone explain, why this happens?
Thanks in advance
-Andreas
--
Andreas Schäfer
Cluster and Metacomputing Working Group
Friedrich-Schiller-Universität Jena, Germany
0049/3641-9-46376
PGP/GPG key via keyserver
I'm a bright... http://www.the-brights.net
(\___/)
(+'.'+)
(")_(")
This is Bunny. Copy and paste Bunny into your
signature to help him gain world domination!
#define GRID_WIDTH 1024
#define GRID_HEIGHT 1024
#define MAX_STEPS 1024
#include
#include
#include
double grid[GRID_HEIGHT][GRID_WIDTH];
double gridNewArray[GRID_HEIGHT][GRID_WIDTH];
double gridOldArray[GRID_HEIGHT][GRID_WIDTH];
void printAddress(void *p)
{
printf("address %p\n", p);
}
void test(double (*grid)[GRID_WIDTH])
{
double (*gridOld)[GRID_WIDTH] = gridOldArray;
double (*gridNew)[GRID_WIDTH] = gridNewArray;
printAddress(&gridNew[0][0]);
printAddress(&gridOld[0][0]);
// copy initial state
for (int y = 0; y < GRID_HEIGHT; ++y) {
memcpy(&gridOld[y][0], &grid[y][0], GRID_WIDTH * sizeof(double));
memset(&gridNew[y][0], 0, GRID_WIDTH * sizeof(double));
}
// update matrices
for (int step = 0; step < MAX_STEPS; ++step) {
for (int y = 1; y < GRID_HEIGHT-1; ++y)
for (int x = 1; x < GRID_WIDTH-1; ++x)
gridNew[y][x] =
(gridOld[y-1][x ] +
gridOld[y ][x-1] +
gridOld[y ][x ] +
gridOld[y ][x+1] +
gridOld[y+1][x ]) * 0.2;
double (*tmp)[GRID_WIDTH] = gridOld;
gridOld = gridNew;
gridNew = tmp;
}
// copy result back
for (int y = 0; y < GRID_HEIGHT; ++y)
memcpy(&grid[y][0], &gridOld[y][0], GRID_WIDTH * sizeof(double));
}
void setupGrid()
{
for (int y = 0; y < GRID_HEIGHT; ++y)
for (int x = 0; x < GRID_WIDTH; ++x)
grid[y][x] = 0;
for (int y = 10; y < 20; ++y)
for (int x = 10; x < 20; ++x)
grid[y][x] = 1;
}
int main(int argc, char** argv)
{
setupGrid();
test(grid);
printf("res: %f\n", grid[10][10]); // prevent dead code elimination
return 0;
}
slowdown.fast
Description: Binary data
test.sh
Description: Bourne shell script
pgpDDJSZ5oTFh.pgp
Description: PGP signature
Re: Strange Performance Hit on 2D-Loop
On Thu, Jul 9, 2009 at 4:19 PM, Andreas Schäfer wrote:
> Hey guys,
>
> I noticed a strange performance hit in one of our stencil codes,
> causing it to run twice as long.
>
> To nail down the error, I reduced our code to the two attached demo
> programs. Basically they take two matrices and average each matrix
> element with its four direct neighbors. Depending on how these
> matrices are allocated, the performance hit occurs -- or does not.
>
> Here is the diff of the two files:
> @@ -17,8 +17,7 @@
>
> void test(double (*grid)[GRID_WIDTH])
> {
> - double (*gridOld)[GRID_WIDTH] =
> - malloc(GRID_WIDTH * GRID_HEIGHT * sizeof(double));
> + double (*gridOld)[GRID_WIDTH] = gridOldArray;
> double (*gridNew)[GRID_WIDTH] = gridNewArray;
> printAddress(&gridNew[0][0]);
> printAddress(&gridOld[0][0]);
>
> where gridOldArray is a statically allocated array. Depending on the
> machines processor the performance hit varies from negligible to
> dramatic:
>
>
> Processor GCC Version Time(slow) Time(fast) Performance Hit
> -- --- -- -- ---
> Core 2 Quad Q9550 4.3.3 12.19s 5.11s 138%
> Athlon 64 X2 3800+ 4.3.3 7.34s 6.61s 11%
> Opteron 2378 4.3.2 6.13s 5.60s 9%
> Opteron 2352 4.3.3 8.16s 7.96s 2%
> Xeon 3.00GHz 4.3.3 18.98s 14.67s 29%
>
> Apparently Intel systems are more susceptible to this effect.
>
> Can anyone reproduce these results?
> And could anyone explain, why this happens?
Depends on the GCC version used. First of all
printAddress(&gridNew[0][0]);
printAddress(&gridOld[0][0]);
makes the addresses escape and GCC versions other than the
current development trunk think that the malloced address can
alias the global variables.
Richard.
> Thanks in advance
> -Andreas
>
>
> --
>
> Andreas Schäfer
> Cluster and Metacomputing Working Group
> Friedrich-Schiller-Universität Jena, Germany
> 0049/3641-9-46376
> PGP/GPG key via keyserver
> I'm a bright... http://www.the-brights.net
>
>
> (\___/)
> (+'.'+)
> (")_(")
> This is Bunny. Copy and paste Bunny into your
> signature to help him gain world domination!
>
Re: Strange Performance Hit on 2D-Loop
On 16:37 Thu 09 Jul , Richard Guenther wrote:
> Depends on the GCC version used. First of all
>
> printAddress(&gridNew[0][0]);
> printAddress(&gridOld[0][0]);
>
> makes the addresses escape and GCC versions other than the
> current development trunk think that the malloced address can
> alias the global variables.
AFAICS that doesn't really matter: I still get the same results, even
if I remove printAddress().
-Andreas
--
Andreas Schäfer
Cluster and Metacomputing Working Group
Friedrich-Schiller-Universität Jena, Germany
0049/3641-9-46376
PGP/GPG key via keyserver
I'm a bright... http://www.the-brights.net
(\___/)
(+'.'+)
(")_(")
This is Bunny. Copy and paste Bunny into your
signature to help him gain world domination!
pgptiyoEUGfEm.pgp
Description: PGP signature
Re: libiberty should be a shared library when cc1 has plugin enabled.
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST: > While Ralf's point about static data is valid, the functions likely to > be in libiberty on any platform supporting plugins should not suffer > from this problem. Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as missing setenv, and of course they are tertiary platforms only. However, I wouldn't be surprised if plugins such as melt used setenv, esp. if they spawn other processes, e.g., to compile code. > If you're concerned about it, then build a subset. I've considered a > separation of libiberty into replacements and utilities, anyway. Why would that help in this case? Even if the static data issue concerns one set of these functions only now (does it?), it won't prevent anyone from adding problems to the other set tomorrow, unless you also introduce a policy that libiberty functions be safe against multiple entities. Cheers, Ralf
Re: libiberty should be a shared library when cc1 has plugin enabled.
Ralf Wildenhues wrote:
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
While Ralf's point about static data is valid, the functions likely to
be in libiberty on any platform supporting plugins should not suffer
from this problem.
Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as missing
setenv, and of course they are tertiary platforms only. However, I
wouldn't be surprised if plugins such as melt used setenv, esp. if they
spawn other processes, e.g., to compile code.
MELT is not currently using setenv yet, but may very easily need to use
it. MELT does spawn processes already and uses getenv.
If you're concerned about it, then build a subset. I've considered a
separation of libiberty into replacements and utilities, anyway.
Why would that help in this case? Even if the static data issue
concerns one set of these functions only now (does it?), it won't
prevent anyone from adding problems to the other set tomorrow, unless
you also introduce a policy that libiberty functions be safe against
multiple entities.
I do agree with this point.
Currently, in plugin mode, MELT does not use libiberty any more (which
is a shame). So far, the only functions annoying me are pex_execute &
friends (-in plugin mode MELT is simply calling system-) and
choose_tmpdir (-in plugin mode MELT just calls tmpnam, which is pityful).
But we really need to decide if all of libiberty is usable in plugins. I
believe it should be usable in plugins, because that is the easiest way
to prototype future GCC core code: make it a plugin, and when it is
ready & mature, propose it as a patch. I think that plugins are a new
possibility in GCC, and FSF owned plugins should be welcomed (sadly I
know that most people disagree with that).
We could also state that libiberty is becoming deprecated (in favor of
recent standards like some flavor of Posix, ...). [I am half joking; I
understand that they are many platforms requiring libiberty]
But we need to state a clear policy about libiberty & plugins. Can
plugins use all of libiberty or should they use only functions already
called by cc1?
[I am not able to propose a patch about this libiberty point because I
do not understand all the portability issues]
Regards.
PS. I hope that my RTLD_GLOBAL patch
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00497.html will be reviewed
& accepted. It is essential (& tiny).
--
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} ***
Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg
> "Larry" == Larry Evans writes: Larry> I compiled gcc with -g3 -O0' compiler flags to enable invocation of Larry> macros during a gdb session; however, the Larry> macro, PACK_EXPANSION_PATTERN, apparently uses a symbol: Larry> __extension__ Larry> not understood by gdb. How can gdb be made to understand Larry> __extension__ or how can __extension__ be rm'ed from the Larry> macros? This is a gdb PR: http://sourceware.org/bugzilla/show_bug.cgi?id=9748 If you use a new (CVS) gdb, that has "macro define", you can use the defines in that PR to circumvent the GCC statement expressions and make everything work reasonably well. You lose checking but I never missed that when evaluating things from the gdb CLI. Once this gdb is released I think those macro defines should go in gcc's .gdbinit. Tom
plugins & PCH
Hello
I believe plugins and PCH are not always mixing well. For sure, plugins
which are using PLUGIN_REGISTER_GGC_ROOTS & are called when *generating*
a precompiled header should be coded with extraordinary care, and very
probably some more suppport is needed inside the GCC trunk.
See the discussion on
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html for more.
Maybe we should for the moment issue a warning when a precompiled header
is generated with plugins having used PLUGIN_REGISTER_GGC_ROOTS?
To be safe, the generated *gch file should know all the active plugins
when it was generated. We also need a "dynamic tag" support which I only
sketched in the discussion of
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html
Of course, this does not affect the read of precompiled headers.
Comments are welcome.
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} ***
Re: Internal Representation
Nicolas COLLIN writes: >> From internal representation. I got the body with DECL_SAVED_TREE >> and I > succeed to get the name of functions and methods called from > CALL_EXPR, using TREE_OPERAND, EXPR_STMT_EXPR, etc... But I can't get > the object on which is called the method (for example in att.getX(); i > would like to get the name :"att"). I tried in many ways but never got > it. There need not be any such name (f().getX()), or for a given call there may be more than one such name (f ? a.getX() : b.getX() with the method call factored out by the optimizers). Assuming you are working in SSA form, and assuming you have an SSA_VAR, the best you can do is look back to the defining statement to see if you can find a VAR_DECL there. Ian
Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu
Andrew Stubbs writes: > The problem insn is created by gen_reload when it is given the > following rtl as input: > > (plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:192 a ] [192]) > (const_int 2 [0x2])) > (reg:SI 0 r0 [orig:188 ivtmp.24 ] [188])) You need to backtrack before that point to see why find_reloads let that go through. Ian
gcc-4.5-20090709 is now available
Snapshot gcc-4.5-20090709 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090709/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 149446 You'll find: gcc-4.5-20090709.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090709.tar.bz2 C front end and core compiler gcc-ada-4.5-20090709.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090709.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090709.tar.bz2 C++ front end and runtime gcc-java-4.5-20090709.tar.bz2 Java front end and runtime gcc-objc-4.5-20090709.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090709.tar.bz2The GCC testsuite Diffs from 4.5-20090702 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: TARGET_OPTION_CAN_INLINE_P vs TARGET_CAN_INLINE_P
> The OPTION is there because this was introduced for the option
> attribute. But the entry in the target structure is named
> can_inline_p, and the macro should be TARGET_CAN_INLINE_P. So the
> doc is the desired state, and the code is not.
How's this?
* targhooks.c (default_target_can_inline_p): Rename from
default_target_option_can_inline_p.
* targhooks.h (default_target_can_inline_p): Likewise.
* target-def.h (TARGET_CAN_INLINE_P): Rename from
TARGET_OPTION_CAN_INLINE_P.
* config/i386/i386.c (TARGET_CAN_INLINE_P): Likewise.
* config/mep/mep.c (TARGET_CAN_INLINE_P): Likewise.
(mep_target_can_inline_p): Rename from
mep_target_option_can_inline_p.
Index: targhooks.c
===
--- targhooks.c (revision 149452)
+++ targhooks.c (working copy)
@@ -768,13 +768,13 @@ default_target_option_pragma_parse (tree
"#pragma GCC target is not supported for this machine");
return false;
}
bool
-default_target_option_can_inline_p (tree caller, tree callee)
+default_target_can_inline_p (tree caller, tree callee)
{
bool ret = false;
tree callee_opts = DECL_FUNCTION_SPECIFIC_TARGET (callee);
tree caller_opts = DECL_FUNCTION_SPECIFIC_TARGET (caller);
/* If callee has no option attributes, then it is ok to inline */
Index: targhooks.h
===
--- targhooks.h (revision 149452)
+++ targhooks.h (working copy)
@@ -104,8 +104,8 @@ extern int default_reloc_rw_mask (void);
extern tree default_mangle_decl_assembler_name (tree, tree);
extern tree default_emutls_var_fields (tree, tree *);
extern tree default_emutls_var_init (tree, tree, tree);
extern bool default_hard_regno_scratch_ok (unsigned int);
extern bool default_target_option_valid_attribute_p (tree, tree, tree, int);
extern bool default_target_option_pragma_parse (tree, tree);
-extern bool default_target_option_can_inline_p (tree, tree);
+extern bool default_target_can_inline_p (tree, tree);
extern unsigned int default_case_values_threshold (void);
Index: target-def.h
===
--- target-def.h(revision 149452)
+++ target-def.h(working copy)
@@ -824,24 +824,24 @@
#endif
#ifndef TARGET_OPTION_PRAGMA_PARSE
#define TARGET_OPTION_PRAGMA_PARSE default_target_option_pragma_parse
#endif
-#ifndef TARGET_OPTION_CAN_INLINE_P
-#define TARGET_OPTION_CAN_INLINE_P default_target_option_can_inline_p
+#ifndef TARGET_CAN_INLINE_P
+#define TARGET_CAN_INLINE_P default_target_can_inline_p
#endif
#define TARGET_OPTION_HOOKS\
{\
TARGET_OPTION_VALID_ATTRIBUTE_P, \
TARGET_OPTION_SAVE,\
TARGET_OPTION_RESTORE, \
TARGET_OPTION_PRINT, \
TARGET_OPTION_PRAGMA_PARSE,\
-TARGET_OPTION_CAN_INLINE_P,\
+TARGET_CAN_INLINE_P, \
}
/* The whole shebang. */
#define TARGET_INITIALIZER \
{ \
TARGET_ASM_OUT, \
Index: config/mep/mep.c
===
--- config/mep/mep.c(revision 149453)
+++ config/mep/mep.c(working copy)
@@ -167,13 +167,13 @@ static tree mep_validate_based_tiny (tre
static tree mep_validate_near_far (tree *, tree, tree, int, bool *);
static tree mep_validate_disinterrupt (tree *, tree, tree, int, bool *);
static tree mep_validate_interrupt (tree *, tree, tree, int, bool *);
static tree mep_validate_io_cb (tree *, tree, tree, int, bool *);
static tree mep_validate_vliw (tree *, tree, tree, int, bool *);
static bool mep_function_attribute_inlinable_p (const_tree);
-static bool mep_option_can_inline_p (tree, tree);
+static bool mep_can_inline_p (tree, tree);
static bool mep_lookup_pragma_disinterrupt (const char *);
static int mep_multiple_address_regions (tree, bool);
static int mep_attrlist_to_encoding (tree, tree);
static void mep_insert_attributes (tree, tree *);
static void mep_encode_section_info (tree, rtx, int);
static section * mep_select_section (tree, int, unsigned HOST_WIDE_INT);
@@ -233,14 +233,14 @@ static tree mep_gimplify_va_arg_expr (tr
#undef TARGET_COMP_TYPE_ATTRIBUTES
#define TARGET_COMP_TYPE_ATTRIBUTESmep_comp_type_attributes
#undef TARGET_INSERT_ATTRIBUTES
#define TARGET_INSERT_ATTRIBUTES mep_insert_attributes
#undef TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P
#define TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P
mep_function_attribute_inlinable_p
-#undef TARGET_OPTION_CAN_INLINE_P
-#define TARGET_OPTION_CAN_INLINE_P mep_option_can_inline_p
+#undef TARGET_CAN_INLINE_P
+#define TARGET_CAN_INLINE_Pmep_can_inline_p
Re: TARGET_OPTION_CAN_INLINE_P vs TARGET_CAN_INLINE_P
DJ Delorie writes: > * targhooks.c (default_target_can_inline_p): Rename from > default_target_option_can_inline_p. > * targhooks.h (default_target_can_inline_p): Likewise. > * target-def.h (TARGET_CAN_INLINE_P): Rename from > TARGET_OPTION_CAN_INLINE_P. > * config/i386/i386.c (TARGET_CAN_INLINE_P): Likewise. > * config/mep/mep.c (TARGET_CAN_INLINE_P): Likewise. > (mep_target_can_inline_p): Rename from > mep_target_option_can_inline_p. This is OK. Thanks. Ian
Re: TARGET_OPTION_CAN_INLINE_P vs TARGET_CAN_INLINE_P
Thanks, committed.
CALL_USED_REGISTERS vs CALL_REALLY_USED_REGISTERS
Hello all, The GCC 4.4.0 internal says : [Macro] CALL_REALLY_USED_REGISTERS Like CALL_USED_REGISTERS except this macro doesn’t require that the entire set of FIXED_REGISTERS be included. (CALL_USED_REGISTERS must be a superset of FIXED_ REGISTERS). This macro is optional. If not specifed, it defaults to the value of CALL_USED_REGISTERS. But it doesn't say why one needs to use this. What is the need for the macro CALL_REALLY_USED_REGISTERS when compared to CALL_USED_REGISTERS? regards, Shafi
