Tuesday, September 28, 2004

Complaining about compilers

Like many astronomers, I have written or acquired a small set of Fortran tasks to help in data analysis. All these programs ran fine on the machines I used at Harvard (DEC Alphas), but today I tried to recompile one of them on my Linux machine at the office. Among the many issues with g77 on Linux: 1) It doesn't like the "encode" command, 2) It doesn't support some of the options on the "open" command, 3) It didn't like one of my subroutine names because it has been reserved as an as-yet-unused intrinsic, 4) It complains that I (intentionally) modified a loop variable within a loop, and 5) It doesn't seem to deal with units defined as FORTnn environment variables. After much futzing, I got the program to compile without error, but the algorithm didn't work, even though the program compiled and ran without error on the same data on the Alphas (which I verified today).

Okay, I admit that some of the code is antiquated, and my coding technique is questionable. But that's no excuse for the multiple errors I encountered with g77 under Linux. If code compiles and runs properly on one platform, it ought to work on another platform with another compiler, without reediting.

7 Comments:

Blogger Eric said...

Being only an infrequent fortran user (when I inherit someone else's code), I'm not sure about all of the issues you mentioned. However some of them sound like you may have mixed f77 and f90. I think f77 supports a few of f90's features, but not all of them. You can't really blame a f77 compiler for not compiling f90 code.

Also, note that the DEC fortran compiler may have a few non-standard features (I know some brands do and think DEC is likely one of them, but not entirely sure.) So it could be partially DEC's fault for not warning you that you were using non-standard f77. If you want to test your code for standards compliance, I'd recommend trying the IBM fortran compiler.

Of course, it would seem to me that it should not compile sucessfully anything that has an ambiguous meaning. So I don't understand why it would compile and give a different anser, unless you did something bad. Given that fortran makes it very difficult to use real pointers, the obvious problem area is ruled out.

Perhaps there's an array accessed out-of-bounds? Or does fortran have some auto-array-bounds checking? I would think that there would at least be a compiler option avaliable to do that in fortran.

Or perhaps there's some difference in floating point round off error that's affecting your results. (I once worked with a student who put in a line that read "if(x==0)" where x was a floating point value determiend by solving differential equations and had it very different things depending on the outcome of the test!)

9/29/2004 01:04:00 PM  
Blogger acg said...

I haven't written anything in Fortran in years, and I hope I never have to do so again.

9/29/2004 04:26:00 PM  
Blogger Vincent said...

Indeed, DEC Fortran has quite a few features that aren't considered "standard", although I don't know what's standard and what's not. And it's possible that I'm mixing f77 and f90, although the g77 manual claims to support a lot of f90 (and DEC Fortran) extensions.

Anne: What didn't you like about Fortran? Other than fixed-form format (and some unknown compatibility issue I'm facing), it's pretty straightforward. And even fixed-form format isn't compulsory under f90 (and some f77) compilers.

9/30/2004 12:51:00 AM  
Blogger Eric said...

For small projects, Fortran is pretty good (assuming you have a version where whitespace does not have meaning). But if you're working on larger coding projects, it's much harder to build, maintain, and expand than C++. Also, now that C++ has templates I find C+++ code is much more reusable. And stl has saved me a bunch of time that would be spent reimplementing basic algorithms in fortran.

9/30/2004 01:26:00 AM  
Blogger Ben said...

I confess, I've never written a word of fortran! :)

I too have found stl to be extremely usefull when writing in C++. There's nothing worse than having to write simple things like queues from scratch. Even in C though there are still some platform issues (like endianness and word/address size) to worry about when programming.

9/30/2004 11:25:00 AM  
Blogger Qian said...

Which is why java can be so nice to program in for a lot of things. You don't have to worry about things that are too low level and for most purposes the performance is adequate. The built-in class library is pretty comprehensive for most basic things and there's a lot of other libraries out there. But then come deployment time you find that you've got to lug around this huge runtime all over the place since it really just simulates cross-platformness by making you code to its own platform. I'm eagerly waiting for GCJ, which can compile java directly to object code, to finally become usable enough. But I guess java wouldn't be all that great for heavy numeric work anyway since it has no operator overloading.

"The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++."
-- Richard P. Gabriel in 1991

Sadly for the software world I think that's still true for 2005.

9/30/2004 01:29:00 PM  
Blogger acg said...

I once had to find a bug in a Fortran program that was as long as a book. The program would compile fine, but when run it crashed the server. I tried debugging it, but that crashed too. The sysadmin had to hard reset the machine! This thing took a while to compile, too. It took me so long to find this stupid bug, and what was it? One space! ONE SPACE in the entire program!

9/30/2004 11:18:00 PM  

Post a Comment

<< Home