Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
On 2005-06-01 15:29:37 +0930, Alan Modra wrote:
> On Tue, May 31, 2005 at 09:53:05PM +0200, Vincent Lefevre wrote:
> > Under the 32-bit version, there's no extended precision.
>
> No. powerpc-linux has 128-bit IEEE soft-float long double.
>
> $ cat > fadd.c <<\EOF
> long double fadd (long double a, long double b) { return a + b; }
> EOF
> $ gcc -m32 -mlong-double-128 -c fadd.c
But that's not the default and you'll have problems when linking with
existing libraries on the machine, that use a 64-bit long double...
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:
Re: ERROR in the gfortran testsuite
On Tue, May 31, 2005 at 05:24:15PM -0700, Steve Kargl wrote: > On Tue, May 31, 2005 at 07:40:37PM -0400, Andrew Pinski wrote: > > Right now on powerpc-darwin with the following versions: > > Expect version is 5.38.0 > > Tcl version is 8.4 > > Framework version is1.4.4 > > > > I get the following failure in the gfortran- > > ERROR: tcl error sourcing > > (snip) > > > I think this is due to the empty file > > "testsuite/gfortran.fortran-torture/execute/forall_3.x" but I don't > > know for sure. Could someone check to make sure and fix this? > > I just finished a bootstrap/regression test of gfortran on HEAD > and do not see this problem. Can you XFAIL forall_3.f90 and > see if the problem persists? Works for me too. BTW, there is no forall_3.x nor forall_3.f90.x in CVS... Jakub
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
Vincent Lefevre <[EMAIL PROTECTED]> writes:
> On 2005-06-01 00:58:25 +0200, Andreas Schwab wrote:
>> #include
>> #include
>>
>> long double one = 1.0;
>> long double one_plus_eps;
>>
>> int
>> main (void)
>> {
>> long double one_plus_eps;
>>
>> one_plus_eps = one + LDBL_EPSILON;
>> assert (one != one_plus_eps);
>> return 0;
>> }
>
> I don't know how the standard should be interpreted (see below), but
> if your program fails, this means that either your program is buggy
> or the C implemention is buggy.
This works fine with a non-broken implementation which claims IEC 60559
compliance.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
help needed
Hello, I'm trying to migrate from open vms to Linux. I'm compiling programs on Linux which are running on open VMS I'm facing problem with int64 function. my hardware configuration is P-IV 3.06 GHz 512 MB, I'm Running Fedora Core 3 with gcc Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) can i compile the same with this? what compiler option will i have to use? Thanks in advance regards Sandeep __ Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html
Hello,Gnu
Hello , I want to make the an compiler for a new language to produce elf and pe(windows) format file. Can you tell me where to find the document of them(most detail)? or,Is there some allready exist library ? Thank You! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: help needed
On Wed, Jun 01, 2005 at 04:22:24AM -0700, sandeep nadkarni wrote: > Hello, Hi, > I'm trying to migrate from open vms to Linux. I'm > compiling programs on Linux which are running on open > VMS > > I'm facing problem with int64 function. What problem? Which function? > my hardware configuration is P-IV 3.06 GHz > 512 MB, > I'm Running Fedora Core 3 with gcc > Reading specs from > /usr/lib/gcc/i386-redhat-linux/3.4.3/specs > Configured with: ../configure --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --enable-shared --enable-threads=posix > --disable-checking --with-system-zlib > --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-java-awt=gtk --host=i386-redhat-linux > Thread model: posix > gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) > > can i compile the same with this? what compiler option > will i have to use? You haven't given much information but as your question is about using GCC (not developing it) you might get a better answer by mailing [EMAIL PROTECTED] The gcc@gcc.gnu.org list is for GCC development. Regards, jon -- "Anyone who cannot cope with mathematics is not fully human. At best, he is a tolerable subhuman who has learned to dress himself, bathe, and not make messes in the house." - Robert Heinlein
Re: SMS in gcc4.0
Hi, all I've taken a look on modulo-sched.c recently, and found that both new_cycles and orig_cycles are imprecise. The reason is that kernel_number_of_cycles does not take the data dependences of insns into account as the DFA scheduler does in haifa-sched.c. On IA-64, three improvements are needed to let SMS work. 1) Modify doloop_register_get or the similar function defined in doloop.c to recognize the loop count register. I have supplied a patch about this in April. 2) Use more precise way to calculate the values of the two kind of cycles, or just ignore this benefit assertion. 3) The counted loop register 'ar.lc' of IA-64 can not be updated directly. Another temporary register is needed to evaluate the value of the actural loop count after SMS schedule, and assign its value to 'ar.lc'. Mostafa Hagog <[EMAIL PROTECTED]>: > > > > > Steven Bosscher <[EMAIL PROTECTED]> wrote on 22/04/2005 09:39:09: > > > > > > Thanks! > > For the record, this refers to a patch I sent to Mostafa and Canqun to > > do what Mostafa suggested last month to make SMS work for ia64, see > > http://gcc.gu.org/ml/gcc-patches/2005-03/msg02848.html. > > I have tested the patch on powerpc-apple-darwin and there are some tests > that > started failing. So I am going to debug it to see what causes the failures. > > Mostafa. > > > > > Gr. > > Steven > > > > > > Canqun Yang Creative Compiler Research Group. National University of Defense Technology, China.
Re: SMS in gcc4.0
On Wednesday 01 June 2005 16:43, Canqun Yang wrote: > Hi, all > > I've taken a look on modulo-sched.c recently, and found > that both new_cycles and orig_cycles are imprecise. The > reason is that kernel_number_of_cycles does not take the > data dependences of insns into account as the DFA > scheduler does in haifa-sched.c. How does this affect the cycles computation? > On IA-64, three improvements are needed to let SMS work. > 1) Modify doloop_register_get or the similar function > defined in doloop.c to recognize the loop count > register. I have supplied a patch about this in April. Mustafa and I have a patch that has a similar effect, see http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00035.html. > 2) Use more precise way to calculate the values of the > two kind of cycles, or just ignore this benefit assertion. Probably need to be more precise :-/ When I manually hacked modulo-sched.c to ignore this test, I did see loops getting scheduled, but I also ran into ICEs in cfglayout. > 3) The counted loop register 'ar.lc' of IA-64 can not be > updated directly. Another temporary register is needed > to evaluate the value of the actural loop count after > SMS schedule, and assign its value to 'ar.lc'. Actually, should SMS just not update the loop register in place? I never figured out why it tries to produce a sub insns (using gen_sub2_insn which is also wrong btw). Gr. Steven
Re: Mac OS X Panther to Tiger Build Changes for GCC 3.3 and 3.4
On Tuesday, May 31, 2005, at 08:11 PM, Dan Allen wrote: I tried doing bootstrap builds of GCC 3.3.6 and GCC 3.4.4 but these builds fail due to the absence of the 'c++filt' tool. mrs $ type c++filt c++filt is /usr/bin/c++filt The builds proceed for quite awhile until they hit this missing 'c++filt' tool problem. Since you don't cut and paste what you saw, it makes it hard for me to guess/comment. Anyway, I guess I would just recommend using 4.0 and ignoring the older releases if you can.. :-(
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
On Wednesday, June 1, 2005, at 12:21 AM, Vincent Lefevre wrote: But that's not the default and you'll have problems when linking with existing libraries on the machine, that use a 64-bit long double... Fine, we'll make it the default and recompile all your libraries for you... give me a second while I hack into your machine
Re: Hello,Gnu
On Wednesday, June 1, 2005, at 04:22 AM, dk zhou wrote: Hello , I want to make the an compiler for a new language to produce elf and pe(windows) format file. Can you tell me where to find the document of them(most detail)? All the documentation we have can be found on the web site, or in the source code. For your reading pleasure we provide 8 working examples for you to copy ideas from; they contain lots of various details that may be of interest to you.
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
On Wed, 2005-06-01 at 10:26 -0700, Mike Stump wrote: > On Wednesday, June 1, 2005, at 12:21 AM, Vincent Lefevre wrote: > > But that's not the default and you'll have problems when linking with > > existing libraries on the machine, that use a 64-bit long double... > > Fine, we'll make it the default and recompile all your libraries for > you... give me a second while I hack into your machine > Mike says sarcastically, as if this isn't what tiger did :)
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
On Wednesday, June 1, 2005, at 11:01 AM, Daniel Berlin wrote: Mike says sarcastically, as if this isn't what tiger did :) Someday, get me drunk and ask me how hard abi compatibility is. :-( I hate how we did it, and I hate that it was necessary. I hate that bools on darwin are 4 bytes, because _Bool is 4 bytes, and once set, is set in stone. Maybe in the future we'll have so much CPU and disk space and RAM that we can dispense with hard, inflexible abis... I''m gonna go off and hold my breath now... Oh, and we already bought into a fixed libstdc++.dylib, so there's lots more fun and magic awaiting us.
Bogous trees in ivopts again!
rewrite_address_base is trying at *op = build1 (INDIRECT_REF, TREE_TYPE (*op), with); to substitute *op state_inD.7206_16->savedD.7200[regD.7211_3] which is of type integer_type 0x4014a3cc char with *state_inD.7206_38 where state_inD.7206_38 is of type pointer_type 0x4047b21c type . This obviously results in a strange INDIRECT_REF typing. Note that rewrite_use_address() ends up calling rewrite_address_base with something useful, namely (gdb) call debug_tree(op)
Re: SMS in gcc4.0
Steven Bosscher <[EMAIL PROTECTED]>: > On Wednesday 01 June 2005 16:43, Canqun Yang wrote: > > Hi, all > > > > I've taken a look on modulo-sched.c recently, and found > > that both new_cycles and orig_cycles are imprecise. The > > reason is that kernel_number_of_cycles does not take the > > data dependences of insns into account as the DFA > > scheduler does in haifa-sched.c. > > How does this affect the cycles computation? > An insns is ready for schedule only when all the insns it dependent on have already be scheduled. In haifa- sched.c, there is a queue to hold the insns which are ready for schedule. To find how the data dependence affect the cycles computation, the more simple way is to compare the two versions of assembly code generated by GCC respectively, one is generated by turning on '-fmodulo- sched', the other not. Without SMS, the code in loop has many stops ';;' to seperate the instrcutions which have data dependence, while with SMS, though the kernel code of the loop has more instructions, but less stops ';;'. > > On IA-64, three improvements are needed to let SMS work. > > 1) Modify doloop_register_get or the similar function > > defined in doloop.c to recognize the loop count > > register. I have supplied a patch about this in April. > > Mustafa and I have a patch that has a similar effect, see > http://gcc.gnu.org/ml/gcc-patches/2005- 06/msg00035.html. > > > 2) Use more precise way to calculate the values of the > > two kind of cycles, or just ignore this benefit assertion. > > Probably need to be more precise :-/ > > When I manually hacked modulo-sched.c to ignore this test, I > did see loops getting scheduled, but I also ran into ICEs in > cfglayout. There are no ICEs for pi.f90, swim.f, and mgrid.f according to my test. But, an internal compile error of 'unrecognizable insn' is produced by 'gen_sub2_insn' which explicitly minus 'ar.lc' when swim.f and mgrid.f are being compiled. > > > 3) The counted loop register 'ar.lc' of IA-64 can not be > > updated directly. Another temporary register is needed > > to evaluate the value of the actural loop count after > > SMS schedule, and assign its value to 'ar.lc'. > > Actually, should SMS just not update the loop register in place? > I never figured out why it tries to produce a sub insns (using > gen_sub2_insn which is also wrong btw). > The current implementation of SMS does not use IA-64's epilog register (ar.ec). After SMS, the loop count is just used to control the execution times of the kernel code, and the kernel code will execute loop_count - (stage_count - 1) times The sub insns generated by gen_sub2_insn is used to produce this value. > Gr. > Steven > > Canqun Yang Creative Compiler Research Group. National University of Defense Technology, China.
Re: SMS in gcc4.0
Canqun Yang <[EMAIL PROTECTED]>: > Steven Bosscher <[EMAIL PROTECTED]>: > > > On Wednesday 01 June 2005 16:43, Canqun Yang wrote: > > > Hi, all > > > > > > I've taken a look on modulo-sched.c recently, and > found > > > that both new_cycles and orig_cycles are > imprecise. The > > > reason is that kernel_number_of_cycles does not > take the > > > data dependences of insns into account as the DFA > > > scheduler does in haifa-sched.c. > > > > How does this affect the cycles computation? > > > > An insns is ready for schedule only when all the insns > it dependent on have already be scheduled. In haifa- > sched.c, there is a queue to hold the insns which are > ready for schedule. > > To find how the data dependence affect the cycles > computation, the more simple way is to compare the > two versions of assembly code generated by GCC > respectively, one is generated by turning on '- fmodulo- > sched', the other not. Without SMS, the code in loop > has many stops ';;' to seperate the instrcutions which > have data dependence, while with SMS, though the > kernel code of the loop has more instructions, but > less stops ';;'. > > > > On IA-64, three improvements are needed to let SMS > work. > > > 1) Modify doloop_register_get or the similar > function > > > defined in doloop.c to recognize the loop count > > > register. I have supplied a patch about this in > April. > > > > Mustafa and I have a patch that has a similar > effect, see > > http://gcc.gnu.org/ml/gcc-patches/2005- > 06/msg00035.html. > > > > > 2) Use more precise way to calculate the values of > the > > > two kind of cycles, or just ignore this benefit > assertion. > > > > Probably need to be more precise :-/ > > > > When I manually hacked modulo-sched.c to ignore this > test, I > > did see loops getting scheduled, but I also ran into > ICEs in > > cfglayout. > > There are no ICEs for pi.f90, swim.f, and mgrid.f > according to my test. But, an internal compile error > of 'unrecognizable insn' is produced > by 'gen_sub2_insn' which explicitly minus 'ar.lc' when > swim.f and mgrid.f are being compiled. There is no ICEs for pi.f90 according to my test. But ICEs of 'unreconizable insn' is procuded by 'gen_sub2_insns' which explicitly minus 'ar.lc' when swim.f and mgrid.f are being compiled. > > > > > > 3) The counted loop register 'ar.lc' of IA-64 can > not be > > > updated directly. Another temporary register is > needed > > > to evaluate the value of the actural loop count > after > > > SMS schedule, and assign its value to 'ar.lc'. > > > > Actually, should SMS just not update the loop > register in place? > > I never figured out why it tries to produce a sub > insns (using > > gen_sub2_insn which is also wrong btw). > > > > The current implementation of SMS does not use IA- 64's > epilog register (ar.ec). After SMS, the loop count is > just used to control the execution times of the kernel > code, and the kernel code will execute >loop_count - (stage_count - 1) times > The sub insns generated by gen_sub2_insn is used to > produce this value. > > > > Gr. > > Steven > > > > > Canqun Yang Creative Compiler Research Group. National University of Defense Technology, China.
Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]
Camm Maguire wrote: Raymond Toy writes: On the sparc port, this area can be zeroed out with appropriate optimization settings. I ran some tests using Eric Marsden's cl-bench. If the stack is always cleared, the cost of some benchmarks go up, but some go down, because the cost of GC is decreased. (The benchmarks include GC time.) Thanks for the tip -- does this use gcc, and if so, what is the You know, of course, that CMUCL is a native compiler that doesn't use gcc. I hand-wrote the assembly code to clear the stack area. :-) Ray
Re: Mac OS X Panther to Tiger Build Changes for GCC 3.3 and 3.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stump wrote: | Anyway, I guess I would just recommend using 4.0 and ignoring the older | releases if you can.. :-( I think he has to, as far as I know the changes to use libSystemStubs on tiger were never backported to 3.4 and 3.3. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQp5ojbiDAg3OZTLPAQKy6wQAmASPxSFY7pEFzccjIxOgxzkiLKRRfjC9 Y4uDGapKsdrfI+O+UCC6Q3Gx4hkcgfIMxA0BFLgVwuwfuIhZzPYGwSWTTnwg5GEf a8gqVhQlrkQSBTGx5plWX9iWovqsfH3C9dWFqGbzRM0t8ePRpeYvlibNd9I6AAvE l+BW1FC4FD8= =8HJx -END PGP SIGNATURE-
Re: Mac OS X Panther to Tiger Build Changes for GCC 3.3 and 3.4
On Wednesday, June 1, 2005, at 07:01 PM, Peter O'Gorman wrote: I think he has to, as far as I know the changes to use libSystemStubs on tiger were never backported to 3.4 and 3.3. If one uses fink to install the older compiler, it just works. :-(
Re: Mac OS X Panther to Tiger Build Changes for GCC 3.3 and 3.4
Mike Stump wrote:
On Wednesday, June 1, 2005, at 07:01 PM, Peter O'Gorman wrote:
I think he has to, as far as I know the changes to use libSystemStubs on
tiger were never backported to 3.4 and 3.3.
If one uses fink to install the older compiler, it just works. :-(
Fink patched their g77 package for tiger. As long as nobody uses assert()
they'll be fine :/
peter$ cat foo.c
#include
int foo(const char * str)
{
assert(str);
return 1;
}
imac:~ peter$ /opt/gcc3.4/bin/gcc -dynamiclib -o libfoo1.dylib foo.c
ld: Undefined symbols:
_fprintf$LDBLStub
/usr/bin/libtool: internal link edit command failed
Peter
--
Peter O'Gorman - http://www.pogma.com
Re: reload question
Ian Lance Taylor writes: > I agree that gcc is not well designed to cope with an accumulator > architecture. Reload can't cope. I've had a fair amount of success with the approach I initially posted (perturbing the emission order of reloads based on dependencies between the operand they are associated with). It's still pretty fragile in the sense that even a tiny mistake in something like the constraints will cause reload to barf, but I guess that's to be expected. The code produced seems pretty reasonable too (with almost no peepholes at all); for instance it will allocate a variable to the accumulator in the odd case where that's possible. [I don't know if this is the sort of thing that's viable for merging into standard gcc, but maybe a simpler approach based on a backend hook or something would be.] I gotta admit though, by now I thoroughly hate the gcc reload code... -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x)))
