search for: sgefa

...esults to me please remind me of what platform > > you are testing on. > > > > Thanks again to all the testers for your help. > > > > Test results are starting to come in, it looks like we have a few > regressions: > > x86_64: > MultiSource/Applications/sgefa > > ARMV7: > - new failure: ExecutionEngine/MCJIT/remote/simpletest-remote.ll > - new unexpected pass: > ExecutionEngine/MCJIT/remote/cross-module-sm-pic-a.ll > > > Has anyone attempted to bisect to figure out which commit broke these > tests? > Hi Jiangning, T...

Dear helpers, I am trying to create a library which uses some Fortran source files and Lapack and Blas subroutines. The Fortran source files from the original author contain subroutines isamax.f, sgefa.f and sgesl.f, which are part of BLAS subroutines on my Linux computer, but maybe different (old) versions. So in addition to these subroutines, there are other Lapack and Blas subroutines involved. There is no problem to compile and run these files using g77, such as the following to create car:...

Hi, I have just tagged the first release candidate for the 3.4.1 release, so testers may begin testing. Please refer to http://llvm.org/docs/ReleaseProcess.html for information on how to validate a release. If you have any questions or need something clarified, just email the list. For the 3.4.1 release we want to compare test results against 3.4-final. I have added support to the

Fair enough... The following tests under MultiSource fail: Benchmarks/Olden/power Benchmarks/OptimizerEval Benchmarks/Ptrdist/ks Benchmarks/MallocBench/perl Applications/sgefa However, they also fail in the exact same way without my change. OptimizerEval appears to be non-deterministic; it produces different output each time it runs. Everything else passes. I also compared a few *.s files generated by the tests, with and without my change, to see if everything is as I...

...09-11 at 12:49, Jeff Cohen wrote: > For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It > didn't make a difference. So here are the failures for llvm-test. All > diffs are against the "native" output. > > ===================== MultiSource/Applications/sgefa > > cbe failed differently from jit/llc. First cbe: > > 84c84 > < One-Norm(A) ---------- 8.879153e+02. > --- > > One-Norm(A) ---------- 8.879156e+02. > 100c100 > < One-Norm(A) ---------- 5.000000e+35. > --- > > One-Norm(A) ----------...

On Sat, 11 Sep 2004 13:53:11 -0700 Reid Spencer <reid at x10sys.com> wrote: > On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > > > > ===================== MultiSource/Applications/sgefa > > > sgefa is a known XFAIL. See the nightly test results over the last > several months. Actually, you should compare your test results with the > 1.3 release test results (on or about August 13th, 2004). Please only > report deltas from there. Where can I find these? I see...

On Sun, 2004-08-29 at 16:01, Jeff Cohen wrote: > Fair enough... The following tests under MultiSource fail: > > Benchmarks/Olden/power > Benchmarks/OptimizerEval > Benchmarks/Ptrdist/ks > Benchmarks/MallocBench/perl > Applications/sgefa > > However, they also fail in the exact same way without my change. > OptimizerEval appears to be non-deterministic; it produces different > output each time it runs. Everything else passes. I also compared a > few *.s files generated by the tests, with and without my change, to...

For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It didn't make a difference. So here are the failures for llvm-test. All diffs are against the "native" output. ===================== MultiSource/Applications/sgefa cbe failed differently from jit/llc. First cbe: 84c84 < One-Norm(A) ---------- 8.879153e+02. --- > One-Norm(A) ---------- 8.879156e+02. 100c100 < One-Norm(A) ---------- 5.000000e+35. --- > One-Norm(A) ---------- 5.000005e+35. And jit/llc: 79a80 > Zero Column...

On Thu, 9 Sep 2004 20:16:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Thu, 9 Sep 2004 08:52:10 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > > I haven't got around to this yet but I will. The odds are good the > > > problem is in a BSD system header file so I need to capture the > > > preprocessed source. > > >

...54 0 12 46 32 1 0 minisat 458 10 10 3 1 35 4 0 0 sgefa 439 1 121 0 20 14 55 0 0 SIBsim4 153 15 6 0 3 40...

...are apparently not frequently used. :) That said, here is the status of programs: Regression/Jello: All work SingleSource: All work MultiSource: Working: health, perimeter, power, treeadd, bisort, voronoi, tsp, em3d : pi, llubenchmark, etc... __iob : bh, anagram, fhourstones, burg, sgefa, sim, 181.mcf, ... other : mst The __iob problems are because of explicit references to stdin,out,err in the .c code. The problem is that the headers we're using turns them into references to an __iob array, which doesn't exist on X86. The _right_ fix to this is to port glibc to LLVM....

> Are you using LLVM CVS? If not, please update. Yes, I'm using LLVM CVS. Updated a couple of hours ago. If so, please run 'make > bugpoint-llc' in that directory and file a bug. This is an instruction > selector bug, not yours. We'll be happy to fix it if it's not already > fixed in LLVM CVS. The test is running and I already have Segmentation Fault

...committed. Thanks for the patches! Reid. On Sun, 2004-08-29 at 16:01, Jeff Cohen wrote: > Fair enough... The following tests under MultiSource fail: > > Benchmarks/Olden/power > Benchmarks/OptimizerEval > Benchmarks/Ptrdist/ks > Benchmarks/MallocBench/perl > Applications/sgefa > > However, they also fail in the exact same way without my change. > OptimizerEval appears to be non-deterministic; it produces different > output each time it runs. Everything else passes. I also compared a > few *.s files generated by the tests, with and without my change, to...

After puzzling about the size of the executables and the build times, I discovered (thanks Chris!) that I had compiled everything without debug symbols in the automake version. So, here's some revision from the first version of this email. The build times didn't change much (I guess I/O is cheap on my machine). The new "Build With Automake" times are 20m28.672s (elapsed),

Jeff, Chris isn't likely to respond to this for a while as he's on vacation. I'll take a look at it and will commit it if it looks good. Since code gen isn't my specialty, could you increase my comfort level a little by giving me some examples of the test results you got when testing your patches? Ideally, I'd like to see some of the test/Programs/MultiSource programs working

...lalign.test | 1.74 | 1.75 | 2.80 | 2.80 | |SingleSource/Benchmarks/McGill/chomp.test | 1.29 | 3.32 | 8.75 | 8.75 | |MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset.| 1.18 | 1.06 | 0.87 | 0.87 | |MultiSource/Applications/sgefa/sgefa.test | 1.11 | 1.22 | 2.61 | 2.61 | |MultiSource/Benchmarks/MallocBench/cfrac/cfrac.test | 1.06 | 1.22 | 0.72 | 0.72 | |MultiSource/Benchmarks/VersaBench/dbms/dbms.test | 1.05 | 1.28 | 2.00 | 2.00 | |MultiSource/Benchm...

On Tue, 19 Sep 2006, Anton Vayvod wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x00634572 in (anonymous namespace)::X86DAGToDAGISel::DeleteNode ( > this=0x4c3b710, N=0x4c3e5c0) > at /llvm/obj/lib/Target/X86/X86GenDAGISel.inc:77 > 77 SDNode *Operand = I->Val; > > SEGFAULT seems to come before register allocation pass is being run. Are you

...; FAILED! ******************** ******************** TEST (cbe) 'spirit' FAILED! ******************** ******************** TEST (jit) 'spirit' FAILED! ******************** ******************** TEST (cbe) 'burg' FAILED! ******************** ******************** TEST (cbe) 'sgefa' FAILED! ******************** ******************** TEST (cbe) 'make_dparser' FAILED! ******************** ******************** TEST (jit) 'spiff' FAILED! ******************** ******************** TEST (cbe) 'oggenc' FAILED! ******************** ******************** TEST...

...efile.am for analyze was wrong. It wasn't linking in the some of the passes. The new size is 56951088 which is in line with the other executables. Also, I have now completed a run of projects/llvm-test/MultiSource with the tools generated by automake. The only errors were for: TEST (llc) 'sgefa' FAILED! TEST (jit) 'sgefa' FAILED! TEST (jit) 'make_dparser' FAILED! TEST (llc) 'kc' FAILED! TEST (jit) 'anagram' FAILED! TEST (llc) 'mason' FAILED! TEST (cbe) 'mason' FAILED! TEST (jit) 'mason' FAILED! TEST (jit) 'pcompress2' FAI...

Folks, I have completed the addition of automake makefiles to LLVM. All libraries, tools, and runtime libs build now with automake. Note that there are still many missing things in the automake support. Right now it just builds the basic software. However, before I invest more time in it, I thought some comparison would help us make some decisions about whether or not to proceed with automake