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.
#includeiostream
#includecstdio
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_castDerived*(a);
if(d1)
cout cast1 ok\n;
else
cout cast1 failed\n;
d1 = dynamic_castDerived*((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 spillfill 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 spillfill 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.
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #7 from dominiq at lps dot ens dot fr 2007-11-13 08:01 --- Created an attachment (id=14539) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14539action=view) Good assembly code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #9 from dominiq at lps dot ens dot fr 2007-11-13 08:10 --- and the from the debugger which field of the array caused the abort and maybe even good and bad char_cshift_2.*.fwprop* dumps? Can you hit breakpoint on _gfortran_cshift1_4_char and _gfortran_cshift1_8_char and compare the incoming and outgoing arrays between a good and bad version? This will take a little more time (I have to restore the revision and rebuild gcc). I have printed the arrays a and b, and with shift4 the first 4 lines, i.e., b(:,1:2,1) is different from the corresponding a's. Do you know the important differences in the config files for Darwin8 and Linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #8 from dominiq at lps dot ens dot fr 2007-11-13 08:02 --- Created an attachment (id=14540) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14540action=view) Bad assembly code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #10 from bonzini at gnu dot org 2007-11-13 08:16 --- Anyway, it looks like a latent bug somewhere else. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #11 from bonzini at gnu dot org 2007-11-13 08:21 --- Since you are at it, could you test on *exactly* the involved revisions, i.e. 130042 and 130043? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug tree-optimization/33860] [4.3 Regression] ICE in vectorizable_load, at tree-vect-transform.c:5503
--- Comment #6 from tbm at cyrius dot com 2007-11-13 08:27 --- So I guess this can be closed? -- tbm at cyrius dot com changed: What|Removed |Added CC||dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33860
[Bug target/33923] [4.3 Regression] ICE in reload_cse_simplify_operands (insn does not satisfy its constraints)
--- Comment #8 from tbm at cyrius dot com 2007-11-13 08:29 --- Would be great if some IA64 people could comment on the patch. -- tbm at cyrius dot com changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33923
[Bug fortran/34079] New: Bind(C): Don't pass the string length as argument (for STDCALL)
Using STDCALL, not the callee but the called procedure pops the arguments from the stack. The problem is that gfortran currently also for BIND(C) passes the string lengths as arguments. See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/19d77dfc75f8be58 -- Summary: Bind(C): Don't pass the string length as argument (for STDCALL) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #12 from dominiq at lps dot ens dot fr 2007-11-13 08:42 --- Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin Since you are at it, could you test on *exactly* the involved revisions, i.e. 130042 and 130043? Yes, but allow for more time!-) Meanwhile, I have restored the changes of revision 130043 and the bug did not reappeared, wierd!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug fortran/34008] ICE in gfc_trans_call, at fortran/trans-stmt.c:389 on elemental assignment
--- Comment #3 from dominiq at lps dot ens dot fr 2007-11-13 08:52 --- The patch works as advertised without regression on both PPC and Intel Darwin8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34008
[Bug fortran/34080] New: Transfer was working, now broken
I have code that was previously working with gfortran and now is broken. The
problem has to do with the 'transfer' intrinsic. If I transfer a character
string into an array of a different type, and then transfer the array back to a
string, the result is not the original string, but apparently random bytes.
I have prepared sample code to demonstrate:
module TransferBug
type ByteType
private
character(len=1) :: singleByte
end type
type (ByteType), save:: BytesPrototype(1)
contains
function StringToBytes(v) result (bytes)
character(len=*), intent(in) :: v
type (ByteType) ::
bytes(size(transfer(v, BytesPrototype)))
bytes = transfer(v, BytesPrototype)
end function
subroutine BytesToString(bytes, string)
type (ByteType), intent(in) :: bytes(:)
character(len=*), intent(out) :: string
character(len=1) :: singleChar(1)
integer :: numChars
numChars = size(transfer(bytes,singleChar))
string = ''
string = transfer(bytes, string)
string(numChars+1:) = ''
end subroutine
end module
program main
use TransferBug
character(len=100) :: str
call BytesToString( StringToBytes('Hi'), str )
print *, trim(str) ! This should print 'Hi'
end program
--
Summary: Transfer was working, now broken
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drewmccormack at mac dot com
GCC build triplet: 4.3.0 20071026 (experimental)
GCC target triplet: powerpc-apple-darwin9.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34080
[Bug target/34081] New: [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
gcc -v Using built-in specs. Target: s390x-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3.0 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --without-system-libunwind --with-tune=z9-109 --with-arch=z900 --with-long-double-128 --build=s390x-suse-linux Thread model: posix gcc version 4.3.0 20071109 (experimental) [trunk revision 130038] (SUSE Linux) /usr/lib64/gcc/s390x-suse-linux/4.3.0/cc1plus -w -Wfatal-errors -fpreprocessed fam.min.ii -quiet -dumpbase fam.c++ -version -o /dev/null GNU C++ (SUSE Linux) version 4.3.0 20071109 (experimental) [trunk revision 130038] (s390x-suse-linux) compiled by GNU C version 4.3.0 20071109 (experimental) [trunk revision 130038], GMP version 4.2.1, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: fa0dba4316cd7f190032018dbf935c39 fam.min.ii: In member function 'BTreeKey, Value::Closure::operator BTreeKey, Value::Status()': fam.min.ii:148: internal compiler error: in s390_function_value, at config/s390/s390.c:7880 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. -- Summary: [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: s390-*-*, s390x-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-13 10:00 --- Created an attachment (id=14541) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14541action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug target/34077] GCC -O1 -minline-all-stringops -minline-stringops-dynamically fails for spec 2006 bzip2, gobmk, and h264ref benchmarks
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-13 10:19 --- I think ix86_expand_movemem should not call emit_cmp_and_jump_insns with constant tests. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34077
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #13 from dominiq at lps dot ens dot fr 2007-11-13 10:40 --- Created an attachment (id=14542) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14542action=view) Comparison between revisions 130042 and 130043 with -O2 -funroll-loops and with -O1+all the others bzip2 tar archive with four directories r42_O1, r42_O2, r43_O1, and r43_O2 containing the result of -fdump-tree-all and the assembly codes for the different revisions and options (see comment #2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 10:26 --- Either we should use correct order of arguments in chrec_evaluate (that function is swapping CHREC_LEFT based expression with CHREC_RIGHT based expression for pointer_plus addition) - testing patch for that - or chrec_fold_plus_1 should swap op0 with op1 if code is POINTER_PLUS_EXPR and the first argument has integer type, but second POINTER_TYPE_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #14 from dominiq at lps dot ens dot fr 2007-11-13 10:41 --- Could you try to compile the assembly code in r43_O2 and see if you get the abort? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug c++/34054] [4.3 regression] ICE with parameter pack in return type
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 11:38 --- Mine. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-13 11:38:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34054
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-11-13 11:43 --- Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin bzip2 tar archive with four directories r42_O1, r42_O2, r43_O1, and r43_O2 containing the result of -fdump-tree-all and the assembly codes for the different revisions and options (see comment #2). Please use -fdump-rtl-all since fwprop is not a tree pass. :-) Also, please check if the bug appears disappears with -O2 -fno-forward-propagate -funroll-loops versus -O2 -funroll-loops in both 130042 and 130043. If the -fno-forward-propagate would make a difference, this would be a great way to narrow the bug. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 12:12 --- The set_packs_to_error stuff is very problematic in this case, because trees are shared and the C++ FE certainly doesn't expect error_mark_nodes to appear at random places. In this case T* type is shared (as the pointer to T has been cached). check_for_bare_parameter_packs should have errored about this twice, but will do only once because of the sharing and in the second case just won't fail, so doesn't let the caller to deal with the errorneous type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34056
[Bug tree-optimization/33319] [4.2 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization
--- Comment #12 from victork at gcc dot gnu dot org 2007-11-13 12:26 --- Still fails on 4.2 branch. I've just tried with 4.2 on PPC from svn and it did not ICE: ./gcc/cc1plus -O3 -ftree-vectorize -maltivec ~/42/build/pr27549.C Can we close this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
[Bug fortran/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-13 12:28 --- (In reply to comment #4) __builtin_copysign has got SFmode(*)(SFmode, SFmode) prototype and is invoked on DFmode arguments. copysign takes doubles and returns a double. Does the SH double have SF mode in the conditions of this PR? It is assumed, throughout the Fortran front-end, that SF mode corresponds to float, and DF corresponds to double. (This will be changed for 4.4, but not before... it's a most significant reworking.) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time
--- Comment #10 from pault at gcc dot gnu dot org 2007-11-13 12:46 ---
(In reply to comment #9)
This patch is OK.
Yes indeed, I have applied it a long time ago.
As I found out minutes after I posted this note - thanks!
I have only pointed to the last bug on transfer I know of.
It is only at the default logical length that it fails!
The optimizer is doing something horrible to the code in
transfer_simplify_4.f90; I have CC'd Andrew in the hope that he can shed some
light on it:
As an experiment, I tried the following patch to circumvent the mashing up of
the logical by BUILT_IN_MEMCPY when transferring between LOGICAL and INTEGER:
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (révision 130095)
--- gcc/fortran/trans-intrinsic.c (copie de travail)
*** gfc_conv_intrinsic_transfer (gfc_se * se
*** 3277,3282
--- 3277,3291
se-expr = ptr;
se-string_length = argse.string_length;
}
+ else if (expr-value.function.actual-expr-ts.kind == expr-ts.kind
+ ((expr-value.function.actual-expr-ts.type == BT_LOGICAL
+expr-ts.type == BT_INTEGER)
+|| (expr-value.function.actual-expr-ts.type == BT_INTEGER
+expr-ts.type == BT_LOGICAL)))
+ {
+ ptr = convert (build_pointer_type (type), ptr);
+ se-expr = build_fold_indirect_ref (ptr);
+ }
else
{
tree moldsize;
The example in comment #6 now works at any level of optimization, even without
the PRINT statement (the reason why I mention this will be apparent in a
moment).
transfer_simplify_4.f90 itself fails in the third block, at -O2 and higher,
whereas it failed at all levels of optimization withhout the patch.
a = transfer(ip1, .true.)
i = transfer(a, 0)
if (i .ne. ip1) call abort ()
Adding a PRINT *, a; or a PRINT *, i; anywhere in the program allows it to work
at any level of optimization. This is true, even if the PRINT replaces one of
the call abort's.
I have looked to see what the i/o might be doing but cannot understand it at
all.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #16 from dominiq at lps dot ens dot fr 2007-11-13 13:18 --- Also, please check if the bug appears disappears with -O2 -fno-forward-propagate -funroll-loops It disappears with -fno-forward-propagate (rev 130043). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug tree-optimization/33319] [4.2 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization
--- Comment #13 from victork at gcc dot gnu dot org 2007-11-13 13:26 --- I've just tested it with 4.2 on x86 on it worked OK as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
[Bug tree-optimization/33860] [4.3 Regression] ICE in vectorizable_load, at tree-vect-transform.c:5503
--- Comment #7 from dorit at gcc dot gnu dot org 2007-11-13 13:29 --- fixed -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33860
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #5 from p dot vestjens at gmail dot com 2007-11-13 13:38 --- Okay. First of all the code causing the problems isn't actually my own code. It is used in the Connexis middleware layer of IBM's Rational Rose Real-Time application. The reproduce.cpp file was created by IBM's support department to reproduce the problem. They claim that the file compiles with the GNU 3.2 compiler but not with the GNU 3.4.4 and 4.1.0 compilers. I'm using GNU 4.1.1 which also doesn't compile the code, but WindRiver's Tornado 2 GNU 2.7.2 and the MS Visual Studio 6 compiler do. The problem seems to lie in the abundant use of parentheses: - list = new (pure(*[3])); = does not compile - list = new (pure*[3]); = compiles - list = new pure(*[3]); = does not compile - list = new pure*[3]; = compiles So, the only question still relevant to me is whether the original construction is valid C++ code according to the ISO C++ standard. I tried verifying this using the grammar printed in Stroustrup's C++ Programming language (third edition but did not quite succeed. I guess grammatically it is ok, but semantically the GCC compiler interprets the construction differently from its previous version(s). How do we determine if the original construction is correct, both grammatically and semantically? If it isn't valid, IBM should fix their code. If it is, there might be a bug in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 13:43 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:43:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34056
[Bug c++/34057] [4.3 regression] ICE with variadic template and vector attribute
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 13:44 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:44:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34057
[Bug c++/34058] [4.3 regression] ICE with variadic template and typedef
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 13:44 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:44:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34058
[Bug c++/34060] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 13:44 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:44:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34060
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #17 from dominiq at lps dot ens dot fr 2007-11-13 13:46 --- Created an attachment (id=14543) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14543action=view) outputs with -fdump-rtl-all outputs with -fdump-rtl-all with -O2 -funroll-loops for revisions 130042 and 130043. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #36 from victork at gcc dot gnu dot org 2007-11-13 13:53 --- Subject: Bug 32582 Author: victork Date: Tue Nov 13 13:53:33 2007 New Revision: 130138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130138 Log: 2007-11-13 Victor Kaplansky [EMAIL PROTECTED] PR tree-optimization/32582 * Makefile.in (CRTSTUFF_CFLAGS): Add -fno-tree-vectorize Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug fortran/34080] [regression] Transfer was working, now broken
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-13 13:55 --- Confirmed on x86_64-linux. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|4.3.0 20071026 | |(experimental) | GCC target triplet|powerpc-apple-darwin9.0.0 | Keywords||wrong-code Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:55:55 date|| Summary|Transfer was working, now |[regression] Transfer was |broken |working, now broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34080
[Bug libf2c/34082] New: someinfo
someinfo -- Summary: someinfo Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libf2c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jim3 at iq17 dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34082
[Bug libf2c/34082] someinfo
--- Comment #1 from jim3 at iq17 dot com 2007-11-13 14:32 --- aa -- jim3 at iq17 dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34082
[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-13 14:39 ---
Example:
interface
subroutine subiso(x) bind(c)
use iso_c_binding
character(kind=c_char,len=1), dimension(*) :: x
end subroutine subiso
subroutine subiso2(x) bind(c) ! { dg-warning may not be C interoperable }
character(len=1), dimension(*) :: x
end subroutine subiso2
subroutine sub(x)
use iso_c_binding
character(kind=c_char,len=1), dimension(*) :: x
end subroutine sub
end interface
call sub(abcdef)
call subiso (ABCDEF)
call subiso2(AbCdEf)
end
Dumped tree should look like:
sub (abcdef[1]{lb: 1 sz: 1}, 6);
subiso (ABCDEF[1]{lb: 1 sz: 1});
subiso2 (ABCDEF[1]{lb: 1 sz: 1});
Draft of a patch:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 130131)
+++ gcc/fortran/trans-expr.c(Arbeitskopie)
@@ -2390,8 +2390,8 @@ gfc_conv_function_call (gfc_se * se, gfc
}
/* Character strings are passed as two parameters, a length and a
- pointer. */
- if (parmse.string_length != NULL_TREE)
+ pointer - except for Bind(c) which only passes the pointer. */
+ if (parmse.string_length != NULL_TREE !sym-attr.is_bind_c)
stringargs = gfc_chainon_list (stringargs, parmse.string_length);
arglist = gfc_chainon_list (arglist, parmse.expr);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug fortran/34080] [regression] Transfer was working, now broken
--- Comment #2 from dominiq at lps dot ens dot fr 2007-11-13 15:08 ---
Reduced test case:
module TransferBug
type ByteType
character(len=1) :: singleByte
end type
contains
subroutine BytesToString(bytes, string)
type (ByteType), intent(in) :: bytes(:)
character(len=*), intent(out) :: string
string = 'Hi! '
! print *, len(trim(string)) ! -- works
print *, len(transfer(bytes, string)) ! -- gives garbage (crash with
g95)
end subroutine
end module
program main
use TransferBug
character(len=100) :: str
type (ByteType) :: bytes(4)
bytes = (/ByteType('t'), ByteType('e'), ByteType('s'), ByteType('t')/)
call BytesToString( bytes, str )
print *, trim(str) ! This should print 'Hi!'
end program
[karma] f90/bug% gfc -fbounds-check pr34080_red.f90
[karma] f90/bug% a.out
0
0låŨ0l0 ]Q(Ô¿ÿà`á
d
[karma] f90/bug% pgfc -fbounds-check pr34080_red.f90
[karma] f90/bug% a.out
100
Hi!
If I exchange the commented print lines, the code works. So the bug is related
to transfer, but apparently through some memory leak and not due to its result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34080
[Bug fortran/34083] New: internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819
While looking at pr34080, I produced the following invalid code
module TransferBug
type ByteType
character(len=1) :: singleByte
end type
end module
program main
use TransferBug
type (ByteType) :: bytes(4)
print *, size(bytes)
bytes = ByteType((/'H', 'i', '!', ' '/)) ! -- ICE
! bytes = (/ByteType('H'), ByteType('i'), ByteType('!'), ByteType(' ')/) !
-- works
end program
which gives an ICE:
pr34080_ice.f90: In function 'MAIN__':
pr34080_ice.f90:12: internal compiler error: in
gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819
--
Summary: internal compiler error: in
gfc_conv_array_constructor_expr, at fortran/trans-
expr.c:2819
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34083
[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite
--- Comment #23 from dnovillo at gcc dot gnu dot org 2007-11-13 15:20 --- Subject: Bug 33870 Author: dnovillo Date: Tue Nov 13 15:20:40 2007 New Revision: 130141 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130141 Log: pr 33870 * tree.h (strcut tree_memory_tag): add field unpartitionable. remove field in_nested_struct. (struct tree_struct_field_tag): add field nesting_level. (sft_in_nested_struct): remove. (sft_nesting_level): define. (sft_unpartitionable_p): define. * tree-ssa-alias.c (mem_sym_score): if mp-var is not partitionable, return long_max. (compute_memory_partitions): do not partition sfts marked unpartitionable. (create_sft): add argument nesting_level. set sft_nesting_level with it. update all users. (create_overlap_variables_for): show nesting level. * tree-dfa.c (dump_subvars_for): likewise. (dump_variable): likewise. show whether the sft is partitionable or not. * tree-flow.h (struct fieldoff): remove field in_nested_struct. add field nesting_level. * tree-ssa-structalias.c (struct variable_info): remove field in_nested_struct. (push_fields_onto_fieldstack): add argument nesting_level. update all users. update documentation. update pair-nesting_level with nesting_level. make recursive calls with nesting_level + 1. (set_uids_in_ptset): if an sft is added to the points-to set, mark it as unpartitionable. * tree-ssa-operands.c (ref_nesting_level): new. (add_vars_for_offset): call it. add argument full_ref. update callers. if var is inside a nested structure and the nesting level of full_ref is lower than the nesting level of var, adjust offset by the offset of var. testsuite/ChangeLog PR 33870 * gcc.c-torture/execute/pr33870-1.c: New test. * gcc.dg/tree-ssa/alias-16.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr33870-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33870
[Bug fortran/34083] internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-13 15:44 --- Confirmed. NAG f95 reports: Error: aa.f90, line 13: Array value for scalar component SINGLEBYTE of type BYTETYPE -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin8 | GCC host triplet|powerpc-apple-darwin8 | GCC target triplet|powerpc-apple-darwin8 | Keywords||ice-on-invalid-code Known to fail||4.1.3 4.2.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-11-13 15:44:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34083
[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite
--- Comment #24 from dnovillo at gcc dot gnu dot org 2007-11-13 15:47 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00719.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33870
[Bug fortran/34080] [4.3 regression] Transfer was working, now broken
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-13 15:51 --- I did not do proper regression tests, but it works using 4.3.0 20071016 (experimental) [trunk revision 129378] (SUSE Linux) which has presumably no Fortran patches applied. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Known to work||4.2.1 4.1.3 Summary|[regression] Transfer was |[4.3 regression] Transfer |working, now broken |was working, now broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34080
[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #18 from jakub at gcc dot gnu dot org 2007-11-13 15:57 --- Is this still reproduceable with current trunk? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #18 from dominiq at lps dot ens dot fr 2007-11-13 15:58 --- At revision 130137 the minimal flags are: [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fschedule-insns -fregmove -fexpensive-optimizations -fforward-propagate char_cshift_2_red_1.f90[ibook-dhum] f90/bug% a.out test 2 'adf' 'acf' 'adf' 1 1 2 1 'bdf' 'bcf' 'bdf' 2 1 2 1 'aef' 'adf' 'aef' 1 2 3 1 'bef' 'bdf' 'bef' 2 2 3 1 'acf' 'aef' 'acf' 1 3 1 1 'bcf' 'bef' 'bcf' 2 3 1 1 Abort [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fregmove -fexpensive-optimizations -fforward-propagate char_cshift_2_red_1.f90 [ibook-dhum] f90/bug% a.out test 2 'bdf' 'bcf' 'bdf' 2 1 2 1 'bef' 'bdf' 'bef' 2 2 3 1 'bcf' 'bef' 'bcf' 2 3 1 1 Abort where the printed lines come from print *, ', a (i1, i2p, i3), ' ', b (i1, i2, i3), ' ', b (i1, i2p, i3), ', i1, i2, i2p, i3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
Patch: bootstrap broken when building boehm-gc
Hi there, I'm not sure if there's something broken on my system(s), but here we go. Building current gcc from HEAD Tue Nov 13 11:39:03 UTC 2007 (revision 130136) fails for me on i686-suse10-linux-gnu and x86_64-suse10-linux-gnu; I'm using gcc-4.2.2 and binutils-2.18 for bootstrapping and configured the stuff as follows: env CC=gcc CFLAGS=-O2 CXXFLAGS='-O2 -g' GCJFLAGS='-O2 -g' LDFLAGS=-s /bin/sh ../gcc-20071113/configure --host=$config --target=$config --build=$config --srcdir=../gcc-20071113 --prefix=/opt/gnu --with-gnu-as --with-gnu-ld --enable-multilib=yes --enable-__cxa_atexit --enable-checking=release --enable-clocale=gnu --enable-interpreter --enable-shared --enable-threads=posix --with-system-zlib --with-local-prefix=/opt/gnu --enable-languages=c,c++,ada,java,fortran,objc --disable-nls --verbose (No multilibs for i686-suse10-linux-gnu, of course). Up until boehm-gc, the build runs without issues, but here it bails out: gmake[3]: Entering directory `/home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/x86_64-suse10-linux-gnu/boehm-gc' /bin/sh ./libtool --mode=compile /home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/./gcc/xgcc -B/home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/./gcc/ -B/opt/gnu/x86_64-suse10-linux-gnu/bin/ -B/opt/gnu/x86_64-suse10-linux-gnu/lib/ -isystem /opt/gnu/x86_64-suse10-linux-gnu/include -isystem /opt/gnu/x86_64-suse10-linux-gnu/sys-include -DHAVE_CONFIG_H -I/home/gnu/work/GNU/gcc-20071113/boehm-gc/include -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 -fexceptions -Iinclude -I././targ-include -I.//libc/include -c -o allchblk.lo ../../../gcc-20071113/boehm-gc/allchblk.c libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' gmake[3]: *** [allchblk.lo] Error 1 gmake[3]: Leaving directory `/home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/x86_64-suse10-linux-gnu/boehm-gc' The generated libtool script contains a line available_tags=CXX but no --tag=whatsover is passed when invoking libtool. Looking at other .../Makefile.in files, it appears that one has to pass e.g. --tag=CC (like most files do), or --tag=CXX (as in libstdc++-v3/src/Makefile.in); this option is missing in the definition of LTCOMPILE and LINK in both boehm-gc/Makefile.am and boehm-gc/Makefile.in . I have absolutely no idea why apparently nobody else is seeing this, though. The patch below fixes it for me. OK to check in? Cheers. l8er manfred boehm-gc/ChangeLog: 2007-11-13 Manfred Hollstein [EMAIL PROTECTED] * Makefile.ac (LTCOMPILE): Add missing --tag=CC argument; wrap line to fit with 80 column rule. (LINK): Likewise. * Makefile.in: Regenerate. diff -rup -x .svn -x CVS -x RCS -x '*.o' -x '*.info*' -x '*.elc' -x '*.dvi' -x '*.orig' -x '*~' -x version.el gcc-20071113.orig/boehm-gc/Makefile.am gcc-20071113/boehm-gc/Makefile.am --- gcc-20071113.orig/boehm-gc/Makefile.am 2007-07-23 12:24:57.648580681 +0200 +++ gcc-20071113/boehm-gc/Makefile.am 2007-11-13 16:45:34.792758499 +0100 @@ -64,9 +64,10 @@ TESTS = gctest ## We have our own definition of LTCOMPILE because we want to use our ## CFLAGS, not those passed in from the top level make. -LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) $(CPPFLAGS) \ - $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) -LINK = $(LIBTOOL) --mode=link $(CC) $(AM_CFLAGS) $(MY_CFLAGS) $(LDFLAGS) -o $@ +LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) \ + $(CPPFLAGS) $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) +LINK = $(LIBTOOL) --tag=CC --mode=link $(CC) $(AM_CFLAGS) $(MY_CFLAGS) \ + $(LDFLAGS) -o $@ # Work around what appears to be a GNU make bug handling MAKEFLAGS # values defined in terms of make variables, as is the case for CC and diff -rup -x .svn -x CVS -x RCS -x '*.o' -x '*.info*' -x '*.elc' -x '*.dvi' -x '*.orig' -x '*~' -x version.el gcc-20071113.orig/boehm-gc/Makefile.in gcc-20071113/boehm-gc/Makefile.in --- gcc-20071113.orig/boehm-gc/Makefile.in 2007-07-23 12:33:53.628861021 +0200 +++ gcc-20071113/boehm-gc/Makefile.in 2007-11-13 16:46:33.28565 +0100 @@ -300,10 +300,11 @@ gctest_LDADD = ./libgcjgc.la $(THREADLIB gctest_LDFLAGS = -shared-libgcc TESTS_ENVIRONMENT = LD_LIBRARY_PATH=../../$(MULTIBUILDTOP)gcc TESTS = gctest -LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) $(CPPFLAGS) \ - $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) +LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) \ + $(CPPFLAGS) $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) -LINK = $(LIBTOOL) --mode=link $(CC) $(AM_CFLAGS) $(MY_CFLAGS) $(LDFLAGS) -o $@ +LINK = $(LIBTOOL) --tag=CC --mode=link $(CC) $(AM_CFLAGS) $(MY_CFLAGS) \ + $(LDFLAGS) -o $@ # Work around what appears to be a GNU make bug handling MAKEFLAGS # values defined in terms of make variables, as is the case for CC and
[Bug fortran/34084] New: Error in November 9 version of gfortran when the first line in a source file is an INCLUDE statement
The following error occurs in the November 9 snapshot version of gfortran. It applies to all platforms. I compile the following program: INCLUDE 'anything' PROGRAM test_cg END PROGRAM test_cg The INCLUDE file can contain anything. I get the message: f951: internal compiler error: in end_source_file, at fortran/scanner.c:327 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The error does not occur if I change the program to: INCLUDE 'anything' INCLUDE 'anything_2' PROGRAM test_cg END PROGRAM test_cg -- Summary: Error in November 9 version of gfortran when the first line in a source file is an INCLUDE statement Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34084
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #19 from paolo dot bonzini at lu dot unisi dot ch 2007-11-13 16:46 --- Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fschedule-insns -fregmove -fexpensive-optimizations -fforward-propagate char_cshift_2_red_1.f90[ibook-dhum] f90/bug% a.out test 2 'adf' 'acf' 'adf' 1 1 2 1 'bdf' 'bcf' 'bdf' 2 1 2 1 'aef' 'adf' 'aef' 1 2 3 1 'bef' 'bdf' 'bef' 2 2 3 1 'acf' 'aef' 'acf' 1 3 1 1 'bcf' 'bef' 'bcf' 2 3 1 1 Abort [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fregmove -fexpensive-optimizations -fforward-propagate char_cshift_2_red_1.f90 [ibook-dhum] f90/bug% a.out test 2 'bdf' 'bcf' 'bdf' 2 1 2 1 'bef' 'bdf' 'bef' 2 2 3 1 'bcf' 'bef' 'bcf' 2 3 1 1 Abort Can you attach a -fdump-rtl-all tarball for these two sets of options for revision 130137? Thanks! Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-11 12:26:15 |2007-11-13 16:57:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #20 from dominiq at lps dot ens dot fr 2007-11-13 16:59 --- Created an attachment (id=14544) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14544action=view) outputs of -fdump-rtl-all for two set of options at -O1 The folder r137_O1_insns corresponds to -fschedule-insns. I have also added the modified test whith printing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.
--- Comment #5 from jsjodin at gcc dot gnu dot org 2007-11-13 17:07 --- (In reply to comment #4) Related to PR 33790 (and most likely fixed by it). There is another issue with that bug relating to not deleting the extra store. Indeed the extra load disappeared when with the patch. The store did not get deleted as expected. I looked at the differences between the good and bad case. Compiling the good case has the following sequence before the fre pass: Note: src and dst are unions src.f = D.9650_45; D.9630_31 = src.f; D.9655_46 = __builtin_ia32_addps (D.9630_31, D.9630_31); dst.f = D.9655_46; D.9632_33 = dst.f; After fre the temps have been propagated and replaced the uses of dst.f: src.f = D.9650_45; D.9630_31 = D.9650_45; D.9655_46 = __builtin_ia32_addps (D.9630_31, D.9630_31); dst.f = D.9655_46; D.9632_33 = D.9655_46; The extra stores to src.f are eliminated in dce. The bad case has the following code before and after fre: src.i = D.9651_44; D.9630_31 = src.f; D.9655_45 = __builtin_ia32_addps (D.9630_31, D.9630_31); dst.f = D.9655_45; D.9632_33 = dst.i; Since the src.i and src.f are probably not considered to be the same the propagation does not work. It might be possible to handle this case if one consideres the size of data being written and read from unions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34043
[Bug c++/34059] [4.1/4.2/4.3 regression] ICE with invalid base type for class member
--- Comment #1 from janis at gcc dot gnu dot org 2007-11-13 17:23 --- The change on mainline from silently accepting the code to an ICE is due to this patch: http://gcc.gnu.org/viewcvs?view=revrev=117360 r117360 | mmitchel | 2006-10-02 04:12:30 + (Mon, 02 Oct 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-11-13 17:34 --- (In reply to comment #3) Either we should use correct order of arguments in chrec_evaluate (that function is swapping CHREC_LEFT based expression with CHREC_RIGHT based expression for pointer_plus addition) - testing patch for that This is the correct fix. - or chrec_fold_plus_1 should swap op0 with op1 if code is POINTER_PLUS_EXPR and the first argument has integer type, but second POINTER_TYPE_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts
--- Comment #29 from alexandre dot nunes at gmail dot com 2007-11-13 17:35 --- (In reply to comment #28) (In reply to comment #26) (In reply to comment #25) [cut] Mark does not actually read the full list of messages when changing the target milestone. I think this should be closed as WONTFIX since there is no easy way to fix this for 4.2 but it is fixed in 4.3. As a workaround, you should be able to use -Wno-cast-qual to avoid the warning. I don't remember if 4.2 supports -Wno-error=cast-qual. If it does, you can still get the warning as a warning even when using -Werror. It does, thanks for the tip. I added this to my makefile: check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null /dev/null 21; then echo $(1); else echo $(2); fi ;) # Work-around for stupid gcc 4.2 bug ifneq ($(findstring Werror,$(WARN)),) WARN += $(call check_gcc,-Wno-error=cast-qual,) endif ... now it compiles fine with -Werror both on gcc 4.1 and 4.2. It would be nice if this bug would get somehow documented on gcc manual or the main site before gcc 4.2.3 release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts
--- Comment #30 from manu at gcc dot gnu dot org 2007-11-13 17:55 --- (In reply to comment #29) It would be nice if this bug would get somehow documented on gcc manual or the main site before gcc 4.2.3 release. I agree. But I am not sure how this is typically done (I am too newbie). I think if you write a patch [*] for http://gcc.gnu.org/gcc-4.2/changes.html (a new item under Caveats) pointing to http://gcc.gnu.org/PR29478 with you would like (as an user) to know, that may do. Send it to [EMAIL PROTECTED] If you have any doubts, ask me. Thanks. [*] Getting the webpages: http://gcc.gnu.org/cvs.html#wwwdocs And a bit more of info: http://gcc.gnu.org/contribute.html#webchanges -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug rtl-optimization/34085] New: ICE with -freorder-blocks-and-partition
When compiling the testacse attached with -O3 -fprofile-use -freorder-blocks-and-partition flags, I get the following error: (I use the profiling information given by first compiling with -fprofile-generate and than running the executable) tmp.c: In function âmainâ: tmp.c:36: error: insn 186 outside of basic blocks has non-NULL bb field tmp.c:36: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This ICE seems to happen when not all of the bbs are in the same partition (hot/cold). -- Summary: ICE with -freorder-blocks-and-partition Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #1 from eres at il dot ibm dot com 2007-11-13 18:21 --- Created an attachment (id=14545) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14545action=view) The testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-13 18:23 --- Subject: Bug 34063 Author: jakub Date: Tue Nov 13 18:23:03 2007 New Revision: 130151 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130151 Log: PR tree-optimization/34063 * tree-chrec.c (chrec_evaluate): Put CHREC_LEFT based argument as first chrec_fold_plus operand rather than second. * g++.dg/tree-ssa/pr34063.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr34063.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-13 18:24 --- Can you please also attach your profile information and give the exact compiler revision ID that you used to create that information? That way, people without access to POWER can still help debug this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug c++/34057] [4.3 regression] ICE with variadic template and vector attribute
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 --- Subject: Bug 34057 Author: jakub Date: Tue Nov 13 18:27:09 2007 New Revision: 130152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130152 Log: PR c++/34054 PR c++/34056 PR c++/34057 PR c++/34058 PR c++/34060 * pt.c (find_parameter_packs_r): If ppd-set_packs_to_error, set to error_mark_node the outermost POINTER_TYPE to the pack if it is seen in a POINTER_TYPE. (push_template_decl_real): If check_for_bare_parameter_packs fails for function return type, set the return type to integer_type_node. If check_for_bare_parameter_packs failed for non-function, return error_mark_node. * g++.dg/parse/crash36.C: Add another dg-error. * g++.dg/cpp0x/pr34054.C: New test. * g++.dg/cpp0x/pr34056.C: New test. * g++.dg/cpp0x/pr34057.C: New test. * g++.dg/cpp0x/pr34058.C: New test. * g++.dg/cpp0x/pr34060.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash36.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34057
[Bug c++/34054] [4.3 regression] ICE with parameter pack in return type
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 --- Subject: Bug 34054 Author: jakub Date: Tue Nov 13 18:27:09 2007 New Revision: 130152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130152 Log: PR c++/34054 PR c++/34056 PR c++/34057 PR c++/34058 PR c++/34060 * pt.c (find_parameter_packs_r): If ppd-set_packs_to_error, set to error_mark_node the outermost POINTER_TYPE to the pack if it is seen in a POINTER_TYPE. (push_template_decl_real): If check_for_bare_parameter_packs fails for function return type, set the return type to integer_type_node. If check_for_bare_parameter_packs failed for non-function, return error_mark_node. * g++.dg/parse/crash36.C: Add another dg-error. * g++.dg/cpp0x/pr34054.C: New test. * g++.dg/cpp0x/pr34056.C: New test. * g++.dg/cpp0x/pr34057.C: New test. * g++.dg/cpp0x/pr34058.C: New test. * g++.dg/cpp0x/pr34060.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash36.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34054
[Bug c++/34058] [4.3 regression] ICE with variadic template and typedef
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 --- Subject: Bug 34058 Author: jakub Date: Tue Nov 13 18:27:09 2007 New Revision: 130152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130152 Log: PR c++/34054 PR c++/34056 PR c++/34057 PR c++/34058 PR c++/34060 * pt.c (find_parameter_packs_r): If ppd-set_packs_to_error, set to error_mark_node the outermost POINTER_TYPE to the pack if it is seen in a POINTER_TYPE. (push_template_decl_real): If check_for_bare_parameter_packs fails for function return type, set the return type to integer_type_node. If check_for_bare_parameter_packs failed for non-function, return error_mark_node. * g++.dg/parse/crash36.C: Add another dg-error. * g++.dg/cpp0x/pr34054.C: New test. * g++.dg/cpp0x/pr34056.C: New test. * g++.dg/cpp0x/pr34057.C: New test. * g++.dg/cpp0x/pr34058.C: New test. * g++.dg/cpp0x/pr34060.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash36.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34058
[Bug c++/34060] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 --- Subject: Bug 34060 Author: jakub Date: Tue Nov 13 18:27:09 2007 New Revision: 130152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130152 Log: PR c++/34054 PR c++/34056 PR c++/34057 PR c++/34058 PR c++/34060 * pt.c (find_parameter_packs_r): If ppd-set_packs_to_error, set to error_mark_node the outermost POINTER_TYPE to the pack if it is seen in a POINTER_TYPE. (push_template_decl_real): If check_for_bare_parameter_packs fails for function return type, set the return type to integer_type_node. If check_for_bare_parameter_packs failed for non-function, return error_mark_node. * g++.dg/parse/crash36.C: Add another dg-error. * g++.dg/cpp0x/pr34054.C: New test. * g++.dg/cpp0x/pr34056.C: New test. * g++.dg/cpp0x/pr34057.C: New test. * g++.dg/cpp0x/pr34058.C: New test. * g++.dg/cpp0x/pr34060.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash36.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34060
[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:27 --- Subject: Bug 34056 Author: jakub Date: Tue Nov 13 18:27:09 2007 New Revision: 130152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130152 Log: PR c++/34054 PR c++/34056 PR c++/34057 PR c++/34058 PR c++/34060 * pt.c (find_parameter_packs_r): If ppd-set_packs_to_error, set to error_mark_node the outermost POINTER_TYPE to the pack if it is seen in a POINTER_TYPE. (push_template_decl_real): If check_for_bare_parameter_packs fails for function return type, set the return type to integer_type_node. If check_for_bare_parameter_packs failed for non-function, return error_mark_node. * g++.dg/parse/crash36.C: Add another dg-error. * g++.dg/cpp0x/pr34054.C: New test. * g++.dg/cpp0x/pr34056.C: New test. * g++.dg/cpp0x/pr34057.C: New test. * g++.dg/cpp0x/pr34058.C: New test. * g++.dg/cpp0x/pr34060.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash36.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34056
[Bug c++/34054] [4.3 regression] ICE with parameter pack in return type
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:28 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34054
[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-13 18:28 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34056
[Bug c++/34057] [4.3 regression] ICE with variadic template and vector attribute
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:30 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34057
[Bug c++/34058] [4.3 regression] ICE with variadic template and typedef
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:30 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34058
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #3 from eres at il dot ibm dot com 2007-11-13 18:30 --- Created an attachment (id=14546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14546action=view) the testcase (please ignore the previous testcase it has been uploaded by mistake) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
