Re: Declaring artificial fields
Ian Lance Taylor wrote: Are you emitting CLI directly from GIMPLE? Yes, we emit gimple right before GIMPLE is transformed into RTL so our code doesn't go through the RTL-only optimizations It may help to look at store_bit_field and extract_bit_field so see how this sort of thing is handled when expanding trees to RTL. I've looked a bit into them and we currently deal with bit-fields roughly that way when we emit CLI code. Our current solution works but emits poor code as it generates a lot of temporaries which are not cleaned up later. I was trying to move some of our expansions before the tree-ssa optimizations hoping to simplify the emission phase and to obtain better code. I don't recommend adding artificial fields to the struct. If you need them in CLI, then add them at CLI generation time. If you can get away with direct memory references, then do that. I see. I don't need the extra fields inside the struct, in fact the CLI emission simply ignores them they would be needed only as 'container' fields referenced by the new COMPONENT_REF statements I inject to replace the bit-field ones. I can certainly get away with indirect references instead. In that case do I have to set TREE_ADDRESSABLE() on the enclosing type? BTW I'm currently doing these transformations right before the control-flow graph is built. Thank you very much for your help. Gabriele
internal compiler error when compile busybox 1.1.3 using buildroot in cygwin
hi , when I try to compile the busybox 1.1.3 using buildroot in cygwin. an internal compiler error happens. Could any one give a help on this? LINK busybox_unstripped /home/mahua/opt/armbuild26_v0 /build_arm/busybox- 1.1.3/networking/telnetd.c: In function 'telnetd_main': /home/mahua/opt/armbuild26_v0 /build_arm/busybox-1.1.3/networking/telnetd.c:541: warning: pointer targets in passing argument 3 of 'accept' differ in signedness /home/mahua/opt/armbuild26_v0/build_arm/busybox-1.1.3/editors/vi.c: In function 'do_cmd': /home/mahua/opt/armbuild26_v0/build_arm/busybox-1.1.3/editors/vi.c:2989: internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c :830 Please submit a full bug report, I post it on busybox mailist, someone advice me to ask here. Thanks very much. huamama
Re: internal compiler error when compile busybox 1.1.3 using buildroot in cygwin
Hi, On Nov 13, 2007 2:29 PM, 马骅 <[EMAIL PROTECTED]> wrote: > hi , when I try to compile the busybox 1.1.3 using buildroot in cygwin. > an internal compiler error happens. > Could any one give a help on this? > > LINK busybox_unstripped > /home/mahua/opt/armbuild26_v0 /build_arm/busybox- > 1.1.3/networking/telnetd.c: In function 'telnetd_main': > /home/mahua/opt/armbuild26_v0 > /build_arm/busybox-1.1.3/networking/telnetd.c:541: warning: pointer > targets in passing argument 3 of 'accept' differ in signedness > /home/mahua/opt/armbuild26_v0/build_arm/busybox-1.1.3/editors/vi.c: In > function 'do_cmd': > /home/mahua/opt/armbuild26_v0/build_arm/busybox-1.1.3/editors/vi.c:2989: > internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c :830 > Please submit a full bug report, > > I post it on busybox mailist, someone advice me to ask here. You have not mentioned the target platform , the version and other information so that people can help understand where the problem is . Please read http://gcc.gnu.org/bugs.html about how to report a bug. cheers Ramana > Thanks very much. > huamama > -- Ramana Radhakrishnan
Re: internal compiler error when compile busybox 1.1.3 using buildroot in cygwin
Hi, Please reply to the list also and not only to me . On Nov 13, 2007 2:38 PM, 马骅 <[EMAIL PROTECTED]> wrote: > The target platform is arm, gcc version is 4.0.3, > binutils-2.17.50.0.8, uClibc-0.9.28. You might need to use a newer version of the compiler. The current release series supported by the community are only 4.1.2 and 4.2.2. Please provide all the information required for someone to reproduce the bug and file a bug on bugzilla if you see this in a more recent version of the compiler and you can't find a duplicate of this bug in bugzilla (http://gcc.gnu.org/bugzilla ) Please provide all the information as specified here . http://gcc.gnu.org/bugs.html#detailed Thanks Ramana > The host platform is cygwin (1.5.24). > I build the toolchains use buildroot. > Thanks. > > > On Nov 13, 2007 5:02 PM, Ramana Radhakrishnan <[EMAIL PROTECTED]> wrote: > > Hi, > > > > > > > > On Nov 13, 2007 2:29 PM, 马骅 <[EMAIL PROTECTED]> wrote: > > > hi , when I try to compile the busybox 1.1.3 using buildroot in cygwin. > > > an internal compiler error happens. > > > Could any one give a help on this? > > > > > > LINK busybox_unstripped > > > /home/mahua/opt/armbuild26_v0 /build_arm/busybox- > > > 1.1.3/networking/telnetd.c: In function 'telnetd_main': > > > /home/mahua/opt/armbuild26_v0 > > > /build_arm/busybox-1.1.3/networking/telnetd.c:541: warning: pointer > > > targets in passing argument 3 of 'accept' differ in signedness > > > /home/mahua/opt/armbuild26_v0/build_arm/busybox-1.1.3/editors/vi.c: In > > > function 'do_cmd': > > > /home/mahua/opt/armbuild26_v0/build_arm/busybox-1.1.3/editors/vi.c:2989: > > > internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c :830 > > > Please submit a full bug report, > > > > > > I post it on busybox mailist, someone advice me to ask here. > > > > You have not mentioned the target platform , the version and other > > information so that people can help understand where the problem is . > > > > Please read http://gcc.gnu.org/bugs.html about how to report a bug. > > > > cheers > > Ramana > > > > > > > > > Thanks very much. > > > huamama > > > > > > > > > > > -- > > Ramana Radhakrishnan > > > -- Ramana Radhakrishnan
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
David Daney writes: > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > impossible for GCC's exception unwinding machinery to unwind through > signal frames. The cause of the problems is the > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > impossible to determine offset from the signal return trampoline. The > unwinder depends on being able to find the sigcontext given a known > location of the trampoline. > > It seems there are a couple of possible solutions: > > 1) The comments in war.h indicate the problem only exists in R7000 > and E9000 processors. We could turn off the workaround if the > kernel is configured for R5000. That would help me, but not those > with the effected systems. > > 2) In the non-workaround case, the siginfo immediately follows the > trampoline and the first member is the signal number. For the > workaround case the first word following the trampoline is zero. > We could replace this with the offset to the sigcontext which is > always a small negative value. The unwinder could then distinguish > the two cases (signal numbers are positive and the offset > negative). If we did this, the change would have to be coordinated > with GCC's unwinder (in libgcc_s.so.1). > > Thoughts? The best solution is to put the unwinder info in the kernel. Does MIPS use a vDSO ? Andrew.
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On Tue, Nov 13, 2007 at 11:48:53AM +, Andrew Haley wrote: > David Daney writes: > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > > impossible for GCC's exception unwinding machinery to unwind through > > signal frames. The cause of the problems is the > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > > impossible to determine offset from the signal return trampoline. The > > unwinder depends on being able to find the sigcontext given a known > > location of the trampoline. > > > > It seems there are a couple of possible solutions: > > > > 1) The comments in war.h indicate the problem only exists in R7000 > > and E9000 processors. We could turn off the workaround if the > > kernel is configured for R5000. That would help me, but not those > > with the effected systems. > > > > 2) In the non-workaround case, the siginfo immediately follows the > > trampoline and the first member is the signal number. For the > > workaround case the first word following the trampoline is zero. > > We could replace this with the offset to the sigcontext which is > > always a small negative value. The unwinder could then distinguish > > the two cases (signal numbers are positive and the offset > > negative). If we did this, the change would have to be coordinated > > with GCC's unwinder (in libgcc_s.so.1). > > > > Thoughts? > > The best solution is to put the unwinder info in the kernel. Does > MIPS use a vDSO ? No though we should. Another reason is to get rid of the classic trampoline the kernel installs on the stack. On some multiprocessor systems it requires a cacheflush operation to be performed on all processors which is expensive. Having the trampoline in a vDSO would solve that. I need to look into it, not sure what it would take. Ralf
Re: Designs for better debug info in GCC
Hi,
On Mon, 12 Nov 2007, Alexandre Oliva wrote:
> With the design I've proposed, it is possible to compute the value of i,
No. Only if the function is reservible. There are many which aren't:
static inline int foo(int i)
{
return i % 10;
}
int foobar(int j)
{
return foo(j % 20);
}
int main(int argc, char **argv)
{
return foobar(argc);
}
If foo is inlined and foobar simplified (to return j%10), the value for
'i' (j % 20) can not be recovered anymore. Hence for a 100% solution (and
for systemtap you want that) you have no choice than to force the value to
be live, e.g. by a volatile asm or the like.
> As I wrote before, I'm not aware of any systemtap bug report about a
> situation in which an argument was actually optimized away.
I think it all started from PR23551. For us it also happened in the
kernel in namei.c, where real_lookup is inlined sometimes, and it's
arguments are missing. That might or might not be reversible functions,
so your scheme perhaps would have helped there. But generally it won't
solve the problem for good.
> I wouldn't go as far as stopping the optimization just so that systemtap
> can monitor the code.
Like I said, at some point you have to or accept that some code remains to
be not introspectable.
> > at which point you have to force the value of 'i' being live, if you
> > want to be sure that systemtap works in all cases.
>
> I don't want to be sure of that. At least that was not the problem I
> was asked to solve.
Then I'm probably still confused what problem you're actually trying to
solve. If you don't want to be sure you get precise location information
100% of the time, then what percentage are you required to get? And how
do you measure this? Or is the task rather "emit better debug info"? But
that can be done also in our scheme, so why is there a need for DEBUG_INSN
if it can't solve the systemtap problem for good?
> And, indeed, it's not solvable without disabling optimizations.
Ciao,
Michael.
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On Nov 13, 2007 1:10 PM, Ralf Baechle <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 13, 2007 at 11:48:53AM +, Andrew Haley wrote: > > > David Daney writes: > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > > > impossible for GCC's exception unwinding machinery to unwind through > > > signal frames. The cause of the problems is the > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > > > impossible to determine offset from the signal return trampoline. The > > > unwinder depends on being able to find the sigcontext given a known > > > location of the trampoline. > > > > > > It seems there are a couple of possible solutions: > > > > > > 1) The comments in war.h indicate the problem only exists in R7000 > > > and E9000 processors. We could turn off the workaround if the > > > kernel is configured for R5000. That would help me, but not those > > > with the effected systems. > > > > > > 2) In the non-workaround case, the siginfo immediately follows the > > > trampoline and the first member is the signal number. For the > > > workaround case the first word following the trampoline is zero. > > > We could replace this with the offset to the sigcontext which is > > > always a small negative value. The unwinder could then distinguish > > > the two cases (signal numbers are positive and the offset > > > negative). If we did this, the change would have to be coordinated > > > with GCC's unwinder (in libgcc_s.so.1). > > > > > > Thoughts? > > > > The best solution is to put the unwinder info in the kernel. Does > > MIPS use a vDSO ? > > No though we should. > > Another reason is to get rid of the classic trampoline the kernel installs > on the stack. On some multiprocessor systems it requires a cacheflush > operation to be performed on all processors which is expensive. Having > the trampoline in a vDSO would solve that. > And the stack wouldn't need to have exec permission anymore. > I need to look into it, not sure what it would take. > I started to add vdso support for MIPS a couple months ago, but it's in a very early stage and I unfortunately haven't time to finish it. I can send it to you if you want. -- Franck
Re: Using crlibm as the default math library in GCC sources
Hi, On Mon, 12 Nov 2007, Geert Bosch wrote: > The big advantage of having a libm with GCC is that, instead of only > being able to rely on the lowest common denominator for accuracy of math > functions, you'll be able to rely on the same precision on all targets. > This is a huge benefit, especially on less popular operatings systems > and embedded systems, which often have crappy math libraries. You don't have to preach to the choir, I know why I looked at several libms in the past :-) I just say that crlibm is not it. There are libms which would impose much less work, are more complete, faster and more proven in the real world. Ciao, Michael.
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote:
> > > David Daney writes:
> > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > > impossible for GCC's exception unwinding machinery to unwind through
> > > > signal frames. The cause of the problems is the
> > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> > > > impossible to determine offset from the signal return trampoline. The
> > > > unwinder depends on being able to find the sigcontext given a known
> > > > location of the trampoline.
> > > >
> > > > It seems there are a couple of possible solutions:
> > > >
> > > > 1) The comments in war.h indicate the problem only exists in R7000
> > > > and E9000 processors. We could turn off the workaround if the
> > > > kernel is configured for R5000. That would help me, but not those
> > > > with the effected systems.
> > > >
> > > > 2) In the non-workaround case, the siginfo immediately follows the
> > > > trampoline and the first member is the signal number. For the
> > > > workaround case the first word following the trampoline is zero.
> > > > We could replace this with the offset to the sigcontext which is
> > > > always a small negative value. The unwinder could then distinguish
> > > > the two cases (signal numbers are positive and the offset
> > > > negative). If we did this, the change would have to be coordinated
> > > > with GCC's unwinder (in libgcc_s.so.1).
> > > >
> > > > Thoughts?
> > >
> > > The best solution is to put the unwinder info in the kernel. Does
> > > MIPS use a vDSO ?
> >
> > No though we should.
> >
> > Another reason is to get rid of the classic trampoline the kernel installs
> > on the stack. On some multiprocessor systems it requires a cacheflush
> > operation to be performed on all processors which is expensive. Having
> > the trampoline in a vDSO would solve that.
> >
>
> And the stack wouldn't need to have exec permission anymore.
Oh?
extern void frob(void (*)(void));
int foo(void)
{
int x;
void bar(void)
{
x++;
}
frob(&bar);
print("x is %d\n", x);
}
Compile and enjoy.
Ralf
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On Nov 13, 2007 3:00 PM, Ralf Baechle <[EMAIL PROTECTED]> wrote:
>
> On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote:
>
> > > > David Daney writes:
> > > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > > > impossible for GCC's exception unwinding machinery to unwind through
> > > > > signal frames. The cause of the problems is the
> > > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> > > > > impossible to determine offset from the signal return trampoline.
> > > > The
> > > > > unwinder depends on being able to find the sigcontext given a known
> > > > > location of the trampoline.
> > > > >
> > > > > It seems there are a couple of possible solutions:
> > > > >
> > > > > 1) The comments in war.h indicate the problem only exists in R7000
> > > > > and E9000 processors. We could turn off the workaround if the
> > > > > kernel is configured for R5000. That would help me, but not those
> > > > > with the effected systems.
> > > > >
> > > > > 2) In the non-workaround case, the siginfo immediately follows the
> > > > > trampoline and the first member is the signal number. For the
> > > > > workaround case the first word following the trampoline is zero.
> > > > > We could replace this with the offset to the sigcontext which is
> > > > > always a small negative value. The unwinder could then distinguish
> > > > > the two cases (signal numbers are positive and the offset
> > > > > negative). If we did this, the change would have to be coordinated
> > > > > with GCC's unwinder (in libgcc_s.so.1).
> > > > >
> > > > > Thoughts?
> > > >
> > > > The best solution is to put the unwinder info in the kernel. Does
> > > > MIPS use a vDSO ?
> > >
> > > No though we should.
> > >
> > > Another reason is to get rid of the classic trampoline the kernel installs
> > > on the stack. On some multiprocessor systems it requires a cacheflush
> > > operation to be performed on all processors which is expensive. Having
> > > the trampoline in a vDSO would solve that.
> > >
> >
> > And the stack wouldn't need to have exec permission anymore.
>
> Oh?
>
> extern void frob(void (*)(void));
>
> int foo(void)
> {
> int x;
>
> void bar(void)
> {
> x++;
> }
>
> frob(&bar);
> print("x is %d\n", x);
> }
>
> Compile and enjoy.
>
Sorry Ralf, I missed your point.
--
Franck
Re: Designs for better debug info in GCC
Hi, On Mon, 12 Nov 2007, Alexandre Oliva wrote: > > Why does it make sense to have that, rather than notes on instructions > > that say what affect the instruction has on user variables? > > Few instructions need such notes, so the proposal of growing SET by 33% > doesn't quite appeal to me. Though I don't have produced hard numbers yet, that every SET now contains an additional pointer is less of an issue than one might think. There only ever exists one RTL body at each point in time, hence the memory use for RTL is vastly dominated by the memory use of GIMPLE, which exists for all functions at the same time. Having this annotation in the SET is just the esthetically most pleasing place. If you do it with notes on insns you have issues with multi-set insns, and you have to move them around in case you change the insns. Putting them in the SET itself keeps them up-to-date nearly automatically (of course you still have to touch them once in a while). > That said, growing SET to add to it a list of variables (or components > thereof) that the variable is assigned to could be made to work, to > some extent. But when you optimize away such a set, you'd still have > to keep the note around, so it's not clear to me that adding code all > over to maintain the notes in place when the SETs go away or are > juggled around would bring us any advantage. The nice thing is, that there are only few places which really get rid of SETs: remove_insn. You have to tweak that to keep the information around, not much else (though that claim remains to be proven :) ). Ciao, Michael.
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
Franck a dit: > > Another reason is to get rid of the classic trampoline the kernel installs > > on the stack. On some multiprocessor systems it requires a cacheflush > > operation to be performed on all processors which is expensive. Having > > the trampoline in a vDSO would solve that. > > > > And the stack wouldn't need to have exec permission anymore. True, though it should perhaps be noted that currently it's only on 4KSc/Sd systems (which I know you work on) where it's even possible for the stack *not* to have exec permissions, since the classical MIPS MMU gives execute permission to any page that is readable. Regards, Kevin K.
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On Nov 13, 2007 3:37 PM, Kevin D. Kissell <[EMAIL PROTECTED]> wrote: > Franck a dit: > > > Another reason is to get rid of the classic trampoline the kernel installs > > > on the stack. On some multiprocessor systems it requires a cacheflush > > > operation to be performed on all processors which is expensive. Having > > > the trampoline in a vDSO would solve that. > > > > > > > And the stack wouldn't need to have exec permission anymore. > > True, though it should perhaps be noted that currently it's only on 4KSc/Sd > systems (which I know you work on) where it's even possible for the stack > *not* to have exec permissions, since the classical MIPS MMU gives > execute permission to any page that is readable. > Well, the noexec stack is pretty usefull I think. I can't believe it will be limited to these 2 systems in the near future... -- Franck
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On Tue, Nov 13, 2007 at 03:22:33PM +0100, Franck Bui-Huu wrote:
> > > And the stack wouldn't need to have exec permission anymore.
> >
> > Oh?
> >
> > extern void frob(void (*)(void));
> >
> > int foo(void)
> > {
> > int x;
> >
> > void bar(void)
> > {
> > x++;
> > }
> >
> > frob(&bar);
> > print("x is %d\n", x);
> > }
> >
> > Compile and enjoy.
> >
>
> Sorry Ralf, I missed your point.
This piece of code compiles to something that copies a trampoline to the
stack. The address of that trampoline is what is then passed as argument
to frob().
Old versions of glibc were probable the most notorious users of trampolines.
Objective C also generates them. Since a cacheflush that is a syscall is
required performance is less than great.
Which means the libc() cacheflush() function is another candidate for a
vDSO, it can be optimized by using SYNCI on some configurations.
Ralf
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On Tue, Nov 13, 2007 at 03:37:39PM +0100, Kevin D. Kissell wrote: > True, though it should perhaps be noted that currently it's only on 4KSc/Sd > systems (which I know you work on) where it's even possible for the stack > *not* to have exec permissions, since the classical MIPS MMU gives > execute permission to any page that is readable. Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take care of I-cache coherency. So it's somewhat beneficial even in absence of a protection bit in the actual TLB hardware. Some of these performance optimizations are impossible because the kernel can't have definate knowledge that certain addresses have never entered the I-cache. Ralf
Re: Using crlibm as the default math library in GCC sources
On Nov 13, 2007, at 08:17, Michael Matz wrote: You don't have to preach to the choir, I know why I looked at several libms in the past :-) I just say that crlibm is not it. There are libms which would impose much less work, are more complete, faster and more proven in the real world. Do you know if there is any documentation on the numerical aspects and development objectives of this libm? I have looked at the implementation of a few functions (such as double precision exp and sin/cos) and they seem to be sound using accurate argument reduction techniques and claim a maximum rounding error of 0.503 ulp, which would be very good. However, it is hard to look at specific functions and get a good sense of the entire library and all precisions. It would be great to have a library that provides good accuracy across all functions and precisions, for a large range of architectures. If the FreeBSD libm can provide that, I'm all for it. When things get a bit more quiet here at work, I hope to be able to look more into using this library and do some testing. -Geert
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
David Daney wrote: With the current kernel (2.6.23.1) in my R5000 based O2 it seems impossible for GCC's exception unwinding machinery to unwind through signal frames. The cause of the problems is the ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost impossible to determine offset from the signal return trampoline. The unwinder depends on being able to find the sigcontext given a known location of the trampoline. It seems there are a couple of possible solutions: 1) The comments in war.h indicate the problem only exists in R7000 and E9000 processors. We could turn off the workaround if the kernel is configured for R5000. That would help me, but not those with the effected systems. 2) In the non-workaround case, the siginfo immediately follows the trampoline and the first member is the signal number. For the workaround case the first word following the trampoline is zero. We could replace this with the offset to the sigcontext which is always a small negative value. The unwinder could then distinguish the two cases (signal numbers are positive and the offset negative). If we did this, the change would have to be coordinated with GCC's unwinder (in libgcc_s.so.1). I think I have found a solution that doesn't require kernel changes. The CFA (i.e. the stack pointer of the signal handler) of the the context when calling mips_fallback_frame_state is at a constant offset from the sigcontext. I can just use the CFA instead of the trampoline's address. Does this seem plausible? Thanks, David Daney
dynamic_cast problem
I have this example program below.
#include
#include
using namespace std;
class Base {
public:
Base() {}
Base(int aa) {
a = aa;
}
int a;
char c;
virtual void show() {
cout << "a=" << a << endl;
}
};
class Derived: public Base {
public:
Derived() {}
Derived(int aa,int bb) {
a = aa;
b= bb;
}
int b;
void show() {
cout << "a=" << a << " b=" << b << endl;
}
};
class Derived2: public Base {
public:
Derived2() {}
Derived2(int aa,int bb) {
a = aa;
b= bb;
}
int b;
void show() {
cout << "a=" << a << " b=" << b << endl;
}
};
int main(void) {
Derived b(1,2);
Base *a = (Base*)(&b);
Derived *d1 = dynamic_cast(a);
if(d1)
cout << "cast1 ok\n";
else
cout << "cast1 failed\n";
d1 = dynamic_cast((Derived2*)a);
if(d1)
cout << "cast2 ok\n";
else
cout << "cast2 failed\n";
return 0;
}
Can someone tell me why the cast2 fails but cast1
works? What effect does the cstyle cast have?
In one of my old cross compilers (ppc_82xx-g++ gcc
version 2.95.4 20010319) both the casts work
thanks
ganesh
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Re: undocumented optimization options
Razya Ladelsky <[EMAIL PROTECTED]> writes: > This patch adds documentation for fipa-cp and -fipa-matrix-reorg. > > 2007-11-12 Razya Ladelsky <[EMAIL PROTECTED]> > > * doc/invoke.texi (fipa-cp, fipa-matrix-reorg): Add documentation. > > Ok to commit? This is OK. Thanks. Ian
Re: alias and pointers analysis
Hi again,
i have been studing gcc docs to undestand SSA and steps to take to get
SSA form. In one GCC online document:
http://gcc.gnu.org/projects/tree-ssa/#ssa, the steps to translate to
SSA form are listed. Here, i copy and paste the mentioned text:
[]
Conversion to SSA form is a three step process driven from tree-optimize.c:
1. Convert the function into GIMPLE form. Implemented in gimplify.c
and c-simplify.c.
2. Find variable references in the code. Implemented in tree-dfa.c.
3. Build a control-flow graph (CFG). Implemented in tree-cfg.c.
This implementation uses the same basic_block structure used by the
RTL optimizers. This allows us to share most of the existing CFG code.
4. Rewrite the tree in SSA form. Implemented in tree-ssa.c.
[]
But i still doubt about the process, in some ways:
* Is the step #2 related to the alias analysis? That is hold with the
def-use chains, and SMT / NMT structures. And, make any sense doing
these step before the SSA variable versioning? If positive answer,
why?
Thanks in advance
Fran.
2007/10/26, Diego Novillo <[EMAIL PROTECTED]>:
> On 10/26/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> > What is the matter if the 'b' var. is unused and
> > optimally removed by the SSA algorithm?
>
> In this case, it will not be removed. If any of the p_i pointers is
> ever dereferenced in this code, that will be considered a use of
> variable 'b'.
>
>
> > int a;
> > int b;
> >
> > a = 2;
> > p_4 = phi(a)
>
> Is this 'phi' as in a PHI function or a function in your code? If the
> former, then it's wrong, you can never have such a phi function in
> this code snippet.
>
> > // b doesn't used here
> > if (...)
> > p_1 = &a;
> > else
> > p_2 = &b;
> > endif
> > p_3 = phi (p_1, p_2)
> >
> > points-to (p_1) = { a }
> > points-to (p_2) = { b }
> > points-to (p_3) = { a b }
> >
> > In this case, should exist hidden p_5 = phi(b) although 'b' is not used
> > but yes used his reference to phantom cell 'b'. It's weird for me.
>
> I recommend that you read about the SSA form. PHI nodes are special
> constructs that exist only where multiple control flow paths reach a
> common join node. The getting started section of the wiki has links
> to books and articles about it. Morgan's book on compiler
> optimization is fairly good.
>
> > I've not idea WHERE put "hidden p_5 = phi(b)"!
>
> No such thing exists.
>
>
> > Too it's possible to ocurr *p_2 = c where 'b' will be hidden used through
> > the pointer p_2. It's too weird for me.
>
> Yes, that is possible, an that is precisely what alias analysis tells
> the compiler. We know from the analysis that reading/writing to
> '*p_2' is exactly the same as reading/writing to 'b'.
>
Re: alias and pointers analysis
On Nov 13, 2007 1:38 PM, Fran Baena <[EMAIL PROTECTED]> wrote: >1. Convert the function into GIMPLE form. Implemented in gimplify.c > and c-simplify.c. >2. Find variable references in the code. Implemented in tree-dfa.c. >3. Build a control-flow graph (CFG). Implemented in tree-cfg.c. > This implementation uses the same basic_block structure used by the > RTL optimizers. This allows us to share most of the existing CFG code. >4. Rewrite the tree in SSA form. Implemented in tree-ssa.c. > [] > > But i still doubt about the process, in some ways: > > * Is the step #2 related to the alias analysis? Yes, though this documentation is fairly old. Finding referenced variables is needed to determine what symbols are of interest. > That is hold with the > def-use chains, and SMT / NMT structures. And, make any sense doing > these step before the SSA variable versioning? If positive answer, > why? Sorry, I don't understand this question. Diego.
Two questions on register allocation & reload.
Hi. I have two questions related to register allocation and reload area. 1. Is there a way to distinguish memory accesses introduced during register allocation (register spills and fills) from "regular" ones? Or, alternatively, is augmenting reload & friends to use specific instructions to perform spill&fill possible? I'm asking because on ia64 one must use special instructions to read/write registers that originate from control-speculative load (in case speculation was unsuccessful, such registers will have an attribute, called NaT bit, set, and it must be saved and restored properly when such register is spilled), so currently GCC cannot perform control speculation before register allocation on ia64. 2. Is there a way to ask register allocator to allocate same hard regs for given pseudo in given pair of insns? I assume the answer is 'no', but just in case :) Again, this is needed to support data speculation before register allocation: register that is speculatively loaded must be same for speculative load and check. Thanks. Alexander Monakov
Re: Two questions on register allocation & reload.
Alexander Monakov wrote: Hi. I have two questions related to register allocation and reload area. 1. Is there a way to distinguish memory accesses introduced during register allocation (register spills and fills) from "regular" ones? Or, alternatively, is augmenting reload & friends to use specific instructions to perform spill&fill possible? I'm asking because on ia64 one must use special instructions to read/write registers that originate from control-speculative load (in case speculation was unsuccessful, such registers will have an attribute, called NaT bit, set, and it must be saved and restored properly when such register is spilled), so currently GCC cannot perform control speculation before register allocation on ia64. You can differ spill slots from other stack memory. All spill slots are generated in reload1::alter_reg. It is called at the start of reload1::reload for pseudo-registers got memory (their reg_renumber is negative) and during reload work when the reload needs a hard register and has to spill a pseudo-register assigned to the hard register during local/global alloc. This pseudo-register is spilled and getting memory from alter_reg. In the last case, a simple sharing stack slots has been implemented (based on a hard-register assigned to the pseudo before spilling). 2. Is there a way to ask register allocator to allocate same hard regs for given pseudo in given pair of insns? I assume the answer is 'no', but just in case :) Again, this is needed to support data speculation before register allocation: register that is speculatively loaded must be same for speculative load and check. Currently the same pseudo-register always get the same hard-register (or memory). The current register allocator does not support register live range splitting.
Re: dynamic_cast problem
On 13/11/2007, ganesh subramonian <[EMAIL PROTECTED]> wrote: > > Can someone tell me why the cast2 fails but cast1 > works? What effect does the cstyle cast have? It makes the program incorrect. This mailing list is for discussion of GCC development, for help using GCC use the gcc-help list. For help with C++ try a newsgroup such as comp.lang.c++ Jon
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
On 11/13/07, Ralf Baechle <[EMAIL PROTECTED]> wrote: > Old versions of glibc were probable the most notorious users of trampolines. > Objective C also generates them. Since a cacheflush that is a syscall is > required performance is less than great. No Objective-C does not generate them. Objective-C returns the exact function pointer back. Now libffi generates trampolines. -- Pinski
Re: Cannot unwind through MIPS signal frames withICACHE_REFILLS_WORKAROUND_WAR
> > True, though it should perhaps be noted that currently it's only on 4KSc/Sd > > systems (which I know you work on) where it's even possible for the stack > > *not* to have exec permissions, since the classical MIPS MMU gives > > execute permission to any page that is readable. > > Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take > care of I-cache coherency. So it's somewhat beneficial even in absence of > a protection bit in the actual TLB hardware. That depends on just what the consequences of I-cache incoherence might be. Without help from the MMU, the kernel cannot *know* that a given location isn't in the I-cache, because a program can always compute a pointer-to-function to an arbitrary address and dereference it successfully so long as the location is readable. If it's only the user who does this that will suffer as a result of I-cache incoherence, one can argue that it serves him right. But if it can screw up the execution of the kernel, or other user processes, I think we have to assume the worst. > Some of these performance optimizations are impossible because the kernel > can't have definate knowledge that certain addresses have never entered the > I-cache. Sad but true. Regards, Kevin K.
Re: [RFC][modulo-sched] Fix scheduling order within a cycle
Revital1 Eres/Haifa/IBM wrote on 13/11/2007 15:13:25: > Hello, > > Following our off-line discussion; attached is the dump file of the > problematic testcase. (sms-4.c) > > Here are some relevant details: > > insn 61(write) and 58(read) were swapped, so sms tries to generate some > kind of reg-move and fails. > > [CYCLE 4 ]: 61, 58, > Yes, this is wrong, clearly breaking the 58->(A,0,0)->61 dependence. > insn 61 is the only already scheduled instruction which insn 58 depends > on. > > The window of insn 58 is (4 .. -1), calculated as follows: > > Processing edge: [61 -(T,14,1)-> 58] > Scheduling 8 (58) in psp_pss_not_empty, checking p 11 (61): pred st = 4; > early_start = 0; latency: 14 > Processing edge: [58 -(A,0,0)-> 61] > Scheduling 8 (58) in psp_pss_not_empty, checking s 11 (61): succ st = 4; > late_start = 4; latency: 0 > Processing edge: [58 -(T,2,0)-> 59] > Scheduling 8 (58) in psp_pss_not_empty, checking s 9 (59): the node is not scheduled > > Trying to schedule node 8 INSN = 58 in (4 .. -1) step -1 > Scheduled w/o split in 4 > > insn 61 only must_preceed insn 58 because the latency between 61->58 is > 14 which causes the end boundary of the window to be 0. > > Thanks, > Revital > > [attachment "test.c.172r.sms" deleted by Ayal Zaks/Haifa/IBM] Indeed the latency between 61->58 is 14 causing end boundary of the window to be 0: insn 61 is scheduled in cycle 4 and II = 18, so 61->(T,14,1)->58 implies that insn 58 can be scheduled no earlier than 4 - 18 + 14 = 0. But it is not the case that insn 61 must_preceed insn 58, because insn 61 is scheduled in cycle 4 which is not equal to 0 (modulo 18). However, insn 61 must_follow insn 58 when attempting to place insn 58 in cycle 4. When scheduling insn 58, we calculate a window of possible cycles according to already scheduled predecessors and successors. This window looks like a parallelogram in general rather than a rectangle: in the first cycle there may be predecessors (already scheduled in the first cycle, or a multiple of II cycles away) which must_preceed insn 58 (having tight dependence with insn 58 if it is placed in the first cycle). So insn 58 can be placed in 'rightmost' slots of the first cycle only. Similarly, in the last cycle, insn 58 might be placed in 'leftmost' slots only, due to successors which must_follow insn 58. Inside internal cycles (strictly between first and last cycles), insn 58 can be placed in any vacant slot. Now if (as in the above case) an already scheduled insn 61 is both a successor and a predecessor of insn 58, it may be that (not it the above case) insn 61 must_precede insn 58 (when looking for available slots for insn 58 in the first cycle) and must_follow insn 58 (when looking for available slots in the last cycle). Currently we apply the must_precede and must_follow restrictions to all cycles of the window. This is overly conservative (i.e., should not produce above wrong code!). One way to improve this is to split the window into first cycle (with must_precede), internal part (with neither must_precede nor must_follow), and last cycle (with must_follow). And, of-course, if first cycle == last cycle, apply both must_precede and must_follow for it. Finally, note that in the above case we traverse the window backwards with step -1, so 'start' is the last cycle 4, and 'end' is one past the first cycle 0 (i.e. -1). Ayal.
Re: alias and pointers analysis
hi, i have a some what similar confusion . i am trying to implement reference count algo for c. i need to knw how to manupulate pionters and which file i need to alter. for example if i have some statements like int *p,*q,a; p=&a; q=p; and i need to change the pointer assignments so that i can increment the assignmnets for reference counting can anybody suggest me or guide me regarding this -- deepak On 11/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote: > On Nov 13, 2007 1:38 PM, Fran Baena <[EMAIL PROTECTED]> wrote: > > >1. Convert the function into GIMPLE form. Implemented in gimplify.c > > and c-simplify.c. > >2. Find variable references in the code. Implemented in tree-dfa.c. > >3. Build a control-flow graph (CFG). Implemented in tree-cfg.c. > > This implementation uses the same basic_block structure used by the > > RTL optimizers. This allows us to share most of the existing CFG code. > >4. Rewrite the tree in SSA form. Implemented in tree-ssa.c. > > [] > > > > But i still doubt about the process, in some ways: > > > > * Is the step #2 related to the alias analysis? > > Yes, though this documentation is fairly old. Finding referenced > variables is needed to determine what symbols are of interest. > > > That is hold with the > > def-use chains, and SMT / NMT structures. And, make any sense doing > > these step before the SSA variable versioning? If positive answer, > > why? > > Sorry, I don't understand this question. > > > Diego. >
c-pch.c:149: undefined reference to `_executable_checksum'
hi , I have a error when i compile gcc-4.1.2 using buildroot in cygwin gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -o cc1 c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o cc1-checksum.o \ main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a -liconv ../libiberty/libiberty.a c-pch.o: In function `c_common_valid_pch': /home/mahua/opt/armbuild26_v1/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:239: undefined reference to `_executable_checksum' /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:271: undefined reference to `_executable_checksum' c-pch.o: In function `c_common_print_pch_checksum': /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:489: undefined reference to `_executable_checksum' c-pch.o: In function `pch_init': /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:135: undefined reference to `_executable_checksum' /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:149: undefined reference to `_executable_checksum' collect2: ld returned 1 exit status make[2]: *** [cc1] Error 1 make[2]: Leaving directory `/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2-initial/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2-initial' The target platform is arm, gcc version is 4.1.2 binutils-2.17.50.0.8, uClibc-0.9.28. The host platform is cygwin (1.5.24). Thanks.
Re: c-pch.c:149: undefined reference to `_executable_checksum'
sorry, it's my mistake. I clean all, and rebuild, and find the make will stop at first gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o dummy-checksum.o \ main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a -liconv ../libiberty/libiberty.a gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc -I/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/build -I/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/../include -I/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/../libcpp/include -o build/genchecksum.o /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/genchecksum.c gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genchecksum \ build/genchecksum.o ../build-i386-pc-linux-gnu/libiberty/libiberty.a build/genchecksum cc1-dummy > cc1-checksum.c opening cc1-dummy: No such file or directory make[2]: *** [cc1-checksum.c] Error 1 make[2]: Leaving directory `/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2-initial/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2-initial' make: *** [/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2-initial/.compiled] Error 2 After I rename cc1-dummy.exe to cc1-dummy, the compile seems to continue. Sorry for take up your time. Thanks. On Nov 14, 2007 3:16 PM, 马骅 <[EMAIL PROTECTED]> wrote: > hi , > I have a error when i compile gcc-4.1.2 using buildroot in cygwin > > gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -Wmissing-format-attribute-DHAVE_CONFIG_H -o cc1 c-lang.o > stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o > c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o > c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o > prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o > tree-mudflap.o c-pretty-print.o cc1-checksum.o \ > main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a > -liconv ../libiberty/libiberty.a > c-pch.o: In function `c_common_valid_pch': > /home/mahua/opt/armbuild26_v1/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:239: > undefined reference to `_executable_checksum' > /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:271: > undefined reference to `_executable_checksum' > c-pch.o: In function `c_common_print_pch_checksum': > /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:489: > undefined reference to `_executable_checksum' > c-pch.o: In function `pch_init': > /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:135: > undefined reference to `_executable_checksum' > /home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2/gcc/c-pch.c:149: > undefined reference to `_executable_checksum' > collect2: ld returned 1 exit status > make[2]: *** [cc1] Error 1 > make[2]: Leaving directory > `/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2-initial/gcc' > make[1]: *** [all-gcc] Error 2 > make[1]: Leaving directory > `/home/mahua/opt/arm/toolchain_build_arm/gcc-4.1.2-initial' > > The target platform is arm, gcc version is 4.1.2 > binutils-2.17.50.0.8, uClibc-0.9.28. > The host platform is cygwin (1.5.24). > Thanks. >
