The back end and libraries are now up for general testing on a variety of boxes and operating systems. The tarball is usually updated as the web page is. To download and install g95 on unix systems, run the following command (originally from Joost Vandevondele):

wget -O - http://ftp.g95.org/g95-x86-
linux.tgz | tar xvfz -

This will create a directory named 'g95-install' in the current directory. Run (or better yet make an appropriate symbolic link to) ./g95-
install/bin/i686-pc-linux-gnu-
g95 in order to run g95.

2003 Archive

December 22

Outta town for a week or so, for the obvious reason... Merry Christmas

December 17

Lothar Birk sent in a problem with EQUIVALENCE blocks-- these have to be arranged in the old way before the fix for COMMON blocks.

I've also fixed the F descriptor so that it squishes out a zero to the left of the decimal point if the width requires it.

There haven't been many new bug reports the couple days, and it is just as well, since I haven't had much time for fixing them. And it is going to get worse. Probably not much on g95 until next year.

December 13

Douglas Cox sent a problem where the library was incorrectly truncating files. Files have be truncated at the point following the last write in sequential mode, but the truncation was happening in read mode. Fixed. Martien Hulsen sent a problem where an array section of an assumed-size array was not being printed properly. Also fixed.

He also sent in a problem where common blocks where not being properly allocated. After this was fixed, it flushed out a bug in one of the NIST suites, where the blank common was being allocated different lengths in different program units. Steven Yellowhair reported a problem in scalarization where the vector part of the subscript wasn't the first subscript. Fixed.

Delbert Franz pointed out that an E form with |exponent|>999 should be defined. I want g95 to support the 80-bit real*10 on the x86 and compatibles, so I've added it to the library. Unfortunately, this isn't testable right now.

Lothar Birk sent in a problem with a program that did lots of sequential unformatted IO. The bug was quite subtle and took a while to find. Lothar's code works now.

Michael Richmond sent in a problem in the front end where a function result was incorrectly being overwritten.

December 10

Joost reported a problem with the E format, the fact that printing zero printed "0.000E+01" instead of "0.000E+00". Martien mentioned this too, and I pointed out that 0.000x10^n = 0.0, but it's clear that people just expect to see it this way. Doug also sent in a problem with E, where the optional leading zero wouldn't get squeezed out if the format was narrow enough. Joost found another problem where if |exponent|>99, the exponent shifts to a form that eliminates the letter. All fixed now.

Joost had another problem involving an array constructor argument of an elemental intrinsic function. The type wasn't being correctly propagated to the type of the constructor.

Peter Weinert reported a similiar problem to his last, a parameter structure in a module, instead of a parameter array. Both of these things need to be stored in the module, and I think that these are the only cases.

Michael Richmond sent in a problem with the bounds checking on an assumed-size array. It seems the upper bound was being checked, when it should not have been. Fixed now.

December 9

Doug pointed out a NIST test that failed with complex logarithm. Joost and I sent a couple emails back and forth, and figured out that the branch cut is correctly implemented, the front end a had a bug in the simplification of complex logarithms that has been fixed and also that the front end doesn't handle minus zero quite right.

Michael Richmond sent in a problem with an structure constructor that contained an array constructor. After some suitable generalizations, not only does this work, but the totally general case of a structure constructor containing an array constructor of other structures which contain other array constructors now works. As you might imagine, this involved making some functions recursive. Michael also sent in a crash on the ENTRY statement that has been fixed. This was in the parser, but ENTRY still has to be implemented by the back end.

December 8

Don Isgitt reported a problem with FORALL, some of the statements within a forall weren't being scalarized. Fixed now.

December 7

Joost reported problem with the USE statement. It turns out that a variable can be USEd multiple times. There was also another problem with the INQUIRE statement. The way I had things set, the existence property of a unit was equivalent to that unit being open. This isn't the same thing. G95 allows unit numbers from zero to HUGE(0), so all units exist. Fixed now.

There was another problem Joost reported that had to do with passing a pointer array that was a component of a derived type. Now fixed.

Douglas sent in a bizzare problem where the H's in hollerith constants were not being printed. He also reports that several more of the Meissner examples now work.

Steven Yellowhair reported a problem with scalarization-- functions returning arrays inside of vector subscripts weren't handled quite right. Fixed now.

December 4

Douglas Cox sent in a program a while back that showed a minor issue with the random number generator. G95 uses Marsaglia's xor-shift generator with three words of state, discussed below in the April 23rd entry on this page. This generator has a number of nice properties-- fast, random and a small number of state words (three). Douglas's program asked the user for the initial state of the generator by calling RANDOM_SEED(SIZE=n) to get the number of words, then asking the user for that number of seed words. In other implementations, the number of words range from a couple dozen to tens of thousands. You need another RNG to seed your RNG...

The problem is that people are lousy random number generators. If you chooses a seed for the xor-shift generator with lots of zero bits, the first half dozen numbers tend to be close to zero as well. A workaround is to replace the user's seed with a hashed version of the seed. The requirement of GET and PUT means that the hash has to be reversible. Douglas and I tossed around the idea of simply iterating the generator forward a dozen times when a new seed was set, but this would have required storing a dozen intermediate states in order to make GET and PUT work properly.

It occurred to me last night that the ideal hash function is simply exclusive-oring the seed with some number with an relatively equal number of zero and one bits. It's reversible and fast. The magic numbers are 0xf95f9500, 0x0f95f950, 0x00f95f95. If your seed is close to the bit pattern of these numbers, then you'll get some initially unrandom-looking numbers.

John Dormand sent in a problem dealing with an assumed length character parameter array. The actual sizes of the elements are now correctly propagated to the assumed length.

John's code also had a problem with parameter arrays that lived in modules. Fixed. Also reported by Peter Weinert.

December 3

Delbert and I have been corresponding over the last couple of days, trying to track down a serious slowdown in I/O. The problem was that I ended up using lots of other system calls instead of caching data at the user level and some of these system calls are expensive and apparently have run times proportional to at least the cube of the file size. Things are much faster now. We were also trying to trace a memory leak, but that somehow evaporated, even though the changes didn't have anything to do with memory allocation.

Douglas has moved on to the NIST test suites and we are keeping track of how things are progressing there as well as the other suites mentioned over the last couple of days. Douglas did report a problem with another Meissner that has been fixed, the problem dealt with a dummy procedure. The integral even comes out right.

December 2

Fixed a longstanding problem with variable length character functions reported by Jim Rosinski, Douglas Cox (a trio of Meissners), Martien Hulsen and Frode Meling.

November 30

Doug pointed out some problems with complex sine and cosine that have been fixed.

Joost pointed out that some people use \t to print tabs. I hadn't thought of that, so the expansion for \t (and \b and \f) is now turned off. Expanding unprintable characters into these sequences has already paid off-- when \x00\x00\x00\x00 comes out, I can tell that something is wrong.

November 29

Doug reported that the recent format fixes have fixed other problems that he has reported.

Martien and Michael both reported an internal error that was really a check on my part to see if some code involving simplification of constructors was dead or not. It wasn't and a rewrite was needed elsewhere. This also fixes a Meissner problem reported by Douglas involving simplification of constructors.

Martien reported that minus zero was not printing correctly. Of course, I was comparing numbers against zero to get the sign, which is of course, incorrect. This has been fixed.

Doug found some problems with reading the A descriptor and complex sine and cosine that have been fixed.

November 27

Implemented a suggestion from Douglas a while ago, that F does. For formatted output, unprintable character sequences are expanded with C-like backslash codes, \n, \r, \xff if necessary. This is on by default, set G95_EXPAND_UNPRINTABLE to zero if the literal characters are desired.

Bell characters (\a) are handled separately. If the G95_QUIET variable is set to true, bell characters are silently deleted in formatted output. This variable is false by default, so g95 programs will beep at you.

Fixed a small off-by-one problem introduced to E and D editing from yesterday's fixes to the P descriptor.

Michael Richmond reported a problem in the front end with continuation statements in fixed source mode that has been fixed.

November 26

Delbert Franz reported a problem with the P descriptor that has been fixed.

Douglas Cox noted that several of the Meissner codes that he had reported bugs with now work correctly, no doubt from yesterday's fixes to I/O.

November 25

Douglas reported a subtle problem with floating point reads that has been fixed.

Steven Yellowhair reported a problem with reading an array containing a vector subscript that has been fixed.

November 24

Martien Hulsen reported a problem associated with nesting FORALL statements. Fixed now.

Joost sent in a problem with vector subscripts that seems to have been fixed sometime previously, and another associated with printing an array with a vector subscript that needed fixing.

Doug sent two programs, one with an array return issue, another with a scalarization issue that both seem to have already been fixed as well as a bug in FORALL that is now fixed. Doug reports that many more of the Meissner examples now work.

Frode Meling pointed out that Hollerith constants weren't supported. I've added support for them.

November 23

Martien Hulsen reported another problem with direct access I/O. Multiple problems have been fixed in this area.

Took a break from other bugs and implemented FORALL.

November 21

I goofed last night, turing off the scalarizer trying to reproduce a problem Philippe sent in (I couldn't). I didn't turn it back on before producing the last build of the night. Reported by Joost, Alvin, Lothar, Édouard and Delbert.

November 20

Michael Richmond reported a problem with setting a function return value from within a contained subroutine. This one was a bit difficult to diagnose, but it is fixed now.

John Dormand reported a crash on a code that now seems to run fine. Another case of fixing multiple problems without realizing it.

Douglas Cox sent in a problem with one of the Meissner examples-- The BACKSPACE intrinsic wasn't working correctly. Also noted by Delbert Franz.

Joost reported that g95 was not allowing loop variables to be pointers. My draft of the standard prohibits this, but all other vendors seem to allow this, as does the f2003 draft. This may have been removed at the last minute from the f95 standard. In any case, I've removed the prohibition.

Philippe Marguinaud sent in a front-end problem dealing with PARAMETER variables that is now fixed.

Alvin Brattli had a weird situation where a common block triggered an internal error when being loaded. Internal errors are supposed to be this-can't-happen sorts of things. Turned out the situation reported by the error can happen after all.

November 19

Xavier Leoncini reported that the EOSHIFT() intrinsic was still missing. This one was a bear to implement. I also ended up fixed a problem with returning character arrays.

Édouard Canot reported a while back that

PRINT *, HUGE(0.0d0)

Was printing infinity. Fixed now.

I have many, many bugs queued right now. I will fix them all! But not enough time tonight. One the nastier problems is that character returns (scalar) have to be rewritten. This one is requiring a lot of thought.

November 17

Travis Johnson and Martien Hulsen both sent in problems with unformatted I/O, Travis with sequential and Martien with direct. Both problems were because of bad memory management. Fixed.

Michael Richmond wrote in a while back to ask if g95 does/would support runtime checking of array bounds. I've implemented this feature, which is turned on with -fbounds-check. The checking is active inside of array expressions.

I've fixed several bugs dealing with the intialization of common blocks, including a string array initialization bug reported by Michael. The full generality of common blocks is almost there, and you won't notice it unless you do some of the strange but legal things that fortran lets you do.

Douglas sent in a table of how far g95 is on the examples in Meissner's book. The quick answer is about 3/4 of the way done. The table included annotations of what failed, and there is still quite a ways to go here. The thing that jumps is that the early chapters work fine, but the more esoteric stuff in later chapters needs work.

One of the problems was the CSHIFT() intrinsic, which is now implemented. Xavier Leoncini also mentioned this problem.

The most exciting report was a code that g95 compiles and runs correctly, but another vendor's compiler does not, reported by Douglas in one of Alan Miller's codes. Stay tuned for more of these! Woo hoo!

November 15

Douglas sent in three of Meissner's examples for solving a linear system. In two cases, a temporary variable was being use before it was set and in the last, the scalarization was not quite complete, and the back end ended up seeing a vector quantity. All work now. He also had another mystery bug in scalarization that has been fixed at some point in the last week or so. There was also a problem with the ':' format descriptor. Fixing this also brought out another bug in format reversion-- a new record wasn't always being started, which is now fixed.

November 14

Joost sent in a couple more problems with scalarization. The first had to do with scalarization of assumed-shape dummy arguments. The second had to do with using temporary arrays before they were allocated.

November 13

Picked what turned out to be a fairly involved bug today. Doug reported a problem with one of Meissner's code, involving an array constructor that contained an array expression. These are now supported, including general expressions like A+B, and vector subscripts.

Doug also reported a problem where the library was misreading some numbers, treating trailing blanks in an integer field as zero. It turned out that BLANK='ZERO' was being set for the implicitly opened units. Fixed now. He also had a program where kind=1 logicals didn't work. Taken care of now. For g95, the default is kind=4 logicals which fit in a word (32 bits). A kind=1 logical fits in a byte, so if you have millions flags, you can save lots of memory this way. The intrinsics support kind=1 logical mask arrays. If you find one that doesn't let me know.

Joost reports that his Car-Parinello code is now down to seven failing testcases, some of which may be duplicates. He plans a new bug hunt soon.

November 12

Charlie Zender reported a successful compile and link of the netcdf library. with it's testing subroutines. Running the code shows many failures. More to come here soon.

Joost and Michael both reported a problem with specification of dummy arrays involving other dummy arrays which has been fixed with much effort.

Michael reported a problem with scalarization, when an actual argument involved a vector subscript.

Martin Aichele also reported the problem (a couple days ago) involving PRESENT and optional array arguments that was fixed a couple days ago.

November 10

Found some more problems with the I/O library with respect to handling files that don't end in newlines. Fixed problem in list and formatted reads.

Douglas also pointed out that ms-dos files that are CR/LF terminated were having problems, so I've changed the carriage return to a separator. He also found a Meissner-problem in the front end regarding character constants.

The fix for .F90 didn't work, since I didn't recompile back far enough. This is fixed now.

November 9

Fixed more bugs in the new constructor handling functions. Things appear to work now.

Douglas Cox noted that files ending with '.F90' were not treated correctly, this is fixed now. Also added '.F95' to the list. He also pointed out some problems in the I/O library when doing list reads on files that didn't end in newlines. After some serious rearrangement, g95 now tries to do the reasonable thing, ie, act as if end of record was read, and signal an end of file on further reads.

November 8

Charlie Zender reports a lot of progress with his netcdf code. It compiles and links now, and we are actually testing execution now. I've added a new external function for this purpose-- EXIT(n), which when called exits the program and returns n to the operating system.

I've fixed a longstanding bug with array constructors. Now these can be of indefinite size, something like (/i,i=1,n/), where n is known only at runtime. Michael, Joost, Xavier and Doug all reported this problem.

Also found a nasty memory leak in the runtime library while this was being debugged.

Joost reported a problem with the PRESENT intrinsic when the argument was an array that has been fixed. Also found by Michael.

November 7

Joost and Douglas pointed out that MINLOC and MAXLOC were *still* messed up. It turns out that people use the DIM parameter, which does that weird little contraction, to force minloc/maxloc to return a scalar instead of an array. Fixed now.

Michael sent in a code conundrum. The problem was an initialization expression that contained an intrinsics that was overridden by an interface. Other vendors' compilers compiled it fine, while g95 reported an error. I wasn't sure, so I asked Richard Maine for claification. He pointed out that since the code is illegal (non-intrinsic in the initialization expression), the compiler is free to do what it will.

November 6

Fixed a problem with MINLOC() and MAXLOC() when the DIM parameter was being used. Reported by multiple people.

Douglas reported a problem with the P descriptor that is now fixed.

November 1

Both Michael Richmond and Martien Hulsen sent in an I/O error where the end of record was being hit too soon-- this was a fencepost style error. Michael seems to be working his way through some of Alan Miller's codes.

Joost sent in a problem with character functions, cause by a recent fix to assumed size character functions. Both styles work now.

Another problem he sent was using a function in a call to the ASSOCIATED() intrinsic, which now properly checks for the pointer attribute.

Michael sent in a problem dealing where the string lengths weren't getting propagated correctly in a component reference. They are now.

Francois Jacq also reported the problem with reads after advancing writes fixed some days ago and also reported that there wasn't any way to get an environment variable, so I've added an extern procedure 'getenv'.

Martin Aichele reported a problem having to do with array naming of equivalence blocks in modules that is now fixed.

Douglas Cox pointed out that MATMUL() was not implemented... took care of it.

I'm off to California tommorrow and will be avoiding the Santa Anna freeway for the reasons that everyone has no doubt seen on tv.

October 29

Fixed the problem with reading... it was caused by the fix to writing the other day. Joost and someone else (can't find the mail now) reported this problem.

Added underscores for module procedure names as well as external procedures for Charlie Zender-- netcdf seems to need them here as well. Charlie reports that the library almost links now.

Jim Rosinski had a code with an octal constant that was a double precision integer. The standard requires that BOZ constants always be default integers, but I've implemented the standard extension of kind specification.

Lothar Birk and Martien Hulsen both reported the same runtime error complaining about doing a read after a nonadvancing write. Well, they were both doing advancing writes, and the check was bogus. Fixed now.

Fixed Xavier's problem with scalarization. The problem was dealing with scalar expressions within vector expressions. The scalarizer is now more aggressive about removing scalars from vector expressions.

Martin Aichele wrote in with a problem that turned out to be a parameter array initialized by a scalar instead of an array constructor. Because of this, the simplification process replaced the parameter with the scalar instead of the constructor. Fixed now.

Michael Richmond sent in a frontend problem with generic function resolution. In this case, an intrinsic function was being correctly resolved, but failing at the end.

I am still very much behind on the bugs. To make matters worse, I am going to be out of town next week.

October 28

Early update today, since I messed up last night. Xavier reported a problem with scalarization that I started to fix, but it was late and I was tired. I mis-undid a one-line change, and built the package without the usual checks. The result was g95 segfaulted on programs that used an elemental intrinsic function in a scalar context. Which most do.

October 27

Charlie Zender reported that his netcdf package almost compiles with g95. The only thing missing was trailing underscores which g95 didn't produce until now. G77 has a very elaborate system for allowing the user to mangle global names in various ways that I'm not sure anyone uses.

This problem also highlighted a problem with the SYSTEM() extension reported by Douglas Cox, which was calling the system() function in the C library. G95's system call inserts the required trailing nul before calling the C library. Joost is fond of calling ABORT() in his code, which was again calling the C library directly. I've added a g95 interface for abort().

Martien Hulsen and Douglas Cox both reported that the library's default record size was way too low, leading to end of record errors when long records were being printed. Martien did some legwork on this issue and it turned out that the 2k allocated by g95 was very small compared to other libraries. I've upped the default to 50 megs. If you need lines longer than this, set the G95_DEFAULT_RECL environment variable for the preconnected units (the OPEN statement already has the RECL parameter).

Michael Richmond reported that raising a complex number to a real power wasn't working. Added support for this as well as raising a complex number to a complex power.

October 26

Douglas pointed out that '[' and ']' delimit array constructors in f2003, and requested this for g95. It was easy to do. He and Joost also reported bugs with minloc and maxloc that are now fixed.

Martien Hulsen reported a subtle problem with list formatting that has been fixed.

October 25

Francois Jacq had a problem where a the result of an assumed length character function was in a 'result' specification. He and Michael Richmond both noted problems with taking the lengths of assumed length function results. Fixed now.

Helga Avlesen sent in three regressions, one of which has already un-regressed back into a working state by the time I could take a look at it. Another was yet another fix to RESHAPE() (a problem also reported by Douglas Cox). I think a lot of the fixes made to RESHAPE() have been running counter to one another.

Jim Rosinski sent in some code that bombed, but in the week since he sent it, it compiles fine now. FYI, I do tend to be biased in favor of smaller bug reports.

Michael Richmond reported a problem with functions returning character pointers. This was fixed two days ago in a similar report from Joost. Xavier Leoncini and Michael Richmond both noticed scalarization problems having to do with non-array constant in the expression being scalarized. The problem was not marking scalarized expression nodes as scalar nodes.

Xavier also had a code that highlight another problem with scalarization not fully recursing into an expression tree. This caused a much needed restructuring that is complete.

October 24

Martin Kleinschmidt reported a problem with parameter variables in array specifications inside of derived types. They weren't getting replaced by their values. Fixed now.

October 23

Martien Hulsen reported an off-by-one error in the return values of the SHAPE intrinsic which has been fixed.

Joost reported a pair of problems a while back that are now fixed-- raising complex numbers to integer powers and returning structure pointers.

October 22

Fixed a couple of issues reported by Michael Richmond a while back. The first was the lack of a DFLOAT intrinsic, which is a pretty standard extension. The second was a problem in the front end that gave the wrong type to parameter variables. All fixed.

Charlie Zender and Mats Hamrud both reported problems with RESHAPE(). Mats's problem is fixed, but I'm not sure about Charlie's, since there were some missing include files.

I am still kind of behind on a lot of bugs.

October 21

Fixed the three problems with array expressions reported by Douglas Cox-- two of them had to do with printing array returns instead of assigning them, and the second had to do with nested functions that return arrays.

Larry Meadows once told me at a J3 meeting that scalarization was pretty hard to implement. He was right.

Implemented TRANSPOSE()

October 20

Implemented RESHAPE, MINLOC, MAXLOC. Then I made the mistake of trying to integrate array returns with scalarization. This is somewhat difficult and I am still working on it.

October 15

Douglas Cox sent in a pair of problems regarding array returns that have been fixed. The problem was printing the value of array function, and array functions that had their extents determined at runtime.

Joost sent a problem where an array constructor was being passed as an actual argument. Fixed as well.

Philippe Marguinaud-- Mail me. I tried mailing you this morning and my mail bounced, saying my "client wasn't authorized".

October 14

Joost and Michael both reported a problem with the scalarization of elemental functions, which had a trivial fix. Joost also reported a problem passing the NULL() pointer in an actual argument list. Also fixed.

October 12

Added support for vector subscripts.

Added support for array returns (user functions)

October 11

Martien Hulsen wrote in a while back with a problem involving the default record lengths of files. G95's length may be significantly shorter than other libraries. We investigating this one further.

Several array problems that Michael Richmond sent are now working fine, the array work of a couple of days ago is probably when it really got fixed. An internal error involving the DATA statement works as well, along with a problem having to do with statement labels on statements being scalarized.

Helge Avlesen sent a program that was crashing because of array pointers not working quite correcty. After much head-scratching, it turned out that g95 was allowed to crash.

Xavier Leoncini sent back a full version of the code that caused a crash during scalarization. This has now been fixed as well.

Mats Hamrud sent in a code that crashed a couple days ago, but now compiles fine. No doubt the problem was recently fixed.

October 10

Francois Jacq reported that functions returning pointer arrays weren't working. This isn't returning arrays, this is pointers to arrays. This has been fixed.

October 9

Continuing on with the array extravaganza, Helge reported a problem with array operations where a one dimensional slice was not in the first dimension of the array. This of course fixes a whole family of similar problems.

Xavier Leoncini sent in a similar looking problem, but it may not be the same, since I couldn't reproduce a segfault. We're still going back and forth on this one.

Helge also reported a problem with structure constructors. You can now put pointers in these.

Michael Richmond sent in a couple of bugs on the data statement that all went away in the meantime, all except one. This one crash had to do with a DATA array that had 10^6 elements. The mark phase of GCC's garbage collector was crashing on it because the code that does the mark is recursive and therefore requires as many stack levels as there are elements. The reason the garbage collector is recursive is that the mark code is machine generated.

In other languages, you have to actually provide each initial value for each element of an array, but not fortran. If you want a million 1's in an array, just use "1000000*1". Or if you really like fun, (/(i,i=1,1000000)/). So fortran is really the only language that has this problem.

There may be some way to inform the collector that it should mark these nodes through a loop, but given problems that other people have had, it's clear that g95 does not always mark the roots of all of it's tree nodes, leading to crashes after a collection. In times that I've seen the garbage collector run, it generally compresses a 5M arena into a 1M arena. Well, ten years ago, 5M was a lot of memory. Now it's peanuts.

GCC has had a reputation as a memory hog in the past, and the collector was probably a response to that reputation. But with memory so cheap, why bother? I've disabled garbage collection for the time being and will plan on transitioning away from it permanently unless someone convinces me otherwise.

Michael also sent in an array expression which looked like:

INTEGER :: s(3)
x = SUM(s(1:3)*y)

The fixes here involved traversing the argument of SUM to determine the extent of the temporary array, even through the implicit integer to real conversion (which is elemental). The other fix was to disable copy-out for this case (which crashed). Other cases where copy out is unnecessary is where the procedure being called is PURE, which many intrinsics are.

October 8

Several people (Douglas Cox, Joost and Michael) have sent in reports with problems of array constructors not working properly in various contexts, from simple assignments to

print *, (/ .true., .false. /)  

These appear to be working now.

Francois Jacq reported that array association wasn't working right for arrays passed to procedures. Copy-out is now working.

Xavier Leoncini reported a problem with assigning array sections where the full rank of the array being assigned was not used, ie something like x(i,:)=x(:,i). This is fixed now.

October 7

Tom Browder sent in a program a while back with a bug that involved using modules within a main program unit that has been fixed.

Michael Richmond pointed out a bizzare case where the IF statement failed. Fixed. There was also another front end problem where a substring reference was not being dealt with properly. Also fixed a problem with array expressions when the array was a deferred array within a structure.

October 6

Many bugs fixed today, lost track of them all. Most were from Michael Richmond and a couple were from Joost Vandevondle. Several fixes were in the scalarization, and there was a nasty memory problem in the DATA statement. Initial support for the TRANSFER function has been added. I am still about a week behind on most bugs.

October 5

Array temporaries are now implemented. This means that you can do things like:

integer :: a(10)
do i=1, 10; a(i) = i; enddo

print *, count(a > 5)

or

integer :: a(10)

print *, 2*a

October 2

Sourceforge shell services were down last night, so no update then.

I've been working implementing array expressions, and have a preliminary version that works for expressions that do not require an array temporary. Elemental functions and the like should work. I have code for generating temporaries, but it is getting late and it is not enabled. Vector subscripts don't work either, but they shouldn't be too hard.

September 29

Moved the checking for the requirement that array bounds be specification expressions to the resolution phase. It is not always possible to check this properly at parse time.

Michael also sent a short code that initialized an array of 10^6 element with the DATA statement. The list of elements was being built in horribly inefficient manner. The new method now builds the list in five seconds instead of an hour.

September 28

Michael Richmond pointed out the lack of a SUM intrinsic. Now implemented for real/complex 4/8 and integer 1/2/4/8. The DIM form which returns an array is not implemented yet. The PRODUCT intrinsic is implemented for these types and kinds as well. Another bug involved the array assignment of a structure component has been fixed.

Michael also found a pair of bugs in the front end. The first had to do with making a bad choice between a function call and a substring, which is fixed. The second problem goes much deeper and involves a pretty fundamental reordering of some checking. This is going to have to wait until tomorrow.

Michael also has his electricity back!

Fixed a pair of bugs from Martien Hulsen. The first involved a data transfer element being gobbled during format reversion, resulting in not enough elements being displayed. The second was incorrect end of file detection for unformatted reads. Both fixed.

September 23

Back from vacation, and working on a rewrite of the DATA statement to handle some of the strange ways that it can be used. Bug reports are still queued.

Michael Richmond, still without electricity because of Isabel, sent in a pair of bugs. I imagine his only source of illumination is his laptop's LCD display.

September 16

Michael Richmond reported a problem with recursive subroutines. The front end was not resolving these properly, and the back end was failing to insert the call instructions. Fixed it, but not sure what was wrong. The problem apparently also extended to module procedures.

I've fixed a longstanding problem with variables being too large to put on the stack. Michael reported this one along with Sylvain Heilliette and other people over the last couple of weeks. The existing scheme was to put arrays over a certain size in static memory. This is the approach used in g77 and other fortran 77 compilers. With the advent of recursive functions and subroutines, this won't always work.

The new scheme keeps track of the total size of arrays allocated on the current procedure's stack. If a particular array would make the size bigger than a critical value, then it is put on the heap. The size is 250k by defaulted and can be overridden with -fmax-frame-size.

I've been busy with a bunch of other things and mails have been piling up. This is unfortunately going to last another week, but I'll try to slip g95 stuff in.

September 11

Michael Richmond sent a problem involving a crash involving GOTO statement that ended up with no place to branch to after a bug bit. Fixed. Also fixed a type resolution problem in the ALLOCATE statement where a STAT variable was present.

Martien Hulsen sent in a problem involving scopes getting messed up and separate variables ended up getting assigned to the same location, creating chaos. Now fixed.

I've also finished off the double precision NEAREST intrinsic.

Guglielmo Pasa and Francois Jacq both sent in crashes that I've isolated as being related to the garbage collector in GCC. This one is not going to be easy to find.

September 10

Took a break from the bugs and implemented the floating point manipulation intrinsics. These are EXPONENT(), SET_EXPONENT(), FRACTION(), SCALE(), RRSPACING(), SPACING() and NEAREST(). The kind=8 version of NEAREST doesn't work quite right yet, so it is not in the binary. A number of people have sent in bugs and I will return to them tomorrow.

September 9

Francois Jacq and Michael Richmond both sent in a problem with array assignments to character arrays. Fixed now.

Vincent Lafage sent in a problem with the square root intrinsic, now fixed as well.

Joost noticed a problem introduced to the CHAR intrinsic by the fix to character array assignments.

September 8

Michael Richmond sent a couple of problems. The first was a problem with using module procedures as dummy procedures which has been fixed. The second, well, the second easily soluable problem was another problem involving substrings which has been fixed.

Martien Hulsen reported a problem with character elements of structure constructors that has been fixed. He also found a really nasty problem in where a loop was exiting before its time. Very bad, but now fixed.

September 7

Joost sent in a pair of problems, a place where infinity was printed incorrectly and some problems with reading and writing kind=8 integers. Both issues are fixed.

Charlie Zender and I have resolved an issue with the iargc() and getarg() procedures. They now work like other vendor's implementations.

September 4

Volker Eyert pointed out that assignment statements involving array constructors on the right were not working. This has now been implemented.

An ongoing problem that I've been having is forgetting to update the date on the binary when a new upload is available. Charlie Zender pointed out some server-side include directives that cause the date on the page to be calculated when you download the webpage. So now the file date is automatically the right value.

September 3

Joost sent a problem with printing infinities that has been fixed. I also noticed that I had zero division set to give a floating point exception. I've reset this, since it is not the behaviour people generally expect. I prefer the exception, but that is settable with environment variables.

Michael Richmond reported a problem with with DOT_PRODUCT. It wasn't implemented, but now is. The problem he reported yesterday with the EQUIVALENCE statement has been fixed.

Charlie Zender and I have been corresponding about the problems he was having with iargc/getarg. We almost have it figured out.

September 2

Martien Hulsen reported a pair of I/O bugs. The first problem had to do with an IOSTAT variable not being set if the I/O operation succeeded. The other was a core dump on reading an empty file instead of simply failing.

Michael Richmond sent in a pair of problems. The first was a duplicate complaint about missing types which was supposedly fixed, but wasn't, in the case of a function and it's result type. I've backed off a little on the halting of resolution when something goes wrong, but did add some code to prevent complaining twice about missing types on the same variable. The other problem is a problem with EQUIVALENCE that isn't fixed yet...

September 1

Thierry Deutsch reported (a couple days ago) that the IOLENGTH form of the INQUIRE statement wasn't working. It is now.

Joost Vandevondle reported a problem in the IO library with OPEN statments that don't have filenames. Fixed the problem. I've also fixed a problem with parameter arrays that he (and others) reported some weeks ago.

Martien Hulsen reported a problem introduced last night with the INQUIRE statement. The type resolution was always failing here, and it ended up incorrectly halting the rest of type resolution.

I've also added some initial support for derived type constructors. You can now use these in initialization expressions as well as general expressions-- right hand sides of assignments and actual parameters of procedures.

August 31

Back from Vegas. What a weird place, but the wedding was nice. I did get a chance to work on g95. I've done a major rewrite of some of the front end primary expression matching. This fixes the host association issues I've mentioned over the last couple of weeks, including Charlie Zender's problem with SELECTED_INT_KIND().

Martien Hulsen reported a problem with statement functions not being compiled correctly, this was a bear to track. Turns out the recent addition of alternate returns was interacting in a very bad way.

Helge Avlesen reported a crash on unformatted writes with large record sizes that has been fixed.

Michael Richmond reported several issues. One of these was a problem with an error message that was repeated twice. This sort of thing was intentional in the early days of g95 when I wanted to flush out seg faults farther down the line. I've now begun adding code that basically stops compilation instead of moving on. In languages like C, the lexical structure makes error recovery easy but fortran was never really designed this way so things are much harder.

August 24

Added support for PAUSE and alternate returns. I'll be out of town the next couple of days, on short trip to Las Vegas. The J3 meeting was unfortunately last week, otherwise I would have popped in and said hi.

August 23

Martien sent in another report about the slash descriptor that is now fixed.

Joost sent a bug regarding logical descriptors that is also fixed.

August 21

Martien Hulsen sent in a problem with the INQUIRE statement that has been fixed.

Michael Richmond sent in a bug that I'd thought I'd already taken care of-- more than one assumed length character dummy variable. Turned out not to be the case, but it is fixed now.

August 20

Martien Hulsen sent in a problem introduced in int() yesterday as it was being disentangled from anint(). Also mentioned by Volker Eyert.

Jon Wright wrote in with a problem with pointer variables, both array and scalar not being handled correctly in common blocks. This is fixed now.

Marlon Schmitz sent a code where nint() was not working correctly. Of course, nint(), int() and anint() look alike but are all different. I think things are resolved in this area now. Francois Jacq sent another bug involving incorrect host association. The rot unfortunately runs pretty deep. I've spent a couple of hours thinking about the fixes and they are not trivial at all.

August 19

Volker Eyert wrote in with a couple of miscellaneous problems in intrinsics. In particular, anint(), dnint(), ceiling() (and floor(), even though he didn't mention it).

Robert Lindebaum pointed out a problem with the random_number() intrinsic where it wasn't returning a value properly. Also fixed.

Michael Richmond found a problem where the scan() intrinsic wasn't linking properly. Fixed as well.

August 18

Martien Hulsen and Michael Richmond both reported a problem introduced with yesterday's fix of select statements. It worked, but it was taking exponential time in the number of cases being compiled. Arghhh. Fixed now.

Joost VandeVondle sent a letter:

 

Hi Andy,
first the good news: g95 compiles, linkes and executes LAPACK and
the tests. In fact, better so than pgf77 and g77. All results at -O0. A
certain number of fails appears normal, and the error is for the few cases
I've checked similar for g77 and g95

g95

dgd.out: DXV drivers: 200 out of 5000 tests failed to pass the threshold
sgd.out: SXV drivers: 37 out of 5000 tests failed to pass the threshold
zgd.out: ZXV drivers: 24 out of 5000 tests failed to pass the threshold


g77 version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)

dgd.out: DXV drivers: 200 out of 5000 tests failed to pass the threshold
sgd.out: SXV drivers: 37 out of 5000 tests failed to pass the threshold
ssvd.out: SBD: 1 out of 5510 tests failed to pass the threshold
zgd.out: ZXV drivers: 24 out of 5000 tests failed to pass the threshold


pgf77 4.0-2

ed.out: DES: 2 out of 3264 tests failed to pass the threshold
ded.out: DSX: 2 out of 3494 tests failed to pass the threshold
dgd.out: DXV drivers: 200 out of 5000 tests failed to pass the threshold
sgd.out: SXV drivers: 37 out of 5000 tests failed to pass the threshold
zgd.out: ZXV drivers: 24 out of 5000 tests failed to pass the threshold
zgg.out: ZGG drivers: 1 out of 1273 tests failed to pass the threshold

...

Woo-hoo! I've known that we've been fixing LAPACK related problems for about a week now, but I had no idea we were this close, or rather, done. The bad news wasn't all that bad, either.

August 17

Douglas Cox wrote in with a problem of the / descriptor that caused too many lines to be printed. Fixed.

Martien Hulsen found a program that caused infinite recursion for a particular class of SELECT statements. Also fixed.

August 15

Joost pointed out that complex square roots weren't supported, so I've added that. Also added support for complex absolute value, sine, cosine, exponential and logarithm.

August 14

Joost VandeVondle sent in a small problem involving converting complex values to integer that has been fixed.

August 13

Charlie Zender sent a bug in the parser that was uncovered by the same fix that uncovered the problem with host association. The way I intend to fix the parser for host association will also fix Charlie's bug, so making the changes there are becoming an increasing priority.

Joost VandeVondle reported some I/O issues associated with reading a unit that had not been explicitly opened. It will now open the default file for reading just like writing. I've also fixed some problems in list input to prevent unnecessary hangs.

August 11

Lots of progress today:

Steven Yellowhair wrote in with a fairly obscure problem with the MAX1() intrinsic that has been fixed.

Joost VandeVondle and Michael Richmond both pointed out that NINT() was no longer working. Joost also pointed out another problem with list reads. Both fixed now.

Michael and Douglas Cox pointed out problems with MOD() and MODULO() respectively that are now fixed. All these intrinsic problems came from a general overhaul of intrinsics over the weekend.

I've also fixed a problem with common blocks reported by Michael last week. There was a conflict when there was more than one common block was in a file and one of the blocks was initialized. The conflict is now resolved.

August 10

Volker Eyert wrote in that MODULO() wasn't implemented. Now taken care of.

Joost wrote in with a problem regarding equivalences being a little too lenient-- you can't equivalence dummy variables with anything, and a small problem with reading integers. Both are fixed.

August 8

Silly me... C2 is a function...

The crash caused by this code has been fixed.

August 7

Finished off the last of Kevin Thomas's bugs that were easily fixable. Common variables without types now given an error under an implicit none. Unfortunately, this change revealed a serious problem in the front end having to do with host association. I've fixed similar problems a couple of times with what amount to hacks and while the current problem could be fixed with another hack, my fertile imagination came up with other problems in the same family that were unfixable. This means some pretty fundamental changes in the front, but I don't see any way around it.

Fixed about half a dozen bugs sent in by Michael Richmond, ranging from some common/equivalence block issues, lengths of character functions and constructor expansion. He did have an outstanding issue that I would welcome some enlightenment on. Given following code:

SUBROUTINE TEST27
CHARACTER C1
CHARACTER C2
C1 = C2(1)
RETURN
END

I am unsure what C2(1) is. The rule for substrings requires a colon. Is this the first character of C2, and is this an extension?

Douglas Cox sent in a problem with the I/O library which required hitting enter one too many times during input. Fixed now.

Martien Hulsen sent in a problem where the blank common was not being matched correctly during parsing. Fixed as well.

August 6

Kevin Thomas sent a mail pointing out that the order of include files was screwy to say the least. The current directory was being searched before the directories specified by -I options. The new order is the -I directories, the current directory and /usr/include, since some other vendors do it that way.

I've completed the initial work on initialized commons. Common arrays (and regular automatic arrays) can now be initialized by DATA statements, array constructors or constants promoted to array constructors. But not all three at once. Some error checking remains to be added.

August 5

Kevin Thomas reported a couple problems, a couple of which have been fixed. First was a crash on common blocks with a large number of noninitialized elements in which other elements were initialized. The other problem had to do with poor error reporting that has been improved.

August 4

This was catch up night for finishing off bugs that have been on hold for a while.

Fixed a problem reported by Martien Hulsen a while back that had a problem in the OPEN statement with a status of UNKNOWN.

Shawn Ewald reported a problem with scalarizing a character assignment that was causing a crash, a problem with the TRIM intrinsic and a crash with the G descriptor. All are fixed now.

August 3

Got initialization of common blocks to work, at least initially.

August 1

Figured out Reinhold's problem, which actually had to do with arrays in common blocks that were in modules. Kevin Thomas reported another problem with common blocks that has been fixed.

July 31

Fixed David's problem of yesterday.

Reinhold Bader wrote in with some common block problems. The first had to do with the names of common block in the same space as regular variables. I ended up moving these names to a separate space of their own, which should have been done in the first place, but it is fixed now. His test case doesn't quite compile yet and there is still something wrong with common blocks that are part of modules.

July 30

David Acreman reported a crash that has to do with improperly stored string lengths. I've rewritten how these are stored and am now ironing out the problems introduced by doing things differently. I'm also working on initializing members of common blocks which is almost done as well.

July 29

Michael Richmond reported a problem with common blocks growing without bound. This is fixed. I've implemented block data program units in the back end and am focusing on getting initialization in common blocks to work.

Craig Burley also wrote in yesterday to correct some of my lousy English on the page...

July 28

Couldn't stand things anymore so I threw the laptop into the car and headed for the cool pines in the Mogollon Rim. Martien Hulsen's fixed-to-free program compiles once more.

July 20

Put the bug list on hold this weekend and added support for equivalence statements. The only thing not implemented yet is equivalence for structure components, which should not be hard to add. Now returning to the bugs.

July 18

Joost VandeVondele reported a couple problems with function returns. The problem had to do with return variables being loaded from a module. It was pretty useless to save these variables, so I've just removed them from the save/load. Module procedures now end up looking like functions without result variables.

July 16

Michael Richmond reported a problem dealing with recursive functions that has been fixed. I started to fix another problem, and rapidly ran into a fundamental problem in the front end having to do with the order in which specification expressions are specified. The situation rapidly snowballed to the point where I backed out the initial changes until I can figure out a better way to deal with this problem.

July 15

Worked yesterday on an unexpected foray into complex numbers, but today was fixing bugs. Things are close enough back to normal that I am resuming uploads.

July 13

Fixed many bugs yesterday and worked on subroutine linkage today, which is halfway done.

July 10

Variable length strings are back, and I am now working on subroutine linkage. When this is done, I'll resume uploads.

July 9

Character arrays fixed, now working on variable length character variables.

July 8

Simple character variables are working again, as well as simple operations like concat, len() and substrings. Starting on restoring character arrays.

July 6

I've gotten g95 to compile again. Simple programs work again, and I am steadily moving towards more complicated programs. No upload just yet.

July 4

Been work the last couple of days on revamping support for character variables. Édouard reported a problem a while back that revealed a pretty bad flaw in how these were handled, and I've had to move to a new mechanism. After some extensive changes in the library and compiler, g95 is almost back to the point that it compiles again.

June 28

I've been working the last week on some non-fortran related disasters. The worst is over, but work on g95 will be sporadic over the next couple of days.

June 22

Édouard Canot and Shawn Ewald both reported the same problem last week, a problem with calling a module procedures from another module procedure. The code that does this now is tricky and overly complicated. While another piece of baling wire could probably fix the problem, I've decided to simplify this by moving things currently handled by the parser into the resolution phase, and no longer allowing a symbol to live in more than one namespace. This will cost some time to implement, but in the long run will make things simpler.

June 19

Frode Meling and Shawn Ewald both reported a problem with modules caused by the scalarizer. Fixed now.

June 18

Helve Avlesen reported a problem with the required double colon for variable declarations that wasn't really being required. They are now.

Implemented the SELECTED_REAL_KIND() intrinsic.

For a long time now, scalarization has been broken in favor of getting more fundamental things working. But lately it has become more reported. I've made some progress fixing things, and the scalarization of array assignments by scalars is working. Lots of people have reported this over the last couple of weeks too numerous to list. It isn't complete, but it is a start. Now you can do:

andy@fulcrum:~/g95/g95 % cat tst.f90
program test
integer :: a(5,5)

a = 2
a(1,2:5:2) = 12345

print *, a
end
andy@fulcrum:~/g95/g95 % g95 -o tst tst.f90
andy@fulcrum:~/g95/g95 % ./tst
2 2 2 2 2 12345 2 2 2 2 2 2 2 2 2 12345 2 2 2 2 2 2 2 2 2
andy@fulcrum:~/g95/g95 %

June 15

Finished the rework. Michael Richmond's problem is gone, and so is Shawn's. The new system amounts to declaring all backed variables at once, which is simpler and uncovered a couple frontent bugs that were silent simply because the relevant variables weren't used in the right way.

Édouard Canot reported a couple issues-- minexponent for the kind 4 and 8 reals was not correct and fixing these fixed the value of TINY(). HUGE() is messed up as well and I suspect the problem here is the same. Thats what I get for copying numbers off of the internet. He also pointed out a crash in SELECTED_INT_KIND(). It wasn't implemented, but now is. He also reported a problem in the front end dealing with derived types that is now fixed as well.

Martien Hulsen reported a problem with a pair of OPEN statements, the second of which would cause a recursive library call. This is fixed too.

Helge Avlesen reported a problem end-of-file handling during list reads which has been fixed.

June 14

More on internal symbol declaration rework... Had to stop work when I hurt my arm.

June 12

Michael Richmond reported a problem that has required a rework about how the backend declares variables. This code is pretty fragile as it is, and is now pretty broken. I'm hopeful that this will also cure a problem reported by Shawn Ewald.

June 10

Martien Hulsen reported another problem with reading floating point numbers with the 'G' format that has been fixed.

June 9

Finished the problem of passing array pointers around, even for assumed size character arrays. The tricky part here is that passing pointers requires an interface so that the caller knows to pass the pointer and not dereference it during the call.

June 8

Francois Jacq reported that passing array pointers through subroutines didn't work. Shawn Ewald and I touched briefly on this the other day, but didn't get around to actually trying it. It works, but support for doing the same thing with assumed size character arrays requires much more work. No upload yet.

June 4

I asked Shawn Ewald to check the case of the G descriptor printing a real zero. That works now too. He also reported a problem of the BOZ descriptors producing signs which has been fixed-- that was one problem of doing everything in a single place.

Michael Richmond reported a problem with the P descriptor, totally unrelated to the other last week. Another easy fix.

Édouard Canot reported a couple issues, and I only had a chance to fix one of them. The A descriptor now correctly right-justifies the output.

June 3

Michael Richmond reported that opening a file with a status of SCRATCH caused a core dump. This problem was the result of that serious rewrite of the I/O system a few weeks ago, and is now gone.

Benjamin Turner reported a problem with a name collision in module namespaces. Two symbols were given temporary names instead of predictable ones. Problem is fixed here too.

Shawn Ewald sent in a short program that compared G descriptor output from g95 and another commercial compiler. The output was similar but not close. The number of decimals to the right of the point was off by one, the power of ten that switched to the exponential form was off by one and printing integers with G didn't ignore the ".m" part. There was also a small typo in the standard, and it turned out that the F format with d=0 didn't work properly. All fixed now.

Thanks guys, I couldn't do this without you.

June 2

Mika Salonoja and others have written in about access to command-line arguments. For a stopgap solution, I've implemented the IARGC() and GETARG() procedures.

May 29

Shawn Ewald sent in another problem a while back. This one had to do with an allocatable array of structures within a module. The fix was a one line change, but that one line took a while to find. It is a good sign when the bugs start getting more obscure.

Steven Yellowhair reported a problem with the new G descriptor. Depending on the value being converted (for output), the descriptor can run out of width and dump core. This is permitted by the standard, but I've fixed things so that it throws a nice exception instead of the core dump.

Also fixed a couple of bugs in floating-point writing that were introduced in the major reorg a couple weeks ago.

May 28

Shawn Ewald sent in a problem regarding the MINVAL/MAXVAL intrinsics which are both fixed now. He also pointed out that the 'G' descriptor was not supported for writing real numbers, and this has been added as well.

It was a little difficult implementing 'G', since it was hard to see what the standard was trying to accomplish by the strange rules that they have. As far as I can tell, G works, but if someone who has a better understanding of what it is really supposed to do can check it, I would appreciate it.

May 26

Michael Richmond wrote in with a problem dealing with ENTRY statements that was introduced a week or two ago when I fixed one of Francois Jacq's problems. Fixed so it works under all conditions.

Benjamin Turner reported a problem with the separators during list input which has also been fixed.

May 25

Fixed Matrien Hulsen's problem with statement functions. This one had to do with initializing things in the right order, which can be a really mess, but the current ordering seems to work.

Frode Meling reported a problem with H format descriptor. This wasn't quite done, so I went and finished it. It appears to work fine. The addition here found *another* problem with the P descriptor which has also been fixed.

May 21

Francois Jacq and Shawn Ewald both reported a problem with the same (bogus) assertion triggering. The ultimate cause of Francois's problem was a problem caused by mixing external names within module subprograms (which is now fixed). Not sure if I got Shawn's problem yet, he sent some better cases today.

Next in the queue was a problem from Martien dealing with statement functions. The ultimate cause here is a really nasty problem regarding the order that code is being generated in. This one is going to require some thought.

May 20

Doug Cox reported another problem with reading floating-point numbers which has been fixed. In several places.

Joost VandeVondele reported a borderline case with the P descriptor which has also been fixed.

Kevin Thomas found a problem with the code generation phase triggering at the wrong time, which fixes a wide variety of potential problems.

May 19

Martien Hulsen and Michael Richmond both reported the same bug. The problem, passing scalar and character arrays, with and without assumed lengths are now fixed, and appear to work. More bug reports are pending.

May 17

Fixed a pair of subtle bugs from yesterday.

May 16

Fixed the sequence association problems reported by Martien Hulsen, finally. After some initial misunderstandings, things are working the way they should.

May 13

Martien Hulsen reported a problem with parameter passing a couple days ago that has blossomed into a whole nest of bugs. The problem is almost fixed in the front end and will soon be propagated into the back.

May 8

Martien Hulsen reported a problem with reading floating point numbers that was hard to find but ultimately easy to fix.

May 7

Joost reported a problem with raising real numbers to negative integral powers. This wasn't using Knuth's optimal exponentiation table, this was for an exponent determined at runtime. Fixed.

May 6

Martien Hulsen reported a bug a while back involving a crash associated with procedures that were neither subroutines nor functions. The back end assumed that this could never happen, but if a dummy procedure is never actually invoked and never appears in an INTERFACE statement, you really don't know what it is. And because you never invoke it directly it doesn't matter.

The same problem was reported by Charlie Zender about an hour after I fixed it. His code then compiled except for some references to a table used by the ctype family of functions and to intrinsic functions for returning arguments. It turns out the libc used by Redhat 9 changes the ctype-table symbol, so I now include an implementation of ctype developed by Zack Weinberg for libiberty.

My original plan for supporting command line arguments was to follow whatever lead was taken by the J3 committee developing fortran 2000. But just today, there was a proposal for moving these functions into the ISO_FORTRAN_ENV intrinsic module, along with a counterproposal for keeping them as vanilla intrinsics. I think I will just implement it as f2k has it now and deal with possible changes later.

May 5

Finally tracked down the problems reported by Francois Jacq dealing with generic interfaces a while back. The problem program was only twenty lines long, but caused three distinct problems, two in the front end and one in the back.

May 4

Much work over the weekend on the I/O layer. Things are mucher cleaner and more things work. Turning back to the bug backlog which has been growing.

April 30

More work fixing I/O bugs.

April 29

Got T, TL, TR and X working like they should, and the I/O library back in one piece, more or less.

April 28

Doug Cox wrote in last week to point out that the T, TL and TR edit descriptors weren't implemented. I've implemented them about halfway, but ended up breaking some other parts of the library. No upload yet.

April 24

Joost VandeVondele reported a pair of problems yesterday, ICHAR() was malfunctioning and there was a problem allocating a scalar that was part of a pointer within a structure. Both problems have been fixed.

Francois Jacq reported a problem involving generic interfaces and modules. The fix for this one uncovered a truly nasty problem in the front end regarding how interfaces are loaded. I don't understand the complete scope of the problem and hope it won't involve too fundamental of a change to fix.

April 23

A mathematical digression. The random number generator used by g95 was invented by George Marsaglia. I've been mailing him over the last couple of days, finding out more about how it works, and where it came from. The source code is:

static unsigned long x=123456789, y=362436069, z=521288629;

static unsigned long xorshf96(void) { /* period 2^96-1 */
unsigned long t;

x ^= x << 16;
x ^= x >> 5;
x ^= x << 1;

t = x;
x = y;
y = z;

z = t ^ x ^ y;
return z;
}

One can see that this is an extremely fast generator, as it involves exclusive-or, shifts and moves, which map directly to individual machine instructions. The real part of the generator is the transformation that takes (x,y,z) into a new (x', y', z'), and lets the user have the z. Clearly, (0,0,0) is transformed to (0,0,0). Since everything is 32 bits and 3*32=96, the claim is that the generator follows a cycle through all possible (x,y,z) except (0,0,0).

The thing that is not obvious from glancing at the code is that the transformation is linear. It is, mod 2. Exclusive-or is simply addition mod 2. The 96x96 transformation can be represented by the matrix T:

    | 0  0  (I+L^16)(I+R^5)(I+L) |
T = | I 0 I |
| 0 I I |

Each element here is a 32x32 matrix. The I's in the lower left corner take care of the x=y and y=z assignments. L and R are matrices that shift bits left and right, and have diagonal 1's off of the main diagonal. T is really parametrized by three numbers 0 < a,b,c < 32 which are the number of shifts. What Marsaglia has done is to find sets of (a,b,c) that make the order of T equal to 2^96-1.

The next question is how to prove that successive applications of T cycle through all possible (x,y,z). An easy way of doing this is to compute T^(2^96-1).

Instead of applying T twice, we can compute T^2 and view that as a new operator that moves (x,y,z) ahead by two steps instead of one. Once we have T^2, we can get T^4 by squaring it again. By squaring and multiplying one can actually compute T^(2^96-1) without much computational effort.

If T^(2^96-1) is the identity matrix (it cycles (x,y,z) back to itself), then T is a candidate. If a shorter cycle exists, then the cycle length has to be an even divisor of 2^96-1. So then you have to compute the prime factors of 2^96-1, and raise T to these primes and make sure that you don't get an identity matrix. While 2^96-1 is 79228162514264337593543950335, it isn't one of these cryptographic composite numbers which are meant to be hard to factor. In fact, as you can see, it is trivially divisible by five.

Marsaglia says that his PC found all 2200 two-word generators with period 2^64-1 in about three minutes. He uses more sophisticated techniques involving the characteristic polynomials for the larger generators, and is working on four word generators with periods of 2^128-1. He has an invited paper describing this in the next issue of the Journal of Modern Applied Statistical Methods.

It is difficult to imagine a better random number generator. As long as the numbers produced pass the statistical tests for randomness (they all pass his DIEHARD suite of tests), this family of generators is extremely fast and make the best possible use of the state words.

April 22

Steven Yellowhair reported a problem with the initialization of derived pointer variables. It can only be NULL(), so it wasn't difficult to fix.

Michael Richmond suggested letting the control-Z character end a source file, like some other compilers, and this has been added.

Added support for substrings of constant strings.

April 21

Finished work on allocation/deallocation. I think. ALLOCATE and DEALLOCATE now work in all three cases: pointers to scalars, allocatable arrays and pointer arrays. Deallocation is automatic for allocatable arrays, except for arrays with the SAVE attribute. Arrays of characters and derived types work as well. Even allocating and deallocating an array off of a pointer within a derived type works. These pointers aren't deallocated on procedure exit.

The ALLOCATED intrinsic now exists and appears to work, as well as all three cases of the ASSOCIATED intrinsic.

Changed procedure memory back to a doubly linked list because an allocatable array can be deallocated before the procedure exits. Fixed a bug in the I/O library that prevented printing character arrays.

April 20

Serious rework of the memory management pool used by ALLOCATE and DEALLOCATE. These nodes are now stored in a tree instead of a doubly linked list. The problem is that DEALLOCATE is not necessarily allowed to crash the program when given a bad pointer to deallocate. If a status variable is present, it has to let you know that you can't deallocate that pointer. Searching for something in a doubly linked list is O(N), so it had to go, and is now implemented as a tree. Procedure memory was moved to a singly linked list, and temporary memory remains a doubly linked list so that we can make sure that none remains at the end of the program.

Several bugs in the I/O library were fixed and Martien Hulsen's fixed-to-free program now appears to work fine. I've run several fixed sources through it.

The recent work on derived types and pointers has made allocation, traversal and deallocation of linked structures possible. I've successfully written a small program that generates a stack-like singly linked list of structures. The runtime library has been modified so that the default is to report up to 25 abandoned memory segments as well as unfreed memory that was supposed to be temporary. This can be overridden with environment variables if desired.

April 19

Lots of work over the last couple days on pointer issues. My target for a while has been a program by Martien Hulsen that converts fixed form to free form. It now compiles fine, but segfaults in the I/O library.

April 14

I didn't quite fix one of Joost's problems with respect to the SIZE intrinsic yesterday, but it is fixed now. The problem was actually in the front end for a change, and was dependent on the test. I finally isolated the problem with reading the operator interfaces of modules that was uncovered yesterday, the fix was a little hairy, but seems to work.

I've added support for returning derived types. Again, it is not well tested, but appears to work for the simple case that I gave it.

April 13

Implemented array sectioning, originally reported by Joost VandeVondele a while back. G95 can now do something like:

subroutine show(a)
integer :: a(10, 10)
print *, a(5, 10:5:-2)
end

Joost's other bugs consisted of arrays of structures, which appears to work now as well, though it is not well tested.

Frode Meling reported a bug with modules involving the PRIVATE attribute and arrays which has been fixed. I traced the problem to the module reading subroutines in the front end, then uncovered an even nastier bug that I pursued for several hours without a fix. The reported problem is fixed, though.

Frode and Michael Richmond both reported some problems with the binary not being current. Naturally, I had just changed the upload script, but am not sure what is wrong yet.

April 9

George Marsaglia sent me a note saying he still considers his 'Mother of all random number generators' good (he released it in 1994), he now recommends one of his xor-shift generators. This one is about seven lines of really trivial C. The thing I really liked about this one is that it only has three words of state and is extremely fast. On my 833Mhz P3, it generates about 45 million deviates per second. This will slow down with conversion to a real number on the interval [0, 1), but pretty much guarantees that random number generation will not be a bottleneck.

I've added some initial support for arrays inside of structures. Arrays of character and derived type are untested yet, but shouldn't require much to get working.

April 8

Michael Richmond reported a problem where DATA statements involving substrings wasn't work. My initial thought was that this wasn't legal, but it turns out that it is. I've implemented it, and it appears to work.

April 7

Implemented the random number generator. I've chosen Marsaglia's "Mother of all random number generators", because it is simple, fast and only needs ten words to provide the state vector. Other generators require hundreds of words and have implementation details that make an integer array state vector difficult to implement. If there is some reason why this is a bad idea, let me know.

There has also been some attention given to derived types, particularly arrays inside derived types.

April 1

Helge Avlesen sent a big regarding the I/O library. A spurious error was being generated and mishandled into a core dump, which has been fixed.

March 31

Alvin Brattli sent a mail describing five different bugs, four of which are now fixed. The first was a failure to detect an automatic array (variable size) with the 'save' attribute (fixed size), this caused a problem. The second was a problem with statement functions that caused code to be eaten. A mail from Michael Richmond reporting this one showed up half an hour later, but since Alvin lives in Norway, he has a distinct time advantage.

The third bug was an actual argument as a deferred shape array. This is actually the easiest case of all, since the descriptor being passed can be used without transforming it. Fixed now. Bug four was fixing pointers to arrays so that they got the pointer attribute, which wasn't happening.

Bug five dealt with structures, and simplifying it a bit revealed that structures pretty much don't work at all. I am going to try and focues on structures in the coming days, since all the other basic types seem to work.

Joost VandeVondele sent another list of bugs, though the good news is that most of them are things that are things that are known not to work, as opposed to things that I had thought were working.

I also fixed a problem introduced a while back with repect to ACHAR(). I tried to have it share resolution functions with CHAR(), but the argument list is unfortunately different.

March 30

Worked more on trimming Michael's buglist from three days ago. Character array initialization works, but not in common blocks. Not totally sure why it doesn't work there, but it may need a rethink for this. Fixed another problem he reported dealing with passing dummy functions and another with actually calling them.

In other news, the LBOUND, UBOUND and SIZE intrinsics now work in all cases except passing back the full arrays.

March 29

Helge Avlesen report that using arrays in modules was broken, and this has now been fixed. I realized that this would cause similar problems with characters as well, and half an hour later, Michael Richmond's bug report arrived. He did have some unique issues, though. Character arrays that were being passed as actual arguments were getting confused because they weren't really characters but in fact arrays. This has been fixed.

The bigger issue was the initialization of character variables. Previously these had been initialized by code generated at procedure startup. But for static initialization (say in a DATA statement), there is no chance for this to happen, so they have to get their initial values from constructors, like arrays.

The other thing that has to be dealt with here is the initialization of character arrays.

March 27

Michael Richmond sent in a problem with the file positioning statments that only bit under special conditions. I couldn't find the problem right away, but by permuting the code slightly I was able to make it segfault, which led to finding the problem. Michael sends great bug reports-- the code was only four lines long.

I've verified that character arrays with a variable size length work correctly. I spent some time looking at the ALLOCATE statement and deduced what the committee had in mind. I am getting ready to reimplement it as the current version has serious problems and only works under the simplest of conditions.

March 26

Steven Yellowhair reported an off-by-one error in the printing of whole arrays that has now been fixed.

I've added support for character arrays. This has been a stumbling block for several people. They are not fully tested yet (variable length needs to be checked), but should be stable.

March 25

Transferring whole arrays (input and output) is now supported.

March 24

Spent the last couple of days working on arrays. Things are almost working again, and I'm mopping up some final breakages dealing with character variables. The next goals are character arrays (most of the machinery is already there) and printing arrays.

March 18

Lots of bugfixes over the last couple of days, reported by Alvin Brattli, Michael Richmond and Joost VandeVondele. These were mostly character related. Right now, arrays are slightly broken due to an internal upgrade of how types are determined internally. This was sort of inevitable, but will allow character arrays in the near future.

No code last night or tonight, but lots of planning.

March 11

I realised that the only reason array variables were working in common blocks was because of a fortunate accident. The implementation is in fact quite broken. The problems with character variables in common blocks are now fixed. I'm now working on passing character variables back and forth in functions.

March 10

More work on the reorg mentioned yesterday. Simple variables are working again, but arrays are now broken, but should be easy to fix. This change will greatly facilitate things like arrays and character arrays in common blocks and derived types.

March 9

Much more work on character descriptors. Everything that worked before works again except character variables inside COMMONs. This has required a large rework of how things are allocated, so several reported bugs have had to remain pending. No upload yet.

March 4

Michael Richmond and Alvin Brattli both reported a problem with CHARACTER variables in common blocks, which I will try to get to next. Alvin reported a problem with statement functions that caused infinite recursion. This one has been fixed and was a welcome relief from working on a problem with character variable allocation over the last few days.

February 27

Joost VandeVondele sent a couple of bug reports, which are going to have to wait until character handling is back, although one of his bugs deals directly with character valued functions.

Concatentation now works again. The binary available for download is not in sync with the source because too many things are broken. On to character variables!

February 26

The hello-world program now works again. Now working on concatenation.

February 25

Got simple character constants to be correctly created, converted most of the library to work with the new character variables.

February 24

Lots of thinking about how to fix handling of character variables. I've settled on a representation and have started to implement it.

February 23

Fixed some problems associated with calling module procedures. I don't remember who sent me the gregorian calendar module a few weeks back, but it works fine now.

February 21

Helge pointed out some problems with the new code, which all had to do with mistyping numbers from the tree in Knuth's AOCP. He's observed some mysterious slowdowns, but these appear to be array-related.

I've also fixed some problems associated with the type resolution of statement functions-- both the functions and the argument lists. These now appear to be handled correctly.

February 20

Helge Avlesen pointed out yesterday that the new exponentiation code is much slower in the case where something is being raised to a small integral power, ie squaring and cubing, which are common operations. I've implemented an algorithm discussed by Knuth in his Art of Computer Programming, where the optimal set of multiplications is used to compute an intergal exponential. His tree went up to n=100, so thats how far I took things. Negative exponents are implemented by taking the reciprocal.

Here is a sample program:

function exp39(b)
double precision :: b, exp39

exp39 = b ** 39
end

The resulting assembler is:

	    .file	"tst.f90"
.text
.globl exp39
.type exp39, @function
exp39:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
call _g95_push_context
movl 8(%ebp), %eax
fldl (%eax)
fld %st(0)
fmul %st(1), %st
fmulp %st, %st(1)
fld %st(0)
fmul %st(1), %st
fmul %st(0), %st
fmul %st, %st(1)
fmul %st, %st(1)
fmulp %st, %st(1)
fstpl -8(%ebp)
call _g95_pop_context
fldl -8(%ebp)
leave
ret
.size exp39, .-exp39
.ident "GCC: (GNU) 3.5-tree-ssa 20021226 (experimental)"

Which is beautiful-- the temporaries stay totally inside the x87 registers, meaning that this is as fast as it can get.

February 18

Alvin Brattli wrote in with a small program involving module procedures that caused an internal error. I've fixed the problem and discovered that you can't actually call a module procedure yet, so that will be next.

I've also implemented statement functions. This is the current stumbling block in the NIST test suite, and I've added more of them to the current test suite.

February 17

Added support for internal procedures. Ran some tests and they appear to work correctly, including host association.

February 16

Helge Avlesen reported a problem with the floating point exception handling. The denormal exception wasn't being masked, and denormalized numbers show up during underflow situations. The linux kernel also reports denormals as underflows (they aren't), further muddying the situation. Hopefully this is fixed now.

Signal handling for SIGINT and SIGHUP signals now depends on the G95_SIGINT and G95_SIGHUP environment variables. These are useful for preventing unexpected stops of background jobs when the foreground session terminates. SIGQUIT is left unaffected.

February 15

Got a new, more general way of calling intrinsics. Started by adding some more intrinics, notably INDEX, then realized that the way character variables are handled is not going to work at all and is probably going to require a complete rewrite of their handling.

I've also replaced an incredibly naive implementation of exponentiation for integer powers. If the exponent was n, then n-1 multiplications were performed, and there was no taking account of the indeterminate form 0**0. For exponents in the millions, the new method is millions of times faster.

In the process, I rediscovered the identity

lim (1+1/x)^x = e.
n->inf

Also fixed a pair of corner cases in the I/O subsystem, one dealing with printing integers and the other dealing with getting the wrong descriptor during a formatted write.

February 14

Straightened out floating point trap issues mentioned to two days ago. Here is how it works: On a SIGFPE, the signal causing the exception is printed, overflow underflow or whatever. If the program terminates normally, the masked exceptions that occurred during program execution are optionally printed out, under the control of an environment variable (G95_FPU_EXCEPTIONS). This is originally a NAG innovation.

All IEEE-754 exceptions are supported, but not all of them are useful. I had originally thought for a long time that the INEXACT trap would only fire on situations involving a catastrophic loss of precision, something like:

 

real :: x, y, diff
x = 12345678.0
y = 12345677.0
diff = x - y

In which case, 'diff' has almost no significant bits left. It turns out, however, that something like:

real :: x, y, sum
x = 1.0d0
y = 0.1d0
sum = x + y

also triggers the exception, even though only about three bits are lost. Other examples include taking the square root of a number that isn't a perfect square and so on. This means that this bit is almost totally useless.

Now that this is resolved, I'm continuing on with Martien's code, and working on the INDEX intrinsic, but first looking for a more general way of calling library subroutines that doesn't involve declaring them all in advance.

February 13

Martien Hulsen reported a compiler crash. This had to do with character substrings, which has been fixed. Also fixed a problem with the LEN intrinsic, which now appears to work in all circumstances.

Feburary 12

Worked on getting the state of the floating point unit set from environment variables. This now works for x86 linux, and code is present for several other platforms, but querying the state of the FP unit after program execution is over ran into some snags, mainly because Linux clears the state of the FP unit within the signal handler. Rethinking the design a bit.

February 11

Debugging DATA statement. Whole array references, array sections and implied loops over elements are now translated into real loops over elements. Added the SYSTEM_CLOCK intrinsic.

February 10

Worked on DATA statement. Fixed problems with min/max intrinsics.

February 9

Basic handling of COMMON and DATA statements are in place. Work continues on importing the NIST suite with bugs being fixed along the way.

February 6

Reorganization of symbol resolution.

February 4

Arnaud sent a link to the NIST test suites that I have been busy importing.

January 30

Helge Avlesen reported some backsliding which has been fixed both ways.

Arnaud posted a link to the NIST test suites for fortran 77, which look great.

I've also updated g95 to compile files with an '.f' extension (in fixed source mode).

January 28

The reading and writing of internal files has been fixed and now appears to work.

January 27

Implemented the CPU_TIME and DATE_AND_TIME intrinsic subroutines.

January 26

Thierry Deutsch reported a core dump when a RESULT variable was used in a function. Fixed.

January 23

Worked on memory management issues.

January 22

I have a new email address, andyv@firstinter.net. Not sure if the old one is coming back or not.

Arnaud sent a small patch that removed some unused variables and frees the right kind of node in one place. I gave some thought to memory management.

January 20

Helge Avlesen reported a couple more problems, this time with reversion in a format without any data descriptors at all. Also, I/O statements with and emtpy I/O list were not being terminated correctly. The big deal is a serious upgrade to the FORMAT statement, which now appears to work in all of its various forms.

Helge also reported that the I/O library is about 10% slower than the library with the Intel compiler. The good news here is that current I/O library is being compiled with optimization off, for easier debugging, and that there has also been no real attempt at optimization yet, since getting it to work in the first place is a little more important.

Fixed another bug involving appending to files that Helge also reported.

The big hack of the night was to add floating point formatting subroutines. These are intended as stopgaps for a couple of reasons, the main one being that some vendor's sprintf()'s don't round output correctly. In the current implementation, most digits will be correct. Scale factors and the 'g' descriptor are not handled.

January 18

Fixed Helge's last bug, which had to do with bytes not getting written correctly to files. Also fixed a bad comparison in the overflow detection code for reading integers.

Added list output for real numbers. The implementation is a stopgap to get things working and is not accurate in several regards.

January 17

Helge Avlesen reported a couple of problems. First, ERR, EOR and END branching wasn't working correctly. The other problem was with reversion of a formatted failing after the first time.

January 16

I've put up a copy of the g95 binaries and library on the website, and am inviting people to download it and try programs.

Helge Avlesen reported a problem with a file returning an error during truncation which turned out to be misinterpreting the return of a system call.

I've also added the standard prefix to all of the intrinsic procedures generated by the compiler.

January 15

Finished the new constraints sent by Arnaud. Finished work on the SELECT statement. Integer, character and logical selects, bounded and unbounded appear to be handled properly.

January 14

Arnaud sends more constaints and we are being language lawyers.

More work on SELECT statements. Almost done.

January 12

Backend work for SELECT statements, integer and logical. Only character selects are left and this should be done tomorrow.

January 11

Frontend reworking of SELECT statements. Instead of putting the cases into a tree, they really just need to be sorted in order. Added checking for the multitude of overlap cases.

January 10

Finished the STOP statement.

January 7

Arnaud sent a patch fixing the result types of intrinsic comparisons as well as eliminating some unused structure members.

I've been fiddling with gcc specs to prevent the real g95 from linking in shared libraries that duplicate static ones. It's slow going.

January 6

Updated configure system to allow compilation with the ssa branch of gcc. g95 should now be buildable from CVS sources.

Paul and Steven have decided to fork g95, which was inevitable, I suppose. Compilers are such fascinating projects that they attract people who aren't otherwise interested in using them. In my opinion this leads to design choices that are less than optimal for the end user, in this case the numerical professional. I remain committed to producing something wonderful.

January 1

Succeeded in getting the new I/O library to work with g95. Compiled a hello world program, and was able to do simple formatted writes.