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.

2001 Archive

December 31

Back.

I started by reworking the parsing of actual argument lists slightly. There is a rule that once a keyword argument is seen, the rest of the arguments must also be keyword arguments. Some of the obvious error checking has to be deferred until later, because the procedure's interface may change (it can be an internal procedure).

From there, the comparison of formal argument lists was broken. This code was in the part that checks to see if a new interface can be added. The idea is to 'compare' the new interface with each of the old ones so that we can be sure that there doesn't exist an actual argument list that is ambiguous between two formal interfaces. These rules are found in section 14.1.2.3.

After this was done, I fixed the code in g95_compare_formal_actual() to deal properly with optional arguments. The new version also relinks the actual argument list in the right order and adds any blank nodes that correspond to optional arguments that are not present.

Along the way, I added code to the resolution phase that bypasses g95_check_assignment() if the left or right sides fails type resolution. This caused an annoying message complaining about how it was impossible to convert 'unknown' to whatever the LHS was, but it's gone now.

While the old code was clearly riddled with bugs, it wasn't noticable because the resolution wasn't functioning well enough to make it obvious. Steve Kargl's test code, a pain in the butt, but very basic, now works and has been added to the g95 test suite.

There was also a nasty revelation-- you can put subroutines and functions into the same interface. The fortran standard is a little annoying in that it often says what is prohibited and doesn't go much into the consequences. The current code assumes that a generic name is either a function or subroutine of some sort which isn't right. The good news is that the fix mostly involves deleting code.

December 21

Made a small fix that forces all formal argument lists to be written to the module. This gets past the bug found last night, but immediately runs into another one-- functions that return derived types don't seem to have the right types.

I am leaving for home tommorrow morning, so this will probably be the last for g95 for this year.

December 20

Decided to move past the frustrating bug and concentrate more on small, easier fixed bugs. Abandoning the miller suite, I went back to globsol which not too long ago parsed fine with only about 6 files out of 475 giving any problem. Currently only about 80 files can be compiled due to dependent modules being missing. I revised the check in g95_check_pointer_assign() to call g95_variable_attr(). Attributes like pointerness aren't stored in expression nodes, but can be determined by traversing the reference lists of components. The base symbol was being checked which isn't the right things at all.

The next difficuly was similar-- taking the rank from the base symbol instead of the list of reference nodes. After some initial attempts, I realized that the best place to do this is right after the variable specification is matched (which generates the reference nodes).

December 16

Made the changes yesterday and today to get derived types host association working. A symbol node has to be created when the typename is first seen in the program unit in case it is defined later in the specification. If the derived type is 'used' before the components are declared, then the name has to refer to a host associated derived type. If this happens, the existing symbol is deleted and all references are redirected to the node in the host unit.

After that, I fixed a core dump when comparing interfaces-- if the formal argument list wasn't long enough, it just kept on going until it segfaulted.

The problem after that was a problem with the SCALE function. In the intrinsic symbol table, it had specific types and kinds when it actually a generic intrinsic. I added the selection of the right specific to the simplification subroutine, and also noticed that the constant simplification assumed a radix of two, which has also been fixed.

At this point, Alan Miller's quad.f90 parses and resolves correctly. Hooray!

The next bug has to do with arrayness and this is the last frontier for the parser, and I worked for a while revamping things, yet again, but this time with a little more thought beforehand. The thought occurred that the only thing that really needs to be stored in expression nodes is the rank of the expression and not the complete shape.

December 13

Nicolas Produit wrote in with a pair of bugs. The first bug was an incorrect syntax error when a case label followed the case selector without any intervening space. I added a call to g95_gobble_whitespace() at the right place and everything is OK. The second bug had to do with writing modules. His code doesn't break on the current version so hopefully things are OK.

December 12

Finished the code for loading namespaces and then got one of those revelations that you wish you'd had earlier. I realized that we don't actually have to reconstruct the nested namespaces that are created by nested interface blocks. If we leave things alone, the symbols in the interface get loaded into the primary namespace as anonymous symbols, a mechanism that already works fine. Things still point to the right things and everything is OK. I ended up deleting a bunch of stuff I'd just written and it looks like it works fine.

December 10

Michael Richmond wrote in about another core dump, this time when resolving a subroutine with an alternate return. In a sense this isn't that surprising considering that formal argument list handling has been changing rapidly.

I got started a little too late on updating module reading to be of much use. I know that what I have doesn't put the symbols into the right namespaces, and I couldn't quite see where this happens in the current code. I did get some done and will have to work on it tommorrow.

December 9

Another good day with g95. I figured out a way to deal with saving and restoring interfaces within interfaces. It involves storing a number with each symbol that tells which namespace it lives in. All symbols being saved are in the same table as before-- I realized that the name of the symbol doesn't matter in this table. When a symbol with an interface is found in the regular traversal, we just recursively save that namespace and so on.

In between working on this, I finally ripped out most of the resolution subroutines scattered all over and put them in a new file, resolve.c. This 'new' file already has about a thousand lines in it, and substantially reduced the size of some other files, in particular expr.c, which is now down to about 1500.

I also changed the resolution of interfaces slightly. These are type-resolved after they are parsed. Because they are scoping units, there isn't any more information that is needed to determine the types. The subroutine g95_set_default_types() was being called, but that wasn't quite enough-- the flavor of the variables also needs to be set, in this case, whether a name is a variable or a procedure. If it was a procedure, that information has already been set by the act of parsing the interface itself. The remaining FL_UNKNOWNs are really FL_VARIABLE.

Thomas Koenig wrote in pointing out a problem with g95 that I introduced yesterday. The loop for writing symbols does a traversal until nothing more is written to the module. I was checking for this by comparing the old file postition (fpos_t) with the new file position after the traversal. Well, it turns out that for Linux systems with large file support, fpos_t isn't an int and isn't even a long long, like I thought it would be. It turns out to be a structure structure, which don't compare well.

So we're back to the original scheme of comparing line and column counters in the module_locus structure. Writing a module appears to work and the new legibility changes I put in yesterday make it easy to see. Now on to reading the new format.

December 8

Got some quality time with g95 today. I finished the rewrite on how modules are written. Now it corresponds more with how modules are loaded. Symbols are written if their access specficiation permits. If these symbols refer to other symbols, then those symbols are written as well. A lot of the old clunkiness is gone and the format of the module changed slightly, with some improvements to human readability for debugging purposes.

After spending some time looking at the standard, it turns out that interfaces can contain one another and these intervening interfaces can define types used in argument lists, and these arguments can be hosts associated. G95 parses this sort of thing, but now we have to load and save it to a module file.

This means a more general approach is needed to refer to other entities besides symbols, and the symbols do not necessarily appear in the initial namespace.

Oh, and I also have my DSL connection back which took long enough. No more accessing the internet through a straw...

December 2

Started on writing formal argument lists, got partway done and realized that modules are written in a fragile way that depends on two traversals working the same way, so I worked on figuring a way to make it work by traversing once.

I've also update the module documentation on how module reading works-- it was pretty out of date.

December 1

My DSL line has been down the last couple of days due to my attempt to avoid becoming a customer of MSN. I've been spending quality time with the phone company and my new ISP's tech support people. Both claim that the problem lies with the other. So my current connection to the net is over a 14.4K connection with an ersatz PPP.

Nevertheless, I can still get to sourceforge over SSH, so I can still do some things. The current problem, saving formal argument lists sort of stalled this afternoon so I went back and examined some of my basic assumptions. I've decided to trash what I've done and go back to something closer to the original plan-- saving partial namespaces of symbols associated with formal arguments instead of saving and restoring a special formal argument structure. The main program I was running into was how to handle derived types.

I've also done a lot of thinking about how module procedure symbols are handled. I've decided that the current method of maintaining two symbols in two separate namespaces is very error prone. The current plan is now to have both namespaces point to the same symbol, which should work a lot better. Internal programs will work similarly-- the main symbol there will be visible in both namespaces as well.

November 27

Worked a bit at translating some of the scibblings from last night into a workable scheme for storing formal argument lists. No checkin, but I did make some progress. I spent a long day debugging unnecessarily convoluted code written by idiots and that took something out of me.

November 26

I ran a test program Steve Kargl gave me a while back and to my surprise it dumped core. After a long investigation, it turned out that it was dumping in a different place than it was last time. The current problem is that formal parameters and argument lists are not being saved in modules. I worked out a quick solution, but it was immediately clear that it was inadequate. Formal parameters have their own namespaces and that isn't what I had, but I think I can get away with less.

On the way, I realized that formal parameter types have to be resolved before other types, because the whole interface of all module procedures have to be known before the body can be resolved. I added some code to do this.

G95 is now 33,000 lines long.

November 25

Got the string pool code working. It seems to work and there will probably be more string in there before long.

Getting the dot product code going uncovered another problem-- array references don't make it to the expression node. I spent some time restructuring some confusing references to 'shape' that weren't necessary.

Adding the function resolution code uncovered lots of problems...

November 24

I got a couple of things done today. I implemented a new convention for host association. If a variable is host associated, it's symtree in the current namespace points to the symbol node in the host namespace. This lets us detect when a user tries to modify something that has been previously host associated.

I fixed a couple of problems in function resolution where type information was not being propagated.

I've started on a simplification function for dot_product(). It doesn't do what you'd think offhand, it actually copies it's arguments and selects the correct library function based on the type of the arguments. This has highlighted the need for a string pool of various constant strings, like the names of internal type conversion functions.

November 20

Malcolm Cohen answered my question on the fortran interpretation. Turns out my example is not standard conforming at all, and he was able to put his finger on the reason. I've thought a bit about a change to the data structures that would deal with this and similar problems. It's not large, but it is fundamental enough to make me nervous. Thanksgiving weekend has traditionally been a good time for fortran.

November 18

Got busy with some other stuff and then ran into a quandry over retroactive type declarations. I confirmed that the problem with the Miller test suite is a failure of host association of type declarations. G95 mishandles this because it also has to handle a case where the type can be declared after it is used, which sounds totally wrong to me. I've posted an interpretation request to the J3 mail list.

I think I'm probably going to have to put together some kludge that makes the Miller suite work even though it probably won't end up being correct.

Steven Bosscher sent a letter a couple days ago pointing out that development on the Pro-64 compiler has continued even though SGI is not supporting the project. It's on sourceforge under the name Open-64.

November 13

Steven Bosscher has converted our internal docs to texinfo format and from there to pdf. Links are available at the top of the page.

No one has stepped forward to explain the extra 2000 hits we had last week, so it looks like they are the work of a bot.

November 12

Steve Kargl sent a test case that also failed in the module procedures from the most recent snapshot. I tried it on the current g95 and it failed as well, though silently. I realized that the types of functions that are module procedures have to be determined before any of the module procedures themselves-- module procedures can call one another.

I've added some code that does just this. The patch is across several source files but isn't particularly large. Steven's code works, my little test case works, but the Miller quad precision module, which started this whole mess still doesn't work. The cause is derived types not showing up as equal when they should be. This bear has reared it's head before and is not going to be easy to fix.

Steven Bosscher pointed out some unnecessary casting going on in st.c where DO-loops and FORALL loops were being displayed. I've added that to this current patch.

November 11

Worked more on getting the module procedures associated with overloaded intrinsic operators to work. There was some new code added, but mostly it was rearranging existing code. The rearrangements were necessary to comply with all the rules and the awkward necessity of keeping the same symbol names in two different namespaces.

I almost have it, but it's getting late.

I was looking at the web statistics and there was a huge spike of 2000 page views on November 8, followed by about 800 on the 9th. The mention we got in Linux World News last month generated about 700 hits above the usual 200-300 hits. If anyone knows where this came from, mail me or the list, although this may have something to do with a letter I got from a spambot at about the same time promising ways to get more hits.

November 10

I downloaded Udo Grabowski's stellar model code yesterday. I haven't had a chance to do anything but a 'tar tvfz' on it, but it looks like a lot of code for g95 to test.

Lots of small fixes to function resolution today. Right now I'm stuck on how module procedures are supposed to work. The main test code is Alan Miller's quad precision package, which does lot of things like defining generic interfaces with the same names as intrinsic functions.

November 7

Michael Richmond sent a bug report against the last set of changes. External functions were causing a core dump due to a really stupid mistake. Some simple cases seem to work right and I'll try to do some more in-depth testing tommorrow. The changes I've been talking about for the past couple days have been checked in.

Katherine made some minor changes regarding the -l1 option.

Steven Bosscher now has write access to the CVS repository. I've made a backup... :)

November 6

Wrote all of the subroutines that handle resolution for each of the three cases. This code is really raw and probably very wrong in some cases. I'll check it in after some testing.

November 5

Michael Richmond wrote in with a bug that I introduced two days ago. The problem is that CHAR() is a generic function and is also it's own (and only) specific. When I originally wrote make_generic(), I didn't think this was possible and what happened was that CMPLX ended up being a specific of CHAR because it follows it in the intrinsic-creation procedure. His code was:

CHARACTER*2 A
A = CHAR(1)

The '1' was converted to '(1,0)', and bombed when it was assigned to A.

Tim Prince wrote in with a message to the list about the SGI library. His best line was:

    Minor cases of the usual C programmer disdain for Fortran and for portability

The worst problems include using functions without prototyping them, SGI-specific headers and defining floating point numbers by an array of their hexadecimal equivalents (not very portable).

Steven Johnson sent a note explaining that the failure of config.guess to identify a MacOS system was due to an old config.guess and giving a pointer on where to find a newer version. The new version recognizes MacOS. The problem is now that the compile farm machine doesn't have Python installed on it.

The config.guess did fix a problem with recognizing x86 BSD, so we now have five regular machines in the test suite. The current results are already up, and it looks like all the platforms have the same successes and failures.

Despite a couple hours playing Wolfenstein Test 2, I've implemented the rules in section 14.1.2.4 for determining if a procedure call is generic, specific or unknown. My favorite tactic is to lob a grenade into the front of the forward bunker after the allies have taken it, then follow it up with a sneak attack through the front door, which they usually have their backs to. The only big change was that I had to add a bit for flagging if a procedure is inside an interface body or not. The next thing to do is implement the procedures for resolving function names in each of these three cases. I'll check it in when I have some bare bones routines that do these, probably sometime tommorrow.

November 4

Got a note from Tim Prince today. He is working on building the pro64 libio and has identified the I/O components of it. I'm eager to see where he's at on it.

I found a freely available weather prediction code called MOM3 that I want to add to the test suite. It was written by the Geophysical Fluid Dynamics Laboratory and is available for download. It's about 75k lines of code that looks like it started life out as a fortran 77 code that has been mutating towards fortran 90 for some time now. Glancing at it, the code makes heavy use of preprocessor directives and will need a little work to make it palatable for g95.

Jonathan Dursi has volunteered to get it shape.

If anyone has a large code that they'd like to donate or knows of a code being available, let us know about it.

November 3

Got a letter from Udo Grabowski today. He was going to give us one of his code to use for the test suite. The NDA flew across the Atlantic three times before everyone was satified and I hadn't heard from him in a while. It turned out he was on vacation, doing a road trip in the southwestern US.

I started work on implementing the function resolution rules in section 14.1.2.

I added a pair of functions to intrinsic.c that check to see if a name is a generic or specific function name. The function that was there wasn't going to work because a name can be both (like, say, ABS()). The listing of symbols was also missing a bunch of generics and specifics, weird ones that you wouldn't think of, like CHAR(), INDEX(), LLT() and friends. I'm guessing that these are there to support alternate character kinds.

November 2

Fixed a core dump in the floor simplification function that only seemed to bite on the alpha architecture. 87% of the test suite compiles and errors in 1% of the suite prevent the remaining 12% from being tested. I took a look at the remaining problems and one thing that jumps out is function resolution, so it may be time to tackle this bear.

November 1

I got a chance to look at Marcus Lundblad's code and found the cause of the core dump in the code that manipulates the actual argument lists that has been bad for some time. Scary.

Michael Richmond sent a letter pointing out a flaw in the returned type of MIN()/MAX() that I tried to fix yesterday. The specifics worked but the generics had problems. I was setting the right type at one point, but it was getting clobbered later.

My upgrade to autoconf 2.50 caused a problem with the test suite-- config.guess returns a slightly different name on the power pc architecture. This has been fixed as well.

October 31

Marcus sent the rest of those files, but I didn't have a chance to look at them yet. I fixed the core dump associated with the MAX() function and upgraded the MIN/MAX family to return the correct types.

October 30

Marcus Lundblad sent a program that dumped core, but the program used some modules that weren't included in the mail, so I couldn't reproduce the problem. I spent some time tracking one of the two remaining core dumps in the miller suite. The dump was inside some GMP routines and so I couldn't tell what was going on. After a process of binary chopping I think the problem is inside MAX()...

There are also some problems with the test suite that need to be tracked down.

October 28

Marcus Lundblad wrote in with a problem that other have noted-- the configure script has problems finding the GMP libraries if it is actually installed on the build system. I've simplified the script so that --with-gmp-dir modifies the values of CPPFLAGS and LDFLAG. Then the script does the trial including and linking as normally. This approach was actually suggested by Steven Johnson a couple weeks back, and it's clear that getting more sophisticated than this is just asking for trouble.

I've upgraded my autoconf to version 2.52, which will get propagated to the tarball on the nightly download.

I got the MacOS version to compile, but the problem is that config.guess isn't able to identify the system. This means that a --build=none option is necessary. This makes it hard to add it to the regular test suite.

I also worked on eliminating a couple core dumps in simplify.c.

October 24

Ross Bogue wrote in asking what was necessary to get g95 going on MacOS X. I told him that GMP was the main problem, and he figured out how to get GMP to compile without trying to use the wrong assembler libraries. It turns out that if you use

--target=none

, then GMP doesn't try to get fancy with assembler code and uses pure C. He got it to work and reported success with a trivial program, though I suspect that more than that will work.

I tried to duplicate this on the Mac on the sourceforge compile farm and got the library to successfully build, but ran into a problem trying to link it. It turns out that my installation of autoconf is too old to recognize the Mac's architecture and that leads to configure problems. So I've started upgrading my autoconf, which is pretty old (2.13).

I changed some of Steven Bosscher's code this evening, moving the check for statement labels on statements that shouldn't have them (like CONTAINS) upwards so that error reporting is immediate instead of buffered.

I printed my thesis tonight, it's 160 pages and 3M of postscript, with one small section still to be written. It was something of an unexpected thrill.

October 22

Fixed a problem with the statement labels being defined twice. This was causing much of the test suite to fail, but LAPACK77 now parses fine on Linux/x86. I need to arrange for the suite to be compiled on a more regular basis.

October 21

Lots happened last week, not much having anything to do with g95. My thesis is almost complete and I got sick. After two days without solid food, my digestive system has just about completed it's reboot.

In g95 news, the test suite drive appears complete and has been checked into CVS. The current test machines are x86 linux, alpha linux, ppc linux and sun space.

If someone has a machine on the net with a different OS/architecture that they'd like to donate some early morning cycles on, we can use it. The test program cleans up after itself and takes about half an hour to run on most machines. All that is needed is an account. If you're interested in donating, mail me.

People have been talking about working on the back end and library on the mail list, and I posted a list of milestones that I can see, and will bring them up to the website soon.

October 15

Found out that my upload and download to/from the compile farm didn't work. The files got there corrupted, so I had to figure out another way to do it. As of now, 12:53am, it works. This means three or four testbeds, so it should be worth the aggravation. Hopefully not much more work will be needed before I can get back to g95.

October 14

Worked today and yesterday on the regression test scripts again. They're almost ready to go. I've updated a bunch of information on how to compile g95 and how to test it here. People who are contributing should download their own copies of the test suite and start using mkf90.py to check their work.

The first large scale tests in g95 in a while show that it has become pretty broken while the tests weren't being run. I've devoted a lot of time to testing and I'm more convinced than ever of it's importance.

I also got some work done on sending files to and from sourceforge, which will give us a couple of test machines right off. Upload works fine, but something weird is happening with download.

Steven Johnson answered a question I had about some strange behaviour that caused the g95 configuration on other machines to have configuration data left over from my own machine. The basic gist was to upgrade, which is a very easy way to fix things.

October 11

Worked on the test suite scripts, checking the first revisions of the master driver and the local driver into CVS. There is also a new version of mkf90.py-- this now functions as a standalone program for local testing by developers and as a module imported by local_test.py.

Preliminary result pages can be seen at http://g95.sourceforge.net/results.

October 10

Ok, email is back, but the address is still going to be changing soon.

I added patch Steven Bosscher sent a day or two ago that improves handling of goto-branching.

October 9

If you've sent me an email today or yesterday, I'm probably not going to get it. I wasn't expecting the andy@xena address to last much longer anyhow, and am in the process of activating another email.

October 7

No update for a long time-- non-g95 things have been hectic. A couple people have asked if my thesis stuff will be available after my committee gets done with it. I'll put a link here to the thesis and my papers when it is all over.

I've been conversing with Michael Richmond about some HP compile issues and Steven Bosscher about various issues. He's almost done with the test-and-jump code for the character SELECT CASE statement. Steven is also converting some of my docs to texinfo. The preview looked good.

Toon Moene posted an interesting mail to the list. He's looking ahead to when we actually start working with the GCC back end. After thinking about it a bit, I couldn't see any reason why we couldn't start on that right now-- the main issue is someone to actually work on it. Toon sort of volunteered, and his copyright assignment is already on file with the FSF.

I worked on the test script some more tonight. The output looks right and I finished the script part that uploads the final results to sourceforge. Some more testing is needed, but the results should be visible in a couple days.

September 30

Steven Kargl sent a note about some problems with the configure script finding the gmp libraries where gmp has actually been installed. Looks like it's working.

Steven Bosscher is still working on the SELECT CASE branch-and-jump needed for character cases, and ran into a couple deficiencies of g95 dealing with not enforcing branch restrictions.

Got a bunch of stuff done this weekend. I made a start of getting the test programs to produce webpages. Right now it works about halfway.

September 27

There was a lull in thesis work today, so more work on the test suite. At this point, it'll download the files from sourceforge, build a tarball, send it to a remote machine, unpack it, configure, compile and link g95. Then it starts the test compiles, collecting the results. The results aren't downloaded yet, but once they are, webpages will be built from the results.

I'm not sure if I mentioned this, but the current tester will drive multiple machines at once. The eventual output will display results from whoever is willing to donate spare cycles.

September 24

Not much time today, but I did get the remote script to work. Now we just need the part that downloads the results, then builds and uploads the resulting webpages. The current mess is 1200 lines of python, about 500 of which were already laying around.

September 23

Steven Johnson reported that it was Linux World News that linked to us on the 20th, causing all those hits. He also suggested a few more tweaks to the configuration systemt that I've implemented.

Steven Bosscher sent a patch that implements the branch and jump for character SELECT statements. For integer selects, we'll still use the gnu back end because it already knows about ranges and it can also transform the SELECT into a jump table, which is about the fastest way to implement a SELECT.

I've continued to make progress on the test suite. I've been working on the script that will run on the local machine and compile the various test programs. Since this is mostly a copy of the mkf90.py script (it's in CVS under /test), it's almost done. After this, I just need to collect the results and build the webpages.

Progress was hampered by downloading the Linux version of Return to Castle Wolfenstein. Somehow I never thought I'd be a sniper for the Wermacht...

September 21

It looks like that magic 'make dist' that Steven Johnson has been extolling the virtues of for the last couple days really works. People who want to download the tarball get a tarball that looks like all the distributions-- just type 'configure' and 'make' and you get the file you want. Things are slightly more complex for people making changes to the configure.in or the other configuration tools-- you have to run 'autogen.sh' with some arguments that will be passed to configure, which is g95's case is where the gmp library lives.

There were a record number of hits on the website yesterday, a little more than a factor of two above normal. Thanks to whoever linked to us (I can't see where they're coming from anymore).

September 20

Steven Johnson and I have been exchanging mails talking about autos-- autoconf, automake, autoheader and much more. After some resistance on my part, he made me see the light, I think. Anyhow, this build stuff is a lot more complicated than I thought it was. We're still disussing details.

Steven Bosscher found a bug dealing with statement labels on END and end of block statements that we're going to have to deal with at some point. I was also cleaning out my mailbox the other day and found a patch of his that he sent regarding a change to how g95 prints types and kinds in error message that I'll need to apply soon.

September 17

Steven Johnson got a chuckle out of my configure.in and suggested some improvements. He showed me some better ways to do some things I puzzled over for quite a while. I have a letter to him explaining some difficulties and hopefully we can clean it up more.

Steven Bosscher sent a patch adding more stuff to select, mostly dealing with adding the unbounded intervals on the top and bottom of the ranges.

Got a mail from Tobi today. He is in Marseille doing an exchange program. The internet access is very bad, so I pointed out some of the war-driving articles on 802.11 I've been reading lately. Hopefully he will ste^H^H^Hfind a better connection soon.

Katherine is switching jobs soon and has been working on finishing some loose ends. She hopes to have more time for g95 next month. I've figure I've used about 10,000 cpu-hours on her cluster relating to my thesis work, for which I am extremely grateful. As far as I am concerned, g95 is already paying some serious dividends.

Her in-laws live in Surprise, Arizona which is not too far from Mesa and she may come down here in a couple of months. I've invited her husband out to dinner as well so that she doesn't have to explain that she is going to dinner with some guy she met on the Internet...

I fixed a bug in eval_intrinsic() that Steven B.  found the other day. Expressions like "A"<"Z" weren't reducing at parse time, but they are now.

September 15

Finished the machinations associated with autoconf, at least for now. I've deleted the Makefile and added Makefile.in, congfigure.in, config.sub, config.guess, install-sh and configure. The configure script is generated from the configure.in file by running autoconf, so it isn't strictly a source file, but it's there because that is how most people build software these days.

The new sequence is to run 'configure' to generate the Makefile, then running make. The configure script takes a single g95-specific argument at the moment, --with-gmp-dir=PATH, which tells g95 where to find the GMP library if it isn't installed in the usual place that system libraries go. There is also support for testing which will allow linking against multiple possible libraries according to which host configure is being run on.

Steven Bosscher pointed out a couple problems with comparing strings that we're working on. I added a new function g95_compare_string() that compares strings like fortran should (differing lengths pad spaces at the end) and also takes care of ascii vs potentially non-ascii collating sequences. Katherine made a good start on handling non-ascii character sets and I hope I've finished it.

September 13

Worked with autoconf a bit today. The only real feature we need to detect at this point is where the GMP libraries live. On test systems, they'll live in the tarball that is uploaded to the test system, and so we need a way to point configure in the right direction.

I don't know much about autoconf (but will no doubt learn a lot), so it is slow going.

September 12

Steven Bosscher's copyright assignment showed up today. He was actually supposed to be in the Phoenix area this week, but his flight was turned back halfway across the Atlantic for the obvious reason. He sent me a patch for SELECT CASE that I'll apply soon.

I started work on the local end of the test script and realized that it's high time to add autoconf support for g95. I'm thinking about not using the sourceforge compile farm since it is set up in a manner that makes it difficult to transfer files back and forth.

I'll be checking the new code in when it starts to work, and will hopefully return to the main g95 code soon.

September 10

CVS is back. If you've checked something out, you probably want to delete everything and re-check everything out.

Udo wrote back-- he finally got my NDA via snailmail. He had to show it to a couple of legal people and revise things slightly, but things are looking good. He also has the (free) source to three stellar dynamics packages that weigh in at a total of 30M. I can see that we may have to request more disk space from sourceforge...

Worked a little on the test driver this evening. It downloads CVS files and the test suite fine. Now I have to get some systematic way to descibe a test machine-- userid, password, ssh available, etc.

September 9

Moving forward again, but at a slower pace. Got a mail from SF about the file-- the 24-hour turnaround is longer this time, either because it's the weekend or they're getting tired of processing multiple requests after I botched things up pretty good.

I had a chance to work some more on the master test script, with the basic uploading and downloading subroutines.

September 8

The CVS archive remains screwed up. It looks like I deleted everything when I attempted to delete just the screwed up test directory. Things are on hold while SF moves the files back...

September 6

The current plan is now to implement something on Sourceforge that is something like Rob implemented on his local machine. The difference will be that people who have write access to CVS (Rob, Katherine, Tobi and whoever else wants to step forward) will also be able to add and edit test cases, which is what we really need in the first place. Revision history on the test cases isn't particularly important.

Steven Bosscher has completed a patch to check for overlaps in the SELECT CASE statement. I'm just waiting for his copyright assignment before I commit the changes.

The directory reorganization messed up my update script and the web page was blank for most of a day.

The last couple of days on g95 remind me of a bumper sticker I saw a couple years ago: "Another crappy day in paradise".

September 5

Putting the test files under CVS was a good idea, but it isn't practical. Exports are painfully slow and I've asked the sourceforge staff to manually delete the small fraction of files that I've imported so that even the initial version will be deleted.

I tried the same thing with scp copying individual files with the same results, and the fundamental problem is that latency kills the throughput because handshakes have to be sent back and forth for each file. The scheme for downloading the test files is now a command that looks like

ssh andyv@g95.sourceforge.net "cd www; tar cfz - test_suite" | tar xvfz -  

September 4

The sourceforge people took care of the directory structure, and I've imported the first set of test cases. It's not clear that this is going to work very well. CVS appears to be inefficient when transferring files and even my DSL connection may not be enough.

September 3

Steven Bosscher reported a problem with the case statement allowing logical ranges and I fixed a couple problems there. We've been going back and forth in private about checking for case overlaps, and I'm waiting for his copyright assignment to arrive.

I've submitted a support request to the sourceforge staff that will restructure the CVS directory a bit. All the current source files will go into 'g95', and we'll start populating the 'test' directory with the test cases and scripts, which I've been working on off and on over the weekend.

September 2

I finally noticed that I've been sending the web pages and downloads to the wrong directory for a month now...

August 30

More work on the test suite driver. It's almost done, then I'll tackle the subroutines that drive the individual tests on a single platform, then finish it off with turning the results into webpages.

The -r8 discussion on the mail list has died down a little.

August 28

I've been getting really bad about updating this page. I spent some time over the weekend working on some python subroutines that drive other programs-- this is necessary for what I have in mind for the test suite. The idea is to have a system capable of running the test suite on multiple architectures at the same time, collect and build a series of webpages with the results.

Such a class is useful for other things too, so this isn't just to benefit g95. I've used Don Libes' expect program, but although driving other programs is particularly elegant with expect, trying to do other mundane tasks can be quite awkward in tcl. In the end, I've decided to make some semiawkward python subroutines that can do pretty much the same thing in order to be able to exploit the other areas that python makes easy.

There exist some python libraries that do pretty much the same thing now, but they are more awkward and leak memory like a sieve, and require that you have expect installed...

The main idea here is to make a general script that is able to log into arbitrary sites on the internet as opposed to just the sourceforge compile farm. My day job has the possibility of getting us access to a wide variety of unix boxes, the only barrier being that they are off most of the time. But if people want to donate access to machines as testbeds, that possibility is open.

Katherine had a code she wanted to run through g95, and it failed rather spectacularly, because the author had a lot of LOGICAL(1) declarations, where he assumed that default logical was kind=1. The default for g95 has gone from 1 to 4 and back a time or two already, so we discussed an option to set the default logical kind.

As a warming-up excercise, she has implemented the common -r8 extension which changes untyped reals to kind=8 doubles, and also does some promotion of constants not allowed by the standard, but done by everyone else as a practical matter.

The new option will be -l1, which really sucks from a readability standpoint, but makes sense from a consistency point with -r8 and -i8. This option will be a little different in that it will change the default logical kind to one from four, instead of just replacing untyped logicals with kind=1.

I've printed out Udo's NDA, but haven't had time to go down to a post office to send it to Germany yet.

I ran out of fudge a day or two ago and started in on Toon's chocolates. I've brought my own chocolates to potlucks and parties and have received complements, but these are far better than anything I could make.

August 22

Even though I think Las Vegas is a strange place, I had a good time.

A lot of the same people were there that I met last year. I got to meet Toon finally (he doesn't look anything like his pictures) and Dick Hendrickson as well. Richard Maine was there, and he's always easy to find-- just follow the sound of his laugh.

Toon brought me some Dutch chocolates. When I was in Europe a year or two ago, I didn't blow the remaining money I had when I was leaving, wanting to change it back. What I didn't know was that they only change paper money, not coins, so I had a bunch left over. Toon bought me some chocolates, and I gave him the money. He tells me that the coins are only good until the end of the year, so I got rid of it just in time.

The chocolates are an assortment from the Droste company, established in 1863 in Haarlem. The cover is done in the style of a 19th century lithograph and has scenes from the Droste factory, and even a picture of a barge with the company name on it. I haven't tried it yet, but will get to it as soon as my current supply of fudge has been consumed.

Monday was a pretty typical day for the committee. I sat with the C interoperability subcommittee, which I didn't have a chance to do last year. There were some pretty arcane issues to deal with, but I could understand most of them. I did get one little shock-- the C99 standard, which I would have thought simpler than fortan 2k is actually about ninety pages longer than the fortran 2k standard!

I had lunch with Toon, Craig Dedo and Richard Maine. Richard hadn't heard that modules had been implemented, and I encouraged him to try g95 on his codes.

The closing plenary session on the first day is never that busy because things are still getting started and was finished fairly quickly. After a quick rest, we started the BOF session on g95.

Mark Mitchell from the Codesourcery was present for this meeting. Mark is currently a member of the GCC steering committee and makes his living doing custom mods and support for gcc. The basic reason for the meeting was to see if anyone wanted to fund development for g95. No one jumped forward to commit huge amounts of cash, but then that was sort of expected. The scientific and engineering communities make lousy customers-- in the first place, most people there don't have any money and most that do are incredibly cheap.

People introduced themselves and then we had a question and answer session on g95. I gave a brief update on our progress, mentioned the test suite, which is pretty small by industrial standards and talked about the extensions planned for g95. I mentioned that we're going to support floating-point arithmetic in PARAMETER statements as well as transcendental intrinsics, which are mainly due to Katherine's work.

Van Snyder had an excellent suggestion for using g95 as a front end to produce a data flow model. I don't think I understood everything he meant-- I'll quiz him on it next week. The idea is that someone gives you a couple million lines of fortran and tells you to fix some bug or add a feature. Knowing the data flow would tell you where a variable is set and where it is used in what parts of the program.

If I understood him, g95 can almost do the first part of this now. G95's current output using -v is a listing of the program, broken down into the dozen or so basic operations of fortran, with expressions in Polish notation for ease of printing. Grouping is indicated by indentation, producing a stripped down reproduction of the program.

These print routines are currently inside of '#ifdef G95_DEBUG' declarations. By tweaking the format to make it a little more machine-readable, g95 could be the first stage of a pipeline into a program (I'd go for a python script) that would build up the data flow model. Somethink like my current test suite driver could be used to operate on an entire directory hierarchy of source modules. The answers to tricky questions would become pretty straightforward to figure out.

It gets better. Simply grepping for a particular variable is a bad idea because of storage association and the renaming facility involved with USE. But these dumps have the true names of module variables available, so it can't be fooled there.

Something like ftncheck95 could also be written to parse this output, in a much higher level language than C (again, I'd use python), and check that actual and formal argument agree across implicit interfaces in different source files. So it looks like the print routines will be tweaked in the future and not gotten rid of.

Kurt Hirchert observed that g77 has been a spectacular success. After some reflection on this, I'd go farther-- I think g77 has saved the fortran language from death by disuse. Craig deserves a lot of credit for the work he's put into g77.

After the BOF, we went to dinner at the Swiss Cafe, suggested by Mallory North. There was a lot of good conversion and the beer and food was excellent. I had a delicious salmon fillet and some German chocolate cake for dessert. Toon even picked up the bill-- Thanks Toon!

At dinner Mark Mitchell and I got to talking about test suites, and he offered us one that he/they had developed, which I'm guessing is their entry into the Software Carpentry contest. I still need to follow up on that.

One of the neat things about the people in J3 is that they are really intelligent people who can always find something to laugh at, and they laugh a lot.

On the home front, Paul Thomas sent me a letter the other day suggesting that we write down milestones so that progress (or lack thereof) is discernable. Toon and I thought this was an excellent idea and I've written an outline that I'll post later.

Udo Grabowski sent me a letter the day before I left offering his 100k line weather prediction code on the condition that it would be kept private. I've agreed, and it looks like we'll have public and private test suites. He also suggested looking for enhancements starting with the man pages of existing compilers. In response, my list of enhancements has been greatly increased by items gleaned from the Compaq, SGI and PGF man pages.

I'll try and post this tommorrow-- it's difficult for me to do so now, because Code Red has apparently totally slagged Qwest's DSL network in Phoenix... Which is very odd, since it survived the first onslaught just fine. Perhaps this is a 'solution' gone awry.

August 19

Off to Las Vegas for the J3 meeting, and the BOF. Back Wednesday!

August 18

Applied a patch Tobi sent a couple days that replaces the void pointer in the g95_code structure with a union of pointers.

There was also another patch by Arnaud, that removed a couple of unused function and added another case to the intrinsic_op enum to indicate no intrinsic.

I fixed a bug in the scanner that wasn't freeing the memory allocated to the line buffers. There was more work on the test suite stuff, mostly fixing fortran syntax errors within the test programs themselves.

August 15

Finished debugging the upgrade to modules and checked it in. The globsol suite, which uses modules pretty heavily parses fine. The new code, which is mostly in the top-level loading subroutine, is much more readable than the previous mess, and I've also added some docs on the module format at the top of the file.

August 14

After a couple of emails this morning, (afternoon for Katherine), we realized that GMP is actually doing the (documented) right thing with regard to logical operations, even though it stores integers in a sign-magnitude format. For a logical operation, it treats things as if it were a twos complement number.

There is a paper, 01-292, scheduled for the J3 meeting next week that touches on this issue a bit. It's interesting that the committee included recognition for bases other than two. Did they think that fortran 90/95/0x would be implemented on antique machines? Or were they trying to anticipate some weirdo quantum computing scheme that'll use a non-binary base?

Tobi has embarked on project to find memory leaks. He's already pointed out that the source line buffers are never freed and added a couple of need g95_free_*() calls inside of g95_free_symbol().

The hordes are clamoring for the test suite in CVS...

August 13

Arnaud sent another patch to various things, which Katherine said she was going to apply, leaving parts in module.c for me to take care of.

Katherine and I have discovered twos complement numbers. The first rumbling was a persistant overflow in the 'not' function. Since we're keeping all kinds of digits beyond the machine word, all those leading zeros get turned to ones, and then we end up with an overflow. Although there is a gmp_com() function, it's not clear that this does the right thing with integers.

For example, suppose we have an integer -1, and we reset bit 0. Under the signed-magnitude model, we get 0. Under twos-complement, we get -2. The standard weasels out of this problem by defining two integer models-- one for arithmetic and another for bit manipulation. It looks like what we have to do is convert a GMP signed-magnitude number to a twos complement number in order to do the bit manipulations.

I had a chance to work a little more on debugging the module reading and writing. I've got one bug somewhere that is preventing the compiling of the last hundred files or so out of about 500 in the globsol suite.

August 12

Worked on g95 today and yesterday redoing the top-level loading algorithm. The basic scheme is still the same, but loading is now based on loading those symbols that are requested by the user and then iteratively loading dependent symbols until there are no more dependent symbols left. If this sounds a little obvious, the old code tried to make a single pass throught the module, where the new code scans through the symbol information in order to figure out what is where within the module.

The new code is easier to understand than the old scheme, but it was difficult to write. At one point, I simplified away the symtrees, which meant that two names couldn't point to the same thing, which was bad.

It mostly works now, but it's not ready for checkin, as there are some problems halfway through the globsol suite, which will hopefully not be that difficult to fix.

August 9

I've been forgetting to update the page. I've been working away on the changes on how modules are loaded, but it's been hard to get large blocks of time lately, and this will probably get worse.

August 8

Applied a patch sent by Arnaud a couple days ago.

Katerhine has announced that the intrinsic initialization expressions are about done. We're working on generating correct error message when an intrinsic is rejected for type or kind reasons.

I've started work on the revision of modules to better support the ONLY clause. I also changed the format of the links on the webpage slightly, and added a link to sourceforge's bug tracking system.

August 1

It looks like Katherine has implemented sine, cosine, tangent and arctangent. If I've missed something it's because I've misread the diffs. Way to go K!

I tracked the oof90 bug down yesterday and it turns out the problem has to do with loading modules. A symbol is loaded and then discarded, even though it should not have been. This symbol is part of an interface list, and a couple statements later when a new symbol is allocated, it's allocated smack on the top of the old symbol and ends up taking the place of the original symbol in the interface list. Wow.

It isn't clear to me why that symbol is being freed, since there isn't an ONLY clause in the USE statement. I haven't been agonizing over this particular case, because there is a deeper problem. My original approach with respect to ONLY clauses seems to have been "load what you need".

Paul Brook knocked a neat hole in that last week with his example of a type that contains another. If the first type is loaded via an ONLY, then the second type needs to be loaded as a hidden symbol. This shifted the philosophy to "load everything, then throw out what you don't need". Now it seems we're throwing out too much.

Instead of fixing something that is complicated and broken, I think it's better here to take a step backwards and complicate the original simple scheme, and hope it doesn't end up more complicated than what we have now.

One of my (implicit) original goals was to be able to read straight through a module without skipping around via fseek(). In the case of loading everything, I think we can get away with that. However, given the fact that ONLY can refer to just about anything, it looks like we're going to have to go back to "load what you need" by loading the ONLY symbols on the first pass, then loading the dependent symbols as necessary.

July 30

The current bug in the oof90 library that hops around on the interface lists has something to do with a generic interface loaded incorrectly from a module. The top-level module reading and writing code has gotten to the point where I am looking to make it simpler.

I spent a lot of time over the weekend thinking about how to make g95's handling of floating point variables conform to the various floating point chips. The basic problem is that in precomputing a result, the compiler should come up with the same result as a compiled program would. Originally, I thought we'd use a new rounded floating point type in the latest version of GMP, but it no longer looks like this is necessary.

The current idea is to do calculations with GMP, using about twice the number of significant bits as are needed in the final result. At the end of each calculation, we round the GMP number to the nearest machine number. We can do this because g95 is configured with the radix, digits, minimum and maximum exponents for the target's floating point format. The rounding problem is identical to the problem of printing a correctly rounded floating point number. Typically these schemes require multiple precision arithmetic, which is no big deal because we've already got that.

By rounding at each step, we're simulating the arithmetic on the target. One of the basic principles of modern floating point arithmetic (including the dominant IEEE-754) is that the result of an arithmetic operation is done as if the operation had infinite precision, and was then rounded to the nearest machine number. This implies a couple of good properties that keep calculations stable.

I've gotten and read a couple of papers on the subject, and it isn't trivial.

July 29

Arnaud Desitter sent a patch to change the argument of g95_getmem() to size_t that has been applied.

Steven Bosscher pointed out that the links to the ftp site are bad. Sourceforge is getting rid of the ftp site and trying to convince people to use their own file release mechanism. Unfortunately, their mechanism is intended for releasing major versions of software and is not suitable for snapshots, mainly because it is quite awkward to upload new files. Normally, this wouldn't matter, since I'd just automate it, but it requires interacting with a web page, which is really awkward. So the tarball and executable are now hyperlinks on the webpages, which may confuse some browsers.

July 25

I've started working on the oof90 library. This library has some really heavy object-oriented stuff and there are plenty of problems that look completely unrelated to one another. The first problem has to do with a module procedure that somehow pops up on the interface list of a completely unrelated generic function. I spent about an hour on it and still can't figure out where the problem happens.

July 23

Paul Brook sent a patch that fixed a problem when loading a derived type variable with the USE:ONLY construction. The problem was that the variable was loaded, but the type information wasn't. This prevented accessing any of the members of the structure. I've applied the patch and it even works when the type being loaded contains other derived types.

July 21

Worked on implementing things surrounding the NULL function. It turns out that unlike C, the null pointer has a type. The reason it has a type is so that a specific procedure can be deduced when calling a generic procedure.

This means that my original method of setting a pointer bit in the typespec and setting the basic type to BT_UNKNOWN was not going to work. Instead, I've had to add a new expression type, EXPR_NULL, which represents the null pointer value. Since typespec is a part of the expression node, null pointers can have type. I've updated all the switches on expr_type (I think) and have started on a simplification function that returns the null pointer.

July 19

Applied a patch sent by Arnaud Desitter a couple days ago. The idea of the patch was to bring things to where the -Wstrict-prototypes flag could be added without giving warnings.

I've added support for pointer initializers, but discovered that there isn't a way to express pointer-ness in an expression node. I think this will end up as a bit in the g95_typespec structure.

July 18

Finished the modifications for procedure handling and fixed a few simple bugs found by running portions of the test suite. I then added some code to parse_contained() that marked functions as internal procedures in their internal program unit. The test revealed a problem with some code in globsol. The problem amounts to:

module testmod

contains
subroutine hello
print *, 'Hello'
end subroutine hello

end module testmod

subroutine test
use testmod
print *, 'Hello'

contains
subroutine hello
print *, 'World'
end subroutine hello
end

The problem is that you can't define an internal subroutine named hello because that symbol is already use-associated. The pgf compiler allows this construction, presumably because hello() is never actually called.

July 17

Continuation of yesterday. Something that hasn't ceased to amaze me on this project is how easy some of the 'major changes' have gone. I spent a lot of time thinking about it beforehand, and things went a lot quicker than I thought they would. The individual g95_add_* functions also have more intelligence in them than before. For example, g95_add_function() will add the procedure flavor if it isn't a flavor already. The g95_add_procedure() will add the function attribute if the procedure is a statement function, and so on.

This has made some of these subroutines mutually recursive, but I don't see any way for it to get into an infinite loop. Anyhow, things are almost done and ready for checkin.

July 16

After thinking about it for a day or two, I've started a somewhat fundamental change in how symbol nodes represent the various kinds of procedures. This is in preparation for implementing the resolution rules described in section 14.1.2. If you've ever read this section, then you know how you have to read it a couple times before it starts making sense.

Anyhow, the kind of procedure was formerly stored in the 'flavor' field of a symbol. The idea is to get rid of all of the procedure related flavors except for FL_PROCEDURE. If a symbol is a procedure of some kind, then the proc bitfield will hold the type of the procedure-- internal, statement function, module procedure, intrinsic procedure, external procedure, etc.

The main appeal of storing things this way is that quite frequently the compiler will know that a name is a procedure before it knows what kind of procedure it is. So instead of changing an FL_PROCEDURE to an FL_MODULE_PROC or whatever, we start out with marking a symbol as an FL_PROCEDURE, and set proc to PROC_* whenever the information becomes available. Statement functions are recognized as such when they are first seen at parse time, internal procedures are recognized sometime after the first time they are seen and intrinsic and external procedures are only determined in the resolution phase.

This is something Craig Burley wrote about years ago, when he was describing how a fortran compiler 'discovers' things as goes along, and why it was therefore impossible to build the GBE tree representation on the first pass.

Katherine is still on vacation this week, so I'm doing stuff that we would likely have conflicts on before she gets back.

July 14

Nuno Pinhão sent another email reporting an internal error when modules are being written. I couldn't reproduce the problem and suspect that I made the problem go away by modifying the source file when I was fixing the previous problems. I've asked him to resend the original source file.

Arnaud Desitter sent a patch a couple days ago that I've applied. One of the changes he sent made the g95_free_data() subroutine static, which highlighted the fact that it should have been called when namespace structures were freed. So we ended up plugging a memory leak instead of just semi-cosmetic changes.

Toon Moene announced a G95 Birds-Of-A-Feather meeting at meeting #158 of the J3 committee on the evening of Monday, August 20th in Las Vegas. We're going to discuss current progress, libraries and ideas for funding development of g95. I'm going to try mightily to be there. Thesis stuff is going well, defense date is still on target for August.

July 11

Fixed a bug in the ELSEWHERE statement found by Nuno Pinhão's code. It turned out that changes made to the symbol table weren't being committed. This worked most of time because the most commonly used form of ELSEWHERE doesn't modify the symbol table.

July 10

Nuno Pinhão sent an email detailing a couple problems with the parser. The SAVE statement didn't accept a ::, I didn't allow for optional space between a construct name and the 'forall' and the match subroutine for forall-iterators didn't restore the parse position on a failed match.

July 7

Got a letter from Rob today, he has arrived in Fairbanks. He said that he should be reading email regularly in a week or so.

The test suite had a file that had a couple of binary characters in it. This caused a mysterious error message, so I've changed error_print() so that it prints the binary characters in a printable form.

July 6

A program from the miller suite forced me to realize that a generic name can be the same as a module procedure name. Since these were separate flavors, I've gotten rid of FL_GENERIC and added a generic bit to the symbol_attribute structure. The changes weren't that extensive.

July 4

I made a mistake on June 13 when I applied the VARIABLE attribute to declarations with a dimension attribute. The names can also be procedures or parameters. The application of variable attributes is deferred to the resolution phase.

I started applying my new compilation script to the globsol suite. The version in the tarball is apparently not the same as what is in Rob's suite, so I am covering some old ground. It's evident that our version of globsol was being changed when it was downloaded... Anyway, the version I have locally compiles without any errors.

Fixed a longstanding problem that generated an error message if a variable was not a dummy variable and had the optional attribute or had an intent. The check has to be deferred until the resolution phase because of ENTRY statements.

July 3

Fixed a bug dealing with propagating a type definition from a grandparent namespace. As it was, a contained program unit could use a derived type definition from it's parent namespace, but not the grandparent namespace. Three levels of namespaces occur when a module contains a module procedure, which in turn constains an internal subprogram.

July 2

Arnaud sent another patch that fixed another static function and got rid of my C++ comments.

The test suite went up to 97.3% after yesterdays fixes, which is a new record.

July 1

Started on the miller suite. Fixed a few obvious problems, and then found a few problems with g95. Part of one had to do with quirk of fortran 90/95-- when assigning a derived type value to a parameter, the type is not necessarily defined at that point, and can be defined at a later point in the source. Absent a definition, the derived type of a containing program unit can define the type. This means that the typecheck has to be put off until the resolution phase.

June 30

Added Arnaud Desitter's patch to add the 'const char' attribute in places where it can do some good.

I've finished a script that will scan a directory structure, figure out what files produce what modules and run test compiles in an order that prevent uncreated modules and generates the correct -I options for each file. This will help find those files that have the real problems as opposed to those files that fail because another file failed to produce a module

June 28

Arnaud Desitter sent a patch that made a couple of functions static that should have already been static along with a couple of other things.

Laurent Klinger sent me an updated version of Byran Carpenter's test program. I've used this to fix a couple of minor problems, including things like use statements with an empty only list and allowing module procedure statement in non-module program units. The only two errors remaining at this point are empty interface blocks (which I thought were illegal, so I'll just get rid of the check) and pointer initializations via =>NULL().

From looking at the test suite, the vast number of remaining errors are due to code that is just plain illegal, that some compiler out there accepted. Until we check the test suite source into CVS, there isn't a lot that I can do about these problems. This will also mean the current repository will have to be destroyed, as CVS isn't very good at moving sources around and still retaining the revision history. On the other hand, we're mostly using CVS to maintain a coherent current version as opposed to worry about branches.

June 24

Katherine has started work on expanding the check functions to give a reason while they fail. This is a little tricky, because sometimes the message has to be displayed and sometimes quietly returning failure.

Tobi tried compiling g95 with GCC 3.0 and optimization flags. The optimization pass found a couple problems in the simplification functions and the array spec code that I wrote yesterday.

I did a little work on trying Bryan Carpenter's f90 test. I've added operator specifications in a USE statement, and got rid of a problem freeing a block of memory twice in an empty SELECT statement.

I've also been considering changes to the test suite, mainly just putting the test programs under CVS so that we can easily insert new test cases. The other issue has to do with fixing syntax errors in some of the test sources-- we're down to the point where there are a lot of real syntax errors.

June 22

Split some reference to a g95_array_spec to the new g95_array_shape structure. The patch was spread over nearly a dozen files, and went pretty smoothly. It'll be interesting to see how the test suite fares...

June 21

No code today, but some needed thought. I realized a couple days ago that putting an array specification structure off of the expression nodes was a mistake. The reasons for slow deliberation was recalling a month or two ago when it used to be an array reference type, and then changing it to an array spec.

After some reflection, the array spec would be sufficient, but is overkill. The idea here is to distinguish expression nodes that have array type from nodes that are scalar as well as conveying needed shape information. The only specification that would be used would be AS_EXPLICIT, since assumed shape, deferred, assumed size and unknown don't apply. The information that really needs to be stored here is the rank and the shape, ie the number of elements in each dimension, but not the bounds, which the array specification stores.

By contrast, the array reference structure specifies an element, section or the full array. In general, this means that start, end and stride have to be stored for each dimension which is more overkill than the array specification.

So in order to store what needs to be stored, another type needs to be created that stores the specific info, rather than trying to use an structure that is much more general than is needed and is just downright confusing. I know it confused me.

June 20

Lots happened today, not much of which was my doing.

Katherine fixed a problem with MAX(1.0,2.0) returning 1.0 instead of 2.0. :)

Tobi found a problem with the USE statement. The standard has a constraint that require variables that are named in a USE statement to actually be loaded, and g95 wasn't making sure that this happened. He's checked in the fix.

Yesterday, Laurent Klinger mailed me a link that pointed to a very interesting paper written by Bryan Carpenter on a program that has an example of every syntax rule in fortran 90. Basically, the idea is to treat the BNF syntax as a tree and traverse this tree. The result of this are a couple of programs that provide coverage of every rule in the book. The last example even includes Kate Hedstrom's infamous null program program.

After much poking around on webpages, I mailed Bryan this morning and he mailed me all his source this afternoon. I've forwarded it to Laurent, who said he'd try to upgrade the suite to fortran 95. I tried the main test program and it coredumped g95. This is pretty significant when you consider that none of the 6500 programs in the current test suite dump core...

The source will show up in the test suite sometime soon. I'd like to thank Bryan for his kind gift.

June 17

Up to 96.6%. Added a patch to avoid adding the variable attribute in decl.c if the name is known to be a function.

June 16

Added check functions for ANY, ALL, ALLOCATED, ASSOCIATED, COUNT, CSHIFT, DOT_PRODUCT, LBOUND, MATMUL, MAXLOC, MAXVAL, MERGE, MINLOC, MINVAL, NULL, PRODUCT, SHAPE, SIZE, TRANSFER, TRANSPOSE, UBOUND, DATE_AND_TIME, MVBITS, RANDOM_NUMBER and RANDOM_SEED. This lets us remove the not_ready() check function forever. This was about a couple hundred lines of trivial subroutines. It's clear to me that check functions have some more evolution in store for them.

June 15

Ran through some accumulated emails from Michael Richmond, Mohammed Dakna, Pawel Salek on various crashes. Everything they've reported has fixed at some point between then and now. Fixed a problem reported by Martin Kleinschmidt (though others have reported it) concerning the terminating statement of do-loop, which is not allowed to be a GOTO statement. The problem was a program like

     do 10, i=1, 10
...
10 if (i.eq.5) goto 20

where the last statement on the loop is technically not a 'goto' statement. I introduced a new statement type, ST_SIMPLE_IF and modified g95_match_if() to return it instead of the statement type behind the 'if'.

Tobi sent a patch that added a check function for the EPSILON intrinsic.

Katherine and I have added a patch that issues a warning on -pedantic if g95 simplifies an expression that it doesn't have to.

I've fixed a core dump in simplify_sqrt().

June 13

Last night was up 0.2%, not too much but inching towards 100.0%. The current problem has to do with what the compiler knows and when it knows it. For example, the declaration "INTEGER A" doesn't say what A is outside of being an integer. On the other hand "INTEGER A(20)" and "INTEGER :: A=20" both imply that A is a variable, as opposed to possibly being a function.

g95 prematurely declared things as variables when writing modules. It currently doesn't write names that are 'unknown', but it looks like we might have to.

Guillermo Valor sent in a report of g95 on the Itanium-- haven't had a chance to take a look at it yet in detail, but it looks like the gcc there is pickier than the one I use.

Michael Richmond sent in a couple bugs which I forwarded to Katherine.

I will probably not have time for g95 tommorrow, since it will be a work for money day.

The other good news is that I resolved my grid troubles. Instead of fixing geompack or inventing a new generator, now I just perturb the points and let geompack give it a try. If it doesn't work, I re-perturb and try again. This puts me on track for August, when everyone on my committee will be in town at the same time. I am perhaps foolishly going to spend a week adding one more modification that looks like it may save a month in compute time... which at this point I'm gonna need.

June 12

The improvement was 0.6%, or about 40 files. Part of the problem was not expanding constructors within arrays that are supposed to be initialization expressions. It was easy to fix and it should add another 30-40 files to the success column, mostly from a single module that other files depend upon.

Tobi sent Rob a note about another easy thing to fix in the test suite-- an include option that will allow g95 to find the right modules.

June 11

Finished and debugged the RESHAPE simplification function. It appears to work fine in all of it's different forms. The test suite ran last night and yesterday's fix brought things back up to the 95.0% level, which is where it has been for a long time. It will be interesting to see where it is tommorrow morning.

June 10

Finished the merge I started last night-- Katherine has written a bunch of code dealing with flagging our intrinsic extensions in -pedantic mode, and finally got things checked in.

Rob sent a note to the list saying that he's gotten the test suite going at his new job in Alaska. The new address is http://geist.ims.uaf.edu/~cermak/g95/summary.html. The test machine is an 866Mhz P3 and chews through the whole suite like a buzzsaw in about 12 minutes compared with the old Sun we were using which took a couple hours.

I posted a wish list for the test suite. Features included a counter on failed compiles so that we can tell how long something has been failing and using Sourceforge's compile farm to run the tests on a variety of different machines.

Most of today's work was on the RESHAPE function. It ended up being about 200 lines long, which is pretty long compared with most of the other simplification functions. I haven't been able to test it yet, because there are some issues about with figuring out what type a constructor is. I'm proceeding slowly here because this has been a problem area in the past.

I also fixed a minor problem with core dumps in selected_real_kind().

June 9

Katherine pointed to a short article in Linux weekly news about g95. It's located at http://www.lwn.net/2001/0607/devel.php3.

I finished removing the 'child' member from g95_constructor. The changes went easier than I thought they would, which is a good sign that this was the right thing to do. Simplified some things too. The way it works now, a constructor is a singly linked list of expression nodes with an possible iterator at each node. The sub-expression can be an array constructor itself.

I've also debugged the code that provide random access to array elements. This is needed by RESHAPE in order to unpack the contents of the new shape and it's other arrays.

June 6

I started debugging the code for random access to array elements, but ran into what looked like a problem in the matcher that lost elements. The problem turned out to be the fact that the constructor structure has two links for child structures-- 'child' and 'expr'. This is going to require a rework to get rid of one them.

Katherine is still working on intrinsics and is starting to think about handling elemental references.

May 28

Katherine Holcomb fixed a bug reported by Michael Richmond having to do with the min/max intrinsic. Michael also reported that the current tarball is not compilable in it's present state. I haven't heard if she's checked the changes in or not, given Sourceforge's recent troubles. Apparently, the root password was stolen by a trojaned version of ssh. I haven't seen any differences between the source in CVS and the source I have locally, so g95 hasn't had some virus inserted into it.

May 26

Worked a bit on the reshape function. In it's simplest form, this function amounts to relabeling the array indexes. In it's more complicated form, there is padding and permutations that have to be addressed. This requires a function to extract the nth element of an array expression given a constructor that is potentially a tree instead of a linear list. No checkin today.

Sourceforge's ssh appears to still be hosed...

May 23

Michael Richmond found a core dump due to SNGL and FLOAT not being given an optional kind parameter. After looking into this, it seems to me that these kind parameters are not allowed for SNGL and FLOAT, even though they are specific versions of REAL, which does. None of the other compilers accept kind parameters, so in order to make g95 conform to this, separate simplification functions are needed.

My grid woes have continued. Yet another promising scheme failed to work today even though it is debugged. I've come to the conclusion that even though my point set is "well-spaced", it is still impossible to triangulate without producing badly shaped tetrahedrons. This means that I am going to be forced to implement the version of advancing front triangulation where points are selected based on where the front is. Of course, the papers on how to do this are either unreadable or leave out the exact details of point location.

Of course, this is so they can sell their grid generators. While I don't have a problem with this, I do have a problem with the referees who allow incomplete papers to be published.

I'm going to resume regular work on g95 at the expense of my thesis, because at least with g95 I have a sense of things moving forward. In the last two months I've written, debugged and thrown away probably 10k lines of code because the underlying algorithm just didn't do what I needed it to do and it is starting to get to me.

May 7

I've changed common_logarithm and natural_logarithm to pass pointers instead of structures. It may have been passing pointers as it was, but it's hard to tell what mpf_t really is. Anyhow, this makes an issue Katherine was having trouble with more clear.

Michael Richmond reported a successful compile of g95 with the Cygwin tools, and reports success, which in this case are core dumps in the same places....:)

In other news, I've given up on geompack, at least for the time being. After three days debugging obscure problems, I noticed that the test cases in the papers describing geompack used sets containing hundreds to thousands of points. Of course, since I am using tens of thousands to hundreds of thousands of points, there is more opportunity for subtle problems to arise. It was back to the drawing board today, re-implementing another method I think I gave up too quickly on a couple weeks ago. I'm beginning to understand why commerical grid generators start at $10K and then get expensive from there...

The automatic test suite seems to be inactive, I think Rob is in the middle of moving to Alaska...

May 3

I've pretty much given up on graduating this semester and different people on my committee are gone at various times during the summer, so it looks like end of summer is the next possible graduation time.

I've been doing a lot of development work in fortran 77 the last couple weeks and this has strengthened my conviction that a free fortran 95 compiler is needed. A couple of coincidences have happened that will go towards shaping g95's development.

Although geompack appears to work most of the time, it still has problems with the set of points that I give it. I've traced the problem to fixed-precision arithemetic, which is a problem endemic to computational geometry. For example, one of the things that geompack requires is a test to see if a point in three space is contained within a sphere defined by four other points. All of the tests can be written as a three or four dimensional determinant, which itself is a fairly small and uncomplicated function of the coordinates of the points.

For the sphere test, the determinant is positive if on the outside, negative on the inside and zero if exactly on the surface of the sphere. For most cases this works fine, but there are arrangements of points where the formula gives the wrong answer when evaluated with fixed-precision arithmetic.

After investigating a couple of alternatives, I settled for a technique that involves calculating the original quantity with the usual double precision floats, but propagating uncertainties through the calculation. If the magnitude of the result is greater than the uncertaininy, then I use the result. Otherwise, the calculation has to be repeated with a more elaborate one that doesn't do any rounding.

One of the papers I read reported glowing success from writing a simple expression parser that translated assignment statements to generate subroutine calls to the multiple precision subroutines. It occurred to me that I could also use this to generate code to propagate the uncertainies correctly. So at 12:30am, I found myself reading the fortran standard and looking at g95's expression parser to remind myself how to write a simple parser. 200 lines of python later, I have a mini-compiler of sorts.

I'm using a multiple precision technique due to Shewchuk, who improved on some work done by Priest years ago. These were some pretty hard core papers on floating point arithmetic and I think they're going to influence how g95 handles things. It turns out that Priest and Shewchuk's algorithm won't work on an 80x87 that is using the usual intermediate 80-bit reals-- double rounding causes some of their theorems to be violated.

While I think it is important that a compiler should try to do the right thing by default, I also think it's important to give the user the ability to "use the hardware that they've bought" to borrow words from Bill Kahan. Some things I'd like to see someday include a REAL*10 for the x87 family and the option of spilling either 80 or 64 bit doubles to memory when required. Craig Burley was really buffeted back and forth by that one when he was writing g77, with very lucid and reasoned arguments on both sides-- this is of course a sign that sometimes it's better one way and sometimes it's better the other.

I've also fixed a pair of bugs reported by Michael Richmond some time back.

April 23

Michael Richmond has successfully compiled g95 under DJGPP. This is good news.

My thesis difficulties are being resolved and hopefully I will have more time for g95 in the near future.

April 16

Rob Cermak has gotten access to half of the sourceforge compile farm, so we should see the test suite expanding to other platforms.

As for me, I am ill with my semiannual cold.

April 9

No g95 news, but the news is good-- I've settled on another mesh generator-- Barry Joe's GEOMPACK library. It does eveything I need it to do an produces much better grids than my hacked-up method was. It needs a bit of tweaking, but the end is in sight.

April 5

Pawel Salek sent a patch that adds includes of string.h in several appropriate places. The version of gcc that I am using, 2.91, is apparently very forgiving of just using string functions without prototypes. He also patched a place where va_arg() was incorrectly using a character argument.

Katherine Holcomb has continued working on intrinsics. We've been discussing error messages associated with intrinsics on the side, and I added a flag to the function that checks to see if a function reference looks like a call to intrinsics that can be used to generate an error message if the use is incorrect for some reason.

For names not specific or generic, the last resort is to treat the function as an external function, which is why we can't always generate an error.

March 31

Katherine Holcomb has been plugging away on the intrinsics and is currently working on the min/max family.

As for me, the shit has hit the fan regarding my thesis. Turns out the grid generator just isn't good enough. My advisor says I need something quick, and I completely agree, but the current implementation was hacks on hacks. So I've spent the last couple days working on little else. Most of the literature is crap-- they're either unreadable or they leave out critical details. Anyhow, I think I have something that might be workable.

March 26

Jonathon Dursi sent in a patch that made determining the source form of a file from it's extension much easier. The new function takes a filename and returns the right FORM enum. I've also updated the contribution page with another small but spread out project.

March 25

Fixed a couple of problems introduced with simplifying constructors. The pass rate is a new high, 95.2%. It looks like the majority of the remaining problems have to do with reducing that pesky RESHAPE intrinsic. I've got some machinery in place to keep track of array specification within expressions, and implementing the actual intrinsic itself doesn't look too bad, but we'll see.

I started to remove the implementation of log10, thinking I could get away with a simpler version of log10 that returned the integer of the base-10 logarithm, but it turns out that the PRECISION intrinsic requires the base 10 logarithm of the radix multiplied by the number of digits minus one, before the integer part is extracted.

Katherine Holcomb has checked in an implementation of the IBITS subroutine.

March 21

The rewrite of how g95 describes kind types is done. For integers, the input is the kind number, radix, digits and bit_size. From this g95 calculates the value of huge() and range(). For real numbers, the input is kind number, radix, digits, minimum and maximum exponents. From this huge, range, precision and tiny are all calculated.

I added the necessary functions to simplify.c and found that Katherine has checked in stuff since I started on this modification. So I got to do my first merge. I used tkdiff, which made things go pretty smoothly. I don't think anything went wrong.

I talked to Toon Moene earlier tonight, since talking to him doesn't amount to a transatlantic telephone call at the moment. Toon reported our status to the J3 committee meeting in Las Vegas. He says that they are working on about twenty interpretations against fortran 95 (which is a lot) and his subcommittee, the C interoperability committee, is about to resolve the last of it's unresolved issues.

Having been to one so far, these are really working vacations, with the days spent going through many different papers and the nights spent retyping the papers. (Thought it's pretty slack if you're just observing).

Michael Richmond got a surprise this morning when he downloaded and compiled last night's tarball instead of downloading from CVS. The tarball is a copy of whatever was on my hard drive when I update the web page, checked in or not. In this case, he ran g95 and got the following output no matter what:

0.2718281828459045235e1  

Mathematicians will recognize this as 'e', the base of the natural logarithms. The output was debug output to make sure that it was being calculated correctly. Why, you ask, would a fortran compiler calculate e? The reason is because the HUGE, TINY and PRECISION intrinsics require that a base-10 logarithm be evaluated. The common logarithms are usually evaluated in terms of natural logarithms, and I needed 'e' in order to scale the argument such that the series I picked would converge.

Michael also pointed out a bug dealing with the return types and kinds of function calls that cannot be simplified and must be evaluated at runtime.

March 20

Made several small fixes in the code that allow procedures to be actual arguments. Hopefully this should bring us back to 95+%. I also added the bit_size() intrinsic to the list of those intrinsics that don't need to actually evaluate their arguments before returning a result.

The other item for today was starting a rework of how g95 describes the kinds of integers. After staring at the standard for a while, it finally hit me how J3 really set things up. For integers, the critical elements are radix, digits and bit_size. Given these, the values of huge and range can be calculated. For real numbers, the critical elements are radix, digits, minimum exponent and maximum exponent. From these, huge, tiny, epsilon, range and precision can be calculated.

Given our use of the GNU MP libraries, it is fairly easy for us to calculate the derived quantites at run-time, and I have this about halfway done. The current difficulty is calculating the base 10 logarithm of some argument.

A small consequence of the standard's arithmetic model is that the range of numbers is symmetric. This isn't the case for twos-complement arithmetic, which has one more negative number than positive numbers. We might have to support this extra number as an extension.

March 19

Fixed setting a character kind in fortran 95. Consider the bit of code:

integer, parameter :: i__ = 1
character*60 :: a = i___'hi there'

The original code called g95_match_name() to read the 'i__', but the problem is that it gobbles the next underscore. Now there is a custom version of g95_match_name() that does peeking at the right times.

I think I am going to tackle the rest of the numeric inquiry functions tommorrow. I've been working on them piecemeal and we may as well get them over with.

I spent the day periodically watching my thesis code do a binding curve for a periodic solid. About middle afternoon, it didn't look like it was leveling out, meaning no binding, effectively trashing an unwritten paper. But just a couple of hours ago, there was this ever-so-gentle upturn, so it looks like the universe holds together after all...

March 18

More fixes, particularly in the area of constructors. It turned out that the basic arithmetic subroutines weren't setting the right type, which is now fixed. There also had to be some more code added for checking if an expression involves non-iteration variables. The code in array.c has been rearranged to put related functions together, which has been needed for a long time.

An important non-g95 milestone was reached today-- my thesis code now appears to be complete. The last thing was periodic boundary conditions, which I have been hard at work on for the last couple of weeks. Now I just have to turn this crank I've created.

March 17

Several small bugfixes-- array references in equivalence statements now are required to be references to single elements and the indexes must be initialization expressions.

I've also added support for the DIGITS intrinsic. With all of these numeric intrinsic functions, I think we're going to need something like the paranoia program that can (portably) probe a machine's floating point characteristics. The results of this will have to be stored in some sort of configuration script, but we'll have to keep the program around for new architectures.

March 16

The test suite has been down the last couple of days due to an upgrade. It seems to be back now, missing a few packages. There were a smattering of core files due to an uninitialized pointer which has been fixed.

Katherine Holcomb has checked in some stuff, not sure what it is yet.

Toon Moene is getting ready for some major jetlag, heading to meeting #156 of the J3 committee in Las Vegas.

March 11

Worked on attaching array specifications to expressions so that RESHAPE will be able to do something useful. Wrote some new code but it is all dead at the moment. The test suite didn't fire off last night-- Rob says it will work this coming morning.

March 10

Long time since the last update. I've added support for evaluating iterators in array constructors. This has to be done at compile-time in order to evaluate initialization expressions. Katherine Holcomb has been quietly working on run-time intrinsics.

March 1

There was a note on the J3 mailing list about the f95 standard being available from ANSI for $18, instead of the usual $195. If this isn't an error, this will be very good.

I moved a test that had required an assumed-size array specification to also be a dummy variable to the resolution phase. Because of ENTRY statements, you have to wait until the end of the program unit before checking.

February 28

Pleasant surprise this morning at the few bugs that last night's fairly fundamental change flushed out. The only thing required was to add code to allow an implicit type assignment to be explicitly affirmed later.

Added a checking for specification expressions. This has to happen during resolution, since we have to know all about types and attributes before this happens.

February 27

The test suite is back up to 95% passing, and I fixed a little problem associated with giving variables their implicit types-- if the type is a derived type, then this can't be put off until the resolution phase-- the type has to be decided because members have to be parsed. I didn't do too much else, because I want to see how this propagates through the test suite.

Soon the -r option will be removed and the type resolution phase will be done if the first pass succeeds.

Paul Brooks has filed a g95 copyright assignments with the FSF, so he's legal, but I haven't gotten an email from him yet...

February 26

Last two days I was trying to get the rules for forward declarations of types to work. I think I have those finally licked. The globsol library now compiles all except for one file, that also gives Compaq, SGI and IBM compilers problems. PGF compiles it and I'm not sure if the problem is PGF being too loose or that it finds something that everyone else does not.

I've added support for a 'q' in exponents. The default kind for 1.0q0 is double, but it will be trivial to make it quad precision if and when.

The two main remaining problems in the test suite are fully evaluating array constructors, ie expanding them in an initialization statement and the related RESHAPE intrinsic.

February 23

Found the core dump in the case statement that was happening on Solaris. The problem was using uninitialized memory.

Michael Richmond sent in a bug that dumped core when using the FLOAT intrinsic. The problem was that FLOAT wasn't quite being treated a generic of REAL to the extent that the optional KIND= parameter wasn't expected. Since none was there, some random memory was looked at.

February 22

Thesis stuff has been growing steadily more important and this is at the expense of g95. This is likely to be the case for the next month or two.

I found a bug that I've been hunting sporadically for the last couple days-- sometimes a symbol that was loaded as a hidden symbol was deleted as unused when in fact it was. I've also beefed up the error reporting for modules-- the old code in bad_module() complained about an error during reading, even if writing was taking place, which threw me for a loop at one point.

Fixed a problem associated with saving derived types as hidden symbols when necessary. The last fix in this area was only partially right. Now, visible symbols are checked to see if they are entities like variables or parameters that might have a derived type associated with them.

Added some debugging code to find a problem created a couple days ago when fixing the CASE statement. The x86 linux version works fine, but the test suite on Sparc/Solaris dumps core due to a pointer being equal to one. Not sure how this gets there at all.

February 17

Fixed a couple of widely separated problems. The first was a problem associated with saving the information associated with derived types, and this led to fixing problems with modules in general. Fixed parsing of the CASE statement-- the block name is allowed to end the line.

Started on better support for arrays. The current biggest problem in the test suite is the lack of support for the RESHAPE intrinsic, but there is a bunch of stuff that has to happen before we can implement this.

February 16

Finished removing the length restriction on numeric constants. On real constants, the code to do this was practically already there and filling in a statically sized buffer was just silly.

While debugging, I found that using hexadecimal constant z'abc' created a 'z' symbol by mistake, in two places. The original code call g95_get_symbol() which creates the symbol if not found, which was a mistake. The new code matches a name, then looks for the name in the symbol tables.

February 15

I misapplied the boundary condition to my thesis code when it was originally written, and I've been fixing it the last couple of days. At this point, I would have left the hack I had in place, but the math for the correct boundary condition was more elegant and it reduced the memory footprint by about a factor of three. And when your code eats 250M on a large run, ways of reducing the size are always welcome.

I've made some small fixes to g95, with the emphasis on "small". I've also started changing the constant-matching code so that arbitrarily long digit strings are accepted. One of the test suites has a module that has a too-large constant in it, and everything else in the suite uses that module.

February 10

Jean-Philippe Perois reported an almost-successful compile of g95 under VC++. The problem had to do with VC++ treating enum bitfields as signed integers. When the sign was extended the internal codes were changed to different numbers and an internal error quickly resulted. He says that VC++ also doesn't actually pack bitfields into bitfields (it doesn't have to). I can see how this would make for some serious bloat.

I think we can fix this problem by prototyping subroutines like g95_code2string with an "unsigned" value instead of "int", so that the sign-extension doesn't happen. He also sent a program which found a core dump, which have become increasingly rare.

Rob Cermak has added a bunch of new programs to the test suite. Most of these new codes compile just fine, and we are at nearly 95% success rate on parsing.

I did an overhaul of intrinsic type conversions. Instead of listing each conversion function, there is now a master conversion function for constants. The do_simplify() subroutine treats it in a special way compared to other subroutines by supplying the destination type and kind. The construction of intrinsic_sym nodes for each possible conversion is now automated as well. Instead of listing each possible type conversion, we now loop over the kind tables, enumerating each possible conversion.

The other major change is in the check functions for intrinsic functions. These are functions that look at the type and kinds of a function call and decides if the reference is legal for a particular intrinsic symbol. The new convention is just like the simplification functions now. Instead of passing each check function an actual argument list, the arguments themselves are passed. This makes things much easier conceptually.

I got rid of a couple of functions like HUGE and RANGE which had been made into fake generic symbols-- they now rely on their own check functions.

February 8

Rob Cermak added the fortran version of LAPACK to the suite. All of the files compiled without a problem except for three, which had a problem converting a double complex constant to a double constant. This was a one-character fix.

I incorrectly attributed the pointer to the NIST suite to Ben Turner-- It was actually Arnaud Desitter that mailed Rob. We did have a chance to look at the suite and the only problems we could find were lots of H descriptors that g95 does not accept. Charles Russell gave us a pointer to a program that will fix this problems semiautomatically.

Laurent Klinger pointed out a glaring hole in g95's intrinsic type conversions-- only one of the four integer kinds is actually recognized by the conversion routines. This points out the need for a way to add intrinsic conversions by a combination of enumeration and looping over the kind tables.

February 7

Rob Cermak must have applied some of his perl magic to automatically patch g95 so that it turns on standard I/O buffering when reading a module. The test suite now runs in about 8500 seconds as opposed to 17000. We've speculated on if this is the real reason Solaris is sometimes known as "Slowlaris".

Katherine Holcomb checked in some of her code today, mainly dealing with the ACHAR, AJUSTL and AJUSTR intrinsics. She wants to get into doing CMPLX, which is real bear.

I've added couple of fixes which should allow compilation of the last major module in the globsol suite, the failure of which takes a couple dozen files with it into failure. The gist of the changes is that a procedure compiled in a module's CONTAINS statement is now marked (and exported) as a module procedure, instead of just a procedure. The distinction is that these procedures can be listed in, you guessed it, a MODULE PROCEDURE statement.

The other changes involved fixing the parsing of the CALL statement so that it does not examine parent namespaces for the target of the call-- figuring out which procedure is called is for the resolution phase. The other change involved an overhaul of the SUBROUTINE statement parser-- this was written long ago and it was possible for the parse pointer not to be advanced to the next statement. This of course generated an infinite series of errors.

February 6

Ben Turner sent a note yesterday offering to scour the net for more test suites and noted a strong free-form bias in the current suite. He also sent link to a NIST fortran conformance suite that Rob Cermak and I have taken a look at. Rob says we have plenty of disk and CPU available on the test machine, so we're going to start adding legacy codes to the suite.

I haven't had any time for g95, but work has continued...

February 4

Fixed miscellaneous bugs yesterday and did a minor rework of how expressions are handled. The first is that the functions that convert one constant type are a little more generic. For example, a single function converts reals to integers, with a destination kind argument. The other difference is that a NULL pointer is returned if something goes wrong-- overflows. This made the addition of functions that convert to and from double complex easy to add.

The other difference is that eval_intrinsic() now returns a NULL pointer if something goes wrong when it collapses constants. This also meant changes in matchexp.c to watch for these NULL pointers, but overflows are now properly handled instead of an internal error complaining that an initialization expression didn't reduce.

February 2

Lots is happening.

Rob says that g95 fails for every program in Walt's test suite-- long term this is a good thing. Rob and I have also been spending time fixing real errors with programs in the test suite as opposed to bugs in g95. The pass rate is up to 89%, and it should be going higher with all the pruning we've been doing.

Still no idea on why Solaris turns off buffering. I browsed a Solaris manual in a bookstore last night in between searching for Sowell's Basic Economics and Harrison's Bill the Galactic Hero-- no joy.

Walt has also sent in a document that describes the changes to the parser required for parsing F programs. I'll add this to the projects page soon.

Niels Jensen sent a patch that gets rid of some compiler warnings about unused static subroutines in module.c.

Katherine Holcomb has let me know that she is going to work on the simplification functions this weekend. We've been talking a little about how these work and how it wouldn't be that hard to allow advanced intrinsic funcions like sine, logarithm, etc, to appear in initialization expressions as a g95 extension. Lots of compilers allow ABS() for noninteger types, but given our approach to arithmetic, we're in a position to go far beyond the norm. I've fixed a bug in the initialization expression verification subroutine. The same subroutine deals with both structure and array constructors (since they are stored the same way), but with a flag to deal with the slight differences. The problem was that this subroutine is recursive and the flag wasn't being saved.

January 31

Micheal Richmond sent in a problem having to do with an intrinsic function that incorrectly required a check function that hadn't been written yet. I went through the whole list and unmarked any functions I found that didn't need one. It looks like there aren't that many check functions to write, and several can be boiled down to 'is the argument a numeric type'? or 'is the argument an array'?.

Walt Brainerd mailed us a test-suite that he uses for the F compiler. This'll add more tests that we can use to test g95. Thanks Walt!

Niels Jensen reported that simplify.c and simplify.h weren't getting included in the tarball. I've added them to the MANIFEST file which controls what is packed into the tarball.

The percentage pass rate in the test suite jumped to 83% from 73% for the parse phase. As expected, lots of improvement was in the globsol package. The thing that makes debugging some of these libraries difficult is the interwoven sequence of modules that some library authors have written. Usually you can find a 'key log' of sorts that makes everything else work.

A few miscellaneous bug fixes include allowing the 'function' and 'subroutine' attribute bits to be updated. As far as fortran is concerned, these aren't really attributes. They are really just conveniences that prevent us from CALLing functions or putting subroutines in a procedure call.

In any case, sometimes a module declares a name as EXTERNAL, which doesn't really say whether the procedure is a function or subroutine. Therefore we have to be able to update these bits in a program unit which includes that module.

I also fixed a problem with assigning structure constructors a bogus type left over from a previous constructor. The flib.f90 file in the flib library now compiles and this will hopefully lead to more successful parses in the test suite tonight.

January 30

Fixed a bug that prevented initialization expression with unary minuses from being reduced. Also added type checking of array and structure constructors in initialization expressions that allows them to have an overall type. This is a very common problem in the test suite.

January 29

Michael Richmond and Jos Bergervoet sent in several bug reports (a while back) which turned out to have easy fixes.

I've added the HUGE and EPSILON intrinsics-- the code was there, but I commented it out mechanically during changing the calling conventions. When doing something big like this, it rarely pays to try and be smart and let yourself get distracted by details.

I have high hopes for compiling the globsol package tommorrow-- the current failure was g95's not being able to reduce a structure constructor inside an initialization expression in a module that everything else uses. This is the only package left with lots of failures. After that, mop-up on what is left and then onto the fertile fields provided by the -r option...

January 28

Finished changing the intrinsic conversion functions in intrinsic.c to the new conventions for intrinsic function simplification. The rewrite seems to have survived the regression tests...

January 27

Massive reorganization today. I ripped about half the code out of intrinsic.c and put it in a new file, simplify.c. This file does the arithmetic necessary to evaluate intrinsic functions at compile time. We also have a new header file, simplify.h, that contains the prototypes in common between the simplify.c and what is left in intrinsic.c. The calling conventions to the simplification functions has also been changed.

I did the functions from 'a' to 'c' as well as a couple of the more important functions needed for initialization expressions. The rest are commented out for Katherine to have a look at later. Not ready for checkin yet.

January 25

John Lindsay has offered to help with an OS/2 port of g95. The biggest portability problem will probably be the runtime library, but I suggested he start compiling g95 as it exists now to find where the pitfalls are while they still are relatively shallow.

Finished adding basic functionality to check if an expression is an initialization expression or not. The array constructor is untested because it is getting late, but the rest looks like it works. I've also just realized that the agonizing over the legality of

parameter (i=huge(a))  

for undeclared A was silly. The answer is simple-- this isn't legal, because the arguments to a function in an initialization expression have to themselves be initialization expressions. If A isn't a constant, it isn't an initialization expression, making the whole expression not an initialization expression.

I've updated the contributions page with a couple of mini-projects that have come up recently, yet shouldn't be too hard.

January 23

Tobi Schlüter sent a patch that recognizes the '.for' extension.

Rob Cermak and I traded several emails through the day. The problem we were having was some very poor performance on the LAPACK test suite. We guessed that it had something to do with the large modules that it has, but we're still not sure what the problem is.

Profiling a sample file showed that the program was indeed spending about 75% of it's time reading from the module. The mystery deeped when we realized that the total time (including profiling overhead) was about five seconds. The problem was that the wall-clock time was about 22 seconds to compile this file. The shell's built-in 'time' command revealed that 17 seconds were given to "system" time.

During module reading g95 is mostly calling the fgetc() and fsetpos() library functions. The C library should be fully buffered, and we have no idea why things should be taking so long. This on Solaris (which of course is sometimes referred to as 'Slowlaris'...)

January 20

I found what I was looking for in the standard-- variables and such that are the argument of KIND() or other intrinsic functions have to be declared before the inquiry function. This means that the SGI compiler has the correct behaviour. For g95, this means that functions have to be written that check to see if an expression is in fact an initializtion expression. I am going to tackle specification expressions and restricted expressions at the same time because they are similar.

January 19

I'm currently trying to sort out how/when to evaluate initialization expressions. Michael Richmond sent a bug report earlier today that inspired a devious program:

real (kind=kind(A)) :: A
real (kind=2*kind(B)) :: B

The second line is asking for trouble by exploiting the fact that most compilers (all the ones here) have kind=4 for default real and kind=8 for double precision. So how do existing compilers handle this?

IBM XLF90 and Compaq Digital Fortran allow A, making it a default real and give an error on B.

SGI complains on both lines that the entity has to have a type before you can use it in a kind() intrinsic. If you try to call it's bluff by adding IMPLICIT REAL (A,B), you get the same message.

PGF90 allows both lines, effectively re-kinding B, which evidently starts out as default real but ends up being changed to double precision.

January 17

Added a call to g95_set_default_type() in a strategic place where an rvalue is being matched. This corrects the problem mentioned last night. Hopefully this will improve things in the test suite.

January 16

Tobi Schlüter sent a patch that corrects the arithmetic during a complex conjugate operation.

I was expecting a lot more improvement in the test suite by implementing the numeric inquiry intrinsics. The reason this didn't happen was twofold. First, the simplification function wasn't aggressive enough-- if the operands were not constants, the intrinsic-specific simplification function was never called. In the case of the numeric inquiry functions, the important attribute is the type and kind of the operand, not its value. With this fixed, it turns out that g95 is not aggressive enough about assigning types on the parse pass. For example:

integer, parameter :: i = huge(j)  

By the time we get to type declaration statements, any IMPLICIT statements have been seen and the type of j is known, but g95 currently leaves this to the resolution phase. Have to move this up.

January 14

Found the problem with changing symbols-- statements have to be rejected, causing symbol changes to be undone before a namespace is freed. Otherwise, the namespace is gone, and the symbol-undoing operates on symbols that are gone.

Added support for the HUGE, RADIX, EPSILON, PRECISION and RANGE intrinsics. These cause a lot of the current failures. This meant some changes to intrinsic handling, effectively making each a generic function that operates on integers and reals. The specific functions all have the same name and are therefore not accessible.

This also changed the calling convention for make_generic() a bit-- now you give it the name of the function that should be made generic and all the specific versions are those nodes that follow the generic node. Another reason this works is that each generic name is also identical to a specific name.

January 12

Finished adding a mechanism for adding the procedure type to module procedures. This can happen during the parse phase, because the module procedures have all been declared by the time we get to the program units contained within the program units. The changes themselves have been debugged, but g95 somehow dumps core while undoing symbols that I don't have time to trace tonight.

January 10

Stuart McNicholas wrote in about a problem in interface.c that prevents it from compiling-- this is a half-baked version that shouldn't have been posted. I'll try to get to it soon, but I've had a lot of other things going on, and carpel tunnel has reared its painful head again. The good news is that I've figured out what it is that I've been doing wrong and corrected the situation.

January 7

Finished reinserting the g95_interface structures. Tested it on LAPACK and it seemed to work. We'll see how the full testsuite does.

January 4

I've been getting bad about posting updates here. The last of couple of nights have been recovering from a bad turn I took a couple weeks back. I removed the g95_interface structure because it didn't seem like it was legal for a program unit to be a member of more than one interface. Well, it is. I was paging through the test suite and found a program that actually does it. I'm still not quite sure why I thought that wasn't legal.

I've almost finished putting things back in. While this might seem like a real bear to deal with, changing the type of the relevant members in the g95_symbol structure allows the compiler to find most of the problems for me.

Rob Cermak and I have been looking at some of the timings in the test suite. While LAPACK95 parses without error, the time it takes is very high compared with other programs in the suite. I'm hoping Rob can get a profile of what is going on between his job and upcoming move to New Mexico. All I can say is that he picked the right time to move to the southwest.

January 1

Concentrated on core files-- these changes had to do with waiting until after an include file has 'returned' before moving to the next line. On the last line, the locus pointer becomes undefined, so if the file could not be found, a core dump occurred.

Another problem appeared to be g95_clear_attr() not resetting a couple of bits. This bug bit on the regression machine, which is a Sun, but not on x86 Linux.

A similar problem was that the array reference structure generated by an equivalence statement was not cleared to zeros before being used.