Re: New LTO branch ready
Daniel Berlin wrote: Hi guys, I have merged all patches touching lto/ into the new lto branch Thank you! Did you also pull over Kenny's LTO-writer code? I'll try to get it compiling soon. I will perform merges from mainline to branch every week or two, unless you guys see a good reason not to That's great, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Activate -mrecip with -ffast-math?
On 6/18/07, Brooks Moses [EMAIL PROTECTED] wrote: Giovanni Bajo wrote: Both our goals are legitimate. But that's not the point. The point is what -ffast-math semantically means (the simplistic list of suboptions activated by it is of couse unsufficiente because it doesn't explain how to behave in face of new options, like -mrecip). My proposal is: -ffast-math activates all the mathematical-related optimizations that improves code speed while destroying floating point accuracy. I don't think that's a workable proposal. If it is taken literally, it means that the optimization of converting all floating-point arithmetic to no-ops and replacing all references to floating-point variables with zeros is allowed (and would be appropriate under this option). And, personally, I don't think that documentation is of use if it can't be taken reasonably literally. There's a line between what's acceptable and what's not, and regardless of where exactly it is, the documentation needs to fairly clearly indicate its location. I agree. 'destroying floating point accuracy' is too broad and discuraging. Even if in some cases this is exactly what happens - the error we introduce (if you define it as difference of result with and without -ffast-math) is essentially unbound. Still in most 'regular' cases we preserve accuracy quite well or even improve it (for some other metric of accuracy). This is really a hard to solve communication problem. OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply 'wrong', not inaccurate ;) Richard.
Re: Object attribute tagging
On Tue, 2007-06-19 at 01:50 +, Joseph S. Myers wrote: The ARM EABI says that only standard entries under aeabi should affect link-compatibility of object files, not vendor entries such as gnu, but in the absence of corresponding standards for other processors I don't think we can avoid use of gnu for link-compatibility on non-ARM processors for now - if processor ABIs standardize things in future we can deprecate the associated gnu attributes. This isn't quite correct. The ARM aeabi attributes provides Tag_compatibility which describes whether an object contains information that must be processed by a specific toolchain. In essence an object with this tag set to a non-zero value is conforming, but not maximally portable. R.
Re: Activate -mrecip with -ffast-math?
OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply 'wrong', not inaccurate ;) I still support the introduction of a special switch for this kind of transformation, -fwrong-math-optimizations. :-) Paolo
Re: virtual stack regs.
I would like to get some more information about pr32374.
I do not know what virtual_stack_vars are and there is no documentation
in the doc directory.
It is documented:
@findex VIRTUAL_STACK_VARS_REGNUM
@cindex @code{FRAME_GROWS_DOWNWARD} and virtual registers
@item VIRTUAL_STACK_VARS_REGNUM
If @code{FRAME_GROWS_DOWNWARD} is defined to a nonzero value, this
points to immediately above the first variable on the stack. Otherwise,
it points to the first variable on the stack.
1) What are these?
2) Why are they uninitialized?
3) If they really are uninitialized, why is it a problem to assign zero
to them.
Basically like all virtual registers, those are just placeholders used
during expansion for RTL expressions that are fed into the place later.
See instantiate_virtual_regs. As such emitting a store into the
register definitly confuse the logic.
4) If they are not uninitialized, where is the initialization code? Why
does df not see it?
5) How can I tell if a reg is a virtual_stack_reg?
By the regno. If you want to check for all those animals, you need
FIRST_VIRTUAL_REGISTER. Why do you need the dataflow so early?
Honza
Re: Activate -mrecip with -ffast-math?
On 6/19/07, Paolo Bonzini [EMAIL PROTECTED] wrote: OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply 'wrong', not inaccurate ;) I still support the introduction of a special switch for this kind of transformation, -fwrong-math-optimizations. :-) Probably as useful and widely-used as -fhello-world? ;) Richard.
Re: virtual stack regs.
On Mon, Jun 18, 2007 at 08:28:25PM -0400, Kenneth Zadeck wrote:
I would like to get some more information about pr32374.
I do not know what virtual_stack_vars are and there is no documentation
in the doc directory.
less -p 'Virtual registers ' gcc/rtl.h
less -p 'enum global_rtl_index' gcc/rtl.h
1) What are these?
They are placeholders. The vregs pass will replace them with
stack_pointer_rtx, (hard_)frame_pointer_rtx and arg_pointer_rtx using
information from STARTING_FRAME_OFFSET, FIRST_PARM_OFFSET and such.
Here are two examples, where arg_pointer_rtx is (reg/f:HI 14 argp) and
(hard_)frame_pointer_rtx is (reg/f:HI 10 bp):
(insn ... (set (reg/v/f:HI 39 [ tmp ])
(mem/f/c/i:HI (plus:HI (reg/f:HI 15 virtual-incoming-args)
(const_int 4 [0x4])) [0 tmp+0 S2 A16])) -1 (nil)
(expr_list ...
(nil)))
becomes
(insn ... (set (reg/v/f:HI 39 [ tmp ])
(mem/f/c/i:HI (plus:HI (reg/f:HI 14 argp)
(const_int 6 [0x6])) [0 tmp+0 S2 A16])) 9 {*movhi} (nil)
(expr_list ...
(nil)))
(where argp is a virtual hard reg later eliminated by reload) because
FIRST_PARM_OFFSET is 2, and
(insn ... (parallel [
(set (reg:HI 62)
(plus:HI (reg/f:HI 16 virtual-stack-vars)
(reg:HI 61)))
(clobber (reg:CC 13 cc))
]) -1 (nil)
(nil))
becomes
(insn ... (parallel [
(set (reg:HI 62)
(plus:HI (reg/f:HI 10 bp)
(reg:HI 61)))
(clobber (reg:CC 13 cc))
]) 44 {*addhi3} (nil)
(nil))
because STARTING_FRAME_OFFSET is 0.
2) Why are they uninitialized?
There is no meaningful value to assign to them.
3) If they really are uninitialized, why is it a problem to assign zero
to them.
It is possible to mess up the substitution that the vregs pass performs.
IIRC, it happened to me once because I accidentally put one of these virtual
pseudo inside a (clobber) or (use) or something like that. I don't quite
recall the details, but maybe the substitution fails if they appear outside
an operand?
4) If they are not uninitialized, where is the initialization code? Why
does df not see it?
Hmm, how do you handle arg_pointer_rtx, frame_pointer_rtx and the like?
The are all uninitialized until the prologue is emitted, which is some time
after reload.
5) How can I tell if a reg is a virtual_stack_reg?
FIRST_VIRTUAL_REGISTER = regno = LAST_VIRTUAL_REGISTER
--
Rask Ingemann Lambertsen
run-time function adaptation for statically-compiled programs
Hi all, In case someone is interested, we just made a new patch available for gcc to enable run-time multiple option exploration and to enable run-time adaptation for various constraints on heterogeneous systems using function cloning. More information and a patch are avilable here: http://gcc.gnu.org/wiki/functionAdaptation Cheers, Grigori = Grigori Fursin, PhD Research Fellow, INRIA Futurs, France http://fursin.net/research
Re: virtual stack regs.
Rask Ingemann Lambertsen wrote: On Tue, Jun 19, 2007 at 11:11:54AM +0200, Uros Bizjak wrote: On 6/19/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote: It is possible to mess up the substitution that the vregs pass performs. IIRC, it happened to me once because I accidentally put one of these virtual pseudo inside a (clobber) or (use) or something like that. I don't quite recall the details, but maybe the substitution fails if they appear outside an operand? There is one annoying case in PR32374, where on-the-stack constructor creates invalid memory clobber that includes virtual-stack-regs. These are simply ignored by vregs pass and this confuses dataflow register initialization. Yes, that sure rings a bell with me. A bare (clobber) with a virtual-what-have-we reg inside it does the trick nicely. If it hadn't been hidden inside a MEM, you would have seen the rnreg pass choke on it, IIRC. My DKK 0.02 worth: I don't see the point in clobbering a memory location just before storing into it. We do so with pseudos wider than BITS_PER_WORD just before storing into all BITS_PER_WORD sized subregs of it, but that's because life analysis doesn't (didn't?) handle subregs in a useful way. We shouldn't do the same for MEMs. These two mails are the useful information in this whole thread!! I think that the obvious thing to do is to fix this upstream where the clobber is being created, especially if the clobber really is invalid as Rask asserts. While I now see enough so that i could easily teach the init-regs pass to ignore these, I prefer to leave init-regs as is and get rid of the invalid code earlier. The problem with fixing it in init-regs is that we have spent a lot of effort and will continue to make the rtl back end a lot smarter. It is generally true that if one part finds something wrong, just fixing that part so that it ignores a problem will eventually leave it for another part to trip over when it gets smarter. Since it sounds like you understand this, are either of you willing/able to attack the problem at it's source? Kenny
Re: New LTO branch ready
On 6/19/07, Mark Mitchell [EMAIL PROTECTED] wrote: Daniel Berlin wrote: Hi guys, I have merged all patches touching lto/ into the new lto branch Thank you! Did you also pull over Kenny's LTO-writer code? Yup. I have the complete list of revisions merged with their log entries if you'd like to see it.
Re: virtual stack regs.
On Tue, Jun 19, 2007 at 08:33:52AM -0400, Kenneth Zadeck wrote: Since it sounds like you understand this, are either of you willing/able to attack the problem at it's source? Uros is already at it URL:http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html. -- Rask Ingemann Lambertsen
cp_compat_x_tst.o-cp_compat_y_tst.o testcase
Hello, While testing a patch on current trunk (r 125640) I've noticed that g++'s cp_compat_x_tst.o-cp_compat_y_tst testcase fails with unexpected failure on x86_64 with the vanilla version but passes OK with the patched version (-O2). On ppc64 and i486 the test passes both with the vanilla and the patched version. -FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o execute I appreciate any clue regarding the reason this testcase fails (with Segmentation fault) on current mainline on x86_64; this could help me understand why the patch I'm working on caused it to pass. Thanks, Revital
m68k bootstrap problem
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int fi2(int);
void *fp1(int, void *);
void *fp2(int, int);
void *f(int x, int a, int b)
{
if (x) {
int y = fi1(1);
void *p;
y += fi2(3);
p = fp1(2, 0);
return fp1(y, p);
} else {
int z = fi2(2);
z += fi1(z);
return fp2(z, 3);
}
}
The function is exited here via a sibcall, one important thing is that
current_function_return_rtx is set to:
(parallel/i:SI [
(expr_list:REG_DEP_TRUE (reg:SI 8 %a0 [ result ])
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:SI 0 %d0 [ result ])
(const_int 0 [0x0]))
])
This means the return value is returned in both %d0/%a0.
The problem is now that this seems to produce incorrect REG_DEAD notes for
%d0, they are missing at the last use before the sibcall. This now seems
to confuse reload in the full test case, where it calls
save_call_clobbered_regs(), which can't quite decide whether to save %d0
across a function call or not.
setup_save_areas() doesn't create a stack slot for %d0 because it's not
associated with a pseudo which lives across a function call, but later in
save_call_clobbered_regs() %d0 is still live at a function call and it
attempts to save the register, which fails due to the missing stack slot.
AFAICT this behaviour is correct, the question is now how do I get
correct REG_DEAD notes? It seems to be related to the unusual return
expression above, but at this point I need some help to fix this.
bye, Roman
Re: m68k bootstrap problem
Roman Zippel wrote:
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int fi2(int);
void *fp1(int, void *);
void *fp2(int, int);
void *f(int x, int a, int b)
{
if (x) {
int y = fi1(1);
void *p;
y += fi2(3);
p = fp1(2, 0);
return fp1(y, p);
} else {
int z = fi2(2);
z += fi1(z);
return fp2(z, 3);
}
}
The function is exited here via a sibcall, one important thing is that
current_function_return_rtx is set to:
(parallel/i:SI [
(expr_list:REG_DEP_TRUE (reg:SI 8 %a0 [ result ])
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:SI 0 %d0 [ result ])
(const_int 0 [0x0]))
])
This means the return value is returned in both %d0/%a0.
The problem is now that this seems to produce incorrect REG_DEAD notes for
%d0, they are missing at the last use before the sibcall. This now seems
to confuse reload in the full test case, where it calls
save_call_clobbered_regs(), which can't quite decide whether to save %d0
across a function call or not.
setup_save_areas() doesn't create a stack slot for %d0 because it's not
associated with a pseudo which lives across a function call, but later in
save_call_clobbered_regs() %d0 is still live at a function call and it
attempts to save the register, which fails due to the missing stack slot.
AFAICT this behaviour is correct, the question is now how do I get
correct REG_DEAD notes? It seems to be related to the unusual return
expression above, but at this point I need some help to fix this.
bye, Roman
roman do i need any patches to apply before trying this. also what are
the config options i need?
kenny
Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time of the polyhedron test suite increased by 35% compared to the previous snapshot and by 41% compared to the Apr 13 one: compile execute 06/15 06/08 04/13 06/13 06/08 04/13 ac 6.098 4.169 3.754 141.335 141.271 140.479 aermod 266.403 205.639 196.447 92.75693.58390.632 air 14.77311.92511.541 40.14941.53339.399 capacita 7.332 5.542 5.154 175.615 176.229 177.222 channel 4.289 2.519 2.279 15.66415.94715.732 doduc 37.70028.04026.679 68.59968.89568.195 fatigue 12.843 8.733 8.293 23.76624.79523.061 gas_dyn 11.856 8.168 7.598 53.94253.92952.100 induct 36.87823.67122.445 72.24773.03169.283 linpk2.419 1.979 1.910 33.48933.84433.446 mdbx 9.052 7.036 6.716 32.54232.54332.985 nf 5.412 3.629 3.357 51.42451.40458.494 protein 20.09713.16213.063 70.82570.11370.896 rnflow 19.81214.37014.196 76.93677.41976.371 test_fpu17.09812.03411.396 37.33637.32437.697 tfft 2.530 1.938 1.779 16.65316.83116.581 total 474.592 352.554 336.6071003.278 1008.691 1002.573 without any noticable effects on the execution time. Does anyone can explain it (and suggest a fix)? TIA Dominique
Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
On 6/19/07, Dominique Dhumieres [EMAIL PROTECTED] wrote: On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time of the polyhedron test suite increased by 35% compared to the previous snapshot and by 41% compared to the Apr 13 one: I did not see this change. What flags are you using? Richard. compile execute 06/15 06/08 04/13 06/13 06/08 04/13 ac 6.098 4.169 3.754 141.335 141.271 140.479 aermod 266.403 205.639 196.447 92.75693.58390.632 air 14.77311.92511.541 40.14941.53339.399 capacita 7.332 5.542 5.154 175.615 176.229 177.222 channel 4.289 2.519 2.279 15.66415.94715.732 doduc 37.70028.04026.679 68.59968.89568.195 fatigue 12.843 8.733 8.293 23.76624.79523.061 gas_dyn 11.856 8.168 7.598 53.94253.92952.100 induct 36.87823.67122.445 72.24773.03169.283 linpk2.419 1.979 1.910 33.48933.84433.446 mdbx 9.052 7.036 6.716 32.54232.54332.985 nf 5.412 3.629 3.357 51.42451.40458.494 protein 20.09713.16213.063 70.82570.11370.896 rnflow 19.81214.37014.196 76.93677.41976.371 test_fpu17.09812.03411.396 37.33637.32437.697 tfft 2.530 1.938 1.779 16.65316.83116.581 total 474.592 352.554 336.6071003.278 1008.691 1002.573 without any noticable effects on the execution time. Does anyone can explain it (and suggest a fix)? TIA Dominique
Re: m68k bootstrap problem
Hi, On Tue, 19 Jun 2007, Kenneth Zadeck wrote: roman do i need any patches to apply before trying this. None should be needed, but this one can't hurt: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01247.html also what are the config options i need? I use --target=m68k-linux-gnu --enable-languages=c,c++,objc bye, Roman
Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
I did not see this change. What flags are you using? gfortran -w -O3 -ffast-math -funroll-loops Dominique
Re: RFC: Make dllimport/dllexport imply default visibility
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
I suspect that the realview compiler accepts
this as an oversight or a bug, not as an intentional feature.
Let's ask.
Richard E., is the fact that RealView 3.0SP1 accepts:
class __declspec(notshared) S {
__declspec(dllimport) void f();
};
a bug or a feature? If this is considered a bug, is it something that
RealView is likely to change in a future release, or will it be
preserved for the forseeable future for backwards compatibility?
This is well beyond my sphere of expertise, so I've asked one of the
original developers of the spec. He asserts that the above is supported
and intentional. Hopefully I've correctly represented his position
below.
His key point is that 'notshared' on a class is not the same as making
the whole class hidden: only the class impedimenta (vtables, rtti) is
hidden, but the rest of the class can be exported as normal. And that
since it can be exported, there's no reason why definitions of member
functions can't be imported.
R.
Re: cp_compat_x_tst.o-cp_compat_y_tst.o testcase
On Tue, Jun 19, 2007 at 04:26:46PM +0300, Revital1 Eres wrote:
While testing a patch on current trunk (r 125640) I've noticed that g++'s
cp_compat_x_tst.o-cp_compat_y_tst testcase fails with unexpected failure
on x86_64 with the vanilla version but passes OK with the patched version
(-O2). On ppc64 and i486 the test passes both with the vanilla and the
patched version.
-FAIL: tmpdir-g++.dg-struct-layout-1/t026
cp_compat_x_tst.o-cp_compat_y_tst.o execute
I appreciate any clue regarding the reason this testcase fails (with
Segmentation fault) on current mainline on x86_64; this could help me
understand why the patch I'm working on caused it to pass.
These are generated testcases, see
gcc/testsuite/*.dg/compat/struct-layout-1*
If you build the testcase with -DDBG (e.g. changing the generator,
maybe --target_board unix/-DDBG, changing the struct-layout-1.h
header), then it should in g++.log print more details which exact test
failed. Then you can retry just with that single type that failed, say if
it was test 546, use just the
U(546,struct{char * b;}a;struct{}c[0];,F(546,a.b,(char *)intarray[107],(char
*)intarray[95]))
line from testsuite/g++/g++.dg-struct-layout-1/t002_test.h
and if you can reproduce, you can preprocess/simplify as much as needed.
Jakub
Where can I find sizeof implementation in front end
Hello all: I am reading codes of gcc front end. But I can not find the implementation of sizeof. How does gcc front end calculate size of UNION and STRUCT? Where is the codes for these work. Can anybody give me some advices? Thank you so much !
RE: Where can I find sizeof implementation in front end
On 19 June 2007 16:35, bjzheng wrote: Hello all: I am reading codes of gcc front end. But I can not find the implementation of sizeof. How does gcc front end calculate size of UNION and STRUCT? Where is the codes for these work. Can anybody give me some advices? Thank you so much ! grep _sizeof /gnu/gcc/gcc/gcc/*.[ch] Look at c_sizeof_or_alignof_type, #define c_sizeof(T) and #define c_alignof(T) in c-common.c, and look at c_parser_sizeof_expression in c-parser.c cheers, DaveK -- Can't think of a witty .sigline today
Re: Where can I find sizeof implementation in front end
[EMAIL PROTECTED] wrote: Hello all: I am reading codes of gcc front end. But I can not find the implementation of sizeof. How does gcc front end calculate size of UNION and STRUCT? Where is the codes for these work. Can anybody give me some advices? Thank you so much ! The code is heavily target dependent. More or less, the whole of stor-layout.c is devoted to this task. Paolo
Re: virtual stack regs.
On 6/19/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote: .. Hmm, how do you handle arg_pointer_rtx, frame_pointer_rtx and the like? The are all uninitialized until the prologue is emitted, which is some time after reload. ARG_POINTER_REGNUM is included in the artificial defs of all blocks (which I think is overly conservative - just having them in the entry block def should be enough). Hence, from dataflow point of view, they are always considered initialized. I think we should probably do something similar for VIRTUAL_STACK_*_REGNUM. 5) How can I tell if a reg is a virtual_stack_reg? FIRST_VIRTUAL_REGISTER = regno = LAST_VIRTUAL_REGISTER -- Rask Ingemann Lambertsen -- #pragma ident Seongbae Park, compiler, http://seongbae.blogspot.com;
Re: I'm sorry, but this is unacceptable (union members and ctors)
michael.a wrote: Since I'm already posting, now I'm seeing: /home/users/michael/gcc.obj/gcc/f951: symbol lookup error: /home/users/michael/gcc.obj/gcc/f951: undefined symbol: __gmp_get_memory_functions I was able to find this: http://www.nabble.com/Bootstrap-failure-in-libjava...-t3132896.html Which lead me to discover that there was already old GMP libraries in /usr/lib (I guess I wish the gcc configure script could've been more explicit, as opposed to saying it couldn't find gmp libraries when instead it could find mpfr libraries, but lumped the two into the same message) Then the build apparently ran into some bad code when building the fortran front end (i think it was in a .f90 file, might've been intrinsics/asm code, but the output looked like C) ...in any case, after I configured with --enable-languages=c,c++ only, everything made it through ok. So, I really appreciate all of your patience in helping to get me through the build process. I guess I'll post something about how the hacking effort / reprogramming expiriments work out. In the meantime I hope this discussion (and the relevance of a proper extension) still has some legs. sincerely, michael -- View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11199192 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: m68k bootstrap problem
Roman Zippel wrote:
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int fi2(int);
void *fp1(int, void *);
void *fp2(int, int);
void *f(int x, int a, int b)
{
if (x) {
int y = fi1(1);
void *p;
y += fi2(3);
p = fp1(2, 0);
return fp1(y, p);
} else {
int z = fi2(2);
z += fi1(z);
return fp2(z, 3);
}
}
The function is exited here via a sibcall, one important thing is that
current_function_return_rtx is set to:
(parallel/i:SI [
(expr_list:REG_DEP_TRUE (reg:SI 8 %a0 [ result ])
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:SI 0 %d0 [ result ])
(const_int 0 [0x0]))
])
This means the return value is returned in both %d0/%a0.
The problem is now that this seems to produce incorrect REG_DEAD notes for
%d0, they are missing at the last use before the sibcall. This now seems
to confuse reload in the full test case, where it calls
save_call_clobbered_regs(), which can't quite decide whether to save %d0
across a function call or not.
setup_save_areas() doesn't create a stack slot for %d0 because it's not
associated with a pseudo which lives across a function call, but later in
save_call_clobbered_regs() %d0 is still live at a function call and it
attempts to save the register, which fails due to the missing stack slot.
AFAICT this behaviour is correct, the question is now how do I get
correct REG_DEAD notes? It seems to be related to the unusual return
expression above, but at this point I need some help to fix this.
bye, Roman
a particularly useful kind of debugging is available for these kinds of
problems.
if you change the 0 to a 1 at df-problems.c:49, it will turn on a
verbose trace of the process that it goes thru to decide to build
reg_dead notes. This process includes listing all of the info for each
of the insn's uses and defs.
The reason that there is no reg_dead not in the last use (insn 45)
before the sib_call (insn 46) is that there is no def for r0 in the
sibcall (insn 46) and r0 is live at the end of the block.
This of course changes the question to not why there no note to why is
there no def.
Kenny
;; Function f (f)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
f
Dataflow summary:
def_info-table_size = 68, use_info-table_size = 52
;; invalidated by call 0 [%d0] 1 [%d1] 8 [%a0] 9 [%a1] 16 [%fp0] 17
[%fp1]
;; hardware regs used 14 [%a6] 15 [%sp] 24 [%argptr]
;; regular block artificial uses14 [%a6] 15 [%sp] 24 [%argptr]
;; eh block artificial uses 14 [%a6] 15 [%sp] 24 [%argptr]
;; entry block defs 8 [%a0] 9 [%a1] 14 [%a6] 15 [%sp] 24 [%argptr]
;; exit block uses 0 [%d0] 8 [%a0] 14 [%a6] 15 [%sp]
;; regs ever live 0[%d0] 8[%a0] 15[%sp]
(note 1 0 6)
;; Start of basic block ( 0) - 2
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(14){ }u1(15){ }u2(24){ }}
;; lr in14 [%a6] 15 [%sp] 24 [%argptr]
;; lr use 14 [%a6] 15 [%sp] 24 [%argptr]
;; lr def
;; urec in 14 [%a6] 15 [%sp] 24 [%argptr]
;; urec gen
;; urec kill
;; urec ec
;; Pred edge ENTRY [100.0%] (fallthru)
(note 6 1 2 2 [bb 2])
(note 2 6 5 2)
(note 5 2 8 2)
(insn:QI 8 5 9 2 test.c:8 (set (cc0)
(mem/c/i:SI (plus:SI (reg/f:SI 24 %argptr)
(const_int 8 [0x8])) [3 x+0 S4 A32])) 3 {*m68k.md:221} (nil))
(jump_insn 9 8 10 2 test.c:8 (set (pc)
(if_then_else (eq (cc0)
(const_int 0 [0x0]))
(label_ref 32)
(pc))) 386 {beq} (expr_list:REG_BR_PROB (const_int 5400 [0x1518])
(nil)))
;; End of basic block 2 - ( 3 4)
;; lr out 14 [%a6] 15 [%sp] 24 [%argptr]
;; urec out 14 [%a6] 15 [%sp] 24 [%argptr]
;; Succ edge 3 [46.0%] (fallthru)
;; Succ edge 4 [54.0%]
;; Start of basic block ( 2) - 3
;; bb 3 artificial_defs: { }
;; bb 3 artificial_uses: { u5(14){ }u6(15){ }u7(24){ }}
;; lr in14 [%a6] 15 [%sp] 24 [%argptr]
;; lr use 14 [%a6] 15 [%sp] 24 [%argptr]
;; lr def 0 [%d0] 1 [%d1] 8 [%a0] 9 [%a1] 15 [%sp] 16 [%fp0] 17 [%fp1]
32 35
;; urec in 14 [%a6] 15 [%sp] 24 [%argptr]
;; urec gen 0 [%d0] 8 [%a0] 15 [%sp] 32 35
;; urec kill0 [%d0] 8 [%a0] 15 [%sp] 32 35
;; urec ec
;; Pred edge 2 [46.0%] (fallthru)
(note 10 9 11 3 [bb 3])
(insn 11 10 12 3 test.c:9 (set (mem/i:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S4
A16])
(const_int 1 [0x1])) 29 {pushexthisi_const} (nil))
(note 12 11 13 3)
(call_insn 13 12 14 3 test.c:9 (set (reg:SI 0 %d0)
(call (mem:QI (symbol_ref:SI (fi1) [flags 0x41]
Re: Object attribute tagging
On Jun 18, 2007, at 6:50 PM, Joseph S. Myers wrote: Any comments on either the general approach or the details? Sounds fine to me. In mips land we were previously using named sections to solve this, but as long as the approach allows arbitrarily long sets of attributes I think it sounds great. This could be implemented by another section that has a new set of attributes if necessary for a target. -eric
Re: Some thoughts about steerring commitee work
Mark Mitchell wrote: One advantage of having some SC members who are not GCC developers (and thus seem less involved) is that they are more independent. They have no commercial stake in which companies have maintainers, The funny part in the discussion on the SC is that most contributors seem to place me firmly in the users basket, while, at the same time, in the Fortran Standardization Committee (http://j3-fortran.org) I'm firmly placed in the vendors bucket ... You can please some of the people all of the time and all of the people some of the time, but not all of the people all of the time (whose quote am I mangling here ?). BTW, *I* wouldn't be opposed to elections and no-more-years terms for SC members. Part of it is experience in dealing with GCC-within-the-GNU project; part of it is experience in developing a great compiler. Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
scalar expansion and array privatization for loop distribution
Hello, I am looking into writing scalar expansion and array privatization passes for loop distribution with Sebastian. Has scalar expansion and/or array privatization been implemented in gcc? If so, how have they been implemented and also to what extent? Does anyone have any pointers on where I can start looking? Thanks, Harsha
Re: [M16C] : 20 bit data access
- 2 new attributes far_data (to use external memory for data storage) and far_rodata will be added. I'd prefer just one far attribute. GCC knows (usually better than the user ;) what data is read-only and what data is not. - By default, LDE instructions will be used to access the entire constant variables. Perhaps with a compiler switch? Like -mcpu=m16c? ;-) I wouldn't want to use LDE on an r8c which doesn't *have* far memory. We'd need to add a new multilib for that if we did. If we do add an m16c multilib, perhaps we should make the m16c 16 bit aligned internally, to speed performance? Currently, it doesn't, because it's more important to save space on the r8c, which has an 8 bit internal bus. - New attribute near_rodata will be added. This attribute will be used for the latest M16C targets that have 4K/8K flash in near Memory. Again, let's just add near and let gcc figure out if it's read-only or not. Please comment on above proposed solutions and also let us know the possibility of acceptance of any of these by FSF. From the above, I think I like this plan: * Add both near and far attributes. If a variable has one of these, it overrides whatever gcc's default is. GCC knows what's read-only and what isn't, and which chips take advantage of which attributes, but there's no reason to burden the user with that decision. * Add an m16c (vs r8c) multilib, and have it default to far constants, near data. Pick up word-alignment too, maybe. This makes the defaults for most chips close to ideal. * Add .ndata, .nbss, .nrodata, .fdata, .fbss, .frodata to the linker scripts. Stuff with near/far attributes goes into .n*/.f* sections. Depending on the chip, these may just get merged with the usual .data, .bss, .rodata sections (i.e. m32c and most r8c will always merge them, most m16c won't merge .rodata, etc). * If we add an m16c multilib, do we want to add an m32c (vs m32cm) multilib at the same time? That would let us use the extra 32-bit insns in libgcc. I'm just thinking, if we're going to change the multilibs anyway, let's use that change to get some other stuff in also.
Re: GCC 4.3.0 Status Report (2007-06-07)
On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote: Joseph S. Myers wrote: On Thu, 7 Jun 2007, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: Do we at this point believe that the people who were working on updating the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now going to have them ready in time? I don't see any evidence that those changes will be ready. I haven't heard of any progress from the volunteer at AMD who was working on that. However, I also think that those changes could go in during Stage 2, if they are ready by then. I've looked at the changes, and I think with a minor bit of abstraction, we can modify the backends so that they don't care how the arguments are implemented. However, I think changing the representation of the arguments is a much more extensive process, and I don't think we should be doing it right now (there are around 220 references to TYPE_ARG_TYPES in the machine independant and front ends parts of the compiler). But it would allow LTO to make these changes on their branch, and be able to slip in to use the backends without further change. Just so people know what I'm talking about, the current function argument types are stored as a linked list, pointed to by TYPE_ARG_TYPES, using TREE_CHAIN nodes. The oldlto branch has changed this to a vector, and added some new functions: num_parm_types -- count the number of arguments nth_parm_types -- return nth argument (as a tree) nth_parm_types_ptr -- like nth_parm_types, but return of tree alloc_parm_types-- allocate n parameters vec_heap2parm_types -- Make a parameter list stdarg_p-- Return true if arg has variable args The backends use the TYPE_ARG_TYPES field in 3 ways: 1) Determine whether the function is a stdarg function 2) Determine whether the function has a prototype 3) Other iteration over the arguments 4) Wants to know if we hit an incomplete type For the first case, I recomend implementing a stdarg_p function in tree.c and change all callers to use it. For the second case, no changes need to be done, since it just tests if TYPE_ARG_TYPES has been allocated. For the third case, it is fairly simple to switch the code to use num_parm_types and nth_parm_types. This will mean a slight degradation in the code that handles arguments (for handling argument n, you need to do n-1 pointer chases). I suspect this is not performance critical code, but if it is, it would be simple to have a macro that does the iteration (ie, for the linked list case, it would do a TREE_CHAIN, and for the LTO case it would increment the counter and use nth_parm_types). I'm not sure what we want to do about case #4. Probably the best way is to provide a macro in the machine idependant portion of the compiler and use it. The backends that are affected are: arm: Has a simple loop to go through the arguments. avr: Wants to know if a function is a variable argument function. c4x: Wants to know if a function is prototyped, and has a simple loop that goes through the arguments. crx: Wants to know if a function is a variable argument function. i386: Wants to know if a function is a variable argument function. Also, the netware, winnt subports wants to know if we have an incomplete type. There is a simple loop. ia64: Wants to know if the function is prototyped. iq2000: Wants to know if a function is a variable argument function. m68k: Wants to know if a function is a variable argument function. mips: Wants to know if the function is prototyped and wants to know if a function is a variable argument function. mn10300: Wants to know if a function is a variable argument function. pa: Wants to know if the function is prototyped and wants to know if a function is a variable argument function. It could also use num_parm_type. som: Wants to know if a function is a variable argument function. rs6000: Wants to know if the function is prototyped and wants to know if a function is a variable argument function. It also has a simple loop to check the arguments that could use nth_parm_type. sh: Wants to know if the function is prototyped. sparc: Wants to know if the function is prototyped. spu-c: Has a simple loop to access the arguments. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Type-punning
Hi,
gcc's docs states that at -fstrict-aliasing:
In particular, an object of one type is assumed never to reside at the
same address as an object of a different type, unless the types are almost
the same.
I have problems with this:
struct A {
float x, y;
};
struct B {
float x, y;
};
int main() {
A a;
B b = reinterpret_castB(a);
}
I get a type-punned warning for this code. However, A B is exactly the
same type. Is the warning appropriate here? Where can I find the
definition of almost the same [type]?
A little more complicated example:
struct A {
float x, y;
};
struct B: public A {
};
struct C: public A {
};
int main() {
B b;
C c = reinterpret_castC(b);
}
I get the same warning, and I even get miscompiled code with -O6 (for a
more complicated code, not for this).
What is the correct way to do this:
void setNaN(float v) {
reinterpret_castint(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
(memcpy works though, but it's not the most efficient solution, I
suppose).
Thanks for your help,
Geza
PS: gcc-4.1, gcc-4.2 produces this. Earlier gcc versions don't produce
warnings for these cases.
Re: Type-punning
This may have been fixed by a recent patch to -Wstrict-aliasing. Let me
try to run the latest version of pre4.3 and will get back to you.
Herman Geza wrote:
Hi,
gcc's docs states that at -fstrict-aliasing:
In particular, an object of one type is assumed never to reside at the
same address as an object of a different type, unless the types are almost
the same.
I have problems with this:
struct A {
float x, y;
};
struct B {
float x, y;
};
int main() {
A a;
B b = reinterpret_castB(a);
}
I get a type-punned warning for this code. However, A B is exactly the
same type. Is the warning appropriate here? Where can I find the
definition of almost the same [type]?
A little more complicated example:
struct A {
float x, y;
};
struct B: public A {
};
struct C: public A {
};
int main() {
B b;
C c = reinterpret_castC(b);
}
I get the same warning, and I even get miscompiled code with -O6 (for a
more complicated code, not for this).
What is the correct way to do this:
void setNaN(float v) {
reinterpret_castint(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
(memcpy works though, but it's not the most efficient solution, I
suppose).
Thanks for your help,
Geza
PS: gcc-4.1, gcc-4.2 produces this. Earlier gcc versions don't produce
warnings for these cases.
Re: class 3 edges
On 6/19/07, Sunzir Deepur [EMAIL PROTECTED] wrote: hello, when I compile with -dv -fdump-rtl-* I somtimes see in the VCG files some edges that have no meaning in the flow of the program. these edges are always green and class 3. what are those edges ? what is their purposes ? thank you sunzir See gcc/graph.c:print_rtl_graph_with_bb(). -- #pragma ident Seongbae Park, compiler, http://seongbae.blogspot.com;
preventing -m options being passed to the compiler
I have a -m option that I am handling in a LIB_SPEC that I do not want passed down to cc1. It seems that by default, the driver passes all -m options to cc1. Is there a way to prevent that on a per-option basis? Thanks, Ben
Re: I'm sorry, but this is unacceptable (union members and ctors)
On 6/16/07, Ross Ridge [EMAIL PROTECTED] wrote: Robert Dewar writes: The only time that it is reasonable to extend is when there are clear signals from the standards committee that it is likely that a feature will be added, in which case there may be an argument for adding the feature prematurely. I completely disagree. Standards should primarily standardize existing practice, not inventing new features. That is one view. The other view is that standards can push the state of the art in programming. The Ada standard is a pure example of the latter approach. In practice, both C and C++ have been a mix of existing practice and invention. I think purity in approach is actually suboptimal. New features should be created by people who actually want and will use the features, not by some disinterested committee. The C++ standards committee consists of volunteers that actually want and will use the features. There is too much sheer work and negotiation involved in the standards process to not be interested. GCC has always been a place for experimenting with new features. Many of the new features in C99 had already been implemented in GCC. Even in the cases where C99 standardized features differently, I think both GCC and Standard C benefited from the work done in GCC. All true. What the standards process buys you is more review by a wider variety of stakeholders. The result is generally something that more folks can use. On the specific topic of unions, there is a proposal before the committee to extend unions in this direction. Let me caution you that this proposal has not been reviewed by a significant fraction of the committee, and hence has a small chance of being accepted and an even smaller chance of surviving unchanged. See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2248.html -- Lawrence Crowl
Re: I'm sorry, but this is unacceptable (union members and ctors)
Lawrence Crowl writes: On the specific topic of unions, there is a proposal before the committee to extend unions in this direction. Let me caution you that this proposal has not been reviewed by a significant fraction of the committee, and hence has a small chance of being accepted and an even smaller chance of surviving unchanged. This only supports my position. If an active comittee member can't get their proposal reviewed by a significant fraction of the committee, then why should an outsider even bother? You're better off posting a patch to gcc-patches, at least that will have a chance of being seriously considered. Ross Ridge
Re: preventing -m options being passed to the compiler
On Wed, 2007-06-20 at 10:44 +1000, Ben Elliston wrote: I have a -m option that I am handling in a LIB_SPEC that I do not want passed down to cc1. It seems that by default, the driver passes all -m options to cc1. Is there a way to prevent that on a per-option basis? To now answer my own question (for the benefit of others): the CC1_SPEC string can include the sequence %moption* to strip those options from the command line. Ben
Re: GCC 4.3.0 Status Report (2007-06-07)
Michael Meissner wrote:
I've looked at the changes, and I think with a minor bit of abstraction, we
can
modify the backends so that they don't care how the arguments are implemented.
Thanks for working on this!
However, I think changing the representation of the arguments is a much more
extensive process, and I don't think we should be doing it right now (there
are
around 220 references to TYPE_ARG_TYPES in the machine independant and front
ends parts of the compiler). But it would allow LTO to make these changes on
their branch, and be able to slip in to use the backends without further
change.
I think we want to avoid making the same mistake we did last time:
mixing these changes up with LTO. They will help LTO (by reducing
memory use), but they're logically independent. So, if we're not
comfortable putting the changes on the mainline, they should go on some
new branch.
I agree that introducing the abstractions first, and then switching the
implementation afterwards, is a good idea. That's what Sandra did for
CALL_EXPRs and it worked well. However:
For the third case, it is fairly simple to switch the code to use
num_parm_types and nth_parm_types. This will mean a slight degradation in the
code that handles arguments (for handling argument n, you need to do n-1
pointer chases).
I don't think we can do this on mainline. That's introducing
quadradicity, and someone will have a 100-argument function, and then
we'll be sad. So, I think we need to do something different. One
possibility is:
FOR_EACH_ARG_TYPE(fn_type, arg_type)
{
}
which expands today to something like:
for (arg_iter = TYPE_ARG_TYPES (fn_type),
arg_type = arg_iter ? TREE_VALUE (arg_iter) : NULL_TREE;
arg_iter;
arg_iter = TREE_CHAIN (arg_iter),
arg_type = arg_iter ? TREE_VALUE (arg_iter) : NULL_TREE)
and, later to something like:
for (arg_indx = 0, arg_type = nth_parm_type (fn_type, arg_index);
arg_indx != num_parm_types (fn_type);
++arg_indx)
Then, in both cases, the code can use arg_type in the body of the loop.
I think some of the abstractions, like stdarg_p and prototyped_p, are
unquestionably a good thing, and ought to go in forthwith. That will
reduce the number of places TYPE_ARG_TYPES is used directly. And, we
don't have to create a branch to do that part. So, I'd suggest
preparing patches against mainline for those bits. How does that sound?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: virtual stack regs.
ARG_POINTER_REGNUM is included in the artificial defs of all blocks (which I think is overly conservative - just having them in the entry block def should be enough). Hence, from dataflow point of view, they are always considered initialized. I think we should probably do something similar for VIRTUAL_STACK_*_REGNUM. I think we should assert that we don't find virtual regs in dataflow, instead. Paolo
libgcc fails to compile if DItype is not supported [bswapdi2]
Hello, Current function declaration of __bswapdi2 in libgcc2.h is: DItype __bswapdi2 (DItype u) Since this declaration does not check if DItype is supported, it is bound for compilation failure for targets that do not support DItype. Would it be ok to change the DItype to DWtype as in: DWtype __bswapdi2 (DWtype u) Is the above declaration more safer for all targets? Please advice, Thanks, Pompa Pompapathi V Gadad CR Tool Chain Team National Semiconductor Corporation
[Bug c/32399] ICE in build2_stat, at tree.c:3074
--- Comment #1 from marcus at jet dot franken dot de 2007-06-19 06:24 --- Created an attachment (id=13734) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13734action=view) vertexbuffer.i gcc -O2 -c vertexbuffer.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug c/32399] New: ICE in build2_stat, at tree.c:3074
new regression, likely caused by pointer-plus branch merge extracted from Wine /home/marcus/projects/gcc/BIN/bin/gcc -m32 -O2 -c vertexbuffer.i vertexbuffer.i: In function 'f': vertexbuffer.i:1: internal compiler error: in build2_stat, at tree.c:3074 -- Summary: ICE in build2_stat, at tree.c:3074 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
--- Comment #4 from tbm at cyrius dot com 2007-06-19 06:39 --- (In reply to comment #3) I tested the patch on IA64 HP-UX and Linux and verified that it fixed the bug and caused no regressions. Jim, do you want to check this patch in? Given that Jim hasn't answered yet, maybe you can commit the patch yourself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug c++/32368] warnings from system headers not supressed.
--- Comment #3 from pluto at agmk dot net 2007-06-19 06:44 --- (In reply to comment #2) At variance with c++/32256, this one apparently happens as C code too... Probably should be not categorized as C++-only... these little bugs (PR32368, PR32256) are treated as blockers by people having `-Wall -Werror` in theirs projects. could we fix this issue easily and quickly in 4.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32368
[Bug c/21920] aliasing violations
--- Comment #115 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 --- *** Bug 32397 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rosenfeld at grumpf dot ||hope-2000 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/32397] wrong instruction order generated
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 --- ((Cyg_libm_ieee_double_shape_type *)x)-part is ovbiously an aliasing violation. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32397
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:10 --- This is caused by two things, jump threading and inlining. If we jump thread more, we no longer get the warning which is what you are seeing in 4.2.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug middle-end/32399] ICE in build2_stat, at tree.c:3074
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:21 --- This is IV-opts going funny I think as we get pointer+pointer (and yes real pointer SSA_NAMES and no casts). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-19 08:26 ---
This code itself is very weird and I don't know if it is really defined or not.
We have basically:
char *f(char *a, char *b)
{
return a + (int)b;
}
How can that even be defined.
Anyways the following fixes the problem:
Index: tree-ssa-address.c
===
--- tree-ssa-address.c (revision 125776)
+++ tree-ssa-address.c (working copy)
@@ -423,9 +423,9 @@
/* Add ELT to base. */
type = TREE_TYPE (parts-base);
- parts-base = fold_build2 (PLUS_EXPR, type,
+ parts-base = fold_build2 (POINTER_PLUS_EXPR, type,
parts-base,
-fold_convert (type, elt));
+fold_convert (sizetype, elt));
}
/* Finds the most expensive multiplication in ADDR that can be
Though I have not tested it at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-06-19 08:26:50
date||
Summary|ICE in build2_stat, at |[4.3 Regression] ICE in
|tree.c:3074 |build2_stat, at tree.c:3074
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #97 from pinskia at gcc dot gnu dot org 2007-06-19 08:11 --- *** Bug 32391 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sunjoong at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-19 08:11 --- So this is just a dup of bug 323 so closing as such. *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #5 from ubizjak at gmail dot com 2007-06-19 08:27 ---
(In reply to comment #4)
No, this one is caused by dataflow.
Dataflow uncovered generic middle-end (RTL?) problem:
We have this comment in instantiate_virutal_regs():
/* Scan through all the insns, instantiating every virtual register still
present. */
for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
{
/* These patterns in the instruction stream can never be recognized.
Fortunately, they shouldn't contain virtual registers either. */
if (GET_CODE (PATTERN (insn)) == USE
|| GET_CODE (PATTERN (insn)) == CLOBBER
|| GET_CODE (PATTERN (insn)) == ADDR_VEC
|| GET_CODE (PATTERN (insn)) == ADDR_DIFF_VEC
|| GET_CODE (PATTERN (insn)) == ASM_INPUT)
continue;
instantiate_virtual_regs_in_insn (insn);
However, for reduced testcase we generate following creative sequence to put
*.LC0 into virtual-outgoing-args and 0 into virtual-outgoing-args+8 (these are
sections[0] values):
;; f (stderr, [0], [0], conf_name, 0, sections[0])
(insn 6 5 7 pr32374.c:13 (clobber (mem/s/c:BLK (plus:DI (reg/f:DI 54
virtual-stack-vars)
(const_int -16 [0xfff0])) [5 A128])) -1 (nil))
(insn 7 6 8 pr32374.c:13 (set (mem/s/c:DI (plus:DI (reg/f:DI 54
virtual-stack-vars)
(const_int -16 [0xfff0])) [4 S8 A128])
(symbol_ref/f:DI (*.LC0) [flags 0x2] string_cst 0xb7cf1498)) -1
(nil))
(insn 8 7 9 pr32374.c:13 (set (mem/s/c:SI (plus:DI (reg/f:DI 54
virtual-stack-vars)
(const_int -8 [0xfff8])) [3 S4 A64])
(const_int 0 [0x0])) -1 (nil))
(insn 9 8 10 pr32374.c:13 (set (reg:DI 59)
(mem/s/c:DI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [5 S8 A128])) -1 (nil))
(insn 10 9 11 pr32374.c:13 (set (mem:DI (reg/f:DI 56 virtual-outgoing-args) [0
S8 A64])
(reg:DI 59)) -1 (nil))
(insn 11 10 12 pr32374.c:13 (set (reg:DI 60)
(mem/s/c:DI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -8 [0xfff8])) [5 S8 A64])) -1 (nil))
(insn 12 11 13 pr32374.c:13 (set (mem:DI (plus:DI (reg/f:DI 56
virtual-outgoing-args)
(const_int 8 [0x8])) [0 S8 A64])
(reg:DI 60)) -1 (nil))
Putting a break on emit_insn_raw, we can backtrack where (invalid!) clobber is
generated:
#0 make_insn_raw (pattern=0xb7d0ad00) at
../../gcc-svn/trunk/gcc/emit-rtl.c:3312
#1 0x081861c2 in emit_insn (x=0xb7d0ad00) at
../../gcc-svn/trunk/gcc/emit-rtl.c:4347
#2 0x081a9821 in store_constructor (exp=0xb7d63dc8, target=0xb7d4f768,
cleared=0, size=16) at ../../gcc-svn/trunk/gcc/expr.c:5066
#3 0x081aee5b in expand_expr_real_1 (exp=0x11, target=0xb7d4f768,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:7310
#4 0x081bf7cc in expand_expr_real (exp=0xb7d63dc8, target=0xb7d4f6f0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:6862
#5 0x081bf9b6 in expand_expr (exp=0x11, target=0xb7d0ad00, mode=VOIDmode,
modifier=EXPAND_STACK_PARM) at ../../gcc-svn/trunk/gcc/expr.h:504
#6 0x081bd4c4 in expand_expr_real_1 (exp=0xb7ca3058, target=0xb7d4f6f0,
tmode=dwarf2_read_address: Corrupted DWARF expression.
) at ../../gcc-svn/trunk/gcc/expr.c:7455
#7 0x081bf7cc in expand_expr_real (exp=0xb7ca3058, target=0xb7d4f6f0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:6862
#8 0x08115bd1 in store_one_arg (arg=0xbf96e8f0, argblock=0xb7c9c070, flags=0,
variable_size=0, reg_parm_stack_space=0) at ../../gcc-svn/trunk/gcc/expr.h:504
#9 0x0811ad60 in expand_call (exp=0xb7d5a240, target=0x0, ignore=1) at
../../gcc-svn/trunk/gcc/calls.c:2654
It can be tracked from expand_call() down to expr.c:7303, where we re-assign
target to virtual-stack-vars in this highly suspicious part of code (Irix 6?):
else
{
/* Handle calls that pass values in multiple non-contiguous
locations. The Irix 6 ABI has examples of this. */
if (target == 0 || ! safe_from_p (target, exp, 1)
|| GET_CODE (target) == PARALLEL
|| modifier == EXPAND_STACK_PARM)
target
= assign_temp (build_qualified_type (type,
(TYPE_QUALS (type)
| (TREE_READONLY (exp)
* TYPE_QUAL_CONST))),
0, TREE_ADDRESSABLE (exp), 1);
store_constructor (exp, target, 0, int_expr_size (exp));
return target;
}
Just before the call to store_constructor, we have:
p debug_rtx (target)
(mem/s/c:BLK (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [5 A128])
and in
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #6 from ubizjak at gmail dot com 2007-06-19 08:58 --- FWIW, this shoot-in-the-dark patch fixes ICE: Index: expr.c === --- expr.c (revision 125789) +++ expr.c (working copy) @@ -5062,8 +5062,10 @@ store_constructor (tree exp, rtx target, cleared = 1; } +#if 0 if (! cleared) emit_insn (gen_rtx_CLOBBER (VOIDmode, target)); +#endif /* Store each element of the constructor into the corresponding field of TARGET. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-19 09:08 --- Subject: Bug 32353 Author: jakub Date: Tue Jun 19 09:08:39 2007 New Revision: 125841 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125841 Log: PR tree-optimization/32353 * tree-ssa-structalias.c (set_uids_in_ptset): Also handle RESULT_DECL. * g++.dg/opt/nrv13.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/nrv13.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-19 09:11 --- Subject: Bug 32353 Author: jakub Date: Tue Jun 19 09:11:22 2007 New Revision: 125842 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125842 Log: PR tree-optimization/32353 * tree-ssa-structalias.c (set_uids_in_ptset): Also handle RESULT_DECL. * g++.dg/opt/nrv13.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/nrv13.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug target/32392] Support using -mrecip w/o additional Newton-Raphson run
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-19 09:15 --- Confirmed. For 2 NR steps to reach double precision (we'd miss it by some more ulps than the 2.5 for float precision) we would need to do at least the second NR in double precision. Note that this would make sense only for double precision input values that are exactly representable in float precision (otherwise, why the extra precision?). So practically not worth it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-19 09:15:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32392
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-19 09:17 --- The testcase indeed looks undefined (but valid). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-19 09:18 --- Subject: Bug 32353 Author: jakub Date: Tue Jun 19 09:18:13 2007 New Revision: 125843 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125843 Log: PR tree-optimization/32353 * tree-ssa-structalias.c (set_uids_in_ptset): Also handle RESULT_DECL. * g++.dg/opt/nrv13.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/nrv13.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-19 09:19 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #43 from rguenth at gcc dot gnu dot org 2007-06-19 09:24 --- Subject: Bug 30252 Author: rguenth Date: Tue Jun 19 09:24:35 2007 New Revision: 125844 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125844 Log: 2007-06-19 Richard Guenther [EMAIL PROTECTED] Michael Matz [EMAIL PROTECTED] PR tree-optimization/30252 * tree-ssa-structalias.c (solution_set_add): Make sure to preserve all relevant vars. (handle_ptr_arith): Make sure to only handle positive offsets. (push_fields_onto_fieldstack): Create fields for empty bases. * g++.dg/opt/pr30252.C: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/pr30252.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug target/31152] -(xy) generates wrong code
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-06-19 09:41 --- Confirmed. This is a bug in the negscc pattern in arm.md. It's only been there since 1994! -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-19 09:41:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #44 from rguenth at gcc dot gnu dot org 2007-06-19 09:45 --- Fixed on the 4.2 branch. Danny will fix this in a different way on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug c/32397] wrong instruction order generated
--- Comment #2 from rosenfeld at grumpf dot hope-2000 dot org 2007-06-19 10:52 --- Subject: Re: wrong instruction order generated On Tue, Jun 19, 2007 at 07:56:01AM -, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 --- ((Cyg_libm_ieee_double_shape_type *)x)-part is ovbiously an aliasing violation. I doubt that. As you can see in the source file, x is a double and Cyg_libm_ieee_double_shape_type is a union containing a double. To quote the standard, 7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types: a type compatible with the effective type of the object, [...] an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union) [...] So as far as I understand this should be perfectly legal by the ISO C standard. Maybe I'm missing somthing here, I read everywhere that using a union for this kind of thing is a gcc extension. I wonder, if there is no standard way to manipulate doubles by treating them as ints or bitfields or something like that, how is one supposed to write a floating point emulator in ISO C? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32397
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-19 11:16 --- Subject: Bug 31950 Author: rguenth Date: Tue Jun 19 11:16:43 2007 New Revision: 125846 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125846 Log: 2007-06-19 Richard Guenther [EMAIL PROTECTED] PR middle-end/31950 * tree-ssa-alias-warnings.c (ffan_walker): Punt on MTAGs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias-warnings.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-06-19 11:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug c/32397] wrong instruction order generated
--- Comment #3 from rask at sygehus dot dk 2007-06-19 11:27 --- You can use memcpy (int, float, min (sizeof (int), sizeof (float))) and vice versa. I suppose you can also memcpy() into or out of a char array of the right size. If you were to use the GCC extension of using a union, it would look something like this: double x; cyg_uint32 hx, lx; Cyg_libm_ieee_double_shape_type tmp; tmp.value = x; hx = tmp.parts.msw lx = tmp.parts.lsw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32397
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #7 from ubizjak at gmail dot com 2007-06-19 11:54 --- Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug c++/32400] New: [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
svn snapshot from r125847 -- Summary: [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jojelino at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #1 from jojelino at gmail dot com 2007-06-19 12:10 --- Created an attachment (id=13735) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13735action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #10 from dominiq at lps dot ens dot fr 2007-06-19 12:48 --- Even the code in comment #8 is invalid: several variables are used but not set: at least intp and sum. If I set them to 0, gfortran gives the same results with or without -O3. (tests done on PPC Darwin7). In my opinion the bug is invalid, but I'll let others make the final call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug middle-end/32401] New: [PPC/Altivec] Non optimal code structure with -mabi=altivec
With altivec enabled gcc prepares additional space on the stack. Unlike earlier
versions gcc 4.3 removes stack modification instructions if it isn't used. With
just -maltivec or with -mabi=altivec when altivec isn't used it works very
well. But with -mabi=altivec and altivec used gcc produces code with stucture
similar to one produced by eariler gcc versions with just stack modification
instructions removed. Seems like stack isn't optimized early enough.
This simple code:
void
test ( int len )
{
if (len) {
vector unsigned char vSetTo = {};
asm volatile ( : : v (vSetTo) ); /* do something */
}
}
gcc-4.3 -O2 -maltivec -mregnames test.c -S produces:
test:
cmpwi %cr7,%r3,0
beqlr- %cr7
vxor %v0,%v0,%v0
blr
while gcc-4.3 -O2 -maltivec -mabi=altivec -mregnames test.c -S produces:
test:
cmpwi %cr7,%r3,0
beq- %cr7,.L3 # -- should be beqlr
vxor %v0,%v0,%v0
.L3:
blr
The letter one has same structure as produced by earlier gcc versions, but
without stack modification instructions:
gcc 4.1.3 produces:
test:
cmpwi %cr7,%r3,0
stwu %r1,-16(%r1)
vxor %v0,%v0,%v0
beq- %cr7,.L4
.L4:
addi %r1,%r1,16
blr
--
Summary: [PPC/Altivec] Non optimal code structure with -
mabi=altivec
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sparky at pld-linux dot org
GCC build triplet: powerpc*-linux
GCC host triplet: powerpc*-linux
GCC target triplet: powerpc*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32401
[Bug c++/32402] New: Error while allocating array of pointers to objects of a pure virtual class
The compiler thinks we're allocating the actual abstract objects instead of an
array of pointers and reports the following error: cannot allocate an object
of abstract type '...'. Since we're actual allocating an array of pointers,
this should not be an error.
The following code (reproduce.cpp) demonstrates the problem:
class pure
{
public:
pure() {}
virtual bool isPure () = 0;
};
class notPure : public pure
{
public:
notPure() {}
virtual bool isPure () { return false; };
};
int main ()
{
pure ** list;
list = new (pure (*[3]));
for (int i = 0; i 3; i ++) {
list [i] = new notPure();
}
}
The error is reported on line 18 list = new (pure (*[3]));.
gcc -v results in:
Using built-in specs.
Target: i686-linux
Configured with: ../gcc-4.1.1/configure
--prefix=/p/TargetPlatforms/x86-Linux-cdk/cross-gcc/build/tools
--target=i686-linux --build=i686-pc-mingw32 --host=i686-pc-mingw32
--disable-multilib
--with-local-prefix=/p/TargetPlatforms/x86-Linux-cdk/cross-gcc/build/tools
--with-system-zlib --disable-libunwind-exceptions --disable-nls --enable-shared
--enable-languages=c,c++ --enable-__cxa_atexit --enable-c99 --enable-long-long
--enable-threads=posix --enable-win32-registry=oce-gcc4.1.1-glibc2.5
Thread model: posix
gcc version 4.1.1
We're cross compiling from Windows to Linux.
The command line is very basic: gcc reproduce.cpp
This results in the following compiler output:
reproduce.cpp: In function 'int main()':
reproduce.cpp:18: error: cannot allocate an object of abstract type 'pure'
reproduce.cpp:2: note: because the following virtual functions are pure
within 'pure':
reproduce.cpp:5: note: virtual bool pure::isPure()
The preprocessed file looks as follows:
# 1 reproduce.cpp
# 1 built-in
# 1 command line
# 1 reproduce.cpp
class pure
{
public:
pure() {}
virtual bool isPure () = 0;
};
class notPure : public pure
{
public:
notPure() {}
virtual bool isPure () { return false; };
};
int main ()
{
pure ** list;
list = new (pure (*[3]));
for (int i = 0; i 3; i ++) {
list [i] = new notPure();
}
}
--
Summary: Error while allocating array of pointers to objects of a
pure virtual class
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: p dot vestjens at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #1 from p dot vestjens at gmail dot com 2007-06-19 14:47 --- Created an attachment (id=13736) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13736action=view) Sourcefile demonstrating the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug pending/32403] New:
NOTE: Defaulting component because reported component no longer exists Environment: System: Linux marko2 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007 i686 GNU/Linux Architecture: i686 host: i486-pc-linux-gnu build: i486-pc-linux-gnu target: m68hc11-unknown-none configured with: ../src/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --with-gnu-as --with-gnu-ld --enable-nls --without-included-gettext --disable-checking --enable-languages=c --build=i486-linux-gnu --host=i486-linux-gnu --target=m68hc11 --without-headers How-To-Repeat: When reporting a compiler error, preprocessor output mu how to correct or work around the problem, if known (multiple lines) -- Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marko at localhost dot localhost GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: m68hc11-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32403
[Bug fortran/32404] New: Wrong-code with sbdart (valgrind errors, different output)
Spin off from PR 32236. ftp://ftp.icess.ucsb.edu/pub/esrg/sbdart/sbdart_2.4.tar.gz (33181 lines of code) Unpack source and do: - Delete in tauaero.f:1601 the line data wlbaer/0.,0./ - Insert around drt.f:951 the lines weq = 0.0_kr wfull = 0.0_kr If one compiles (-O0) the program with g95, sunf95, ifort and gfortran (4.1.3, 4.2.0, 4.3) and compares the output, one finds (drf.f, subroutine stdout1): - sunf95, ifort and g95 produce identical output except for the 7th column - gfortran's output differs also in the 7th column, but starting from some row it also differs in the 4th column; the results for the 4th column are different depending on the gfortran version A possible reason might be that some variable has not been initialized, however, using ifort -check all I could only find the two problems above (weq, wfull) and g95 and g95 -freal=nan -flogical=true -finteger=123456 -pointer=invalid give the same result. Some further debugging (in drf.f's stdout1) shows that topup - or more precisely flup(ntop) - diverges at some point. flup is set via DISORT (disort.f). Both g95 and gfortran show quite a lot of uninitialized warnings in valgrind (over 30), ifort only shows two, sunf95 four. -- Summary: Wrong-code with sbdart (valgrind errors, different output) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code 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=32404
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #8 from burnus at gcc dot gnu dot org 2007-06-19 15:30 --- Bob, Can you please tell me why the compiler flags tauaero.f:1517 while the problem seems to be associated with the data statement at line 1601? The line number shown when an internal compiler error occurs is often not reliably; often something goes wrong at one place, but this is only triggered when the compiler is at a completely different place. I found the line using other compilers; but also the brand-new error message of the gfortran 4.3 compiler shows now: tauaero.f:1601.17: data wlbaer/0.,0./ 1 tauaero.f:1587.21: wlbaer(2)=0., 2 Error: 'wlbaer' at (1) already is initialized at (2) Thus either =0. in line 1587 or data wlbaer/0.,0./ needs to be removed. I have tried your suggestion (commenting out the data statement), but the code does not appear to work correctly with this modification. I miss a good test case. If you have one, I'm really interested. However, I found some divergence in the output compared with other compilers, see PR 32404. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug pending/32403] foo
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-19 16:02 --- blah -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary||foo http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32403
[Bug target/32369] [frv] macro DF_LIVE_IN passed 2 arguments, but takes just 1
--- Comment #4 from rask at gcc dot gnu dot org 2007-06-19 16:30 --- Subject: Bug 32369 Author: rask Date: Tue Jun 19 16:30:03 2007 New Revision: 125851 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125851 Log: 2007-06-19 Rask Ingemann Lambertsen [EMAIL PROTECTED] PR target/32369 * config/frv/frv.c (frv_ifcvt_modify_tests): Dataflow merge fix. (frv_ifcvt_modify_insn): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/frv/frv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32369
[Bug fortran/20863] [4.2 only] Pointer problems in PURE procedures
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:30 --- Tobias points out to me that this is not a regression - closed and out. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863
[Bug target/20082] unrecognizable insn
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:32 --- Sorry for my screw-up on the PR number - it was 20882 that was fixed. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20082
[Bug fortran/20882] [4.2 only] PURE procedure containing pointer assignment to dummy with pointer component
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-19 16:32 --- This is not a regression, so that is it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20882
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #14 from daney at gcc dot gnu dot org 2007-06-19 16:36 --- Subject: Bug 32313 Author: daney Date: Tue Jun 19 16:36:42 2007 New Revision: 125852 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125852 Log: PR target/32313 * config/mips/mips.md (cprestore): Mark $gp as used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #15 from daney at gcc dot gnu dot org 2007-06-19 16:43 --- The second time is the charm. There are still regressions caused by the dataflow merge, but at least we can bootstrap now. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #9 from pault at gcc dot gnu dot org 2007-06-19 16:44 --- This is not a regression so no backport. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #13 from rob1weld at aol dot com 2007-06-19 17:11 ---
The goal of the tests is not to measure some time, but to check that
intervals are properly ordered, i.e., t1=dat1=t1a and t2a=dat2-dat1= t2.
If that is the goal then could we eliminate all influence of time (midnight /
leap seconds / end of year, and whatever random issues occur) by using a
procedure similar to what is described in:
gcc-4_3-trunk/libmudflap/testsuite/lib/mfdg.exp ?
# Indicate that this test case is to be rerun several times. This
# is useful if it is nondeterministic. This applies to rerunning the
# test program only, not rebuilding it.
# The embedded format is { dg-repetitions N }, where N is the number
# of repetitions. It better be greater than zero.
#
proc dg-repetitions { line value } {
upvar dg-repetitions repetitions
set repetitions $value
}
#
# Indicate that this test case is to be run with a short timeout.
# The embedded format is { dg-timeout N }, where N is in seconds.
#
proc dg-timeout { line value } {
global dg-timeout
set dg-timeout $value
}
# dejagnu's config/unix.exp hard-codes 300 seconds as the timeout
# for any natively run executable. That's too long for tests run
# multiple times and that may possibly hang. So we override it here
# to provide some degree of control.
We could run the test 5 times and if we got at least one pass we could write
PASS: and use WARNING: to write the number of failures. If we get 5
failures then we just write FAIL:.
The last time I ran make -i check I got a pass on this test, the time before
a fail; previously it's been hit and miss. The above technique will catch
random failures better and avoid false positives.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 --- (In reply to comment #10) Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. That *only* applies to register variables, not stack variables. We very very much want to preserve scope of stack variables, because we very very much want to share stack space between stack variables of different scopes. Failure to do so causes bad interactions with inlining, and causes stack space consumtion to grow to unacceptable levels. I.e. you can't build kernels anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #9 from rask at gcc dot gnu dot org 2007-06-19 17:35 --- Subject: Bug 32335 Author: rask Date: Tue Jun 19 17:35:16 2007 New Revision: 125853 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125853 Log: 2007-06-19 Rask Ingemann Lambertsen [EMAIL PROTECTED] PR target/32335 * config/m32c/m32c.c: Include dataflow header file. (m32c_emit_prologue): Adjust for prologue insn change. * config/m32c/prologue.md (prologue_enter_16): Only modify SP_REGNO once inside a PARALLEL. Assume frame size passed in operand 0 includes space to save the fb register. (prologue_enter_24): Likewise. (epilogue_exitd): Only modify SP_REGNO once inside a PARALLEL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32c/m32c.c trunk/gcc/config/m32c/prologue.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #27 from dnovillo at google dot com 2007-06-19 17:39 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 6/19/07 1:26 PM, rth at gcc dot gnu dot org wrote: --- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 --- (In reply to comment #10) Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. That *only* applies to register variables, not stack variables. Yes, but our GIMPLE optimizers don't know that and we do not have a way of enforcing that in GIMPLE. There just are no scope boundaries in the SSA web. So, the end result is that in SSA we only have function scope. We very very much want to preserve scope of stack variables, because we very very much want to share stack space between stack variables of different scopes. Failure to do so causes bad interactions with inlining, and causes stack space consumtion to grow to unacceptable levels. I.e. you can't build kernels anymore. Agreed. We have to find a way of either tying the hands of code motion transformations by making them use the SSA web *and* the TREE_BLOCKs, or make stack slot sharing aware of live ranges. Right now we have the unfortunate situation that an optimizer is making a valid transformation which breaks the scope assumption that stack sharing uses. I am not sure if it would be practical to force code motion optimizations to use anything other than the SSA web to do their analysis. Perhaps we could force scopes by building barriers on the SSA web itself (say, by putting PHI nodes at scope boundaries, or something). Alternatively, we could incorporate live-range analysis to stack slot sharing. That way, if code motion creates undue stack slot pressure, we would merely emit suboptimal code, instead of wrong code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug rtl-optimization/32405] New: assertion failure in loop-iv.c; probable dataflow regression
The following 2 testcases began failing for an xtensa-elf target when the
dataflow branch was merged:
gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c
Both tests fail at -O3 with internal compiler error: in get_biv_step,
at loop-iv.c:792. Neither the Xtensa port nor the loop-iv.c code
changed at the time of the regression in a way that obviously affects this. I'm
suspecting it is somehow related to the dataflow merge.
Here is what appears to be happening for 930921-1.c. The test program is:
f (x)
unsigned x;
{
return (unsigned) (((unsigned long long) x * 0xAAAB) 32) 1;
}
main ()
{
unsigned i;
for (i = 0; i 1; i++)
if (f (i) != i / 3)
abort ();
exit (0);
}
At -O3, function f is inlined into main and x * 0xAAAB is recognized as
a DImode induction variable. I'm pretty sure the problem is related
to the lack of an adddi3 pattern in xtensa.md. We rely on optabs.c to
expand DImode addition. If I dump the RTL file, the induction
variable increment looks like:
;; ivtmp$55 = ivtmp$55 + 0x0aaab
(insn 26 25 27 930921-1.c:4 (set (reg:DI 50)
(mem/u/c/i:DI (symbol_ref/u:SI (*.LC1) [flags 0x2]) [2 S8 A64])) -1
(expr_list:REG_EQUAL (const_double -1431655765 [0xaaab] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0] 0 [0x0])
(nil)))
(insn 27 26 28 930921-1.c:4 (clobber (reg:DI 51)) -1 (nil))
(insn 28 27 29 930921-1.c:4 (set (subreg:SI (reg:DI 51) 4)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4)
(subreg:SI (reg:DI 50) 4))) -1 (nil))
(insn 29 28 30 930921-1.c:4 (set (reg:SI 52)
(const_int 1 [0x1])) -1 (nil))
(jump_insn 30 29 31 930921-1.c:4 (set (pc)
(if_then_else (ltu (subreg:SI (reg:DI 51) 4)
(subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4))
(label_ref 32)
(pc))) -1 (nil))
(insn 31 30 32 930921-1.c:4 (set (reg:SI 52)
(const_int 0 [0x0])) -1 (nil))
(code_label 32 31 33 6 [0 uses])
(insn 33 32 34 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 0)
(subreg:SI (reg:DI 50) 0))) -1 (nil))
(insn 34 33 35 930921-1.c:4 (set (reg:SI 53)
(plus:SI (reg:SI 52)
(subreg:SI (reg:DI 51) 0))) -1 (nil))
(insn 35 34 36 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(reg:SI 53)) -1 (nil))
(insn 36 35 0 930921-1.c:4 (set (reg:DI 45 [ ivtmp$55 ])
(reg:DI 51)) -1 (expr_list:REG_EQUAL (plus:DI (reg:DI 45 [ ivtmp$55 ])
(reg:DI 50))
(nil)))
The failing assertion in get_biv_step() is:
gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
The outer_mode is DImode; the inner_mode is SImode; and extend is
UNKNOWN, since there are no SIGN_EXTEND or ZERO_EXTEND operations
involved here. Is this code intended to work for DImode IVs when
the machine doesn't directly support DImode operations? I don't know
if the problem is in this loop-iv.c code or whether it ought not
recognize the DImode induction variable in the first place.
--
Summary: assertion failure in loop-iv.c; probable dataflow
regression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bwilson at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: xtensa-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405
[Bug target/32406] New: [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
Build from svn r125825 with:
http://gcc.gnu.org/viewcvs?view=revrevision=125852
applied.
Configured: ../trunk/configure --target=mipsel-linux
--with-sysroot=/usr/local/mipsel-linux-test
--prefix=/usr/local/mipsel-linux-test --with-arch=mips32 --with-float=soft
--disable-java-awt --without-x --disable-tls --enable-__cxa_atexit
--disable-jvmpi --disable-libmudflap --enable-languages=c,c++
gcc.c-torture/execute/nestfunc-6.c is FAILing at -O2, -O3, and -Os. This is a
regression from:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00546.html
This is the test case:
---
typedef __SIZE_TYPE__ size_t;
extern void abort (void);
extern void exit (int);
extern void qsort(void *, size_t, size_t, int (*)(const void *, const void *));
int main ()
{
__label__ nonlocal;
int compare (const void *a, const void *b)
{
goto nonlocal;
}
char array[3];
qsort (array, 3, 1, compare);
abort ();
nonlocal:
exit (0);
}
Here is the generated assembly:
/home/daney/gccsvn/mipsel-trunk/gcc/xgcc
-B/home/daney/gccsvn/mipsel-trunk/gcc/ -O3 -S nestfunc-6.c
---
.file 1 nestfunc-6.c
.section .mdebug.abi32
.previous
.abicalls
.rdata
.align 2
$LTRAMP0:
.word 0x03e00821 # move $1,$31
.word 0x04110001 # bgezal $0,.+8
.word 0x # nop
.word 0x8fe30014 # lw $3,20($31)
.word 0x8fe20018 # lw $2,24($31)
.word 0x0060c821 # move $25,$3
.word 0x0068 # jr $3
.word 0x0020f821 # move $31,$1
.word 0x # function address
.word 0x # static chain value
.globl _flush_cache
.text
.align 2
.globl main
.entmain
.type main, @function
main:
.frame $sp,96,$31 # vars= 64, regs= 2/0, args= 16, gp= 8
.mask 0xc000,-4
.fmask 0x,0
.setnoreorder
.setnomacro
lui $28,%hi(__gnu_local_gp)
addiu $sp,$sp,-96
addiu $28,$28,%lo(__gnu_local_gp)
sw $31,92($sp)
sw $fp,88($sp)
.cprestore 16
lui $2,%hi($LTRAMP0)
addiu $6,$2,%lo($LTRAMP0)
addiu $3,$sp,40
addiu $2,$sp,24
sw $2,84($sp)
sw $3,80($sp)
sw $2,28($sp)
sw $sp,32($sp)
move$7,$3
addiu $8,$6,32
$L2:
lw $2,0($6)
lw $3,4($6)
lw $4,8($6)
lw $5,12($6)
addiu $6,$6,16
sw $2,0($7)
sw $3,4($7)
sw $4,8($7)
sw $5,12($7)
bne $6,$8,$L2
addiu $7,$7,16
lw $2,4($6)
lw $4,0($6)
sw $2,4($7)
sw $4,0($7)
lw $2,80($sp)
lui $3,%hi(compare.1584)
addiu $3,$3,%lo(compare.1584)
sw $3,32($2)
lw $3,80($sp)
addiu $2,$sp,28
sw $2,36($3)
lw $25,%call16(_flush_cache)($28)
lw $4,80($sp)
li $5,40 # 0x28
jalr$25
li $6,3# 0x3
lw $28,16($sp)
lw $4,84($sp)
lw $25,%call16(qsort)($28)
lw $7,80($sp)
li $5,3# 0x3
jalr$25
li $6,1# 0x1
lw $28,16($sp)
lw $25,%call16(abort)($28)
jalr$25
nop
$L3:
$L4:
lw $25,%call16(exit)($28)
jalr$25
move$4,$0
.setmacro
.setreorder
.endmain
.align 2
.entcompare.1584
.type compare.1584, @function
compare.1584:
.frame $fp,8,$31 # vars= 0, regs= 1/0, args= 0, gp= 0
.mask 0x4000,-8
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-8
sw $fp,0($sp)
lw $fp,0($2)
lw $sp,4($2)
lui $2,%hi($L3)
addiu $2,$2,%lo($L3)
j $2
nop
.setmacro
.setreorder
.endcompare.1584
.ident GCC: (GNU) 4.3.0 20070618 (experimental)
Note that $gp ($28) is not restored at $L3 where it is used. The compare
function does 'goto nonlocal;' which is a jump to $L3, but $gp will have the
wrong value and must be restored.
This worked before the dataflow merge because the compare function would load
$gp (unnecessarily).
I think the fix is to load $gp at $L3.
--
Summary: [4.3 Regression] MIPS: FAIL in
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #2 from jojelino at gmail dot com 2007-06-19 18:13 --- Created an attachment (id=13737) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13737action=view) source file that causes ICE reduced. just three line for ICE -- jojelino at gmail dot com changed: What|Removed |Added Attachment #13735|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #3 from jojelino at gmail dot com 2007-06-19 18:18 --- (From update of attachment 13737) removing static keyword at the top resolves problem. but is it workaround? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug tree-optimization/32367] [4.3 Regression] internal compiler error: in build_polynomial_chrec, at tree-chrec.h:113
--- Comment #13 from spop at gcc dot gnu dot org 2007-06-19 18:35 --- Subject: Bug 32367 Author: spop Date: Tue Jun 19 18:35:39 2007 New Revision: 125855 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125855 Log: PR tree-optimization/32367 * tree-chrec.h (build_polynomial_chrec): Verify that the left hand side of the chrec has no evolution in that loop. * testsuite/gcc.dg/tree-ssa/pr32367.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32367.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-chrec.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32367
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #28 from amacleod at redhat dot com 2007-06-19 18:57 --- Won't solve the problem currently, but I think the long term solution is to do stack analysis when out-of-ssa and expand have been merged into a single entity. The live range info out-of-ssa calculates can be used to do a decent job of stack sharing regardless of scoping info. Short term, we might be able to check to see if a stack variable is used outside its scope when going out of ssa, and flag it for no sharing, or promote it to file level, or the next appropriate scope level. That would work as long as we don't end up promoting too many things in the wrong routines :-). I'm not fond of trying to make the optimization passes aware of scopes on top of everything else they are aware of, Id rather see it taken care of in one place, and not dependent on scoping info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug ada/32407] New: ACATS cd92001 fails
The detailed content of the log is shown below. splitting /home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/tests/cd/cd92001.a into: cd92001.adb BUILD cd92001.adb gnatmake --GCC=/home/voax/linux/build-4.3.0/gcc/xgcc -B/home/voax/linux/build-4.3.0/gcc/ -gnatws -O2 -I/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/support cd92001.adb -largs --GCC=/home/voax/linux/build-4.3.0/gcc/xgcc -B/home/voax/linux/build-4.3.0/gcc/ /home/voax/linux/build-4.3.0/gcc/xgcc -c -B/home/voax/linux/build-4.3.0/gcc/ -gnatws -O2 -I/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/support cd92001.adb gnatbind -aO./ -I/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/support -I- -x cd92001.ali gnatlink cd92001.ali --GCC=/home/voax/linux/build-4.3.0/gcc/xgcc -B/home/voax/linux/build-4.3.0/gcc/ RUN cd92001 ,.,. CD92001 ACATS 2.5 07-06-18 18:43:09 CD92001 Check object attribute: X'Valid. * CD92001 Expected 'Valid =FALSE for Default item 1. * CD92001 Expected 'Valid =FALSE for Default item 2. * CD92001 Expected 'Valid =FALSE for Default item 3. * CD92001 Expected 'Valid =FALSE for Default item 4. * CD92001 Expected 'Valid =FALSE for Default item 5. * CD92001 Expected 'Valid =FALSE for Default item 6. * CD92001 Expected 'Valid =FALSE for Default item 7. * CD92001 Expected 'Valid =FALSE for Default item 8. * CD92001 Expected 'Valid =FALSE for Default item 9. * CD92001 Expected 'Valid =FALSE for Default item 10. * CD92001 Expected 'Valid =FALSE for Default item 11. * CD92001 Expected 'Valid =FALSE for Default item 12. * CD92001 Expected 'Valid =FALSE for Default item 13. * CD92001 Expected 'Valid =FALSE for Default item 14. * CD92001 Expected 'Valid =FALSE for Default item 15. * CD92001 Expected 'Valid =FALSE for Default item 16. * CD92001 Expected 'Valid =FALSE for Default item 17. * CD92001 Expected 'Valid =FALSE for Default item 18. * CD92001 Expected 'Valid =FALSE for Default item 19. * CD92001 Expected 'Valid =FALSE for Default item 20. * CD92001 Expected 'Valid =FALSE for Default item 21. * CD92001 Expected 'Valid =FALSE for Default item 22. * CD92001 Expected 'Valid =FALSE for Default item 23. * CD92001 Expected 'Valid =FALSE for Default item 24. * CD92001 Expected 'Valid =FALSE for Default item 25. * CD92001 Expected 'Valid =FALSE for Default item 26. * CD92001 Expected 'Valid =FALSE for Default item 27. * CD92001 Expected 'Valid =FALSE for Default item 28. * CD92001 Expected 'Valid =FALSE for Default item 29. * CD92001 Expected 'Valid =FALSE for Default item 30. * CD92001 Expected 'Valid =FALSE for Default item 31. * CD92001 Expected 'Valid =FALSE for Default item 32. * CD92001 Expected 'Valid =FALSE for Default item 33. * CD92001 Expected 'Valid =FALSE for Default item 34. * CD92001 Expected 'Valid =FALSE for Default item 35. * CD92001 Expected 'Valid =FALSE for Default item 36. * CD92001 Expected 'Valid =FALSE for Default item 37. * CD92001 Expected 'Valid =FALSE for Default item 38. * CD92001 Expected 'Valid =FALSE for Default item 39. * CD92001 Expected 'Valid =FALSE for Default item 40. * CD92001 Expected 'Valid =FALSE for Default item 41. * CD92001 Expected 'Valid =FALSE for Default item 42. * CD92001 Expected 'Valid =FALSE for Default item 43. * CD92001 Expected 'Valid =FALSE for Default item 44. * CD92001 Expected 'Valid =FALSE for Default item 45. * CD92001 Expected 'Valid =FALSE for Default item 46. * CD92001 Expected 'Valid =FALSE for Default item 47. * CD92001 Expected 'Valid =FALSE for Default item 48. * CD92001 Expected 'Valid =FALSE for Default item 49. * CD92001 Expected 'Valid =FALSE for Default item 50. * CD92001 Expected 'Valid =FALSE for Default item 51. * CD92001 Expected 'Valid =FALSE for Default item 52. * CD92001 Expected 'Valid =FALSE for Default item 53. * CD92001 Expected 'Valid =FALSE for Default item 54. * CD92001 Expected 'Valid =FALSE for Default item 55. * CD92001 Expected 'Valid =FALSE for Default item 56. * CD92001 Expected 'Valid =FALSE for Default item 57. * CD92001 Expected 'Valid =FALSE for Default item 58. * CD92001 Expected 'Valid =FALSE for Default item 59. * CD92001 Expected 'Valid =FALSE for Default item 60. * CD92001 Expected 'Valid =FALSE for Default item 61. * CD92001 Expected 'Valid =FALSE for Default item 62. * CD92001 Expected 'Valid =FALSE for Default item 63. * CD92001 Expected 'Valid =FALSE for Default item 64. * CD92001 Expected 'Valid =FALSE for Default item 65. * CD92001 Expected 'Valid =FALSE for Default item 66. * CD92001 Expected 'Valid =FALSE for Default item 67. * CD92001 Expected 'Valid =FALSE for Default item 68. * CD92001 Expected 'Valid =FALSE for Default item 69. * CD92001 Expected 'Valid =FALSE for Default item 70. * CD92001 Expected 'Valid =FALSE for Default item
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
19:56 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
We need to know that the return pointer (r2) is not used and that
the function is a leaf function (i.e., that the incoming value in
r2 is unchanged). Calls clobber r2.
Dave
Sounds like the following patch would work:
diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- df_hard_reg_used_count (2) == 1
+ DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
}
This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).
This is an update. Since the dataflow merge I've been unable to
find a way to handle generation of the prologue/epilogue/return insns
that works on all hppa targets. However, debugging time has been
limited.
I had one successful build on hppa2.0w-hp-hpux11.11. However,
I haven't had a successful build on hppa64-hp-hpux11.11 or
hppa-unknown-linux-gnu. The hppa64 problem is PR 32398.
The linux problem is wierd. In stage2, I get the following
failure:
/bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo
../../sinf
o.h
make[3]: *** [ada/sinfo.h] Error 139
The above fault is a stack overflow. The problem is wierd in the sense
that the error doesn't occur when I run ./xsinfo ../../sinfo.h from
an interactive shell. It only occurs when the command is run by make.
Increasing the stack limit didn't help. This suggests a problem with
the environment passed to xsinfo.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #15 from hjl at lucon dot org 2007-06-19 20:10 --- (In reply to comment #14) The linux problem is wierd. In stage2, I get the following failure: /bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo ../../sinf o.h make[3]: *** [ada/sinfo.h] Error 139 The above fault is a stack overflow. The problem is wierd in the sense that the error doesn't occur when I run ./xsinfo ../../sinfo.h from an interactive shell. It only occurs when the command is run by make. Increasing the stack limit didn't help. This suggests a problem with the environment passed to xsinfo. make may change stack limit. You can write a simple Makefile to check the real stack limit of processes spawned by make. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug c++/32408] New: Template Parsing Error
GCC may have a defective template parsing routine which seems to mistake the
'' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '' symbol.
Here is a simple code snippet that reproduces the problem:
template class T
struct templated_struct
{
int count;
};
template class T
int template_func()
{
templated_structT s;
if (s.count 0) return 0;
return 0;
}
int main()
{
template_funcint ();
return 0;
}
The compiler generates the follow error message when trying to compile the
above code:
test4.cc: In function int template_func():
test4.cc:16: error: parse error in template argument list
test4.cc: In function int template_func() [with T = int]:
test4.cc:22: instantiated from here
test4.cc:16: error: count is not a member template function
Note that the above code compiles just fine if you replace the '' token in the
IF statement with an '' or an '==', thus demonstrating that GCC seems to be
confusing the '' token for a template argument.
A temporary workaround is to put a set of parenthesis around s.count.
--
Summary: Template Parsing Error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chsalvia at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32408
[Bug c++/32409] New: Template Parsing Error
GCC may have a defective template parsing routine which seems to mistake the
'' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '' symbol.
Here is a simple code snippet that reproduces the problem:
template class T
struct templated_struct
{
int count;
};
template class T
int template_func()
{
templated_structT s;
if (s.count 0) return 0;
return 0;
}
int main()
{
template_funcint ();
return 0;
}
The compiler generates the follow error message when trying to compile the
above code:
test4.cc: In function int template_func():
test4.cc:16: error: parse error in template argument list
test4.cc: In function int template_func() [with T = int]:
test4.cc:22: instantiated from here
test4.cc:16: error: count is not a member template function
Note that the above code compiles just fine if you replace the '' token in the
IF statement with an '' or an '==', thus demonstrating that GCC seems to be
confusing the '' token for a template argument.
A temporary workaround is to put a set of parenthesis around s.count.
--
Summary: Template Parsing Error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chsalvia at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32409
