similar to: [LLVMdev] test-suite wrongly using big-endian results

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.

On Sat, 2004-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

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 12 March 2013 16:21, Duncan Sands <baldrick at free.fr> wrote: > IIRC the reference output is not used by default. You have to put > USE_REFERENCE_OUTPUT := 1 > in the Makefile in order to make use of the reference output. As > BenchmarkGame doesn't have this, are you sure the reference output > is causing the problem? > That was my initial assumption, too. But

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. > > >

Hi Daniel, I'm trying to add LivermoreLoops test to the benchmark suite (tar ball attached), but I'm getting the error below: --- Tested: 2 tests -- FAIL: SingleSource/Benchmarks/LivermoreLoops/lloops.compile_time (1 of 2) FAIL: SingleSource/Benchmarks/LivermoreLoops/lloops.execution_time (2 of 2) When I use the option to only run this test: --only-test

On 03/17/2010 10:12 PM, Tanya Lattner wrote: > The 2.7 binaries are available for testing: > http://llvm.org/pre-releases/2.7/pre-release1/ > > You will also find the source tarballs there as well. > > We rely on the community to help make our releases great, so please help > test 2.7 if you can. Please follow these instructions to test 2.7: > > /To test llvm-gcc:/

On 12 March 2013 14:24, Tim Northover <t.p.northover at gmail.com> wrote: > Could be worth a try. But if that thing really is generating random > numbers I'm not sure replacing one genuine cast-iron random number > with another is the best solution long-term. > The test is initializing srand(1), so in theory, it shouldn't be different between compilers, since Clang is

On Mar 24, 2010, at 2:47 PM, Török Edwin wrote: > On 03/17/2010 10:12 PM, Tanya Lattner wrote: >> The 2.7 binaries are available for testing: >> http://llvm.org/pre-releases/2.7/pre-release1/ >> >> You will also find the source tarballs there as well. >> >> We rely on the community to help make our releases great, so please help >> test 2.7 if you

Hi Duncan, Do you have sources also in the $LLVM_SRC_ROOT/projects/test-suite/External/SPEC/CINT2000/164.gzip? The following is content of above directory in my case. I have copied the CINT2000 sources in this directory manually. $ls -1 $LLVM_SRC_ROOT/projects/test-suite/External/SPEC/CINT2000/164.gzip 164.gzip.reference_output 164.gzip.reference_output.small compile_info compile_parms

Hi Renato, On 12/03/13 15:33, Renato Golin wrote: > On 12 March 2013 14:24, Tim Northover <t.p.northover at gmail.com > <mailto:t.p.northover at gmail.com>> wrote: > > Could be worth a try. But if that thing really is generating random > numbers I'm not sure replacing one genuine cast-iron random number > with another is the best solution long-term.

Hi, I am not sure if this is the right forum. Please direct me to the appropriate place if it isn't so. Please keep in CC as i am not subscribed to this mailing list. I am trying to test riscv llvm tools in QEMU using llvm testsuite. As a trial i am trying only the Single Source C Regression folder. The steps that i took are : ]$ cmake -DCMAKE_C_COMPILER=/opt/riscv-tools/bin/clang

On 12 October 2016 at 15:05, Hal Finkel <hfinkel at anl.gov> wrote: > This is something we need to understand. No, there's not always an error bar. With FMA formation and without non-IEEE-compliant optimizations (i.e. fast-math), the optimized answer should be identical to the non-optimized answer. What about architectures that this is never respected, like Darwin? In the general

On 12 October 2016 at 14:26, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > Correct me if I misunderstood: you would be ok changing the > reference output to exactly match the output of "-O0 -ffp-contract=off". No, that's not at all what I said. Matching identical outputs to FP tests makes no sense because there's *always* an error bar. The output of O0, O1, O2,

Hi Renato, On 12/03/13 17:33, Renato Golin wrote: > On 12 March 2013 16:21, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > IIRC the reference output is not used by default. You have to put > USE_REFERENCE_OUTPUT := 1 > in the Makefile in order to make use of the reference output. As > BenchmarkGame doesn't

At the LLVM Developers' Meeting in November, I promised to work on isolating a subset of the current test suite that is useful for benchmarking. Having looked at this in more detail, most of the applications and benchmarks in the test suite are useful for benchmarking, and so I think that a better way of phrasing it is that we should construct a list of programs in the test suite that are not

On 2 April 2013 21:20, Török Edwin <edwin+ml-debian at etorok.net> wrote: > You can pass all the filenames from the inputs/ directory directly on the > command-line, instead of specifying -r inputs/. > That way the order of scanning will be exactly the one specified on the > command-line. > Hum, I think I can fix that with Make... --renato -------------- next part

On 04/02/2013 11:06 PM, Daniel Dunbar wrote: > On Tue, Apr 2, 2013 at 11:46 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > > On 2 April 2013 19:20, Daniel Dunbar <daniel at zuster.org <mailto:daniel at zuster.org>> wrote: > > What is it that makes the output of the program asynchronous? The output is

Hi, Using trunk llvm ; on powerpc (powerpc64/power7); trying to do a "gmake check", the sed bits in test/Makefile appear to be getting tripped up when trying to generate lit.site.cfg. I've started to hack at it, made a little bit of progress, but wonder if I'm just digging myself a hole. Highlights of what I've poked at are below.. Comments or thoughts? Thanks,

Hi Torok, I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... INPUT = $(PROJ_SRC_DIR)/inputs/clam.cab \ $(PROJ_SRC_DIR)/inputs/clamdoc.tar.gz \ $(PROJ_SRC_DIR)/inputs/clam.exe \ $(PROJ_SRC_DIR)/inputs/clam.exe.bz2 \ $(PROJ_SRC_DIR)/inputs/clam-v2.rar \