[LLVMdev] compiling the full SPEC CPU2000 suite to LLVM bytecode
kenneth.hoste at ugent.be
Fri Sep 1 07:46:03 PDT 2006
Some problems were solved, new ones arised... Getting closer though...
The fixes for the previous problems are at the bottom of this email,
bug reports will be submitted when all problems are solved.
+++ New/remaining problems +++
Currently, 9/26 benchmarks compile and run succesfully. One (fma3d)
still has a f95 related problem (see below).
The other 16 are divided into two groups:
*** 1) *** bytecode builds ok, but exection fails
For 10 benchmarks the execution fails as follows:
RunSafely.sh 500 galgel.in galgel.out /home/kehoste/work/LLVM/1.8/
llvm/Release/bin/lli -force-interpreter=false ../178.galgel.llvm.bc
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
Core was generated by `/home/kehoste/work/LLVM/1.8/llvm/Release/bin/
Program terminated with signal 6, Aborted.
warning: svr4_current_sos: Can't read pathname for load map: Input/
outpu t error
failed, not a numeric difference.
******************** TEST (llc) '178.galgel' FAILED!
Execution Context Diff:
Strangely enough, no additional output (error or warnings) is
generated. Also, the execution diff seems to be empty.
Additionally, I don't think the programs get executed at all, because
make runs too fast.
For gap/gcc, only the cbe test fails, the other (including JIT) are ok.
Affected benchmarks: galgel, equake, lucas, gcc, gap, facerec,
sixtrack, wupwise, mgrid, applu, apsi
Since these include both SPECfp and SPECint benchmarks, this has
nothing todo with f95.
*** 2) *** Undefined references
With 3 benchmarks (vpr, crafty and eon), I'm getting similar
/tmp/ccGCQxYs.o(.text+0x76b2): In function `init_chan':
175.vpr.cbe.c: undefined reference to `ltmp_6791_156'
/tmp/ccGCQxYs.o(.text+0x76cb):175.vpr.cbe.c: undefined reference to
/tmp/ccGCQxYs.o(.text+0x76f1):175.vpr.cbe.c: undefined reference to
/tmp/ccGCQxYs.o(.text+0x76fb):175.vpr.cbe.c: undefined reference to
These also include SPECint benchmarks, so again, this has nothing
todo with f95.
> *** perlbmk syntax error
> Compiling the perlbmk benchmark produces a syntax error. This may be
> a GCC4 problem.
> nt_perlmain.c:80: error: syntax error before ‘int’
> (among others)
> This specific line of code is:
> DllExport int RunPerl(int argc, char **argv, char **env, void *ios);
> which does seem very strange syntax to me...
> Affected benchmarks: perlbmk.
> This one remains. Solutions/ideas are very welcome.
This one remains. Solutions/ideas are very welcome.
+++ Problems solved +++
> *** cannot find library crtend
This is a know problem. Fix is shown at http://lists.cs.uiuc.edu/
Thanks to Reid for mentioning this (on IRC).
Reason: crtend is a library used in the old frontend, and the
Makefile weren't aware of this.
> +++ following errors seem to be NAG-specific +++
The NAG support was really friendly, here's how the NAG problems got
> *** BEAM (fma3d)
> There seem to be some issues with the fma3d benchmark, when
> translating from Fortran to C:
> f95 -w -S -O2 <path>/SPEC_CPU2000_1.3_src/benchspec/CFP2000/191.fma3d/
> src/beam.f90 -o beam.c -dusty -maxcontin=69
> Error: <path>/SPEC_CPU2000_1.3_src/benchspec/CFP2000/191.fma3d/src/
> 90: Binding label 'beam_' of COMMON/BEAM/ matches module BEAM_
> [f95 error termination]
> Also a f95-related issue I'd guess.
> Affected benchmarks: fma3d.
This is yet to be solved.
> *** problems with f95.h
Adding -DINT64='long long' to the CPPFLAGS solved this. I will submit
a bug report for this some time soon.
> *** f95 PANIC
This was a known problem, which is fixed in the latest edit
(available at ftp://ftp.nag.co.uk/pub/nagware_support/
> *** libf97.dylib not found
It appears the *.dylib files are Mac specific. Apparently the usage
of f95 was only tested on Mac (I think Chris did this?).
Solution (for Linux/x86):
CPPFLAGS += -I$(F95_DIR)/lib
LDFLAGS += $(F95_DIR)/lib/quickfit.o $(F95_DIR)/lib/libf98.so $
I'll also submit a bug report for this one.
Statistics are like a bikini. What they reveal is suggestive, but
what they conceal is vital (Aaron Levenstein)
ELIS - Ghent University
kenneth.hoste at elis.ugent.be
More information about the llvm-dev