compiling the full SPEC CPU2000 suite to LLVM bytecode

Hello LLVM-people,

I've been trying (on and off) to compile the _full_ SPEC CPU2000 benchmark suite to LLVM bytecode. The biggest problem
I'm facing is the Fortran benchmarks, for which some partial support is already available it seems (using f2c).

Unfortunately the f2c compiler only allows the translation of Fortran-77 programs to C code (which is then compiled using llvm-gcc).
Another solution is the commercial f95 NAG Fortran compiler, for which some support seems to be available in the Testsuite.
Only, I can't get it to work, although my NAG f95 compiler is working. Is it normal that this support is broken? I'm getting all kinds of errors...

Also, with the new gcc4 frontend, it seems the Fortran issue will disappear in the near future (with the use of gfortran). Is that correct? Or will there
be other problems? Is the entire benchmark suite (including Fortran benchmarks) being used the nightly tests?

Any pointers on getting the entire SPEC CPU2000 benchmark suite compiled to LLVM bytecode will be highly appreciated.

greetings,

Kenneth

I've been trying (on and off) to compile the _full_ SPEC CPU2000 benchmark suite to LLVM bytecode. The biggest problem
I'm facing is the Fortran benchmarks, for which some partial support is already available it seems (using f2c).

ok.

Unfortunately the f2c compiler only allows the translation of Fortran-77 programs to C code (which is then compiled using llvm-gcc).
Another solution is the commercial f95 NAG Fortran compiler, for which some support seems to be available in the Testsuite.
Only, I can't get it to work, although my NAG f95 compiler is working. Is it normal that this support is broken? I'm getting all kinds of errors...

I use NAG with llvm-gcc4. What sort of errors do you get? Did you configure llvm-test with the appropriate flags to find it?

Also, with the new gcc4 frontend, it seems the Fortran issue will disappear in the near future (with the use of gfortran). Is that correct? Or will there
be other problems?

Someone needs to do the work to test gfortran and fix any problems it runs into. I'm not aware of anyone doing this, though it's probably not hard.

Is the entire benchmark suite (including Fortran benchmarks) being used the nightly tests?

On some testers, yes. This one is:
http://llvm.org/nightlytest/fulltest.php?machine=36&night=811

Any pointers on getting the entire SPEC CPU2000 benchmark suite compiled to LLVM bytecode will be highly appreciated.

What problems are you hitting?

-Chris

Hi Chris,

I use NAG with llvm-gcc4. What sort of errors do you get? Did you configure llvm-test with the appropriate flags to find it?

Yes, I did. llvm-test is configured as follows: (in /work/LLVM/1.8/llvm/project/llvm-test):

./configure --with-spec2000=/work/SPEC_CPU2000_1.3_src/benchspec --without-f2c --with-f95-bin=/work/NAG_f95/bin --with-f95-lib=/work/NAG_f95/lib --with-f95-inc=/work/NAG_f95/lib --with-llvmsrc=/work/LLVM/1.8/llvm --with-llvmobj=/work/LLVM/1.8/llvm

(the inc=.../lib part is correct, the headers files are indeed located in the lib dir of NAG f95).

which returns the following messages concerning my setup:

checking for spec2000 benchmark sources... yes, in /work/SPEC_CPU2000_1.3_src/benchspec
...
checking for nag-fortran bin/lib/include locations... found via --with options
checking sanity for program f95... yes

I then cd into llvm-test/External/SPEC and run make to compile the benchmarks to LLVM bytecode. Make stops with the following error messages:

/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/lucas_distrib_spec.f90:2995: error: syntax error before ‘(’ token
/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/lucas_distrib_spec.f90:2999: error: redefinition of ‘pTmp4’
/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/lucas_distrib_spec.f90:225: error: previous definition of ‘pTmp4’ was here
/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/lucas_distrib_spec.f90:2999: warning: data definition has no type or storage class
/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/lucas_distrib_spec.f90:2999: error: syntax error before numeric constant
/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/lucas_distrib_spec.f90:2999: warning: data definition has no type or storage class
make[2]: [Output/lucas_distrib_spec.o] Error 1 (ignored)
g++ -o Output/189.lucas.native Output/lucas_distrib_spec.o -lm /lib/NAGWare/quickfit.o -Xlinker -flat_namespace /lib/NAGWare/libf97.dylib /lib/NAGWare/libf96.a
g++: Output/lucas_distrib_spec.o: No such file or directory
g++: /lib/NAGWare/quickfit.o: No such file or directory
g++: /lib/NAGWare/libf97.dylib: No such file or directory
g++: /lib/NAGWare/libf96.a: No such file or directory
make[2]: [Output/189.lucas.native] Error 1 (ignored)

Any further suggestions what might be wrong are welcome... Especially the /lib/NAGWare/... part puzzles me.. I did show with configure where the NAGWare lib dir is located, so why this error?

Also, with the new gcc4 frontend, it seems the Fortran issue will disappear in the near future (with the use of gfortran). Is that correct? Or will there
be other problems?

Someone needs to do the work to test gfortran and fix any problems it runs into. I'm not aware of anyone doing this, though it's probably not hard.

So, in the future it will be possible to use gcc/g++/gfortran to generate LLVM bytecode? That would be really cool... because GCC is really friendly to people doing research for various reasons. Also, the Fortran-to-C translation is only a temporary solution. Being able to use GCC as a whole for all SPEC benchmarks would be a great plus.

If you can give me more specific details on how to test gfortan to emit llvm bytecode, I'll be glad to try it. I'm not all that familiar with LLVM at all, but if I can find the time (which I won't in the next few weeks), I'll be glad to help.

greetings,

Kenneth

I use NAG with llvm-gcc4. What sort of errors do you get? Did you configure llvm-test with the appropriate flags to find it?

Yes, I did. llvm-test is configured as follows: (in /work/LLVM/1.8/ llvm/project/llvm-test):
./configure --with-spec2000=/work/SPEC_CPU2000_1.3_src/benchspec -- without-f2c --with-f95-bin=/work/NAG_f95/bin --with-f95-lib=/work/NAG_f95/lib --with-f95-inc=/work/NAG_f95/lib --with-llvmsrc=/work/LLVM/1.8/llvm --with-llvmobj=/work/LLVM/1.8/llvm

What does this print?

$ grep F95 .../projects/llvm-test/Makefile.config
?

I then cd into llvm-test/External/SPEC and run make to compile the benchmarks to LLVM bytecode. Make stops with the following error messages:

/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/ lucas_distrib_spec.f90:2995: error: syntax error before ‘(’ token

Very strange. Have you *looked* at the file? Does it looks reasonable? What's going on on that line?

Have you tried to debug this at all?

Any further suggestions what might be wrong are welcome... Especially the /lib/NAGWare/... part puzzles me.. I did show with configure where the NAGWare lib dir is located, so why this error?

I don't know, maybe your Makefile.config entries will shed light on this.

> Also, with the new gcc4 frontend, it seems the Fortran issue will > disappear in the near future (with the use of gfortran). Is that > correct? Or will there
> be other problems?
Someone needs to do the work to test gfortran and fix any problems it runs into. I'm not aware of anyone doing this, though it's probably not hard.

So, in the future it will be possible to use gcc/g++/gfortran to generate LLVM bytecode?

Yes, if someone does the work.

If you can give me more specific details on how to test gfortan to emit llvm bytecode, I'll be glad to try it. I'm not all that familiar with LLVM at all, but if I can find the time (which I won't in the next few weeks), I'll be glad to help.

I don't have any specific details to give you, as I haven't tried it before. I would suggest getting LLVM CVS HEAD, llvm-gcc SVN head, and then configuring llvm-gcc with gfortran enabled. See what works and what doesn't, debug, fix, submit patch, repeat.

-Chris

I use NAG with llvm-gcc4. What sort of errors do you get? Did you configure llvm-test with the appropriate flags to find it?

Yes, I did. llvm-test is configured as follows: (in /work/LLVM/1.8/ llvm/project/llvm-test):
./configure --with-spec2000=/work/SPEC_CPU2000_1.3_src/benchspec -- without-f2c --with-f95-bin=/work/NAG_f95/bin --with-f95-lib=/work/NAG_f95/lib --with-f95-inc=/work/NAG_f95/lib --with-llvmsrc=/work/LLVM/1.8/llvm --with-llvmobj=/work/LLVM/1.8/llvm

What does this print?

$ grep F95 .../projects/llvm-test/Makefile.config

-bash-3.00$ grep F95 projects/llvm-test/Makefile.config
# F95: Enable LLVM to run Fortran benchmarks without a Fortran front-end
USE_F95=1
F95_DIR :=
F95 := /work/NAG_f95/bin/f95
F95_INC := /work/NAG_f95/lib
F95_LIB := /work/NAG_f95/lib

Looks ok to me...

I then cd into llvm-test/External/SPEC and run make to compile the benchmarks to LLVM bytecode. Make stops with the following error messages:

/work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/189.lucas/src/ lucas_distrib_spec.f90:2995: error: syntax error before ‘(’ token

Very strange. Have you *looked* at the file? Does it looks reasonable? What's going on on that line?

Have you tried to debug this at all?

Any further suggestions what might be wrong are welcome... Especially the /lib/NAGWare/... part puzzles me.. I did show with configure where the NAGWare lib dir is located, so why this error?

I don't know, maybe your Makefile.config entries will shed light on this.

> Also, with the new gcc4 frontend, it seems the Fortran issue will > disappear in the near future (with the use of gfortran). Is that > correct? Or will there
> be other problems?
Someone needs to do the work to test gfortran and fix any problems it runs into. I'm not aware of anyone doing this, though it's probably not hard.

So, in the future it will be possible to use gcc/g++/gfortran to generate LLVM bytecode?

Yes, if someone does the work.

This is just a single error appearing, I'm getting hundreds, if not thousands, of these error, for various benchmarks/files.

Which LLVM version is working for you with F95?

Kenneth

$ grep F95 .../projects/llvm-test/Makefile.config

-bash-3.00$ grep F95 projects/llvm-test/Makefile.config
# F95: Enable LLVM to run Fortran benchmarks without a Fortran front-end
USE_F95=1
F95_DIR :=
F95 := /work/NAG_f95/bin/f95
F95_INC := /work/NAG_f95/lib
F95_LIB := /work/NAG_f95/lib

Looks ok to me...

It doesn't to me. If you set F95_DIR to /work/NAG_f95 things will probably work much better for you.

This is just a single error appearing, I'm getting hundreds, if not thousands, of these error, for various benchmarks/files.

Which LLVM version is working for you with F95?

LLVM 1.7+.

-Chris

$ grep F95 .../projects/llvm-test/Makefile.config

-bash-3.00$ grep F95 projects/llvm-test/Makefile.config
# F95: Enable LLVM to run Fortran benchmarks without a Fortran front-end
USE_F95=1
F95_DIR :=
F95 := /work/NAG_f95/bin/f95
F95_INC := /work/NAG_f95/lib
F95_LIB := /work/NAG_f95/lib

Looks ok to me...

It doesn't to me. If you set F95_DIR to /work/NAG_f95 things will probably work much better for you.

No, that doesn't seem to be the problem. If I provide the additional --with-f95 option with the correct directory to configure,
I still get the same errors (although it mentions /work/NAG_f95/lib/NAGWare/... not found as errors now).
It seems the paths in Makefile.nagfortran (in llvm-test) are hardcoded (lib/NAGWare/quickfit.o and such).

When I adjust the settings in Makefile.nagfortran as follows, I'm able to get bytecode file for lucas, galgel and facerec, but make still quits with an error (after generating
bytecode files for 7 (out of 26) benchmarks.

Also, the file 'libf97.dylib' isn't in my NAG_f95/lib directory, and nothing remotely like it either.

Are some major changes in the NAG Fortran compiler itself the cause of this? Which version are you using? Which paths are present in the Makefile.nagfortran file?
I'm using the 5.1(216) release of f95.

This is just a single error appearing, I'm getting hundreds, if not thousands, of these error, for various benchmarks/files.

Which LLVM version is working for you with F95?

LLVM 1.7+.

Hmm, I'm using LLVM1.8 with the gcc4 frontend. I'm starting to get really frustrated by all this... :frowning:

greetings,

Kenneth

It doesn't to me. If you set F95_DIR to /work/NAG_f95 things will probably work much better for you.

No, that doesn't seem to be the problem. If I provide the additional --with-f95 option with the correct directory to configure,
I still get the same errors (although it mentions /work/NAG_f95/lib/ NAGWare/... not found as errors now).

Okay, well that's progress.

It seems the paths in Makefile.nagfortran (in llvm-test) are hardcoded (lib/NAGWare/quickfit.o and such).

ok

When I adjust the settings in Makefile.nagfortran as follows, I'm able to get bytecode file for lucas, galgel and facerec, but make still quits with an error (after generating
bytecode files for 7 (out of 26) benchmarks.

Also, the file 'libf97.dylib' isn't in my NAG_f95/lib directory, and nothing remotely like it either.

Are some major changes in the NAG Fortran compiler itself the cause of this? Which version are you using? Which paths are present in the Makefile.nagfortran file?
I'm using the 5.1(216) release of f95.

This sounds like differences in NAG version. I'm using 5.0(400). Perhaps newer versions broke our makefile.

If you'd like to investigate what is required to make it work with NAG 5.1, and modify Makefile.nagfortran as appropriate, we can merge it back into mainline adding code that autodetects the nag version and does the right thing.

-Chris

Bummer. I think I'll contact the NAG support for more info on this. Can you show me the content of your Makefile.nagfortran?
Also, it is possible to tell make only to compile benchmark X? How can I enforce this?

I'll try and get to the bottom of this. My evaluation period of the NAG compiler ends next week though... I'll hope I can figure it out before that time.

greetings,

Kenneth

Bummer. I think I'll contact the NAG support for more info on this. Can you show me the content of your Makefile.nagfortran?

It is identical to yours.

Also, it is possible to tell make only to compile benchmark X? How can I enforce this?

Go into the directory for that benchmark, then run 'make' or whatever.

-Chris

OK, I seem to be getting closer to the problem... When compiling a single benchmark, I noticed the following...

/work/NAG_f95/bin/f95 -w -S -O2 /work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/168.wupwise/src/dcabs1.f -o dcabs1.c -dusty -dcfuns
Evaluation trial version of NAGWare Fortran 95 Release 5.1(216)
/home/kehoste/work/LLVM/1.8/llvm-gcc4-1.8-x86-linux/bin/llvm-gcc -DSPEC_CPU2000 -I/home/kehoste/work/LLVM/1.8/llvm/projects/llvm-test/External/SPEC/CFP2000/168.wupwise -I/home/kehoste/work/LLVM/1.8/llvm/projects/llvm-test/External/SPEC/CFP2000/168.wupwise -I/home/kehoste/work/LLVM/1.8/llvm/include -I/home/kehoste/work/LLVM/1.8/llvm/projects/llvm-test/include -I../../../../include -I/home/kehoste/work/LLVM/1.8/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -I /work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/168.wupwise/src/ -I/work/NAG_f95/lib -O3 -S dcabs1.c -o Output/dcabs1.ll -emit-llvm
In file included from /work/SPEC_CPU2000_1.3_src/benchspec/CFP2000/168.wupwise/src/dcabs1.f:1:
/work/NAG_f95/lib/f95.h:109: error: syntax error before ‘Logical4’
/work/NAG_f95/lib/f95.h:109: warning: data definition has no type or storage class
/work/NAG_f95/lib/f95.h:118: error: syntax error before ‘Integer4’
/work/NAG_f95/lib/f95.h:118: warning: data definition has no type or storage class

This seems to suggest something is wrong with the f95.h file provided by NAG. This would be very strange, since I can't imagine them
releasing something without thorough testing on a common platform (Linux/x86). I've mailed the support, but their reply seems to be quite slow...

greetings,

Kenneth

I tried tom compile each of the SPEC CPU2000 benchmarks using the make command is each respective subdirectory of
llvm-test/External/SPEC.

My setup:

LLVM-1.8 with the gcc4 frontend (gcc-4.0.1). The NAG f95 compiler is v5.1(216). My platform is Fedora Core 4 on a Intel Pentium 4.

I was confronted with 6 different errors for the various benchmarks, 4 of which are relate to the NAG f95 compiler. See below for details.
I seems most of the error are directly related to f95, which seems to have undergone some changes in the 5.1 release. Two errors are related
to LLVM I think, (crtend and the syntax error for perlbmk).

Any hints to solve these problems are welcome. I've contacted the f95 people on the NAG-specific problems.

*** cannot find library crtend

This seems to be LLVM-specific. I've check the FAQ, and this is actually mentioned there. Only, it says to
define the LLVM_LIB_SEARCH_PATH environment variable. Only, I can't find libcrtend.a anywhere in the
cfrontend directories. Is there a known workaround for this? And if there is, why isn't it in the documentation?

Affected benchmarks: equake, lucas, vpr, gcc, crafty, eon, gcc

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

+++ following errors seem to be NAG-specific +++

*** f95.h

There seem to be some changes in the f95.h file for version 5.1 which cause llvm-gcc to throw an error. I suspect there's
a small problem, perhaps with the detection of my system. I guess this has more to do with the NAG compiler than with LLVM itself.
Nevertheless, I wanted to mention it.

llvm-gcc <with-a-bunch-of-options> -O3 -S dcabs1.c -o Output/dcabs1.ll -emit-llvm
In file included from <path>/SPEC_CPU2000_1.3_src/benchspec/CFP2000/168.wupwise/src/dcabs1.f:1:
<path>/lib/f95.h:109: error: syntax error before ‘Logical4’
<path>/lib/f95.h:109: warning: data definition has no type or sto rage class
<path>/lib/f95.h:118: error: syntax error before ‘Integer4’
...

Affected SPEC CPU2000 benchmarks: wupwise, swim, mgrid, applu

*** f95 PANIC

Another f95 specific issue is a PANIC when compiling the code of apsi to C code. More specific:

Panic: apsi.f: Unexpected expr node 47050 type 414 in tree flattener
Internal Error -- please report this bug

Again, this is no job for the LLVM people.

Affected benchmarks: apsi

*** libf97.dylib not found

...simply because it's not on my system. I guess this changed in the 5.1 release of f95.
Also, there's no NAGWare subdirectory of the lib directory, which should be the case according to the NAG documentation.
It seems the libraries are directly located in <path>/lib.
This should probably be fixed in the Makefile.nagfortran, but I don't know how (since there's no other *dylib file available it seems).
This only generates a warning from gccld, but I think it's the cause of the problems which are reported subsequently.

Affected benchmarks: galgel, facerec, sixtrack

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

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!

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

Chris,

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