search for: coplin11

Chris Lattner wrote: >I think that we should switch to C constants in this case. Can you try >#include <math.h> and use HUGE_VAL instead? > It works: [finna at coplin11 ~/test]$ cat tst.cpp #include <limits> #include <iostream> #include <math.h> int main() { std::cerr << std::numeric_limits<float>::infinity() << "\n"; std::cerr << HUGE_VAL << "\n"; } [finna at coplin11 ~/test]$ g++ tst.cpp [fi...

...>int main() { > std::cerr << std::numeric_limits<float>::infinity() << "\n"; >} >--- > > Sure thing. It prints "0". Calling that inifinity is somewhat of a stretch, isn't it ? What on earth is going on here? Log: ---------- [finna at coplin11 debug]$ cat - > tst.cpp #include <limits> #include <iostream> int main() { std::cerr << std::numeric_limits<float>::infinity() << "\n"; } [finna at coplin11 debug]$ g++ tst.cpp [finna at coplin11 debug]$ ./a.out 0 ---------- Thanks a lot for your time a...

On Wed, 5 May 2004, Finn S Andersen wrote: > Chris Lattner wrote: > > >Could you try compiling and running this program: > > > >--- > >#include <limits> > >#include <iostream> > >int main() { > > std::cerr << std::numeric_limits<float>::infinity() << "\n"; > >} > >--- > > > > > Sure

On Thu, May 06, 2004 at 04:06:27PM +0200, Finn S Andersen wrote: > Chris Lattner wrote: > > >I think that we should switch to C constants in this case. Can you try > >#include <math.h> and use HUGE_VAL instead? > > > It works: > > [finna at coplin11 ~/test]$ cat tst.cpp > #include <limits> > #include <iostream> > #include <math.h> > int main() { > std::cerr << std::numeric_limits<float>::infinity() << "\n"; > std::cerr << HUGE_VAL << "\n"; > } > [finn...

...led, but runs without problems otherwise. On RH9 (the system I have access to while generating this email) I have the following details: > 1) The LLVM assembly language (.ll file) that is failing. - Attached. > 2) The version of GCC that you are using (gcc -v) ---------------- [finna at coplin11 ~]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/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 --host=i386-redhat-linux T...

On Tue, 4 May 2004, Finn S Andersen wrote: > Chris wrote in a followup: > > > Can you send the output of 'llc -o - foo.bc -debug -print-machineinstrs'? > > > Attached as "linscan". (But added the "-regalloc=linearscan" to provoke > the error). Yes, that's exactly what I meant... thanks for reading my mind! :) It looks like this is where

Finn S Andersen wrote: > Sorry to disturb you all, but I simply cannot get > the linearscan allocator to work. I have upgraded > llvm to mainline cvs. Everything works until I get > to llc -regalloc=linearscan or lli -regalloc=linearscan. > > I have installed it on redhat 9 and on Fedora Core > distributions (I even took it as far as to format a new > partition and

Sorry to disturb you all, but I simply cannot get the linearscan allocator to work. I have upgraded llvm to mainline cvs. Everything works until I get to llc -regalloc=linearscan or lli -regalloc=linearscan. I have installed it on redhat 9 and on Fedora Core distributions (I even took it as far as to format a new partition and install Fedora core all over). I have submitted the bytecode that

...ave opened an account, registered a password and confirmed it through mail, I am still rejected by bugzilla when I try to log in. I hope you can use the attached bc to narrow down the bug. Thanks a lot for any help. ---------------------- The message I get when running the attached bc: [finna at coplin11 fft]$ lli -regalloc=linearscan a.out.bc lli: /home/finna/llvm/llvm/include/llvm/Target/MRegisterInfo.h:144: static bool llvm::MRegisterInfo::isPhysicalRegister(unsigned int): Assertion `Reg && "this is not a register!"' failed. lli[0x849e768] lli[0x849e974] /lib/tls/libc.so...

On Wed, Apr 21, 2004 at 11:01:48AM +0200, Finn S Andersen wrote: > For some of the benchmarks the linear scan regalloc > works. When it does, results are in the x1.0 - 1.5 > range. Unfortunately, the linear scan allocator breaks > on most of my code. Is there a chance you can try cvs? I would be interested to get a simplified test case where the allocator breaks. A lot of

Hi, I have a question about x86 code quality. I have run a few benchmarks and compared the running time of executables created by LLVM to executables created by gcc. It appears that code generated by LLVM is x1.5 - x3 times slower than code generated by gcc, for the x86 For some of the benchmarks the linear scan regalloc works. When it does, results are in the x1.0 - 1.5 range. Unfortunately,