Re: Alias analysis or DSE problem?
On Tue, Oct 20, 2009 at 1:34 AM, Justin Seyster wrote:
> Thanks a lot for the help! It looks like creating a temporary
> took care of it.
>
> On Sat, Oct 17, 2009 at 7:41 AM, Richard Guenther
> wrote:
>> I think the call you insert is not of valid gimple form - an address
>> argument has to fulfill the is_gimple_min_invariant() predicate.
>> Thus I suspect you have something like &ptr->field in there which
>> needs a temporary.
>
> That was it. Actually, the TREE was of the form
> ADDR_EXPR(ARRAY_REF(STRING_CST)), which does not satisfy
> is_gimple_min_invariant().
>
> The strange thing is, I copied that structure verbatim from
> unmodified GCC. I'm trying to insert a call that looks like:
>
> foo("some string constant");
>
> If I put that function call in a simple C program and dump out
> the resulting GIMPLE, it gives me the ADDR_EXPR that was causing
> problems in refs_may_alias_p_1().
>
> Does anyone know why that structure is ok in the contexts that
> GCC is using it but not in the context that my plug-in uses it
> in?
If your "string" does not satisfy is_gimple_min_invariant then
it is not of the form you mentioned above. A wild guess would
be that you have the 2nd or 3rd operand of the ARRAY_REF set.
Richard.
> --Justin
>
Re: __attribute__((optimize)) and fast-math related oddities
On Tue, Oct 20, 2009 at 1:54 AM, tbp wrote: > On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor wrote: >> Please file a bug report. >> __attribute__((optimize())) is definitely only half-baked. > Apparently the code i've posted is just a variation around that 1 year > old PR 37565 and if that doesn't work, worrying about the rest is > entirely futile. > Half baked you say? It's comforting to see that much optimism but > couldn't the doc be adjusted a bit to reflect the fact that the baker > got hit by a bus or something? I would rather suggest to rip out the half-baked code again. Richard.
Re: i370 port - constructing compile script
../configure --target=i370-mvspdp --prefix=/devel/mvscross
--with-sysroot=/devel/mvshead
--enable-languages=c
plus make and make install
then I went to
mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx
and replaced it with a script that does:
i370-mvspdp-xxx -S $*
Maybe a more generic way to work around the missing assembler and linker
would be to provide dummy scripts i370-mvspdp-as
I created one of them, but as far as I can tell it didn't pick it up.
and i370-mvspdp-ld, where
the "assembler" would simply copy the assembler source input as text to
the
"object" file output, and the "linker" would collect all input files into
a tar file (or some other archive) as "executable" output ...
Sounds good.
This would allow usual build processes (including "make") to proceed as
expected.
Yes.
The compiler error output found in the config.log file should hopefully
point to the problem ...
Well, below are some of the changes I made today to get it to go
past the various errors. Probably the most interesting was this
one:
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
I don't have a sys/param.h and so I just stuck those in somewhere
that it seemed to be looking for, so that it didn't come up and say
that it couldn't determine the endian order.
It seemed to try very hard to stick in sys/types.h and sys/time.h
and I'm not sure how well I got around that.
It also seemed to execute /bin/as at one point instead of my
dummy cross-assembler. I'll try to figure out what the logic
is tomorrow.
Note - all this is on 3.4.6.
BFN. Paul.
Index: configure
===
RCS file: /cvsroot/gccnew/gcc/configure,v
retrieving revision 1.1.1.1
retrieving revision 1.8
diff -c -r1.1.1.1 -r1.8
*** configure 9 Jul 2009 00:25:05 - 1.1.1.1
--- configure 20 Oct 2009 12:39:48 - 1.8
***
*** 2463,2470
/* end confdefs.h. */
#include
#include
! #include
! #include
/* Most of the following tests are stolen from RCS 5.7's src/conf.sh. */
struct buf { int x; };
FILE * (*rcsopen) (struct buf *, struct stat *, int);
--- 2463,2470
/* end confdefs.h. */
#include
#include
! /*#include
! #include */
/* Most of the following tests are stolen from RCS 5.7's src/conf.sh. */
struct buf { int x; };
FILE * (*rcsopen) (struct buf *, struct stat *, int);
***
*** 3377,3383
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! #include
int
--- 3377,3383
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! /*#include */
int
***
*** 3448,3454
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! #include
int
--- 3448,3454
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! /*#include */
int
***
*** 3519,3525
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! #include
int
--- 3519,3525
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! /*#include */
int
***
*** 3590,3596
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! #include
int
--- 3590,3596
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! /*#include */
int
***
*** 3662,3668
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! #include
int
--- 3662,3668
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! /*#include */
int
***
*** 3735,3741
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! #include
int
--- 3735,3741
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include "confdefs.h"
! /*#include */
int
***
*** 5656,5662
if test $ac_cv_header_time = yes; then
cat >>confdefs.h <<\_ACEOF
! #define TIME_WITH_SYS_TIME 1
_ACEOF
fi
--- 5656,5662
if test $ac_cv_header_time = yes; then
cat >>confdefs.h <<\_ACEOF
! /*#define TIME_WITH_SYS_TIME 1*/
_ACEOF
fi
***
*** 6150,6157
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
! #include
! #include
int
main ()
{
--- 6150,6160
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
! /*#include
! #include */
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
int
main ()
{
***
*** 6192,6199
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
! #include
! #include
int
main ()
{
--- 6195,6205
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
! /*#include
! #include */
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYT
Re: i370 port - constructing compile script
Paul Edwards wrote: > > Maybe a more generic way to work around the missing assembler and linker > > would be to provide dummy scripts i370-mvspdp-as > > I created one of them, but as far as I can tell it didn't pick it up. Ah, you'll probably have to re-run configure and rebuild the cross compiler. The configure/build process checks for the presence of the cross-assembler and decides which one to use. > > The compiler error output found in the config.log file should hopefully > > point to the problem ... > > Well, below are some of the changes I made today to get it to go > past the various errors. Probably the most interesting was this > one: > > ! #define BIG_ENDIAN 1 > ! #define LITTLE_ENDIAN 2 > ! #define BYTE_ORDER 1 > > I don't have a sys/param.h and so I just stuck those in somewhere > that it seemed to be looking for, so that it didn't come up and say > that it couldn't determine the endian order. Hmm, it seems configure does use a couple of fallbacks to determine byte order if sys/param.h doesn't exist, but those require a working cross-assembler ... > It seemed to try very hard to stick in sys/types.h and sys/time.h > and I'm not sure how well I got around that. Generally speaking, the configure process should work on non-POSIX systems that don't provide those headers. But it may well be that something is broken in this case; this will be rarely tested ... > It also seemed to execute /bin/as at one point instead of my > dummy cross-assembler. I'll try to figure out what the logic > is tomorrow. See above; you should try to rebuild the cross-compiler first. > Index: configure > === > RCS file: /cvsroot/gccnew/gcc/configure,v For now, just patching configure to see how far you get is of course fine. Longer term, however, note that configure is a generated file. You'd have to make those changes either in configure.ac or possible within the autoconf machinery that generates the file. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Need help in understanding code generated for C++ exception handling
Shankar Iyer writes: > I have compiled and generated a C++ shared library with the "-fPIC" option. > But this shared library requires text relocation during runtime and is not > usable on seLinux which disables writeable text segments. The text relocation > is due to use of exceptions inside the shared library. There is a segment > ".gcc_except_table" created in the shared library and it contains symbols > suffixed with "$$LSDA" :- > > 0013df38 <_ZN6comref4runt11userdef20releasebackEPS1_$$LSDA>: > 13df38: ff 00 incl (%eax) > 13df3a: 18 01 sbb%al,(%ecx) > 13df3c: 0c 1c or $0x1c,%al > 13df3e: 03 2f add(%edi),%ebp > 13df40: 01 52 0aadd%edx,0xa(%edx) > 13df43: 6d insl (%dx),%es:(%edi) > 13df44: 00 66 1aadd%ah,0x1a(%esi) > 13df47: 00 00 add%al,(%eax) > 13df49: 02 00 add(%eax),%al > ... >13df4b: R_386_32_ZTIN6comref4runt12genExceptionE > > > Can someone please help in understand the issue and how to work around? This question as stated is not appropriate for the gcc@gcc.gnu.org mailing list. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. You neglected to mention which version of gcc you are using. Normally when compiling with -fPIC the compiler will make the .gcc_except_table section writable if necessary. So the first step is to use readelf -S or objdump -h to see if the section is writable. If it is, it should not be in the text segment. If the section is read-only, then tell us what relocations appear in the section, by using readelf -r. Also tell us the version of the GNU binutils that you are using, and whether it is the same version that was used when gcc was configured and built. The build process will test the binutils at build time to see what capabilities they have. Ian
[RFC] Enabling -flto in libstdc++?
On my nightly tester I force libstdc++ to be built with -flto enabled using
$ make check RUNTESTFLAGS=--target_board=unix/"\{-flto/-O2,-fwhopr/-O2\}"
Recently, this started showing 17 regressions that we don't see in
other testsuites. It would be useful if we would run libstdc++ with
-flto as well as the regular options. This will make testing
libstdc++ longer, but it is useful for LTO as several of these tests
are significant.
Would this be OK?
Thanks. Diego.
Re: [RFC] Enabling -flto in libstdc++?
On Tue, 20 Oct 2009, Diego Novillo wrote:
> On my nightly tester I force libstdc++ to be built with -flto enabled using
>
> $ make check RUNTESTFLAGS=--target_board=unix/"\{-flto/-O2,-fwhopr/-O2\}"
>
> Recently, this started showing 17 regressions that we don't see in
> other testsuites. It would be useful if we would run libstdc++ with
> -flto as well as the regular options. This will make testing
> libstdc++ longer, but it is useful for LTO as several of these tests
> are significant.
>
> Would this be OK?
libstdc++ is a very slow testsuite to run (compared with g++, for
example), at least if your target board is slow. There are infinitely
many combinations of tests you could run; that a combination is useful
does not mean it is appropriate to increase default testing time for
everyone with it. Instead, different people should run regression testers
with different options and report bugs found to Bugzilla; just as some
people run the testsuites with -fpic/-fPIC, or have processes for
generating testcases likely to trigger bugs and then report those bugs,
you could do run such a tester with LTO options and report the bugs you
find. Diversity of testers, and people actually going through the results
and ensuring there are PRs for all existing or new failures and that
regressions are marked as such, is more worthwhile than duplication of
similarly configured testers.
--
Joseph S. Myers
jos...@codesourcery.com
Re: __attribute__((optimize)) and fast-math related oddities
On Tue, Oct 20, 2009 at 2:19 AM, Richard Guenther wrote: > On Tue, Oct 20, 2009 at 1:54 AM, tbp wrote: >> On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor wrote: >>> Please file a bug report. >>> __attribute__((optimize())) is definitely only half-baked. >> Apparently the code i've posted is just a variation around that 1 year >> old PR 37565 and if that doesn't work, worrying about the rest is >> entirely futile. >> Half baked you say? It's comforting to see that much optimism but >> couldn't the doc be adjusted a bit to reflect the fact that the baker >> got hit by a bus or something? > > I would rather suggest to rip out the half-baked code again. > I agree. The idea is good. But the design and implementation are incomplete. -- H.J.
Re: Alias analysis or DSE problem?
You're right: that was exactly the difference. It turns out I was
setting the third and fourth operands in the ARRAY_REF to what I
thought were sensible values. Setting them to NULL instead made the
ADDR_EXPR satisfy is_gimple_min_invariant() and fixed the whole mess.
Thanks again for looking at this.
--Justin
On Tue, Oct 20, 2009 at 5:18 AM, Richard Guenther
wrote:
> On Tue, Oct 20, 2009 at 1:34 AM, Justin Seyster wrote:
>> Thanks a lot for the help! It looks like creating a temporary
>> took care of it.
>>
>> On Sat, Oct 17, 2009 at 7:41 AM, Richard Guenther
>> wrote:
>>> I think the call you insert is not of valid gimple form - an address
>>> argument has to fulfill the is_gimple_min_invariant() predicate.
>>> Thus I suspect you have something like &ptr->field in there which
>>> needs a temporary.
>>
>> That was it. Actually, the TREE was of the form
>> ADDR_EXPR(ARRAY_REF(STRING_CST)), which does not satisfy
>> is_gimple_min_invariant().
>>
>> The strange thing is, I copied that structure verbatim from
>> unmodified GCC. I'm trying to insert a call that looks like:
>>
>> foo("some string constant");
>>
>> If I put that function call in a simple C program and dump out
>> the resulting GIMPLE, it gives me the ADDR_EXPR that was causing
>> problems in refs_may_alias_p_1().
>>
>> Does anyone know why that structure is ok in the contexts that
>> GCC is using it but not in the context that my plug-in uses it
>> in?
>
> If your "string" does not satisfy is_gimple_min_invariant then
> it is not of the form you mentioned above. A wild guess would
> be that you have the 2nd or 3rd operand of the ARRAY_REF set.
>
> Richard.
>
>> --Justin
>>
>
Re: __attribute__((optimize)) and fast-math related oddities
On Tue, Oct 20, 2009 at 11:13:48AM -0700, H.J. Lu wrote: > On Tue, Oct 20, 2009 at 2:19 AM, Richard Guenther > wrote: > > On Tue, Oct 20, 2009 at 1:54 AM, tbp wrote: > >> On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor wrote: > >>> Please file a bug report. > >>> __attribute__((optimize())) is definitely only half-baked. > >> Apparently the code i've posted is just a variation around that 1 year > >> old PR 37565 and if that doesn't work, worrying about the rest is > >> entirely futile. > >> Half baked you say? It's comforting to see that much optimism but > >> couldn't the doc be adjusted a bit to reflect the fact that the baker > >> got hit by a bus or something? > > > > I would rather suggest to rip out the half-baked code again. > > > > I agree. The idea is good. But the design and implementation > are incomplete. As the original author I do tend to agree, we've been finding all of these places, particularly as we go to more and more tree optimizations. However, the question is what do we do at this particular point given it has been in the compiler for 2 years now. There were a number of people that did ask me for it when I presented the initial thoughts a few years ago. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
Re: [MIPS] cannot split restore_gp
"Fu, Chao-Ying" writes:
> Hi,
>
> G++ could not split restore_gp.
> Please check this test (from #line 15017 "configure" of
> gcc/libstdc++-v3/).
>
> # cat foo.cpp
> struct S { ~S(); };
> void bar();
> void foo()
> {
> S s;
> bar();
> }
>
> # ~/dev/gcc45/build/gcc/cc1plus -quiet foo.cpp -o foo.s -mno-shared -mplt
> -mabicalls -G0
> foo.cpp: In function â?~foo()â?T:
> foo.cpp:7:1: error: could not split insn
> (insn 29 28 30 (parallel [
> (set (reg:SI 28 $28)
> (unspec_volatile:SI [
> (const_int 0 [0x0])
> ] 7))
> (clobber (reg:SI 2 $2))
> ]) 555 {restore_gp} (nil))
> foo.cpp:7:1: internal compiler error: in final_scan_insn, at final.c:2651
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
>
> --
>
> Something may be wrong before we reach the "final" pass.
> (Or, we should have split restore_gp earlier.)
> Any idea? Thanks!
It's another case of splits-to-nothing being misinterpreted as failed
splits. The patch below fixes the testcase, and although this particular
testcase probably passes on 4.4, the same patch is needed there.
I'll test it over the next few days.
Richard
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c (revision 153036)
+++ gcc/config/mips/mips.c (working copy)
@@ -9533,7 +9533,10 @@
gcc_assert (TARGET_ABICALLS && TARGET_OLDABI && epilogue_completed);
if (!cfun->machine->must_restore_gp_when_clobbered_p)
-return;
+{
+ emit_note (NOTE_INSN_DELETED);
+ return;
+}
if (TARGET_MIPS16)
{
two ideas to improve C++
Hi, I have 2 ideas about C++ language, maybe they could be implemented as GCC C++ extensions (Microsoft has many his own and no one complains). :-) If it doesn't have them already (I don't know, but I have never heard about this ideas). 1. void as first class type Current status of void is somewhat strange. It is a type but you cannot create objects of type void. So, it is type of what? But you can have memory pointer to void, so object (or array) of type void has its memory position but cannot be here created. Pointer arithmetics for void* is forbidden. Despite this all, we are allowed to use void as a template type parameter. It is not elegant and makes C/C++ harder to understand for beginners. My idea is as follows: Lets allow to create void objects. Let sizeof(void) == 1 Should void variable occupy address space? Yes, but physical memory will be never accessed by this variable. So what void variable contains? Nothing - "void" indeed. It is like an empty box on the table. So, void is similar to char. char is a box containing 1 character, void is the same size box containing nothing. Can we put something inside that box? No, it is compiler error, for example: void a; a = 'a'; // wrong! type mismatch a = 10; // wrong! type mismatch a = 0; // wrong! type mismatch We cannot get anything from empty box either: void a; char c = a; // wrong! type mismatch int n= a; // wrong! type mismatch but: void a; void b; a = b; // OK, but because both a and b are empty, nothing happens. So, if you wish you can create void objects: int a; void void_array[32] ; int z; In the above, between variables a and z, there is 32 bytes of memory reserved for void_array. That chunk of memory will never be accessed by void_array object. Then, we have void function(void x); it is legal to write: void arg; void c = function(arg); nothing is ever copied on call and return. The only drawback on having fun(void x) argument x declaration, is that to be correct 1 byte is reserved on the stack for x argument. (it will never be accessed anyway). But if we never plan to pass that x argument we can write as before fun(void) In addition, we achieve the possibility to perform void* pointer arithmetics, remembering that sizeof(void) == 1; We can allocate memory this way: void* area = new void[1000]; and then do a cast char* string = reinterpret_cast(area); and now the access to that memory (or rather lack of any access) via area pointer obeys all the rules stated, while access to the same memory by the string pointer obeys all C++ rules for char[] array. Maybe a stupid question at the end - do we need any new keyword or literal to name the "value" contained inside the void variable? Of course no, we cannot name something what doesn't even exist. :-). 2. new 'callback' type Some time ago I tried to write a class implementing idea of callbacks (called events or signal/slot mechanism by others) Lets assume we have a Clock object. Every full hour clock rings. Many other active objects of different types want to be notified about that interesting event. So every object says to Clock object: here is my 'this' pointer and a name of one (or more) of my methods. When you start to ring I want you to call that method(s) with an int argument containing current hour. So all these objects have prepared special methods of different names they liked, but of the same signature: void (int hour). Object First has the method void ClockRings(int hour), Object Second has the method OldClockMakesNoise(int hour), and so on. Some objects can have two or more their own methods of said signature and want all of them to be called for any reason. I thought it would be easy. To ask the Clock for ring notifcation every object of type ObjectN would call function CallMe() with 2 parameters: his "this" pointer of type ObjectN* and pointer to its chosen method of type void(ObjectN::*member)(int hour). But every object is of different type, so we need rather template void Clock::CallMe(T* object, void(T::*method)(int hour)) Clock would save somwhere all object&method pairs, and when for example 13:00 hour rings, it would take each pair in turn and call: object->*method(13); But problem is: where to store all those pairs and use them in turn - they are of different types? I thought for some time and went with rather straightforward idea: I would cast every ObjectN* to void* object, then by analogy cast every void(ObjectN::*)(int hour) to void(void::*method)(int hour) :-D, store them all in: std::vector > and when time comes iterate through the vector and call (*iter).first->*(*iter.second)(13); I thought that as void* is "generic pointer" then void(void::*)(int) is "generic pointer to member function of type void(int)". In C++ it is safe to assign Object* to void and then cast back by static_cast to Object*. I thought that it should be safe to call object->*method(13) even without casting them back to appropriate Obje
gcc-4.4-20091020 is now available
Snapshot gcc-4.4-20091020 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091020/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 153041 You'll find: gcc-4.4-20091020.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20091020.tar.bz2 C front end and core compiler gcc-ada-4.4-20091020.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20091020.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20091020.tar.bz2 C++ front end and runtime gcc-java-4.4-20091020.tar.bz2 Java front end and runtime gcc-objc-4.4-20091020.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20091020.tar.bz2The GCC testsuite Diffs from 4.4-20091013 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: two ideas to improve C++
Ireneusz Szpilewski writes: > I have 2 ideas about C++ language, maybe they could be implemented as > GCC C++ extensions (Microsoft has many his own and no one > complains). :-) We generally do not want to implement language extensions. It takes a strong argument to convince us. Also, as a practical matter, we are extremely unlikely to implement an extension ourselves. So realistically you need to 1) send us a patch; 2) convince us that it is worth the ongoing maintenance hassle. > 1. void as first class type > > Current status of void is somewhat strange. It is a type but you > cannot create objects of type void. > So, it is type of what? But you can have memory pointer to void, so > object (or array) of type void > has its memory position but cannot be here created. Pointer > arithmetics for void* is forbidden. > Despite this all, we are allowed to use void as a template type > parameter. It is not elegant and > makes C/C++ harder to understand for beginners. I don't find this argument to be convincing. Sorry. When would I create an object of type void? Why would I create it? > Here is my idea - lets add "callback" pointer data type. It would > require to introduce > new data type symbol: @. Internally it would contain 2 pointers: > pointer to object and pointer to member of that object. As far as I can tell you can write that type yourself. I'm not sure what has to change in the compiler. It sounds a lot like std::tr1::bind. Ian
