G95 compiler website?

G95 was a very good Fortran 95 compiler (plus some Fortran 2003 and 2008), developed between 2000 and 2013. Its slogan was “Crunching numbers”, if my memory is good. In fact, GFortran was forked from G95 in 2003 (GFortran in Fortran Wiki ; G95 - Wikipedia).

I was wondering if the G95 website was still online. And I was surprised by the answer, yes it is still online, but in Japanese:

Does anyone have some information about that?

The SourceForge page is still online:

2 Likes

The page of the 2003 fork is still online:
https://gcc-g95.sourceforge.net/main.html
with the title:

GNU Fortran 95 – Free number crunching FORALL!

1 Like

On Whois g95.org we can see that the domain g95.org was lastly registered on 2022-12-07, and that the servers are in Japan:

  • ns1.mixhost.jp
  • ns2.mixhost.jp

The last snapshot of the original homepage available on the Wayback Machine is from 2022-01-05:
https://web.archive.org/web/20220105201525/http://www.g95.org/

The G95 Project

A copy of the original homepage is also on SourceForge:

Maybe @Pap knows something ? He used the G95 compiler quite a bit.

If the original creator Andy Vaught is still around, maybe you could shoot him an email and ask him ?

1 Like

I was following the g95 project since it was just a curiosity, with a compiler far from being ready for real use. I used to contribute with regressions hunting and reporting. I remember Andy was remarkably quick to respond and squish the bugs reported. It was pretty much like exchanging a few emails today, discussing the problem, and g95 was updated tomorrow, with the bug fixed. The project had momentum and a rather small but enthusiastic user base, that’s for sure.
But this was 20-23 years ago… I lost the mails together with Andy’s email address in the meantime.

In time, g95 reached a pretty decent state, with not much competition in the free Fortran 90 compilers “market”. You had Vast/f90 as an alternative - which was good but not exactly a Fortran 90 compiler, and was not updated much. Sun Studio 9 had a very good free Fortran compiler as well, but this was later, when g95 was already in decline. So for a few years, g95 was the obvious pick. The Fortran Store used to sell a CD with Fortran environment/tools for beginners, and g95 was its compiler, updated regularly (I’m sure some Wayback digging will reveal this.) g95 was also the only compiler supporting the -std=F flag, essentially making it the only F compiler (not to be confused with that… thing called “F#”, which I’ll avoid saying what exactly it is, to avoid censoring.) The only other F compiler I could use was the free NAG F compiler, but this was short-lived. So yes, g95 was thriving for a while.

In the beginning of 2003, the gfrortran vs g95 “schism” was official, and nobody was happy about it. I have no more information, other that I could guess this would happen, sooner or later. For a while, I was still hoping for reconciliation between both projects, but it was quickly apparent this will never happen. Decisions taken early made g95’s development faster for some time after the schism, but gfortran was by design easier to develop in the long run, and eventually took the lead. g95 updates started to be less and less frequent, the community less and less active. The project can be considered dead since… several years ago. The fact SourceForge still hosts it doesn’t mean much, many abandoned projects are still hosted everywhere, even the more “trendy” GitHub is full of them.
In my opinion, a crucial decision taken by Andy was the beginning of the end, years before the end happened. However, that’s all I can conclude by the information publicly available concerning the schism (gfortran official site had a short article about this, and there are several mailing lists with discussions about it.) It is a sad story, that’s for sure.

3 Likes

That FORALL in the end deserves a spot in Anecdotal Fortran. :laughing:

2 Likes

What was that decision ?

If I remember correctly (and I think I do,) g95 was using a specific, “frozen” libgcc version instead of following the general gcc development (which gfortran did.) It was also the main reason for the fork - at least that was what I was reading pretty much everywhere back then. There were other reasons as well, but probably minor ones. g95’s developer insisted on his plan, and it was apparent that forking was inevitable - which eventually happened.

This decision resulted faster g95 development for a while, but problems in the long run. Indeed, it took time for gfortran to catch up, but when it did, development could continue much easier. The rest is (sad) history: g95 eventually died and gfortran lost a talented developer.

3 Likes

It’s a similar problem as with LLVM: you can either put the Fortran compiler directly in the LLVM git repository and then just support exactly the latest version of LLVM. Or you keep the Fortran compiler separate, and then you support multiple versions of LLVM to make it easy to compile on various systems.

G95 could have supported multiple GCC versions. Maybe it was too tied to GCC internals to make that feasible.

I looked some time ago what it would take to use GCC as a backend, and the easiest way seems to be to generate C code, which is what the NAG compiler does, and LFortran as well optionally. That way you do not depend on a particular GCC version and you can use any C compiler. It does seem better in some ways to interface the GCC’s intermediate representation directly, but then you have to maintain it and keep track of all the changes as GCC develops, and support multiple versions.

1 Like

Translation to another target language is (one of) the “classic” approaches for bootstrapping a compiler/language.

From the book Software Tools (1976) by Kernighan & Plaugher:

…since Fortran is widely available and well supported, we will use it as our base in this book. Most programmers have at least a reading knowledge of Fortran, and it runs on almost all computers. The language is sufficiently well standardized that programs can be written to run without change on a wide variety of systems. In a real sense, Fortran is the lingua franca of computing, the closest thing there is to a universal language.

But bare Fortran is a poor language indeed for programming or for describing programs. So we have written all of our programs in a simple extension language called “Ratfor” (short for Rational Fortran). Ratfor provides modern control flow statements like those in PL/I, Cobol, Algol or Pascal, so we can do structured programming properly. […]

[…]

Preprocessing into Fortran is a convenient way to do business. We retain the advantages of Fortran – a language that is universal, portable, and relatively efficient – while at the same time concealing its worst drawbacks. You might say we treat Fortran as an assembly language that will run on any machine. […]

The same approach was used for Stroustrup’s C with classes (later C++) in the CFront compiler which emitted C. (Both Kernighan and Stroustrup worked at Bell Labs.).

There is an experiment from Herb Sutter (former ISO C++ convenor) called cppfront, which replaces C++ with a new and distinct syntax called “Syntax 2”. More in this recent video: https://www.youtube.com/watch?v=ELeZAKCN4tY. The whole thing reminds me of the fixed-form to free-form Fortran change (with a few differences of course). There is also an amusing section where he explains bounds checking (which we’ve known in Fortran compilers for a long time), but with an added option that you can hook in your own bounds check handler (e.g. to print a custom error message or terminate differently).

3 Likes