Bug 24357

Summary:	whither ratfor?
Product:	gcc	Reporter:	Jim Wilson <wilson>
Component:	fortran	Assignee:	Tobias Schlüter <tobi>
Status:	RESOLVED FIXED
Severity:	normal	CC:	gcc-bugs, nicolas.brouard, tobi
Priority:	P2
Version:	4.1.0
Target Milestone:	4.1.0
URL:	http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00062.html
Host:		Target:
Build:		Known to work:
Known to fail:		Last reconfirmed:	2005-11-01 20:25:02
Bug Depends on:	27513
Bug Blocks:

Description Jim Wilson 2005-10-14 02:46:54 UTC

The ratfor support broke when we dropped the old f77 front end.

aretha$ touch tmp.r
aretha$ ./xgcc -B./ tmp.r
xgcc: tmp.r: Ratfor compiler not installed on this system
aretha$

This is the default message we get when a language hasn't been configured in, but I did configure in the fortran compiler and hence something more interesting should have happened.

An older compiler (gcc 3.3.3) gives me
aretha$ gcc tmp.r
gcc: installation problem, cannot exec `ratfor': No such file or directory
aretha$
which would have worked if I had the ratfor preprocessor installed.

It isn't clear to me if we should be dropping the ratfor support, or if we should be fixing it.  Hence this PR.  A web search shows that the language is still alive, but I can't recall the last time someone mentioned it on a gcc list.

If we want to fix it, then we need to add a @ratfor spec to the fortran/lang-specs.h file.  Perhaps just one copied from the old f77 front end would do.

If we want to remove it, then we need to delete the .r filename docs from doc/invoke.texi.  We need to delete ratfor from the -x language list.  And we need to delete the default .r support in the gcc.c file.

Comment 1 Andrew Pinski 2005-10-14 02:53:16 UTC

There looks like ratfor90 also.

See http://sepwww.stanford.edu/software/ratfor90.html

Confirmed.

Comment 2 Tobias Schlüter 2005-11-01 20:25:02 UTC

I'd say, if someone wants to implement the necessary specs, he's free to do so, but for the time being, we can remove the support from invoke.texi, and gcc.c.

Comment 3 Tobias Schlüter 2005-11-16 10:58:45 UTC

Subject: Bug 24357

Author: tobi
Date: Wed Nov 16 10:58:41 2005
New Revision: 107078

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107078
Log:
	PR 24357
	* doc/invoke.texi: Distinguish between free and fixed form instead of
	Fortran and Fortran 90/95.  Remove ratfor from the list of supported
	languages.
	* gcc.c (default_compilers): Remove double entries, add entries for
	suffixes '.F90' and '.F95'.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/invoke.texi
    trunk/gcc/gcc.c

Comment 4 Tobias Schlüter 2005-11-16 11:00:45 UTC

Fixed on the trunk, 4.0 is still waiting for approval.

Comment 5 Nicolas Brouard 2006-05-08 22:03:05 UTC

May I add a comment on Ratfor. 
Ratfor is an ancestor of C, it has been widely used since the 80's. How can you suppress such a facility without any survey of who is still using it? I am not saying who is still writing new softwares with it, but who is still compiling old  scientific softwares still written in ratfor. I have been using Ratfiv since the 80's,  (ratfor->rat4->ratfiv) and recently (2 years ago) built a Mandrake rpm for  ratfiv. The advantage of ratfiv (Institute of Cancer Research) over ratfor was the easier way of programming. Ratfiv was able to output fortran77 on Vax machines. Ratfiv was also written in ratfiv itself and therefore was able to bootstrap (from original fortran sources)  and this is different from the classical ratfor compiled in C.

Since the rpm was built, some programmers have used it and reported bugs to Mandriva bugzilla which means that ratfor (or ratfiv) users using the Fortran code still exist.

Please let ratfor survive. What the problem with it?
I love gcc -o foo foo.r 
And unfortunately with gcc 4.1 and gcc -v foo foo.r I get a message
 "Ratfor compiler not installed on this system"
and this is wrong. In earlier version we got
 ratfor  -v -o /home/brouard/tmp/ccmkIREO.f foo.r

If there is no performance question please keep ratfor using f95. I compiled fortran output of ratfor programme and their is no problem.