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 defau
Thanks, committed.
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.
> * co
> 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_ca
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
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 s
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 a
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 di
> "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 ma
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
* 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 mi
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 c
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
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
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
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 li
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
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 an
* 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
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
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
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 o
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 syste
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 dynami
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 i
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".
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. F
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
28 matches
Mail list logo
