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 -
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-
g95 in order to run g95.

2002 Archive

December 20

Arnaud pointed out some deficiencies in last nights code for dealing with zero length arrays. He also sent a patch for removing some typos that had replaced the default real kinds with default logical kinds.

December 19

Arnaud sent a patch for dealing with zero length arrays, that I ended up rewriting as well as a patch for signalling conflicts between intents and dummy procedures.

Huang sent a patch adding a missing error code to a little-used part of the I/O list matcher.

Paul sent a patch for removing some of the intrinsic subroutines from the list of intrinsics and modified the reshape intrinsic.

December 18

Small fixes from Arnaud, improving some verbage on the help screen and a stickler involving module procedures.

December 16

Paul sent some code that does resolution of intrinsic subroutines, I changed it around a bit.

Arnaud sent fixes with added elemental handling to function comparison and added some constraints. He also sent a link to some f90 code from a finite element textbook which g95 parsed fine and has been added to a suite. A second suite of examples either has some nonconformant code, or our version of the standard is not quite right.

December 14

Miscellaneous fixes from Arnaud.

October 15

Reading up on the intricacies of sequential, direct, formatted and unformatted.

October 14

Implemented the non-IOLENGTH version of the INQUIRE statement.

October 12

More OPEN and CLOSE stuff. These are tentatively complete and appear to work.

October 11

Worked on the library, particularly on the OPEN and CLOSE statements. Most of the code involves making sense of the options passed with the statement and making sure that things do not conflict.

October 8

Many backend changes.

I've been investigating problems associated with array arithmetic reported by Arnaud yesterday. The fixes have uncovered new problems.

October 7

Paul has checked some large changes into the back end dealing with derived types.

Arnaud found a pair of bugs that I haven't had a chance to look at today.

I worked for a couple hours on the runtime library, in particular the error handling/recovery subroutines. Started replacing the C stdio subroutines with the stream I/O in the OPEN statement.

October 6

Lots of work on the library today. Replaced the red-black trees with treaps (less well-balanced, but a smaller code footprint and cleaner). Started adding some necessary constraints to the OPEN statement.

October 3

Miscellaneous patches today, a leak plug from Arnaud, and a patch from Paul completing the copy-constructor patch.

Big thing was adding a call to the type resolution while matching initialization expressions. This causes type and rank of intermediate things to be set. Fixes a problem reported by Arnaud a couple days ago and Paul today.

October 1

Worked on the runtime library. Added support for the three variants of the STOP statement.

Septmeber 30

I didn't check my mail over the weekend and a lot happened...

Paul reported a memory leak when shapes where being copied inside of array arithmetic. I was cutting some corners and reusing some structures there and have decided that it is a much better idea to keep the structures consistent, do the copy, modify the copy and allow the original to be freed.

The next issue was a fix to a problem reported by Arnaud last week involving expanding array constructors. Paul sent a patch, which I modified into a new function since the original was getting too large. When in place, this uncovered some problems in how initialization expressions were being checked-- the iteration variables need to be treated as integer (even if they are something else). I've added some code in expr.c to correctly report these types.

Paul sent a patch to fix evaluation of the SIGN intrinsic. Modified the patch to simplify the function quite a lot.

Arnaud sent a patch for fixing a memory leak in simplifying the SIZE intrinsic and another for more extensive conformance checking between intrinsic binary operations as well as assignments. This also uncovered a bug where SIZE (and other array inquiry functions) weren't being allowed in array inquiry functions.

September 29

Worked on IO library, added functions to parse fortran strings into numeric options and flags.

September 25

Arnaud sent some patches for array handling, some conformance testing in particular. There was a bug he sent that is unresolved at the moment.

Fiddled with the library some more, mostly renaming public interfaces with the prefix.

September 24

Back home. More work on the environment scanner. It looks like it is in the final form. Worked on macros to get rid of the ugly prefix that is mandatory in a library. Now the library can look like a real program without the ugly names.

September 18

Finally got a chance to debug the environment scanner. It now prints the current settings in a pretty manner.

September 17

Paul sent a patch that fixed an order-of-operation problem associated with array arithmetic.

I finally added restrictions against multiple attributes. The biggest surprise was that a symbol can be a dummy variable twice via an ENTRY statement.

September 16

More options to the environement scanner.

September 13

Added a couple restrictions on the front end. Initialized variables can no longer appear in data statements, variable appearing in data statements are now marked and adding a basic type now conflicts with certain flavors like program unit, module and labels.

I am leaving on vacation tommorrow and my net access will be a little sporadic over the next week.

September 12

Added more options to environment scanner, mostly things affecting the floating point control word.

September 11

Richard Maine found a problem with g95 not requiring that procedures within a FORALL statement be PURE. This has been fixed.

September 10

The plan didn't survive contact with the code. I worked on getting things to build. Tommorrow will be debugging of the environment scanner. It was interesting environment to write code. I had my laptop out by the pool and listened to a monsoon had blown of the Superstitions this afternoon. No rain (on me, anyway), but lots of lightning.

September 9

Working on the runtime library. The stream I/O module is pretty much done and I have a module that reads environment variables and sets internal flags that control various aspects of a program's execution. The next task is to starting weaning gforio off of the C I/O library.

September ?

Sander Belien has donated a 20k line finite element code for the test suite, which I have agreed to keep private. An initial test of the causes a failure (of g95) in the first file, which everything else includes.

Paul Book is asking for help on a dependency analysis of array expressions his request is:

Just in case there's somebody sitting on this list wanting to contribute to g95, but not sure where to start:

For array assignments, the fortran spec. requires that all expressions in an assingnment statement are evaluated before the actual assignment takes place. For many expressions (eg. a(:) = a(:) + 1, a(:) = b(:)) this doesn't matter and the processor can perform the assignments in any order. For other expressions (eg. a(2:n) = a(1:n-1)) the compiler must take special precautions to ensure that this constraint is not violated, often involving allocation of a temporary.

The first stage is this is performing dependancy analysis in the expressions.

Given two expressions (g95_expr nodes) we must determine if there are any data dependancies, ie. if assigning a value to the first expression will change the value of the second.

This is further complicated by forall statements, where the dependancy analysis must cope with index variables.

Any volunteers?

August 8

Paul sent a patch that adds intrinsic resolution to hopefully the last remaining holdouts.

Toon Moene is trying to get a working g95 ready for a demo at the J3 in Las Vegas next week. That would be cool to see.

I've scored some more test code, the WETA weather code from the NOAA. I'm still unpacking it. My preference these days is for f90 code, since it uses more of g95's dusty corners than f77 code does.

August 5

After a lot of thought I've decided to abandon using standard C I/O library in our fortran I/O library in favor of something else, the alloc streams interface suggested by Krieger, et al. The main difference is that this approach uses mmap()ed files if possible, and fits very nicely with internal files. I am not going to implement the ASI in its full generality, but only those things fortran needs.

July 31

Found some more minor bugs last night, and spent some time tonight getting some new test codes. The largest came from the web pages of John Burkardt, who has amassed a huge collection of fortran codes. I've also spent time on Udo Grabowski's DarkStar code trying to put things in the right places. I've actually been spending more time fixing test programs that g95. Apparently most other compilers are pretty loose with their code. I haven't had a chance to upload the new codes to the main test suite on the web site, but I will try to get to that soon.

Paul has continued making leaps and bounds on the back end.

July 25

Found a few more memory leaks, and then worked on the test tools. I've been using the malloc-tracing facility of glibc on an intermittant basis, but now have made the process more automatic.

The way this works is that if you define an environment variable named MALLOC_TRACE, it writes allocation and frees to this file. There is a program called 'mtrace' (a perl script) that reads this file an figures out which allocations have no frees. I've been running with this file as a named pipe, which was mandatory in one case where a 700 megabyte trace file was generated.

The script now checks for the environment variable, and if present, forks a copy of mtrace and prints its output on the screen (if something goes wrong). It doens't always do the same thing twice, which is very bad, so a little more work is indicated here...

There are few pending patches that I'll look at tommorrow.

July 18

Paul is continuing to work on the back end, and is almost up to getting the 'hello world' program to work.

I worked more on modules today. The current problem has to do with component references in expressions (array specificatios) in which the base symbol was not loaded prior to the expression. I think I have a solution worked out for this one, but it will have to wait for tommorrow.

July 16

I spent the evening working around a CVS problem. Lately, CVS will just hang at the end of trying to do something on an intermittant basis. After much pain, the problem seems to have to do an interaction between my ssh and SF's sshd. SF is running opensshd 3.1, which is vulnerable to a recently discovered remote root exploit. I suspect SF patched their sshd when the exploit was discovered, because I can now crash my ssh when connecting to SF under certain circumstances.

I thought about upgrading my old ssh, but chose not because no one has found a remote root exploit in the (old) version of sshd that I run at home, and have seen plenty of probes in my logs. SF tech support has not provided any answers (its been a week), but I have been able to bypass the problem.

I've checked in a large revision of the host association handling mentioned a while back. In between, I've added a general module for handling binary trees. This was needed to handle an upgrade to the module reading and writing. In particular, namespaces associated with interfaces are now accurately re-created. The new implementation also leaves flexibility for dealing with circular-references.

July 4

Lots today. I've been working on getting host association to work correctly, and ended up in a problem with how modules are loaded. As it is now, modules don't save namespaces that are interfaces, and this has to change. There is another related known problem with modules that require non-symbol pointers to be correctly saved and restored. For large numbers of names, a binary tree is indicated. Another place binary trees will be required is in character SELECT statements, so I've taken the time to generalize the binary tree code.

The symtrees no longer have specific tree code, but use the general version. I replaced the red-black trees with treaps, which is a mistake, because they don't balance evenly, something which would be a good idea for the SELECT case code. The code is to the point where the actual tree implementation can be changed without bothering those segments that actually use trees.

July 1

Paul and Steven are almost to the point where g95 is emitting actual executable code.

I have been struggling with fixing assumptions that I've broken with my latest symbol reorganization.

June 30

Much work on a rework of how host association is done. The rewrite is done, but has exposed many bugs that were lurking beneath the surface. Hopefully they won't take long to fix.

June 16

I've gotten pretty slack about updating the website lately. The most recent changes have included lots of memory leaks, thanks to Arnaud.

Tonight I started tackling the problem of host association not being done correctly. It turns out that it has to be done at resolution time in general and can only be done at parse time for certain cases. The current system of host association did stink and won't be missed.

June 9

Lots of changes today. Arnaud had several patches that plugged several of leaks, mostly dealing with GMP structures.

Paul Brook has offered to start work on the back end. There hasn't been any reason why this couldn't start a while back.

I've reworked how constructors are expanded. There was a problem on one of the test codes that had an array constructor with 250,000 elements. G95 was using quite a lot of memory and time to expand this beast, and since it was in a module, that made the module pretty huge. So now the rule is to only expand constructors if they are small enough.

The subroutines for counting the size of an array constructor and extracting arbitrary elements also use the new expansion mechanism and this allows elements that are part of iterators to be correctly expanded.

I've added sound to the test scripts. When a suite completes, a nice soothing chord is played. When error message shows up, an explosion is played. This really useful for playing solitaire while changes are being tested.

Édouard Canot sent a set of three problems the other day, two of which have been fixed. The last problem showed a very bad problem with how g95 does host association. It turns out that host association has to be done at resolution time, while I've been trying to do it at parse time...

June 6

Arnaud sent in several patches to eliminate memory leaks, and one that sets IMPLICIT NONE on all the program units, just like g77's -Wimplicit option.

I've continued to make some progress on checking restricted expressions. I'm mostly done except for checking functions.

June 4

Arnaud reported a couple more memory errors, some of which I haven't gotten to. I've added support for checking specification expressions, mostly hooking in code that is already present. Still having some difficulties, so it isn't checked in yet.

June 3

More minor memory leaks from Arnaud. Craig Burley sent a mail poking a little fun at the 'May 39' typo from a couple days ago.

June 2

Plugged lots of memory leaks that Arnaud has found with valgrind.

June 1

Steven and Arnaud have been working on a variety of issues, from assigned GOTOs to memory leaks under various conditions. I've hurt my arm again, and need to avoid non-mandatory typing.

May 26

Steven has implemented a couple of the things talked about on the mail list. First, a couple of alloca()'s have been replaced with the more sensible automatic variables. Swapped parameter in an error message have been flipped to make sense, an error is now returned on a bad IO-iterator, implicitly declared functions are now considered unpure and several enhancements have been made to pointer assignments.

May 23

Steven has been making more changes. The first is to arith.c and fixes some error reporting with the arithmetic handling. He and Arnaud found a couple cases that underflowed instead of overflowed and this patch better handles this situation. He's also added the -d8 option talked about on the mail list that implies both -r8 and -i8. There have also been some fixes with PURE functions and pointers which fix a problem reported by Arnaud a while back.

Arnaud reported a bug in g95_match_whitespace() that caused g95_next_char() to be called twice because of how the g95_is_whitespace() macro works. This has been fixed.

He also had another outstanding problem with g95_intrinsic_sub_interface(), which returns a 'try' but was being handled like a 'match'. The function counterpart returns a match because of the three possible returns, but sub() can only succeed or fail.

I've disposed of 45 mails today, lots of which are duplicates that are sent to me and the list, and I'm still about two days behind...

May 20

Steven has consolidated the real and integer range check functions into a single range checker.

Fixed a memory corruption problem reported by Arnaud. During an error parsing a COMMON statement, blank commons weren't being properly restored.

The next problem was that an error wasn't being reported if a comma wasn't between a P descriptor and a repeat count. There are about a dozen examples of this error in the test codes that I have, and I've made the error only show up during -pedantic.

Arnaud also started a bunch of back and forth on the mail list about some problems with the -i8 option. It was being confused with -r8 at one point, but it is unwrapped now. There were some specific problems with respect to the ABS() function which has been fixed.

May 17

Fixed a wide variety of bugs sent in by Arnaud Desitter a while back. These are fixed except for a problem involving statement labels on declarations and DATA statements, which are legal but useless as opposed to being illegal. (It's just illegal to branch to them).

Steven Bosscher identified one of the problems that I didn't look at as an underflow problem that wasn't being handled gracefully.

May 15

Worked on clearing out my mailbox, where quite a backlog had built up.

Applied a couple more patches from Arnaud that cleaned up a lot of small uglinesses.

May 11

The parties and beer are almost over. Thank goodness. One can only have so much fun.

Got the ISO variable string module to compile correctly. Lots of small bugs fixed there. There were a lot of intrinsic functions that should have been marked as generic which were not.

Arjen Markus wrote in a while back about some spurious warnings under -pedantic. These have been fixed.

Édouard Canot sent another program that failed with the MERGE() intrinisc. The actual problem was that IOR() was not returning the same kind of integer it was passed. Fixed the analogous problems in IEOR(), IAND(), IBITS(), IBCLR() and IBSET().

Arnaud Desitter sent in another patch that fixed all kinds of small problems, ranging from my spelling mistakes to variables that were set and never used.

May 8

Started dealing with some of the backlog.

Arnaud had a mail pointing out an inconsistency in the return type of g95_intrinsic_sub_interface().

Steven had a mail pointing to a variable length string library written by J. L. &;Schonfelder which gives lots of errors. Steven pointed out some bad English in an error message. The first of the technical problems required adding a 'pure' flag to the intrinsic symbols. I thought we could get away with looking at elementalness, but it turns out that all intrinsic functions are pure and all intrinsic subroutines are pure if they are elemental.

May 7

Applied most of a large patch from Arnaud. I took it out of order from the mail queue, but the other problems have to do with bug reports, and fixing the intervening problems tends to make the patch more difficult.

May 6

Things are starting to get back to normal, though most of my family is showing up for commencement at the end of this week.

Arnaud Desitter sent a copyright assignment that I've forwarded to the FSF. He has some changes queued up in my mailbox that I will try to get to soon.

I've done an overhaul of, which is intended to increase it's legibility. I'm planning on making this script the basis of a fortran 95 data analysis tool suggested some time ago by Van Snyder. The plan is to work on it in favor of the code generator for a couple of reasons. In the first place, it'll make g95 immediately useful, even without the code generator. Because it's useful, more people will test the parse and resolution phases and these can be debugged in more detail before I start forgetting how g95 does these things.

May 1

I've passed my defense.

April 21

Finished working on the branch resolution code. Deleted some functions that duplicated the new code. Over the next couple of days I'll be trying to get rid of some of the mail backlog that has built up.

April 18

Started working on Steven's branch resolution code, generalizing it to handle arithmetic IF's and data transfer labels.

April 16

Not much today, at least for g95. I've been very busy lately with too much to do. The good news is that I have a defense date of May 1st, and will soon have that monkey off my back, though most of my present preoccupations don't have anything to do with my thesis.

April 13

Steven added a patch that correctly resolves branches, making sure that the program is not transfering control into a block.

After several days of working sporadically, I've added a patch that keeps track of where interfaces actually come from, as well as correctly handling the case where an interface has no arguments as opposed to no interface.

April 5

Édouard Canot sent in a pair of bugs a couple of days ago that languished for a while but have now been fixed. One had to do with correctly calculating the rank of an elemental function reference, and the other was fixing a core dump when one of the bounds of an array was actually a function reference.

Steven sent a patch that fixes some problems in free form mode with spaces. The problem is that g95 does not complain on invalid code, but parses it something like fixed form where spaces are insignificant. There are plenty of similar issues like this left in g95.

April 4

I've been kind of busy and there are a couple of bug reports that are in the queue, so I'm afraid they are sort of languishing there right now. Wanting to do something easy, I unpacked Udo Grabowski's DarkStar stellar modeling code. There are about 150k lines here spread over about 300 source files. The preliminary run shows some definite problems (hooray!).

By popular request, I've linked the g95 page to sourceforge instructions on obtaining the current g95 from anonymous CVS.

April 2

Steven Bosscher wrote in with a C ordering problem which has been fixed. His newer compiler complained where mine did not.

Added restrictions associated with ELEMENTAL subroutines.

April 1

Erik Schnetter reported a pair of problems. The first was with g95 (stdio really) not correctly dealing with special files. I've added a check so that g95 will only open regular files. The second problem was silencing a warning about uninitialized memory that only shows up when -O2 is specified.

I've completed adding the constraints on PURE procedures. The current suite compiles fine, but I suspect that there aren't many codes that use purity. I did check as I went, but I probably haven't gotten everything. Doing this did reveal some serious problems with argument list handling, in particular they don't appear to be sorted after matching a particular interface.

The plan now is to add the additional constraints on ELEMENTAL procedures (there aren't many), then go back and figure out what is going wrong with the argument lists.

March 31

Started adding support for detecting problems with PURE functions. The changes are mostly done, but I got hung up on a constaint that the intents of actual arguments to the intents of formal arguments. This is so that you can't pass a variable that should be local to the pure procedure to an INTENT(OUT) argument of a procedure. It's related to passing an INTENT(IN) to an INTENT(OUT). The code is in place, but is not called at the moment.

After this is done, the same for the ELEMENTAL attribute. This will be much easier since the main constraint is that elemental functions are also pure.

March 30

Lots of other things have been happening and it has been difficult find time. There have been two more problems fixed.

First, Steven Bosscher had a problem with a code that wrote a module with a non-constant array specification. Pointers to array specifications are stored with each array reference, but not stored in the module mostly for space reasons-- an array spec may be pointed to by many array references. After some false solutions, array specs that are loaded are recomputed as part of the type resolution.

Édouard Canot also reported a problem with a RESHAPE call that had a call to SHAPE() in the SHAPE= keyword. This argument is special in that it requires an array of constant size. The size of the result of SHAPE() depends on the rank. Before, I assumed that we would call a subroutine. As it turns out, this is unnecessary. Calls to the SHAPE intrinsic() can always be simplified as an array constructor of some sort and this is now what happens.

March 25

Added a test suggested by Arnaud that compares the number of elements on the left and right, complaining if the number of elements on the RHS is greater than the number on the LHS. I also switched out of bounds array references back to warnings from errors.

Other than that, I spent some time looking around for more test codes. I found a couple that give g95 problems, so that will probably be for tomorrow.

March 24

Cleared a couple of bugs that have been on the table for a while now. Finally fixed Arnaud's last bug regarding resolution of DATA statements. Édouard also wrote in with a bug that amounted to the SHAPE() intrinsic not returning a constant array constructor when possible. I also implemented the SIZE() function, since most of the functions that calculate array sizes are already there.

I've also added a few more test suites that I found on the net. The upshot there was finding a bug in the parser that got confused on the difference between a complex constant and the start of an list of an array constructor or I/O data transfer list. Fixed these.

March 20

Michael Richmond sent in a easily fixed bug that reported an out of bound string where everything was fine.

I've added code to resolve DATA statements, mostly making sure that there are as many data values as there are variables. Haven't had a chance to test it yet.

March 19

Arnaud Desitter sent in a problem a couple days ago dealing with out of bounds character substrings. I made some modifications, but g95 currently gets a little confused about character arrays. Another serious deficiency is one I noticed when the code refused to give an out-of-bounds warning-- DATA statements are not typechecked at all.

Typechecking DATA statements amounts to traversing the variable and value lists, making sure that everthing is assignment-compatible and that the two lists have the same length. Oh, and iterators have to be expanded too, making this slightly less disgusting than expanding array constructors. I'm giving some thought on the best way to do this.

March 17

Finished finding the bugs associated with subroutine resolution and checked in. My current test suite takes about 20 minutes to run. The first major offender was one of David Bailey's programs that was taking about three minutes to parse and resolve, which was pretty ridiculous for the size of the program. After some investigation, it turned out that hidden symbols were being saved to modules, which wasn't doing anything but taking up time and memory. After excluding hidden symbols from being written, the same program takes ten seconds to compile.

This is still a bit long and so I did some profiling and found a couple subroutines worth optimizing-- parse_name() and parse_atom(). After some attention here, the total test time is down to about 15 minutes, a 25% speedup. The bulk of the time is spent in LAPACK95, which creates a module with a lot of lengthy module procedures. The rest of it has individual wrapper functions for f77 LAPACK subroutines.

More profiling shows that the bulk of the time is now being spent in the stdio subroutines. The lapack subroutines use USE statements with an ONLY that pulls in a single symbol out of a lengthy module. The time isn't taken up finding the one symbol, it's while taking the inventory on where all the symbols in the module are.

The current idea for speeding things up is replacing the long names of various attributes with shorter names, or casting the various fields to a single integer instead of a set of words. For now, it's important to be able to see what is going on. More speed later.

March 16

Édouard Canot's problem with MERGE() turned out to be larger than previously thought. He was writing:

logical :: m(10)
integer :: k(10)

k = merge(1, 0, m)

which was failing because m is a different rank than the scalars. It turns out the MERGE() is elemental and 0 and 1 are conformable with m. I've added code to check ranks based on whether the function is elemental or not.

Added a few more test suites to the main ones I run and fixed the problem with referencing an array element of an array constructor.

Arnaud Desitter reported a problem with a string (array of characters) failed spurious in a UNIT=string tag, since g95 was expecting a scalar variable as the object of a unit tag. Turns out to need an array.

I also started a revision to resolve subroutine reference in the same manner as function references. After a false start, I ended up not re-using the existing function code, because subroutine calls are represented differently and this was making things too messy. This isn't quite done yet.

March 14

Finished moving user operators into their own namespace. The new code passes the current regression tests and has been checked in.

Édouard Canot reported a problem with MERGE() which has been fixed.

Since all the current tests pass, I went out looking for more test suites. I downloaded David Bailey's multiprecision packages which uncovered a bug in the rules for comparing derived types-- the names have to match as well as just about everything else about them. That passes now.

I also found a suite by Richard Maine, the current editor of J3. It uncovered a nasty problem with an array reference of an array constructor. Haven't figured that one out yet.

March 13

Last Saturday's hackathon took a lot out of me and I needed a break. Bang on, though.

I've implemented changes to how formal interfaces are compared with other formal interfaces and actual interfaces. The comparisons now take into account dummy procedures and can recurse to arbitrary depths (subject to stack size of course). Jos Bergervoet's code that failed to resolve now resolves correctly.

I've also started work on a large patch to split user operators into their own symbol tree instead of piggybacking on the regular symbols. The problem is that if a name is used for only a user operator, a variable with that name ends up getting defined. If the user tries to use this variable in a subprogram where the module has been used, an error results. While some hack might have been possible, it seems like a better idea to split it off the right way. As side benefit, the size of the symbol node decreases by eight bytes.

March 9

Finished and tested the RESHAPE() code. Also fixed a problem with converting the type of array constructors.

Hannes Boehm wrote in with a pair of programs that segfaulted. The problem in both cases was a failure to set the result name of a dummy function. In this case, the 'result' variable points to the original symbol of interest.

Jos Bergervoet reported a very subtle problem a couple of days ago that is now resolved. If an intrinsic type conversion was inserted, the rank has to be propagated through the conversion because they are elemental. He also mailed me a list of eleven bad boys that all gave g95 fits. Fixed them all except the one which involves splitting the operator interface names into their own namespace.

March 7

Added more code to deal with RESHAPE(), which means counting the number of array elements given to the 'shape' argument. From the number of elements, you get the rank of the result. Haven't had a chance to test this, and some old test cases still fail, so no checkin yet.

March 5

After monday's frenzy of bug reports, things were very quiet today. I've revised how arrays are handled a little bit, partially because of Jos Bergervoet's remaining bug and another bug with array handling that I found a couple days ago with the Plasmakin suite.

It turns out that you have to defer deciding whether an array reference is to an array element or a vector subscript until the resolution phase. This is because the subscript can be a module procedure, which can itself be scalar or a vector. So the decision has to wait until all the module procedures have been parsed.

Things are about halfway back together, except for the RESHAPE() intrinsic. It currently doesn't return the correct rank, which depends on the number of elements in the shape argument. No checkin yet.

In other news, the formatting people have given me permission to hold my oral defense, along with some "minor" corrections that I haven't seen yet. More on this as it happens.

March 4

Laurent Klinger reported a problem with an INTENT(IN) variable that is also an internal file in a READ statement. The error should have triggered in a WRITE statement.

Édouard Canot reported another crash having to do with array RESULT variables that were in the different namespaces.

There was a bunch of discussion about the REAL intrinsic. Katherine fixed part of the problem in simplify.c and I fixed another problem in iresolve.c.

Jos Bergervoet reported a bunch of other problems. The first had to do with modifying the symbol table too quickly before the identity of a construct was known. The second was some error handling in array constructor matching that could only fail if an extra right paren was present... (which it was). MATMUL was not returning the correct rank and array specifications weren't being copied to the module procedure along with the types. There was another problem involving MAXVAL(), but it is going to have to wait until later...

March 3

Katherine added a lot of intrinsic resolution functions.

Fixed bug that wasn't writing operator interfaces. The problem was that the symbol's access field was being checked instead of the operator's access field.

Fixed a derived type resolution problem. If a function returned a derived type, and the only place the derived type was used was when the result was assigned, the identity of the derived type still could be undetermined. Checks already exist for this in matching of an rvalue (structure constructor) and for declaring a derived type variable.

OOF90 suite now parses and resolves without error.

Got rid of the arg_number field in the actual argument structure. I thought this would be needed sometime, but it hasn't.

Fixed a bug in the actual/formal argument comparison. Only the rank of the first actual argument was being compared correctly.

Fixed some problems with the OSIM suite-- IF statement with an integer instead of logical expression. There were some other problems with using modules that weren't defined by the package that forced me to delete a couple of files. OSIM now parses and resolves.

LAPACK95 parses and resolves, at a glacial pace. This is because g95 is very inefficient in how it looks for symbols through the collection of namespaces. Speeding things up hasn't been a priority, but since it is part of the 'passed' column, that will probably change.

March 2

Laurent Klinger's chocolate arrived yesterday. It looks really yummy...

Laurent Dallois reported a couple days ago that g95 wasn't doing arithmetic with array constants. I've added support for this, it includes basic arithmetic and internal conversion functions. It doesn't include calculating through intrinsic functions yet.

Édouard Canot reported another crash while writing modules. The problem was that interfaces that contained a dummy procedure that was described by another interface wasn't being resolved. The resolution is properly recursive now.

February 27

Katherine added resolution functions for AINT(), ANINT(), CEILING(), CMPLX(), DIM(), FLOOR(), LOGICAL() and NINT(). The lack of resolution functions for these isn't likely to cause visible errors, since the type converter tends to hide functions returning the wrong type.

I was going to work on fixing the problem reported by Laurent Dallois the other day-- no arithmetic on array constructors, but ran out of time on other things. I've given the problem some thought and see sort of what needs to be done.

February 25

Édouard Canot reported a core dump on code in which a dummy parameter was a function with dimension. The problem was tha the array specification wasn't being resolved. I originally thought that it would be possible to resolve formal argument lists at parse time, but this counterexample proves me wrong.

I've removed the call to the resolver at parse-time and modified the traversal search for ENTRY symbols into a search for any function with a formal argument list. It passes Édouard's code as well as the current test suite.

February 24

Did some polishing of the interface code. The code that checked operator interfaces was actually dead, but is now back in the loop. The rest of the enhancements involve checking for ambiguities in interface list in parent program units.

February 23

Steve Kargl sent a small patch that adds an -fquiet option. This suppresses the errors/warnings message at the end and will make it easier to write test drivers.

There was a lot of success with g95 today. After a lot of small bugfixes, the miller suite finally compiles and resolves. Then I went to globsol and after a few more fixes, this test suite compiles and resolves as well. Despite a couple hundred lines of new code, several hundred lines of cruft have been deleted, so the total size is holding steady. This brings the list to four suites, three of which have f90/f95 style code. Whheeeee!!

February 22

Niels sent a small patch that updated the README, fixed a misspelling of his name in AUTHORS and replaced some C++ commends with CPP comments. I ended up deleting the commented out code, which called g95_parent_procedure(). Also replaced the last call to g95_parent_procedure() in the ENTRY statement matching with more current code and deleted g95_parent_procedure() for good.

I also fixed a core dump in the g95 thanks to the IA-32's hardware breakpoint facility. When a symbol was being undone, formal argument lists weren't being undone, leading to disaster during resolution. The problem was really weird. Code that exercised the bug was:

subroutine foo(type)
type (dt) :: v

The variable 'type' starts out as a dummy variable, which means that it gets resolved as a formal argument. The type definition statement starts out being parsed as a statement function, which gets as far as the :: before things go wrong. 'type' ended up with a formal argument list of its own that wasn't being properly resolved. During resolution, the bogus formal argument list was resolved and memory got stomped on.

Spent some time adding to the quad.f90 test suite file, since it is missing an assignment interface used in other test suite files. Then I discovered that assignment interfaces weren't being skipping on reading, but not on writing, which also messed up any following interfaces.

The bug after this is the fact that interfaces are defined for operators, and it is impossible in this case to distinguish between a unary minus and a binary minus. The interfaces all go into one list and the wrong list is searched later on.

February 20

Laurent reported the failure of the TRANSPOSE() intrinsic to return a rank-2 array, which has been fixed.

The large changes over the last two days have been committed. These rewrite how interfaces are written and read by modules, as well as how interface lists are compared. Several interface-related subroutine have been moved out of module.c into interface.c where they belong. There is also a new subroutine for comparing interfaces of user defined or intrinsic operators-- the comparison of these is different from generic procedures because the operator interfaces can't use keyword arguments, which makes it harder for two interfaces to have an ambiguous reference.

Things aren't quite done on this front. Such interfaces are supposed to behave as if there is only a single interface. The reality is that they are spread over multiple namespaces, so I have to make the interfaces in parent namespaces searchable and check for ambiguity there as well.

On the other hand, the current "first error" in the miller suite doesn't have anything to do with interfaces...

February 18

Laurent reports success with his test suite and that the chocolate is on the way! The fudge from Steven's chocolate is almost gone (it is heavenly), and I've decided that room-temperature is better than chilled. It is really delicious, and I can't wait for the Swiss stuff. Laurent sent me a line count of his suite and it's around 10k lines or so.

Steven Kargl reported a problem with logical(8) not being convertable to logical(kind=4). This started a small discussion on the list about why we have logical(kind=8). The solution was easy-- just added another loop in add_conversions() that has a double loop over the logical types, discards equalities and adds an internal function that does the job.

After that was done, I returned to the problem of loading interfaces. Got halfway through my plan and realized that it wasn't going to work. After some thought, I realized that the loading can take place after the symtrees are loaded but not before. The loading process is very delicate with regard to ordering. I've completed the code, but haven't had a chance to test it yet, and that will have to wait for tomorrow or maybe even later.

February 17

Laurent Klinger wroten in with two more problems regarding function naming which are now fixed. The current method tries to figure out if a single named argument is a procedure or not, and defers cases it can't figure out to the resolution phase.

Hugh Pumphrey reported a spurious warning with -pedantic and the PRESENT() intrinsic, which has been fixed.

LAPACK77 and Meissner now parse and resolve, so I've moved onto the Miller suite. The first fix was adding resolution of array specifications. There there but weren't being called.

The next problem was the PRODUCT intrinsic, which needed a resolution function. After that, I ran into the same interface problems as in globsol. This means that that problem is next...

February 13

Laurent wrote in with some compilation problems on HP/UX that he's working on.

I fixed a few more bugs. I added a call to g95_use_derived() within g95_find_component() so that using a component of a structure is considered "using" the structure and forcing the reference to the structure in a parent unit if the type name has not already been defined.

The other big deal was some initial support for elemental functions. There was some confusion in the file about which way the 'elemental' flag was, so I went through all the functions (and the subroutines) setting all the flags to the same interpretation. Then there was a line added to resolve_intrinsic() that copies the rank of the argument to the rank of the result.

The meissner suite now fully parses and resolves... hooray!

February 12

Michael Richmond reported a subtle problem-- If you used a function result in an actual argument list, it was parsed as a procedure argument. In the case of a function with a non-result clause, it has to be interpreted as the function result. Fixed.

February 11

Laurent Klinger wrote in and pointed out that g95 doesn't deal with elemental functions yet. There is a flag for elementals in the intrinsic table, but it isn't used at the moment. He says he'll send me some Swiss Chocolate when g95 can resolve and parse all of his codes, and I am looking forward to that.

Steven Bosscher's chocolate is now fudge. It tasted really good, and it ought be better in two days when it ripens, or whatever it does that makes it even better than when it's fresh.

I made an important change in how procedure symbol nodes are stored. If a program unit has a parent, the procedure name is created in the parent. The current unit also points to the node with a symtree node. This makes things right for module procedures, interfaces and internal procedures. It also makes it look like the name in question has been host-associated and an exception to the usual error message had to be carved out in g95_get_symbol() so that a declaration in a procedure could affect the symbol in the parent space. For example:

module test
subroutine ff(x)
if (tt(x)) print *, 'Hi'
end subroutine ff

function tt(x)
logical tt
tt = .TRUE.
end function tt
end module test

The 'logical tt' has to affect the type of 'tt' so that 'ff' can see it when it is resolved. It looks like things work, but I suspect that some more tweaks will be necessary. There were also some changes in how symbols nodes that represent functions nodes were stored.

For a long time, the name was created in the parent unit as a procedure and in the current unit as a variable (for functions without a RESULT clause). This let things work correctly, but didn't work well at all when the type of the function was specified in a data declaration statement. The type didn't get propagated to the parent program unit, where it had to be so that other module procedures could see it.

This was the main reason for getting rid of the dual symbol storage. Now, there is just one entity to worry about, which is how it should be.

This change passes through LAPACK fine, which was expected since LAPACK is very standard F77 code-- no contained program units. So I moved onto the meissner suite which has lots of small f90/f95 examples.

A couple problems showed up immediately. The dimensionality of array references weren't quite right and the current scheme for storing these wasn't able to calculate rank in all cases. So I added some fields to the array reference structure that make it easy to determine what each kind of subscript was-- a single element, a range or a vector subscript. This makes the calculation much simpler.

There was also a problem with namelists in READ and WRITE statments that was buggy and has been fixed as well.

February 10

Upgrade day. I've got a new kernel, a new version of X windows with DRM support and avoided upgrading glibc.

February 9

Several people pointed out problems with some intrinsics, particularly NINT(). When the various specific functions were being checked for a particular generic, the error suppression wasn't on, meaning that some error messages were shown that weren't supposed to be shown. The error message are only supposed to show up for the last specific being checked, which is also the name of the generic and even then subject to another flag. Things are fixed now.

Laurent Klinger wrote in with a parse bug in DO WHILE loops. G95 wasn't accepting an optional label between the 'DO' and the 'WHILE'. The standard specifies that a comma is optional before the 'WHILE, so the rather bizarre looking:


is perfectly legal. He also had another mail with some issues dealing with too-strict check functions for SUM and MINLOC/MAXLOC. You have to stare at the specification for MINLOC/MAXLOC for a minute to realize how messed up these functions are. There are several different forms which are subtly different from one another depending on how many arguments are passed to it.

Katherine has updated to check for alloca, along with a patch to g95.h that has some nested #if's necessary for using alloca correctly on AIX.

Salvatore Filippone sent in a bug where the intrinsic KIND was used in two separate modules, then both modules included in the same program unit. This failed because it looked like the name was originating from two separate modules. My initial idea was to define a bit that would flag whether a symbol was an intrinsic or not, then have the module reader check those bits, but a better idea suggested itself.

Instead of more attribute bits, when we decide that a function is intrinsic, its module name is set to '(intrinsic)'. This module name is impossible to generate from a real module, and it fixes the problem because intrinsic names are distinguished from user defined names. The name/module pair are compared and since they are equal, all is well.

Steven Kargl found a bug in the scalar_check() subroutine where the comparison was for inequality when it should have been for equality. He's also reported success of parsing and resolution on his code.

Steven Bosscher has an intrinsic test suite that I've been trying to get g95 to pass. Miscellaneous fixes to various intrinsics included: SET_EXPONENT(), SPACING(), RRSPACING(), NOT(), MOD(), MODULO(), FRACTION() and ABS(). DCMPLX simplification has been fixed and much of the code merged with CMPLX simplification. Several check functions were collapsed into common check functions. The test suite resolves without problems.

There were notably less mails about problems with intrinics, so hopefully we can move on to other things. I've bumped the version to 0.17.

February 6

Katherine is working on making the use of alloca() portable. Although this is a sticking point on some systems, it just makes like easier in places.

Jos Bergervoet sent a mail that had some g95 problems. Some of them were already fixed, but I did some fixes to the shape() and resize() intrinsics-- the fixes were pretty trivial-- != to == ...

This afternoon, I had a late lunch with Steven Bosscher. He's in town as part of a field trip to various aeronautical facilities. We talked for about two hours on all kinds of things-- where g95 is headed, language standards, other compilers and how to get an awesome view of Phoenix by climbing Hayden Butte.

He gave me 300g of chocolate, some Droste "Chocolade Extra Puur". He said he hoped that they were better than fudge, but this shows a profound misunderstanding of chocolate-- I'm going to make this into fudge. Ingredients are all, and I have high hopes for this.

February 5

I've been getting bad about keeping this page up to date. To recap the last couple of days:

Konstantin Olchanski sent a small patch that adds support for 132 character line lengths in fixed form. He also pointed out some shortcomings with binary-octal-hex constants when two's complement arithmetic is being used. I've addressed that issue mostly, except for 0x8000000, which still gives an overflow. He also pointed out that we don't honor the alternate hex constants of the form 'f800'Z. More on this later.

Steven Bosscher sent some problem reports for a couple intrinsics that have been half-fixed.

The DCMPLX issue continues. LAPACK uses DCMPLX in much the same manner as CMPLX-- integer arguments and sometimes one argument, so it looks like this has to be fixed as well. The problem with these extensions is that they are not in the standard...

I've also revised how static strings that give the name of library functions are stored. The previous method was to allocate a chunk of memory and put all possible string in there, one after another, then just search linearly for a string when needed.

The problem with this is that we kept having to increase the size of the pool, and it looks like there is going to be a lot more growth. Doing a brute force search is asking for trouble beyond a point, so I've adopted a more sophisticated approach. I now have a hash table with separate linear lists. All possible strings are no longer stored-- they are created as they are needed, which will do wonders for keeping the size down. The new code shaved about 100 lines off of a 400 line file, so this was definitely a good thing.

Even with the trimming, g95 is now 34,000 lines long.

February 2

Finished and committed the upgrade of simplification functions. They now all generate error messages. The original structure is still there, but there are nearly a dozen new subroutines that check for specialized things like type, arrayness, scalarness, ranks, etc. I also managed to consolidate common check functions into single functions and rewrote most of the min/max functions completely.

Hugh Pumphrey sent in a bug a couple days ago having to do with constructor expansion. The simplification of the elements was only possible when the constructor was being expanded, but the simplification wasn't even being tried. This is now fixed.

I've removed dcmplx as a specific of cmplx. It caused the behaviour of cmplx to change in unexpected ways. Anyone using dcmplx() is only using cmplx in the way specified by F77, so it seemed like a bad idea to break cmplx. It's still there, just not a specific of cmplx.

January 31

Worked a while on error messages associated with intrinsics. I decided on adding a flag that suppresses error message. When the intrinsic resolution has more steps, the flag is set and any error messages never happen. At the last step, the flag is off and error message appear.

After the easy cases appeared to be working, I started on the functions that have check functions. It's not quite a rewrite, because the current checks just have to generate error messages. I've also written a few subroutines that do common checking. This is about halfway done right now, so no checkin yet.

I also added the 'cd' forms of the double complex intrinsics. These are done by aliasing the 'z' forms of the commands. The generic form of the intrinsic will never select these, but naming them directly causes a reference to the proper 'z' form.

January 29

Committed the patch. Some of the error handling is commented out in order to be compatible with the old state and detect problems associated purely with the change. Watch for the appearance of lots of bugs to appear once the error checking is more fully developed.

January 28

Started a large reorganization of intrinsics. Now each intrinsic has a check function, a simplification function and a resolution function. The resolution function looks at the arguments and decides what the return type and kind are, and also decides what internal library subroutine to call. I've finished the modifications, and everything compiles, but I haven't tested it yet.

Looking at intrinsic.c, I've decided that it's too big (3500 lines) and needs to be made smaller. The obvious thing to do is break the check functions out into their own file. They currently occupy about 1500 lines, so this puts everything back into nice, easy to handle chunks. I think that simplify.h is going to be renamed to intrinsic.h, because all the prototypes for the resolution and check functions are going to have to go there.

Steven Bosscher sent me a letter this morning pointing out how other people handle this. The pro64 compiler has a .h file that contains a single C initializer with 13,000 lines in it-- all the fortran intrinsics in all the different ways that they can be called. For example, it turns out that MATMUL has 349 entries.

The reality is that this file was probably written by a script, but I think our solution is much compact and flexible-- a table with one entry per function. If a function is sufficiently strange, there is a nonnull pointer to a function that gives the correct result, and this goes for checking the interface, simplifying the function and now type resolution.

January 27

Heck of a day. I spent about midmorning to midafternoon fixing bugs sent by Steve K. and Steven B. Lots of little minor problems are fixed. Paul Brook also found a problem with component type resolution and mail in a patch. Katherine even slipped in a few bug fixes.

January 23

Katherine fixed a problem with arccosine returning the wrong values at the limits where the arctangent identity breaks down.

Steven pointed out an issue with the rank of an expression not being set, and I fixed expression_rank() that now works correctly. He also profiled g95 and found that g95 is very slow loading modules, with about 1/4 of the runtime being spent doing a brute-force search for a symbol's true name. True names aren't indexed in any way at this point, so searching them all is the only way to find it. Some of the larger module hierarchies have about 2-3 thousand symbols in them, so speeding things up is becoming important.

On my Pentium III/866, g95 compiles about 3700 lines/second on pure fortran 77 code (without modules).

January 22

Steve Kargl reported that g95 now parses and resolves much of his personal libraries under freebsd. He reported a problem with the SUM intrinsic that mysteriously vanished by the time I got to looking at it... perhaps the gnomes fixed it. I added a simplification function for SUM that resolves the sum call to the right library subroutine.

Laurent Klinger and Steven Bossher reported a problem with ASSOCIATED that bit when the variable had the dimension attribute. The code associated with the check function was pretty archaic and I replaced it with a call to g95_variable_attr(), which returns the attributes of a variable expression as if it were a symbol, and it looks like it works.

I also added a new match function, g95_match_char(), which matches a single character. Nearly two-thirds of the calls to g95_match() were to match single character strings. When I started g95, I planned on making g95_match() a versatile function that would be able to handle most situations. It turned out to be not so good because of error reporting-- if something went wrong during the match, it was a toss-up whether to return MATCH_NO or the MATCH_ERROR.

In the end, it was easier to call the individual matchers and deal with problems as they came up. Someday I'll go back and remove the now-unused features of g95_match().

I gotta get to bed. It's morning in the Netherlands, and Steven has woken up and is sending more bug reports.....

January 21

Katherine fixed a precision loss problem in arctangent. Arctan was using a version of pi calculated with half the digits that the other calculations were being done at.

Steven found a problem with how intrinsic functions and subroutines. The original scheme distinguished between functions and subroutines by the return type-- BT_UNKNOWN for subroutines. The problem was I've been setting functions to returning BT_UNKNOWN, particularly those functions that return all different types depending on their arugments. The new patch counts things up correctly.

January 19

Spent most of the afternoon on Claus Fischer's webserver, running checkerized g95 on LAPACK. I chose LAPACK because it is fortran 77, and it already parses and resolves without errors. The first problem was a bug in the traversal of the g95_code structures that caused most of the syntax tree to end up leaking. From there, I tracked down a couple of really trivial leaks, then struck gold.

The leak was saved symbols not being freed. One thing that makes fortran difficult is that there can be potentially many changes to symbols before the parser realizes that something is wrong and has to back up to try something else. When the parser looks up a symbol, the original state of the symbol is saved and the symbol is put on a singly linked list.

If the statement matching succeeds, the list is traversed and the old information is deleted. If the statement matching fails, the list is traversed, but old information is restored if the symbol already existed or the symbol is deleted if it was just created in that statement. Now, the bug bites if the symbol is looked up the second time after being created. Because it was the second time, when the symbol was linked into the list of changed symbols, the list was corrupted because it was already in the list.

This bug wasn't noticed until now because statement matching usually succeeds. On success, the whole list wasn't freed leading to the leak. On failure, information on symbols wouldn't have been undone correctly, which hasn't been a problem but could easily lead to symbol aquiring the wrong attributes. The solution was to add a bit to the symbol structure indicating whether the symbol is new or not, independent of the pointer to the saved information.

Anyhow, the g95 has been running on Claus's machine for most of the day, and will probably continue throught the night. The checkerized version is extremely slow...

January 18

Worked fixing problems with LAPACK. There were a couple of separate bugs in resolving the MIN/MAX family of functions, both in the check functions, and it turns out that you have to check for certain functions before others. For example, amin0 and min0 both take integer arguments, but amin0 returns a real result while min0 returns the integer. The upshot is that amin0 can never be matched by resolving the generic min function, and this is accomplished by trying to resolve min0 before amin0. There are similar conditions on min1/amin1 and the MAX family.

I also added a couple of intrinsic extensions that operate on double complex types. It's hard to say why the standard doesn't have these to start with.

January 16

Steven Bosscher wrote in about a problem where setting a pointer to NULL() was causing problems. First, the locus was getting lost, causing a core dump (fixed). The second problem was type conversion. NULL pointers are now converted to the right type by simply setting their typespec nodes. This was also fixed.

The second problem had to do with structures that can point to themselves. The declaration of the derived type triggered the code that checked for defined-before-used. Now, we don't do the check inside a derived type declaration.

Katherine is working on a problem with arctangent that was uncovered a couple days ago. For x>0.5, atan(x) loses half it's significant digits. The problem doesn't appear to be related to the value of pi used in the calculation or the infinite series. The investigation continues.

January 15

No code today, but there is news.

Claus Fischer donated an account on his webserver that has the checkgcc installed on it. Last night's run on LAPACK finished after about eight hours and produced no memory weirdness at all, but we didn't turn on the allocation tracking option yet-- there are probably plenty of places where memory isn't freed. A web status page is on the drawing board-- Vielen Dank Claus!

There are two items in the mail queue which I will hopefully get to tommorrow.

January 14

Steven Bosscher fixed a problem in g95_check_assign_symbol() incorrectly considering the rank of the symbol.

He also pointed out that the RESHAPE() intrinsic wasn't returning the correct type. The difficulty with this in the past is that the simplification subroutines only had access to the parameters and not the function node itself. Simplification in these cases involved building a copy of the argument list and building a new function call.

This was something of a pain, so the new scheme saves a pointer to the current function in a global variable. If the simplification's action is to set the type, we now have a pointer to the node. This makes things much easier.

Claus Fischer compiled a version of g95 with a bounds checking. It runs about 30 times slower than regularly, but it does run even though I was afraid it wouldn't. There is a problem running it under mkf90, but I'm running it in a loop through the LAPACK source. I've got another big job running and it's going to take a while.

January 13

Started on some of the backlock that has built up.

Fixed a problem with a core dump in g95_check_assign_symbol(). When an error was generated, there was no locus to go with the error.

Steven Bosscher sent a program with a syntax error that generated an internal symbol changing error later on. The problem was in the parsing of a FORALL statement. If an unexpected statement was seen, symbol changes weren't rejected.

Fixed a couple more pending problems. RESHAPE() was trying to simplify arguments that weren't array constructors (array variables). The symbol renaming in g95_use_derived() had to recursively search and rename symbols.

Clause Fischer got a checkerized version of g95 to compile, but it won't run on my system (fpos_t has to be an int and isn't), so hopefully he can try running it on his system and send reports on core dumps. Torbjorn Granlund, the author of GMP also helped out.

January 10

Minor updates to intrinsic functions related to the meissner suite. Added simplification functions for any() and all() intrinsics which just return the correct type and rank.

New module reading patch was on hold.

January 9

Michael Richmond sent in a bug report two days ago that I finally had a chance to get to. I made a change in how operators were printed so that unary plus and minus were included. This messed up the matching process, but it's fixed now.

More bug reports are in the queue, including one from Steven Bosscher about a core dump in the dynamic linker.... Sounds interesting.

I've also committed a change that make formal/formal interface comparison a global, because it has to be callable from the module reading subroutine. The module reading patch isn't complete yet.

January 6

Steven Bosscher reported a problem with old-style PARAMETER declarations. It turned out that their types weren't being set because the set_default_type() call was moved to another place. Problem is fixed.

Then I worked a bit on the problem of appending interfaces from modules. The intrinsic operators work, but the symbols need more work, since the behaviour of interfaces really cuts against the grain of how symbols work everywhere else.

January 5

Robert Luke wrote nice letter of encouragement and pointed out a problem with the tarball-- lang-options.h wasn't included in This has been fixed.

Steven Bosscher's problem with sourceforge's CVS set has mysteriously vanished.

I fixed a few more resolution problems, and then realized that I was actually fixing problems with the globsol package. The comments indicated that the code was compiled by a nameless compiler with some serious problems. I ran my script on globsol on another nameless compiler and ended up discovering another bug in the second compiler. The result now is that I have a globsol that I believe is legal fortran 90/95.

The current bug has to do with generic interfaces. Generic interfaces are saved like other information, but are loaded differently. Instead of loading the list of interfaces, using the module appends the modules to whatever is there. So if you use two modules that specify generic interfaces, the interfaces have to be combined, and that isn't happening right now. After some thought, I think that the module format is going to have to change again, though only slightly.

January 4

Added a new subroutine g95_find_get_symbol(), which combines the actions of g95_find_symbol() and g95_get_symbol(). There were a couple places that were doing both, and I went through all the places that called g95_get_symbol()-- this was because g95_get_symbol() changed in a subtle way not to long ago.

Steven Bosshcer sent a patch for moving the configuration options into a new file, lang-options.h. This is how g77 stored options, and the single string that stored all these options was larger than permitted by the C standard (but gcc handled it anyway).

I've also removed the -r option. All procedures are now type-resolved, and I'm going to start working on the new bugs this has uncovered in globsol.

January 3

Steven Bosscher brought up a discusssion on the GCC list regarding a proposed intermediate representation for GCC. This representation operates at a higher level than the tree representation that was our current only choice for interfacing to the back end. If the GCC people go ahead with SIMPLE, it ought to help g95 a lot.

I spent some more time working on resolution problems this evening. After fixing almost a dozen small problems, every file in globsol parses and resolves. Unfortunately, this isn't as good as it sounds. Currently, only modules are resolved, so this means that globsol sources outside modules are not being resolved. For fun, I turned on unconditional resolution and reran the suite. There are about 20 new bugs to track down, and I'm probably going to get rid of -r and have resolution always on.

January 2

Michael Richmond wrote in with a couple more problems. I first tackled a mail he sent some time back regarding a core dump when a subroutine was defined with an alternate return specification, ie:


This involved a small rewrite of how the alternate return specifiers are handled. They are now put into the formal argument list instead of a separate list because the return specifiers have to match with the alternate return labels of the actual argument list.

The next two problems had to do with the order of type resolution. When a function node has a RESULT variable, the function type has to be copied from that type. When the usual default type-setting is done, the function might be set before the variable, and that leads to a problem. The current method traverses the namespace and looks for functions that have result nodes. If it is untyped, we look at the result variable, setting it's default type if it doesn't have one already. The new type is then copied to the function.

This handler was originally put into the resolve_symbol() subroutine, but ordering issues cropped up. I think the way to go here is to make small, single operation subroutines that can be placed in whatever order is necessary.

Steven Bosscher compiled g95 with GCC 3.1 and pointed out that the alloca() in interface.c needs an #include . The other issue was the long string in display_help() that should probably be moved to a lang-options.h.

The next problem was a failure to recognize a binary intrinsic operator. The problem was that I was searching the interface for a subroutine, not a function. Searching for an appropriate function made it work. This doubled the number of successful compiles in globsol from 110 to 224 (out of 425). The automatic regression testing is clearly going to have to be fixed sometime soon.

I've updated the web page to reflect the fact that the parser is basically done, and have been working on the type resolution phase for quite a while now. Sometimes you forget to look up and see where you are. I've also made some notes on g95 over my vacation that I'll type in at some point.

January 1, 2002

Before I got sidetracked on formal and actual argument lists, the current problem had to do with a function returning a derived type not being saved correctly in modules. It looks like derived types are similar to interfaces-- they can reside in other namespaces and have to be saved. The solution is largely the same with interfaces in that symbols in other namespaces can be restored as private symbols in the namespace after the USE statement.

I was sidetracked by some cruft, though. One of the purposes of the recent overhaul of modules was to get rid of the double traversal required during saving modules. These traversals had to see the same symbols and was unnecessary and prone to errors. I got rid of that by initializing the serial number of modules to -1 when they are created. I've also added a 'written' bitfield to the g95_symbol structure that gets rid of the dynamically allocated array. We can get away with initializing these inside g95_new_symbol() because a symbol can only be written once during it's lifetime.

There is also a new method of loading modules, again. Now, we traverse the symbol table and write those symbols that need to be written. mio_symbol_ref() has been changed so that when a symbol is referenced that hasn't been referenced before, it puts the new symbol on a stack. After the traversal is complete, we loop, popping the bottom of the stack and writing the symbol. This can cause other symbols to be referenced which are then written at a later time. When the stack is empty, everything should be in the module.

The format of a module also changed slightly. There is now no count of the number of symbols in the module. The reading subroutine has to figure out what the largest symbol number is before setting up the table for the new symbols. Not a big deal to add.

When trying to test these changes, I ran into the problem of wondering what source file produced the module I wanted to examine. This sort of thing should be in the module itself, so I added it along with a timestamp of when the module was produced.

Once this was working, I still got the same error in globsol, but for a different reason. The module procedures have some redundant USE statements in them that load the same symbols multiple times. There was code there to prevent this, but the symbols were being loaded into different namespaces. The solution is to broaden the search from the current namespace to the parent namespaces. I ended up redoing a bit of the traversal code to avoid g95_traverse_ns() which has the bad property that the work function can only have a single argument.

The first problem advanced to the next file in globsol, the problem had to do with structure constructors that had the wrong types. Instead of trying to convert the types, it just complained and errored out. It was very cool to be able to call some subroutines which are already there and are known to work fine.

Next was an incorrect error on the intent checking for defined assignment interfaces. These were being treated like the other operators, and defined assignment has a different set of required intents.

After that was a long involved bug hunt into function types not being set because they had RESULT specifications that weren't being copied. Fixing this involved a slight rearrangement of the ordering of the various actions in resolution.

Then came a really minor bug in the modules where the symbol part of a structure constructor wasn't being saved. The fix for this was adding a single line.

Two more files compiled successfully, then another glitch, this time something unimplemented. Defined assignment didn't convert the assignment to a subroutine call. Added that.

Next problem had to do with expanding structure constructors as if they were array constructors. Fixed.

Globsol used to compile about 80 out of the 470 files. Now we're up to about 110. The only visible errors are in a single file, the failure of which prevents about 360 files from being compiled...