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
Re: virtual stack regs.
On 6/19/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > 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? 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. Uros.
Re: virtual stack regs.
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. -- Rask Ingemann Lambertsen
RE: Object attribute tagging
On 19 June 2007 02:50, Joseph S. Myers wrote: > Any comments on either the general approach or the details? Sounds like a sane design to me :) cheers, DaveK -- Can't think of a witty .sigline today
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 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 [ ])
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:SI 0 %d0 [ ])
(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 [ ])
> (const_int 0 [0x0]))
> (expr_list:REG_DEP_TRUE (reg:SI 0 %d0 [ ])
> (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: RFC: Make dllimport/dllexport imply default visibility
Richard Earnshaw wrote:
> 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.
Thank you for following up on this!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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 [ ])
> (const_int 0 [0x0]))
> (expr_list:REG_DEP_TRUE (reg:SI 0 %d0 [ ])
> (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)
(ca
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.
class 3 edges
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
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_cast(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_cast(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_cast(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_cast(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_cast(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_cast(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 %
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
