Finding gcc plugin headers
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. Brad
Re: Code optimization only in loops
> It seems that when set in a loop, the program is able to perform some > type of optimization to actually get the use of the offsets where as > in the case of no loop, we have twice the calculations of instructions > for each address calculations. I suggest you look at the dumps for i386 to see which pass does the changes, and then see what happens in your port. Paolo
Re: An optimization question
Dave Korn wrote:
> Andrew Haley wrote:
>> eCos@ wrote:
>
>>> ===
>>> int *p;
>>>
>>> int main(void)
>>> {
>>> p++;
>>> __asm__ __volatile__ (""::);
>>> p++;
>>> }
>>> ===
>
>>> assembly code is like:
>>> 'addl $4, %eax'
>>> 'addl $4, %eax'
>
>>> ===
>>> int *p;
>>>
>>> int main(void)
>>> {
>>> p++;
>>> __asm__ __volatile__ (""::);
>>> p+=8;
>>> }
>>> ===
>
>>> According to the assembly code, we found that gcc merge the 'p++' & 'p+=8'
>>> and generate 'addl $36, p'
>
>> If you really need a memory barrier, you have to use one:
>
> So, this is a real bug then - but it's a missed optimisation in the first
> case, not a bogus one in the second case?
Probably, but it's not a very interesting one. For what it's worth, the
tree dumps are identical right up to the very last tree optimization pass.
Andrew.
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: An optimization question
Andrew Haley wrote: > Dave Korn wrote: >> So, this is a real bug then - but it's a missed optimisation in the first >> case, not a bogus one in the second case? > > Probably, but it's not a very interesting one. For what it's worth, the > tree dumps are identical right up to the very last tree optimization pass. Did you accidentally send an old draft? This sounds a lot like what you said yesterday, or did you just mean to de-emphasise it a bit? I guess I agree that it's not a very important missed optimisation, you have to expect a few when volatile is in play. cheers, DaveK
Re: Finding gcc plugin headers
Rafael Espindola wrote: > 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: Instead of pkg-config, the tradition for GCC is to use one of the driver's default switches. Does gcc -print-file-name=plugin/include/.h work for you? cheers, DaveK
Re: An optimization question
Dave Korn wrote: > Andrew Haley wrote: >> Dave Korn wrote: > >>> So, this is a real bug then - but it's a missed optimisation in the first >>> case, not a bogus one in the second case? >> Probably, but it's not a very interesting one. For what it's worth, the >> tree dumps are identical right up to the very last tree optimization pass. > > Did you accidentally send an old draft? Yes. My mailer unstuck itself. Andrew.
[C++] Inheritance chain enumeration
Consider a class hierarchy with single inheritance, as follows:
struct A {
virtual ~A() = default;
}
struct B : public A {
virtual ~B() = default;
};
and
A* p = new B();
then how can I get the type_info object of the base class of B?
Or, in other words, how do I enumerate the chain of base classes
starting with a pointer to an object? Of course I mean a GCC-internals
-aware way. The following short document:
http://www.codesourcery.com/public/cxx-abi/abi.html#rtti
says that
"For similar reasons, we only keep direct base information about
a class type. Indirect base information can be found by chasing
type_info pointers (and care should be taken to determine
ambiguous base class types)."
Namely, where do you keep the "direct base information about
a class type" and what data structures from libstdc++ should I
become familiar with? And the last question: is the format
expected to stable in terms of GCC development?
Best regards
Piotr Wyderski
RE: Multilib for ARM in thumb2 mode
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Samuel Tardieu > Sent: 06 May 2009 11:06 > To: gcc@gcc.gnu.org > Subject: Multilib for ARM in thumb2 mode > > Right now, to be able to compile a mutilib-enabled ARM-targeted > compiler > supporting thumb2, one has to uncomment some code in > gcc/config/arm/t-arm-elf. Given that thumb2 processors are more and > more > used (such as microcontrollers based on the Cortex-M3), wouldn't it > make > sense to unconditionnaly compile the thumb2 version of the library in > 4.5.0 and 4.4.1? Don't you already get this if you created a toolchain with --with-arch=armv7-m and the multilib for thumb ? A toolchain configured for --with-arch=armv7-m and the multilib for thumb would automatically cover this configuration. By default we compile for armv4t and why should one have an additional multi-lib for thumb2 in such a case ? Cheers Ramana
Re: Multilib for ARM in thumb2 mode
* Alexandre Pereira Nunes [2009-05-08 11:24:14 -0300] | > Don't you already get this if you created a toolchain with | > --with-arch=armv7-m and the multilib for thumb ? A toolchain configured for | > --with-arch=armv7-m and the multilib for thumb would automatically cover | > this configuration. By default we compile for armv4t and why should one | > have | > an additional multi-lib for thumb2 in such a case ? | | And how would someone generate code for an armv4t, or v5, or even v6, with | thumb1, and other scenarios, using a toolchain built the way you suggest? | Samuel's idea seems to increase the multilib range to cover most arm | configurations, and not to generate a build restricted to lesser | configurations. To cope with your idea and still get the other cases, one | would have to tweak the multilib configuration anyway, so Samuel's idea | seems the way to go from the start. Yes, this is exactly what I was thinking: cover more configurations. For example, in the engineering school where I teach, we have many ARM boards with different CPUs, and we would really like to have a single cross-compiler that our students can use or install on their own machines. Sam
Re: [C++] Inheritance chain enumeration
Piotr Wyderski wrote: > Namely, where do you keep the "direct base information about > a class type" and what data structures from libstdc++ should I > become familiar with? And the last question: is the format > expected to stable in terms of GCC development? libstdc++-v3/libsupc++/typeinfo. Anything defined in the ABI docs should be pretty stable. To find the base classes, look at the typeinfo for the class, which will be abi::__class_type_info or one of its derivatives as specified in the ABI doc section 2.9.5; the derived types have pointers to (one or more) base class typeinfos. cheers, DaveK
RE: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report (2009-05-05)]
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Paolo Bonzini > Sent: 07 May 2009 14:53 > To: m...@codesourcery.com > Cc: gcc@gcc.gnu.org; Ramana Radhakrishnan; Richard Earnshaw > Subject: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report > (2009-05-05)] > > > > The slush that I requested last week has been lifted. However, I > have > > asked for relative calm until the cond-optab branch has been merged > to > > mainline, which will hopefully occur on Friday, May 8th. > > cond-optab branch was bootstrapped on arm-linux among other targets, so > the merge should not introduce any new problem. Still, because the ARM > crash has not been solved yet, I will perform the merge either on > Friday > 8th *afternoon* or on Tuesday 12th *morning* (always European time). > > I'll go for Tuesday unless I get a "go" from either Richard Earnshaw > (ARM maintainer and global reviewer) or Ramana Radhakrishnan (who's > taking care of bootstrapping the ARM-fixing patch). The patch thanks to Michael got arm-linux-gnueabi bootstrapping again. The tests are still running and I don't notice anything untoward with atleast the ARM tests. It's now cycling on to the thumb tests. cheers Ramana > > Paolo
Re: [C++] Inheritance chain enumeration
Dave Korn wrote: > To find the base classes, look at the typeinfo for the class, which will be > abi::__class_type_info or one of its derivatives as specified in the ABI doc It should be __si_class_type_info in my case. Beautiful! Many thanks Dave :-) BTW, how do you know what derivate is pointed to by a pointer during RTTI processing, especially in the context of exception handling? Is there a type_info for type_info, e.g. an enum? Best regards Piotr Wyderski
[Fwd: Failure in bootstrapping gfortran-4.5 on Cygwin]
The current snapshot 4.5-20090507 fails to bootstrap on Cygwin:
[...]
/tmp/build/./prev-gcc/xgcc -B/tmp/build/./prev-gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-DHAVE_CONFIG_H -I. -I. -I/tmp/gcc-4.5-20090507/gcc
-I/tmp/gcc-4.5-20090507/gcc/. -I/tmp/gcc-4.5-20090507/gcc/../include
-I/tmp/gcc-4.5-20090507/gcc/../libcpp/include
-I/tmp/gcc-4.5-20090507/gcc/../libdecnumber
-I/tmp/gcc-4.5-20090507/gcc/../libdecnumber/bid -I../libdecnumber-I.
-I. -I/tmp/gcc-4.5-20090507/gcc -I/tmp/gcc-4.5-20090507/gcc/.
-I/tmp/gcc-4.5-20090507/gcc/../include
-I/tmp/gcc-4.5-20090507/gcc/../libcpp/include
-I/tmp/gcc-4.5-20090507/gcc/../libdecnumber
-I/tmp/gcc-4.5-20090507/gcc/../libdecnumber/bid -I../libdecnumber \
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c
cc1: warnings being treated as errors
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:39: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:39: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:40: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:40: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:41: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:41: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:42: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:42: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:43: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:43: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:44: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:44: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:44: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:44: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:58: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:75: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:87: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:110: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:128: error: enum
conversion in initialization is invalid in C++
/tmp/gcc-4.5-20090507/gcc/config/i386/msformat-c.c:145: error: enum
conversion in initialization is invalid in C++
make[3]: *** [msformat-c.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gfortran.pod gfdl.pod gcov.pod cpp.pod fsf-funding.pod gcc.pod
make[3]: Leaving directory `/tmp/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/tmp/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/tmp/build'
make: *** [all] Error 2
Usually I do weekly build configuring with:
${gcc_dir}/configure --prefix=/usr/local/gfortran
--exec-prefix=/usr/local/gfortran --sysconfdir=/usr/local/gfortran/etc
--libdir=/usr/local/gfortran/lib --libexecdir=/usr/local/gfortran/lib
--mandir=/usr/local/gfortran/share/man
--infodir=/usr/local/gfortran/share/info --program-suffix=-4.4
--enable-languages=c,fortran --enable-bootstrap
--enable-decimal-float=bid --enable-libgomp --enable-threads
--enable-sjlj-exceptions --enable-version-specific-runtime-libs
--enable-nls --enable-checking=release --disable-fixed-point
--disable-libmudflap --disable-shared --disable-win32-registry
--with-system-zlib --without-included-gettext --without-x
Cheers,
Angelo.
Re: opaque vector types?
On Wed, May 06, 2009 at 02:29:46AM -0400, DJ Delorie wrote:
>
> Andrew Pinski writes:
> > You could do what the rs6000 back-end does for the altivec builtins
> > and resolve them while the parser is run (the SPU back-end does the
> > same thing too). Yes there are opaque vector types, you just use
> > build_opaque_vector_type instead of build_vector_type.
>
> Thanks, I'll look at those. Any way to prototype such functions in C ?
As Andrew says the rs6000/spu have the notion of overloaded builtins. I've
been working in this area somewhat for the power7 port, and you might want to
look at my power7-branch.
In rs6000.h it uses REGISTER_TARGET_PRAGMAS to set the
resolve_overloaded_builtin target hook:
/* Target pragma. */
#define REGISTER_TARGET_PRAGMAS() do { \
c_register_pragma (0, "longcall", rs6000_pragma_longcall);\
targetm.resolve_overloaded_builtin = altivec_resolve_overloaded_builtin; \
} while (0)
In rs6000-c.c you have the function that tries to resolve the builtin given the
argument types:
tree
altivec_resolve_overloaded_builtin (tree fndecl, void *passed_arglist)
{
...
}
It returns a tree of the builtin function with the appropriate types. In the
code, there is a giant table (altivec_overloaded_builtins) that maps the
generic builtin functions to the specific ones based on the argument types.
For example, altivec has a builtin function that does absolute value for any
vector type, and internally it converts this to the appropriate builtin for
each type:
const struct altivec_builtin_types altivec_overloaded_builtins[] = {
/* Unary AltiVec/VSX builtins. */
{ ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V16QI,
RS6000_BTI_V16QI, RS6000_BTI_V16QI, 0, 0 },
{ ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V8HI,
RS6000_BTI_V8HI, RS6000_BTI_V8HI, 0, 0 },
{ ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V4SI,
RS6000_BTI_V4SI, RS6000_BTI_V4SI, 0, 0 },
{ ALTIVEC_BUILTIN_VEC_ABS, ALTIVEC_BUILTIN_ABS_V4SF,
RS6000_BTI_V4SF, RS6000_BTI_V4SF, 0, 0 },
...
};
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com
Re: [gnat] reuse of ASTs already constructed
> "Oliver" == Oliver Kellogg writes: Oliver> Also, I'm thinking that in multi-source mode, the switch "-o" Oliver> can perhaps continue to be used - not by giving a filename Oliver> but instead by giving a directory. All object files would then Oliver> be placed in the given directory. What do you think? I think a new option would be preferable to overloading the meaning of an existing one. Tom
Re: Avoiding REG+OFF memory accesses
Ian suggestion worked perfectly, thanks. Can you tell me the macro/function name to look up to work out the secondary reload you're mentioning? - Original Message From: Michael Meissner To: Ian Lance Taylor Cc: Iceman ; g...@gnu.org Sent: Friday, May 8, 2009 11:47:43 AM Subject: Re: Avoiding REG+OFF memory accesses On Wed, May 06, 2009 at 05:01:33PM -0700, Ian Lance Taylor wrote: > Iceman writes: > > > Sorry for such trivial question, but is there any macro that can be used to > > avoig GCC to generate > > REG+OFF memory accesses? > > So basically to force GCC to break: > > > > (mem (plus (reg const_int))) > > > > into > > > > (set regtmp (plus (reg const_int))) > > (set (mem regtmp) reg) > > > > This w/out writing custom RTL. > > Assuming this is a private port, this should happen more or less > automatically if GO_IF_LEGITIMATE_ADDRESS rejects register plus offset > addressing. > > If that is not what you are looking for, I think you need to provide > some more context. And you may also need to provide secondary reload support as well to convert spill addresses into just REG addresses. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
Re: [Fwd: Failure in bootstrapping gfortran-4.5 on Cygwin]
Angelo Graziosi writes: > The current snapshot 4.5-20090507 fails to bootstrap on Cygwin: There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html Not sure if it has been approved. I sort of thing that (enum format_lengths) 0 should be replaced by FMT_LEN_none In c-format.c I replaced (enum format_std_version) 0 with STD_C89 but that is certainly more a style issue than anything substantive. Ian
Re: [Fwd: Failure in bootstrapping gfortran-4.5 on Cygwin]
Ian Lance Taylor wrote: Angelo Graziosi writes: The current snapshot 4.5-20090507 fails to bootstrap on Cygwin: It did bootstrap effortlessly for me, once I logged off to clear hung processes, with the usual disabling of strict warnings. I'll let testsuite run over the weekend.
Re: Finding gcc plugin headers
On Friday 08 May 2009 10:37:27 pm Dave Korn wrote: > Instead of pkg-config, the tradition for GCC is to use one of the > driver's default switches. Does > > gcc -print-file-name=plugin/include/.h > > work for you? $ /opt/gccsvn/bin/gcc -print-file-name=plugin/include/gcc-plugin.h /opt/gccsvn/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin/include/gcc-plugin.h So if my autoconf / cmake tool just checked for $ /opt/gccsvn/bin/gcc -print-file-name=plugin/include /opt/gccsvn/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin/include then I should be set. Thanks Brad
Re: Avoiding REG+OFF memory accesses
Perfect, thank you! - Original Message From: Michael Meissner To: Iceman Cc: Michael Meissner ; Ian Lance Taylor ; g...@gnu.org Sent: Friday, May 8, 2009 3:45:20 PM Subject: Re: Avoiding REG+OFF memory accesses On Fri, May 08, 2009 at 02:05:18PM -0700, Iceman wrote: > > Ian suggestion worked perfectly, thanks. Can you tell me the macro/function > name to look up > to work out the secondary reload you're mentioning? Look up TARGET_SECONDARY_RELOAD in the documentation. Basically it is a hook that is called and the backend can say it needs extra scratch registers for a move, or whether it needs to load a value into another register class. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
varargs target handling
Hi!
I'm porting GCC to a software VM with 32 32bit registers, and 32 64bit
registers.
The 64bit registers are used for DI, SF and DF mode. Pointers and QI, HI and SI
modes are handled with 32bit registers.
The first 8 32bit parameters of functions are passed into the first 8 32bit
registers (g0..7)
and the first 8 64bit function parameters are passed in the first 8 64bit
registers (d0..7).
Everything works fine, but now I've to figure out how to handle varargs
functions.
Before adding the 64bit registers, I simply had a bit set in the cumulative
args, to signal
a vararg function, and I was dumping g0..7 in the prologue, that looked like:
str.l g0, SP[4]
str.l g1, SP[8]
str.l g2, SP[12]
str.l g3, SP[16]
str.l g4, SP[20]
str.l g5, SP[24]
str.l g6, SP[28]
str.l g7, SP[32]
push SP
mov SP, FP
This was working fine, and the code generated by GCC for the _builtin_* va_arg
macros
were OK.
Now having the 64bit registers passed in registers (before they were pushed)
confuses
me a little WRT the implementation.
My idea was to increase REG_PARM_STACK_SPACE to add the space for 8 64bit
registers,
and dump d0..7 into this area.
So instead of (8 * 4) it'd become (8 * 4 + 8 * 8).
Then I was thinking in creating a va_list (via xxx_build_builtin_va_list())
like:
struct va_list {
void *gptr; // Pointer to the first byte after the register dump area
void *rptr;// Pointer to the first byte of the 32bit dump area
int rcount; // Byte count left for 32bit pulls
void *xptr; // Pointer to the first byte of the 64bit dump area
int xcount; // Byte count left for 64bit pulls
};
In xxx_va_start() I'd initialize va_list like:
first_arg = SP + 4; // Skip IP
v->gptr = first_arg + 8 * 4 + 8 * 8;
v->rptr = first_arg;
v->rcount = 8 * 4;
v->xptr = v->rptr + 8 * 4;
v->xcount = 8 * 8;
The in the arg function I'd implement a logic like:
if (TYPE_SIZE <= 4) {
if (v->rcount > 0) {
arg = *(int *) v->rptr;
v->rptr += 4;
v->rcount -= 4;
} else {
arg = *(int *) v->gptr;
v->gptr += 4;
}
return arg;
}
if (v->xcount > 0) {
arg = *(long long *) v->xptr;
v->xptr += 8;
v->xcount -= 8;
} else {
arg = *(long long *) v->gptr;
v->gptr += 8;
}
return arg;
Question. Am I doing it wrong? If yes, what are my best options to tackle this
problem?
If not, how can I implement the logic above in practical terms?
Thank you,
