llvm dev - Sep 2006 - [LLVMdev] compiling the full SPEC CPU2000 suite to LLVM bytecode

Hello,

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:

JIT problems:
<start>
Running: /home/kehoste/work/LLVM/1.8/llvm/projects/llvm-test/ 
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/ 
lli-force-interpreter=false ../17'.
Program terminated with signal 6, Aborted.

warning: svr4_current_sos: Can't read pathname for load map: Input/ 
outpu        t error
</end>

Other tests:
<start>
  /home/kehoste/work/LLVM/1.8/llvm/Release/bin/fpcmp: Comparison  
failed, not a numeric difference.
******************** TEST (llc) '178.galgel' FAILED!  
********************
Execution Context Diff:
</end>
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  
undefined references:

/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  
`ltmp_6792_156'
/tmp/ccGCQxYs.o(.text+0x76f1):175.vpr.cbe.c: undefined reference to  
`ltmp_6793_157'
/tmp/ccGCQxYs.o(.text+0x76fb):175.vpr.cbe.c: undefined reference to  
`ltmp_6794_156'

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.
>
> <path>/SPEC_CPU2000_1.3_src/benchspec/CINT2000/253.perlbmk/src/
> 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/ 
pipermail/llvm-commits/Week-of-Mon-20060828/037184.html
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  
fixed.
> *** 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/
> beam.f
> 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/ 
nplux51na_rh90_282.tgz).
>
> *** 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):

modify Makefile.nagfortran:

CPPFLAGS += -I$(F95_DIR)/lib
LDFLAGS += $(F95_DIR)/lib/quickfit.o $(F95_DIR)/lib/libf98.so $ 
(F95_DIR)        /lib/libf98.a

I'll also submit a bug report for this one.

greetings,

Kenneth

-- 

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
kenneth.hoste at elis.ugent.be
http://www.elis.ugent.be/~kehoste

On Fri, 1 Sep 2006, Kenneth Hoste wrote:
> 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.
Kenneth,

In general, I am more than happy to help people on this list.  It is good 
for the community and I enjoy helping people be successful at what they 
do.  However, my time is finely divided by many different things I'm 
juggling on an on-going basis: it's not "my job" to monitor this
list and
respond to your emails.  As such, I would appreciate it if you 
investigated the problems and tried to find solutions on your own for some 
of these issues: I feel like you aren't doing "your share" of the 
investigation work, you are just complaining about stuff that doesn't 
work.

I'm sorry that things are not working for you "out of the box". 
The one
useful thing I can contribute w.r.t. this email is that the *warnings* 
about crtend can be simply ignored.  If you update to llvm cvs, they will 
be gone, but they don't hurt anything with LLVM 1.8.

I hope that you do figure out what has changed between NAG 5.0 and 5.1, 
because I *do* want you to be successful.  If NAG doesn't work, perhaps 
you could contribute to getting gfortran up and running.

-Chris
> +++ 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:
>
> JIT problems:
> <start>
> Running: /home/kehoste/work/LLVM/1.8/llvm/projects/llvm-test/
> 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/
> lli-force-interpreter=false ../17'.
> Program terminated with signal 6, Aborted.
>
> warning: svr4_current_sos: Can't read pathname for load map: Input/
> outpu        t error
> </end>
>
> Other tests:
> <start>
>  /home/kehoste/work/LLVM/1.8/llvm/Release/bin/fpcmp: Comparison
> failed, not a numeric difference.
> ******************** TEST (llc) '178.galgel' FAILED!
> ********************
> Execution Context Diff:
> </end>
> 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
> undefined references:
>
> /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
> `ltmp_6792_156'
> /tmp/ccGCQxYs.o(.text+0x76f1):175.vpr.cbe.c: undefined reference to
> `ltmp_6793_157'
> /tmp/ccGCQxYs.o(.text+0x76fb):175.vpr.cbe.c: undefined reference to
> `ltmp_6794_156'
>
> 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.
>>
>> <path>/SPEC_CPU2000_1.3_src/benchspec/CINT2000/253.perlbmk/src/
>> 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/
> pipermail/llvm-commits/Week-of-Mon-20060828/037184.html
> 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
> fixed.
>
>> *** 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/
>> beam.f
>> 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/
> nplux51na_rh90_282.tgz).
>>
>> *** 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):
>
> modify Makefile.nagfortran:
>
> CPPFLAGS += -I$(F95_DIR)/lib
> LDFLAGS += $(F95_DIR)/lib/quickfit.o $(F95_DIR)/lib/libf98.so $
> (F95_DIR)        /lib/libf98.a
>
> I'll also submit a bug report for this one.
>
> greetings,
>
> Kenneth
>
>
-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Chris,

On 01 Sep 2006, at 19:53, Chris Lattner wrote:
> On Fri, 1 Sep 2006, Kenneth Hoste wrote:
>> 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.
>
> Kenneth,
>
> In general, I am more than happy to help people on this list.  It  
> is good for the community and I enjoy helping people be successful  
> at what they do.  However, my time is finely divided by many  
> different things I'm juggling on an on-going basis: it's not
"my
> job" to monitor this list and respond to your emails.  As such, I  
> would appreciate it if you investigated the problems and tried to  
> find solutions on your own for some of these issues: I feel like  
> you aren't doing "your share" of the investigation work, you
are
> just complaining about stuff that doesn't work.
>
> I'm sorry that things are not working for you "out of the
box".
> The one useful thing I can contribute w.r.t. this email is that the  
> *warnings* about crtend can be simply ignored.  If you update to  
> llvm cvs, they will be gone, but they don't hurt anything with LLVM  
> 1.8.
>
> I hope that you do figure out what has changed between NAG 5.0 and  
> 5.1, because I *do* want you to be successful.  If NAG doesn't  
> work, perhaps you could contribute to getting gfortran up and running.
>
My last email wasn't a cry for help, it was a follow-up on the  
problems I've encountered using f95. Some problems are still open,  
and I will get to the bottom of them.
Most of the problems I've been faced with are f95 related, and are  
caused by the fact that the support for f95 in LLVM was incomplete  
and tuned for Mac only.
I'm not saying things have been done wrong, I just noticed support  
from f95 is all but complete, which is a shame for the things I'm  
trying to do with LLVM.
The problems have little or nothing to do with the fact that I'm  
using the latest version of NAG f95.

My last email, to which you replied, mentioned a list of fixes for  
the errors I've encountered with f95. The people from NAG support  
asked me to post the fixes on this
mailing list, so I did. I also mentioned my remaining problems,  
because someone (who's more experienced than me with LLVM), might  
know of a solution.
I've changed too many small things in my current LLVM setup, that's  
why I'm not working from CVS. I figured the last 1.8 release was the  
best thing to start from.
I will submit bug fixes for the various problems I've encountered, to  
the best of my ability.

About the crtend errors, I didn't know they were harmless. It seemed  
they were the cause of some major problems, but apparently they are not.
Some of the problems I'm facing are due to incomplete documentation  
of the gcc4 frontend, which has come up on this mailing list in the  
last couple of weeks (the emit-llvm flag which has to be used with  
the new frontend). For new users, like me, this is a shame, because  
trying to figure out stuff which have been solved already, is quite  
demotivating.

Getting the gfortran frontend working would be a great plus for me,  
but I don't have the time nor knowledge of LLVM to get it up and  
running myself. I am willing to test any ongoing
work, but am unable to do it myself. Getting the full SPEC CPU2000  
benchmark to compile to LLVM bytecode seemed a much easier task,  
since I have been working with it for some time now. Unfortunately,  
some problems still remain in that area.

I hope this isn't the start of a war of some kind. I'm very pleased  
with LLVM, and think it can be a great asset for my research. I will  
be using it intensively in the upcoming
months, and hope to contribute to this interesting project as I do so.

greetings,

Kenneth

-- 

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
kenneth.hoste at elis.ugent.be
http://www.elis.ugent.be/~kehoste