Bug 19292

Summary: [meta-bug] g77 features lacking in gfortran
Product: gcc Reporter: Tobias Schlüter <tobi>
Component: fortranAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: alfredo.ferrari, dberkholz, franke.daniel, fxcoudert, gcc-bugs, kargl, malitzke, P.Schaffnit, pertusus, pinskia, tkoenig
Priority: P2 Keywords: meta-bug
Version: 4.0.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2006-10-02 09:41:07
Bug Depends on: 24546, 5900, 12884, 13082, 13257, 13939, 14067, 14994, 15234, 15235, 15326, 15332, 15382, 15966, 16435, 16436, 16465, 16511, 16531, 16580, 16907, 17229, 17285, 17423, 17472, 17675, 17737, 17871, 17941, 17992, 18026, 18210, 18398, 18476, 18481, 18518, 18540, 18600, 18737, 18781, 18791, 18794, 18827, 18833, 18870, 18879, 18902, 18977, 18982, 19021, 19052, 19155, 19216, 19280, 19425, 19478, 19589, 19678, 20059, 20085, 20086, 20092, 20108, 20124, 20125, 20224, 20440, 20441, 20467, 20592, 20786, 20811, 20867, 21565, 22175, 22217, 22244, 22282, 22290, 22304, 22359, 23060, 23151, 23232, 23912, 24285, 24459, 24643, 24828, 24892, 24917, 24919, 24945, 25036, 25116, 25146, 25349, 25392, 25403, 25598, 25756, 26136, 26551, 27457, 27757, 27784, 29689, 29786, 30009, 30056, 30278, 30452, 30525, 30532, 31409, 31880    
Bug Blocks:    

Description Tobias Schlüter 2005-01-06 14:39:36 UTC
This is a metabug for all issues in gfortran that need to be resolved before
gfortran can be used as a complete replacement for g77.

I'm not sure about the following bugs:
- PR 15553 : does this also occur without explicit interfaces? IOW is it
possible to provoke this error in Fortran 77 code?
- PR 18833 : I'm not sure if this is valid Fortran 77
Comment 1 Thomas Koenig 2005-01-06 17:28:48 UTC
I don't think PR 18476 needs to be in there.  The test case is
invalid (just putting nml instead of nml= into the list).
Comment 2 Tobias Schlüter 2005-01-06 17:35:29 UTC
(In reply to comment #1)
> I don't think PR 18476 needs to be in there.  The test case is
> invalid (just putting nml instead of nml= into the list).

I don't understand your parenthetical remark.

Please see my comment to PR18476: g77 gives a runtime error, but compiles this
flawlessly.

Comment 3 Steve Kargl 2005-01-08 05:40:10 UTC
Here is the list of unimplemented g77 intrinsics procedures.  It may not
be a complete list, but others can find the info in g77.info if so desired.
Access,   fcn,   Check file accessibility.

Alarm,    fcn,   Execute a routine after a given delay.
And,      fcn,   Boolean AND.
ChDir,    sub,   Change directory.
ChMod,    sub,   Change file modes.
Complex,  fcn,   Build complex value from real and imaginary parts.
CTime,    sub,   Convert time to Day Mon dd hh:mm:ss yyyy.
CTime,    fcn,   Convert time to Day Mon dd hh:mm:ss yyyy.
FDate,    sub,   Get current time as Day Mon dd hh:mm:ss yyyy.
FDate,    fcn,   Get current time as Day Mon dd hh:mm:ss yyyy.
FGet,     sub,   Read a character from unit 5 stream-wise.
FGetC,    sub,   Read a character stream-wise.
FPut,     sub,   Write a character to unit 6 stream-wise.
FPutC,    sub,   Write a character stream-wise.
FSeek,    fcn,   Position file (low-level).
FTell,    sub,   Get file position (low-level).
FTell,    fcn,   Get file position (low-level).
GError,   fcn,   Get error message for last error.
GetEnv,   fcn,   Get environment variable.
GetLog,   fcn,   Get login name.
GMTime,   fcn,   Convert time to GMT time info.
HostNm,   sub,   Get host name.
HostNm,   fcn,   Get host name.
IDate,    sub,   Get local time info.
IErrNo,   fcn,   Get error number for last error.
ImagPart, fcn,   Extract imaginary part of complex.
Int2,     fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.
Int8,     fcn,   Convert to `INTEGER(KIND=2)' value truncated to whole number.
IsaTty,   fcn,   Is unit connected to a terminal?
ITime,    sub,   Get local time of day.
Kill,     sub,   Signal a process.
Link,     sub,   Make hard link in file system.
LnBlnk,   sub,   Get last non-blank character in string.
Loc,      fcn,   Address of entity in core.
Long,     fcn,   Conversion to `INTEGER(KIND=1)' (archaic).
LShift,   fcn,   Left-shift bits
LStat,    sub,   Get file information.
LStat,    fcn,   Get file information.
LTime,    sub,   Convert time to local time info.
MClock,   fcn,   Get number of clock ticks for process.
MClock8,  fcn,   Get number of clock ticks for process.
Not,      fcn,   Boolean NOT.
Or,       fcn,   Boolean OR.
PError,   sub,   Print error message for last error.
Rename,   sub,   Rename file.
RShift,   fcn,   Right-shift bits.
Short,    fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.
Signal,   sub,   Muck with signal handling.
Sleep,    sub,   Sleep for a specified time.
SymLnk,   sub,   Make symbolic link in file system.
Time,     fcn,   Get current time as time value.
Time8,    fcn,   Get current time as time value.
TtyNam,   sub,   Get name of terminal device for unit.
TtyNam,   fcn,   Get name of terminal device for unit.
XOr,      fcn,   Boolean XOR.

Comment 4 Thomas Koenig 2005-01-20 10:47:20 UTC
Added PR 18902 because complex division isn't scaled at the moment
(it is in g77).
Comment 5 Francois-Xavier Coudert 2005-03-22 22:17:25 UTC
List of unimplemented g77 intrinsics is now reduced to:

Access,   fcn,   Check file accessibility.
Alarm,    fcn,   Execute a routine after a given delay.
And,      fcn,   Boolean AND.
ChMod,    sub,   Change file modes.
Complex,  fcn,   Build complex value from real and imaginary parts.
CTime,    sub and fcn,   Convert time to Day Mon dd hh:mm:ss yyyy.
FDate,    sub and fcn,   Get current time as Day Mon dd hh:mm:ss yyyy.
FGet,     sub,   Read a character from unit 5 stream-wise.
FGetC,    sub,   Read a character stream-wise.
FPut,     sub,   Write a character to unit 6 stream-wise.
FPutC,    sub,   Write a character stream-wise.
FSeek,    fcn,   Position file (low-level).
FTell,    sub and fcn,   Get file position (low-level).
GMTime,   fcn,   Convert time to GMT time info.
IDate,    sub,   Get local time info.
ImagPart, fcn,   Extract imaginary part of complex.
Int2,     fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.
Int8,     fcn,   Convert to `INTEGER(KIND=2)' value truncated to whole number.
IsaTty,   fcn,   Is unit connected to a terminal?
ITime,    sub,   Get local time of day.
Loc,      fcn,   Address of entity in core.
Long,     fcn,   Conversion to `INTEGER(KIND=1)' (archaic).
LShift,   fcn,   Left-shift bits
LStat,    sub and fcn,   Get file information.
LTime,    sub,   Convert time to local time info.
MClock,   fcn,   Get number of clock ticks for process.
MClock8,  fcn,   Get number of clock ticks for process.
Not,      fcn,   Boolean NOT.
Or,       fcn,   Boolean OR.
RShift,   fcn,   Right-shift bits.
Short,    fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.
Signal,   sub,   Muck with signal handling.
TtyNam,   sub and fcn,   Get name of terminal device for unit.
XOr,      fcn,   Boolean XOR.
Comment 6 Tobias Schlüter 2005-03-22 23:19:51 UTC
WRT g77 intrinsics: if we instructed the compiler to compile calls to these
routines following the calling conventions for f2c, we could simply call their
implementations from libf2c.

This seems much easier and less error-prone than reimplementing them (even
though that's not hard, I admit).
Comment 7 Francois-Xavier Coudert 2005-11-12 23:29:51 UTC
With my last patch () that I am currently commiting, the list of unimplemented intrinsics is now:

Access,   fcn,   Check file accessibility.
ChMod,    sub,   Change file modes.
FSeek,    fcn,   Position file (low-level).
GMTime,   fcn,   Convert time to GMT time info.
IDate,    sub,   Get local time info.
Int2,     fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.
Int8,     fcn,   Convert to `INTEGER(KIND=2)' value truncated to whole number.
ITime,    sub,   Get local time of day.
Long,     fcn,   Conversion to `INTEGER(KIND=1)' (archaic).
LShift,   fcn,   Left-shift bits
LStat,    sub and fcn,   Get file information.
LTime,    sub,   Convert time to local time info.
MClock,   fcn,   Get number of clock ticks for process.
MClock8,  fcn,   Get number of clock ticks for process.
RShift,   fcn,   Right-shift bits.
Short,    fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.

I plan to work on ACCESS and CHMOD (I already have them half-implemented in one of my trees) and FSEEK is though to get (it has a label as optional argument, which I don't know how to handle). GMTIME, IDATE, ITIME, LSTAT and LTIME need some library part and should be easy, if someone wants to have a go at them, feel free!
Comment 8 Ray Malitzke 2006-01-07 20:30:42 UTC
Not all of the underlying are just g77 features. Some like 18540/25705 are legal f90, f95, f06 code an just calling them "excremental" is unprofessional. This diminishes the 90% plus of dedicated people working on GCC. If something is clearly impoosible to continue as part of fortran then an effort to change the specs should be made. 
Comment 9 kargl 2006-01-07 21:55:06 UTC
(In reply to comment #8)
> Not all of the underlying are just g77 features. Some like 18540/25705 are
> legal f90, f95, f06 code an just calling them "excremental" is unprofessional.
> This diminishes the 90% plus of dedicated people working on GCC. If something
> is clearly impoosible to continue as part of fortran then an effort to change
> the specs should be made. 

Well, in looking at the code in 25705, I think the code is nonconforming via
8.1.1.2 of the Fortran 95 standard.  I don't have a copy of the Fortran 90
standard, but I suspect that it will also show that the code is nonconforming.

Comment 10 Steve Kargl 2006-01-07 22:17:42 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

On Sat, Jan 07, 2006 at 09:55:07PM -0000, kargl at gcc dot gnu dot org wrote:
> 
> 
> Well, in looking at the code in 25705, I think the code is nonconforming via
> 8.1.1.2 of the Fortran 95 standard.  I don't have a copy of the Fortran 90
> standard, but I suspect that it will also show that the code is nonconforming.
> 

I'll also note that Lahey's web base checking utility calls out
the "goto 105" with a warning.  NAG's Fortran 95 compiler issues
an error similar to gfortran's message.  The exact text of 8.1.1.2
is:

    Transfer of control to the interior of a block from outside the block
    is prohibited.  Transfers within a block and transfers from the interior
    of a block to outside the block may occur.

This statement is followed with 

    NOTE 8.3
    For example, if a statement inside the block has a statement label,
    a GO TO statement using that label is only allowed to appear in the
    same block.

My advice would be to fix the code to make it portable.

Comment 11 Ray Malitzke 2006-01-08 00:33:28 UTC
Last things first: The code posted in 25705 is copyrighted 1994 and published in Computer Physics Communications; hence just modification by a third party could be legally questionable. The two academics (one in computer Science) conceivably were cogniscent of the f90 standard. Anyhow, standards sould be quoted in context, I have the Sep 2002 working draft (only abrogating f77, f90, and f95, per Annex B) which per Para 8.1.1.2 matches the quotation in comment 10. However, the 105 label precedes the first executable statement. Now, line 18 of 8.1 reads as follows:

Any of these constructs may be named. If a construct is named, the name shall be the first lexical token of the first statement of the construct and the last lexical token of the construct. In fixed source form, the name preceding the construct shall be placed after character position 6. 

Therefore, the 105 GOTO address clearly is not inside the construct, because it  immediately follows the ELSE and precedes character position 6 of the construct proper; and 8.1.1.2 does not apply.

If label 105 would not precede the block, but be inside, then error message, pertaining to the inside of the block would be proper.

Also, if commercial compilers would have a clear basis to issue an error message, they probably would do so and get off the hook.

As I am clearly no the author the the code, I have no real position to defend. As my post 25705 makes clear legalistic arguments should be avoided. I also coded a parallel C program and used f2c on the code fragment posted. In both cases gcc-4.1.0 emitted object code without complaint. In this respect C and fortran are both block structured languages without nesting of subroutines. Therefore, if gcc-4.1.0 can handle it for C a parallel construct should do it for fortran.
Comment 12 Andrew Pinski 2006-01-08 00:51:22 UTC
(In reply to comment #11)
> As I am clearly no the author the the code, I have no real position to defend.
> As my post 25705 makes clear legalistic arguments should be avoided. I also
> coded a parallel C program and used f2c on the code fragment posted. In both
> cases gcc-4.1.0 emitted object code without complaint. In this respect C and
> fortran are both block structured languages without nesting of subroutines.
> Therefore, if gcc-4.1.0 can handle it for C a parallel construct should do it
> for fortran.

C is different than Fortran.  I am not clear why you are bring that up at all.

Also ICC warns about the code which is why I put in PR 25705 which makes me question the code  and if other compiler also warns (or even errors out) about it (by default), it is even more questionable.

Also fortran does have nesting of subroutines, I don't get why you said it is not, it is a feature of Fortran 90.  You can do something like:
function g(f)
REAL :: g
REAL :: f
g = h()
contains
function h()
REAL :: h
h = f +1.0
end function
end function
Comment 13 Steve Kargl 2006-01-08 01:58:11 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

On Sun, Jan 08, 2006 at 12:33:29AM -0000, malitzke at metronets dot com wrote:
> 
> Last things first: The code posted in 25705 is copyrighted 1994 and published
> in Computer Physics Communications; hence just modification by a third party
> could be legally questionable. The two academics (one in computer Science)
> conceivably were cogniscent of the f90 standard.

So, contact the original authors!  Posting the copryrighted code to
a mailing list is also questionable.  

> Anyhow, standards should be quoted in context, I have the Sep 2002
> working draft (only abrogating f77, f90, and f95, per Annex B) which
> per Para 8.1.1.2 matches the quotation in comment 10.  However, the
> 105 label precedes the first executable statement. Now, line
> 18 of 8.1 reads as follows:
> 
> Any of these constructs may be named. If a construct is named, the
> name shall be the first lexical token of the first statement of the
> construct and the last lexical token of the construct. In fixed source
> form, the name preceding the construct shall be placed after character
> position 6. 
>
> Therefore, the 105 GOTO address clearly is not inside the construct,
> because it immediately follows the ELSE and precedes character position
> 6 of the construct proper; and 8.1.1.2 does not apply.

There are no named constructs in the code posted!  The 105 in is a
*statement label*.  A named construct in fixed form would be

c234567
      n = 2
      AAA: if (n == 1) then
         n = 100
      else if (n == 2) then AAA
         n = 200
      else AAA 
         n = 0
      end if AAA
      print *, n
      end


> If label 105 would not precede the block, but be inside, then error message,
> pertaining to the inside of the block would be proper.

It is in a block.  If we remove the unneeded lines, you have


   506 IF(IX.EQ.0. AND. IY.EQ.1) THEN
A         IF(IBACK3.EQ.0) THEN
AB           IF(MGO.EQ.0) THEN
ABD             N=4
AB           ELSEIF(MGO.EQ.1) THEN
ABE             IF(IBACK3.EQ.1) THEN
ABEF               GO TO 105 ! rmg questionable goto
ABE             ELSE
ABEG               N=4
ABE             ENDIF
AB           ELSE
ABD             GO TO 108
AB           ENDIF
A         ELSE
AC 105       IRHO=NU
AC           RETURN
A         ENDIF
A  108 MEMR=IRHO
      ENDIF

Everything marked with an A is in the constituent block of the 
outermost IF...ENDIF.  Everything marked with the AB is in the
constituent block of the IF(IBACK3.EQ.0) THEN ... ELSE. Everything
marked with AC is in the constituent block of the ELSE ... ENDIF
that corresponds the IF(IBACK3.EQ.0) THEN.   The "GO TO 105" is
transferring control into the AC block, which is prohibited!

> Also, if commercial compilers would have a clear basis to issue an error
> message, they probably would do so and get off the hook.

The wording in 8.1.1.2 is such that a compiler is not required by
the standard to issue an error here.  The words are "Transfer of
control to the interior of a block from outside the block is 
prohibited."  The "is" provides wiggle room for a vendor.  If the
"is" were "shall be", then an error message would be required.

> As I am clearly no the author the the code, I have no real position
> to defend.  As my post 25705 makes clear legalistic arguments should
> be avoided.

We're trying to write a Fortran 95 conforming compiler.  We can't
avoid legalistic arguments.  I'm sorry if this view offends you.

> I also coded a parallel C program and used f2c on the code fragment
> posted. In both cases gcc-4.1.0 emitted object code without complaint.
> In this respect C and fortran are both block structured languages
> without nesting of subroutines.  Therefore, if gcc-4.1.0 can handle
> it for C a parallel construct should do it for fortran.

C and Fortran are two different languages with two different standards.
f2c is at best a Fortran 77 compiler.  The behavior you want may be
permitted by Fortran 77, but I would need to study the Fortran 77
standard before I make any judgement.

Comment 14 Tobias Schlüter 2006-01-08 02:30:50 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

malitzke at metronets dot com wrote:
> ------- Comment #8 from malitzke at metronets dot com  2006-01-07 20:30 -------
> Not all of the underlying are just g77 features. Some like 18540/25705 are
> legal f90, f95, f06 code an just calling them "excremental" is unprofessional.
> This diminishes the 90% plus of dedicated people working on GCC. If something
> is clearly impoosible to continue as part of fortran then an effort to change
> the specs should be made. 

I find this very offensive.  As you will have noticed we have a problem report
about this, which is not closed as "WONTFIX", and thus we're definitely not
just calling this feature "excremental".  Also, you're saying that Paul Thomas
(who wrote the original bug report where this wording is used) is
unprofessional and undedicated.  The latter is easily disproved by taking a
look at the ChangeLog.   In fact, everybody working on gfortran is doing so
out of dedication, as noone of us is getting paid for this work, and everybody
has access to commercial compilers.</rant>

This construct in non-standard for the reasons quoted by Steve and and so far
the people working on gfortran have considered the importance of this bug
second to the other bugs they were fixing.  If somebody cares enough he may
bring forth a patch, which -- provided sufficient quality -- will be
integrated, and we will be one step closer to a complete Fortran 66 compiler.
Comment 15 Steve Kargl 2006-01-08 02:43:29 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

On Sun, Jan 08, 2006 at 02:30:51AM -0000, Tobias dot Schlueter at physik dot uni-muenchen dot de wrote:
> 
> I find this very offensive.  As you will have noticed we have a problem report
> about this, which is not closed as "WONTFIX", and thus we're definitely not
> just calling this feature "excremental".  Also, you're saying that Paul Thomas
> (who wrote the original bug report where this wording is used) is
> unprofessional and undedicated.  The latter is easily disproved by taking a
> look at the ChangeLog.   In fact, everybody working on gfortran is doing so
> out of dedication, as noone of us is getting paid for this work, and everybody
> has access to commercial compilers.</rant>
> 
> This construct in non-standard for the reasons quoted by Steve and and so far
> the people working on gfortran have considered the importance of this bug
> second to the other bugs they were fixing.  If somebody cares enough he may
> bring forth a patch, which -- provided sufficient quality -- will be
> integrated, and we will be one step closer to a complete Fortran 66 compiler.
> 

Wow.  You took the words out of my mouth.  It took me nearly 
40 minutes to write my last reply.  Self editing of some rather
pointed comments.

Comment 16 Ray Malitzke 2006-01-08 10:41:13 UTC
Well I am very glad you people are offended. Imaging how you would feel I some one had called your work a piece of excrement. Excrement (with some minor variation in spelling) comes from Latin and means vernacular M.... in Spain, Portugal, France, Italy and S... in England, Germany, Sweden. At least per Webster excremental is the adjective pertaining to excrement. Pofessor Emerita C. Froese Fischer (Computer Science Vandebilt University) is the principal author of the MCHF Atomic Structure Package. Acoording to Google there are about 139 thousand citations and authorships to her credit. The MCHF package has about 1.5 megabytes of source code. I never met the lady as student, collaborator or otherwise. Calling her work even only by clearly erroneous association excrement is equivalent to calling GCC a piece of excrement. Happy sulking to you all!

Now to the coding and standards issues. I stand corrected by Mr Pinski as to the contains issue. I took the statements regarding CONTAINS (page 116)in Fortran 90 Programmning (TMR Ellis et  all) literally as just pertaining for fortran modules to get the calling parameters properly to the compiler the way header files do in C. Only much later in the book is the nesting issue broached. However Mr Pinski also jumping a (in may reckoning) to a wrong conclusion in terming my submission the short citation (a fraction of one percent, allowable under my interprtration of Copyright) of Professor Frose Fischer work as being the equivalent the one containing the "excremental" adjective. The 105 label in my submission precedes the first executable statement while the pertinent label in the ealier submission (which never turned up when I searched for various combinations of GTO and fortran) clearly comes after the first executable statement. This makes that "excremental" case a clear violation of 8.1.1.2.

To Mr. Kargl I would counsel moderation is the the of the "Imperial" we and perhaps practice some more reading specifications. His interpretation of "is" and "shall be" in relation the 8.1.1.2 clearly shows his lack of experience. 

Last, but not least, I do not even pretend to be compiler expert, even after having fairly good understanding of the "Dragon Book". At best I am just a tester, regardles of having hacked GCC code since the late 80's to get GCC to work on SCO's 386 Xenix. I got my start with plugboard punched card equipement and worked as real-time assembly programmer. Now, I am just trying (as a retiremnt hobby) to bring code  like Professor Froese Fischer's to a wider audience before it is withdrawn from public access in disgust at being belittled. If in the process I can do some further good by testing forthcoming versions of GCC so much the better. Your reactions provide further amusement. As a result of submitting aboout 10 Gigabytes of source code to GCC I have other irons in the fire for the easily offended to get burned. 
Comment 17 Tobias Schlüter 2006-01-08 13:18:45 UTC
Instead of continuing a pointless flame war in a PR which is only organisationally related to the bug we're talking about, let me explain a few procedural details which will hopefully make you understand that noone called your colleague's code names.

You submitted a bug which was closed as a duplicate of an existing bug.  In the existing bug, the submitter (who by that time wasn't yet a developer of gfortran) dismissed as "excremental" an artificial example which demonstrates a bad coding practice that has not been allowed by any Fortran standard since 1978.  Somehow you form the opinion that Paul insulted your colleague, and question Paul's motivations and skills.  (WRT Let me just say that Paul has fixed 105 PRs during the last year alone -- obviously he thought they were more important than this bug which he reported.)

I understand your frustration that this bug hasn't yet been closed, and I'm grateful that you're using gfortran and reporting bugs, but I think that everybody's time could be better spent than by arguing about who insulted who and how the standard should be quoted.
Comment 18 Steve Kargl 2006-01-08 16:37:09 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

On Sun, Jan 08, 2006 at 10:41:15AM -0000, malitzke at metronets dot com wrote:
> 
> one had called your work a piece of excrement. Excrement (with some minor
> variation in spelling) comes from Latin and means vernacular M.... in Spain,
> Portugal, France, Italy and S... in England, Germany, Sweden. At least per
> Webster excremental is the adjective pertaining to excrement. Pofessor Emerita
> C. Froese Fischer (Computer Science Vandebilt University) is the principal
> author of the MCHF Atomic Structure Package. Acoording to Google there are
> about 139 thousand citations and authorships to her credit. The MCHF package
> has about 1.5 megabytes of source code. I never met the lady as student,
> collaborator or otherwise. Calling her work even only by clearly erroneous
> association excrement is equivalent to calling GCC a piece of excrement. Happy
> sulking to you all!

No one called Fischer's life work crap.  The phrase was used to describe
a piece of code in PR 18540.  Fischer's code has the same bug, and
somehow you infer that we, the gfortran developers, have called all
of Fischer's work crap.  If MCHF is in fact 1.5 MB of source code, and
this is the only bug, well I suppose Fischer should thank us, the 
gfortran developers, for debugging her code.

> adjective. The 105 label in my submission precedes the first executable
> statement while the pertinent label in the ealier submission (which never
> turned up when I searched for various combinations of GTO and fortran) clearly
> comes after the first executable statement. This makes that "excremental" case
> a clear violation of 8.1.1.2.

I've already explain to you why the code is nonconforming.  To recap,
using NOTE 8.3 from the Final Committee Draft of the Fortran 95 standard.

   NOTE 8.3
   For example, if a statement inside the block has a statement label,
   a GO TO statement using that label is only allowed to appear in the
   same block.

> To Mr. Kargl I would counsel moderation is the the of the "Imperial" we and
> perhaps practice some more reading specifications. His interpretation of "is"
> and "shall be" in relation the 8.1.1.2 clearly shows his lack of experience. 

If you're concerned with my ability to read the Fortran 95 specification,
you can revert all of the patches I've committed.  These are documented
in ChangeLog.  You'll then need to revert the patches of other committers
that were reviewed and OK by me.  

If you want expert opinion on the code in PR 25705 because my interpretation
upsets you, then I suggest that you send it to comp.lang.fortran.  Several
former and current members of J3 answer questions on c.l.f.  (J3 is the
group of people who actually wrote the standard.)

Comment 19 Paul Thomas 2006-01-08 20:27:20 UTC
(In reply to comment #8)
> Not all of the underlying are just g77 features. Some like 18540/25705 are
> legal f90, f95, f06 code an just calling them "excremental" is unprofessional.
> This diminishes the 90% plus of dedicated people working on GCC. If something
> is clearly impoosible to continue as part of fortran then an effort to change
> the specs should be made. 
> 
As several people have noted, my involvement with gcc is unprofessional; appparently in every sense of the word.  If my use of the word "excremental" caused offence, I am sorry.  Let me just restate it that it is my opinion that it is unprofessional fortran style to jump into IF blocks. Doubtless the original author is as much a software professional as me....  That said, you will note that I submitted it as PR because I thought that it should be fixed.

Paul 
Comment 20 Steve Kargl 2006-05-27 19:24:12 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

On Sat, May 27, 2006 at 07:11:01PM -0000, tkoenig at gcc dot gnu dot org wrote:
> 
> 
> tkoenig at gcc dot gnu dot org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>   BugsThisDependsOn|                            |27757
> 
> 

27757 does not belong in this meta-bug.  It is actually
a regression with respect to a version of gfortran.

Comment 21 Thomas Koenig 2006-05-27 20:24:29 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

sgk at troutmask dot apl dot washington dot edu wrote:

> 27757 does not belong in this meta-bug.  It is actually
> a regression with respect to a version of gfortran.

Do you know which version?  We should mark 27757 as a regression, then.

	Thomas
Comment 22 Steve Kargl 2006-05-27 20:28:03 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

On Sat, May 27, 2006 at 08:24:31PM -0000, Thomas dot Koenig at online dot de wrote:
> 
> Do you know which version?  We should mark 27757 as a regression, then.
> 
>         Thomas
> 

laptop:kargl[203] gfc --version
GNU Fortran 95 (GCC 4.1.0 20050716 (experimental))

http://gcc.gnu.org/ml/fortran/2006-05/msg00457.html

Comment 23 Daniel Franke 2006-07-03 12:14:41 UTC
Is the list of missing intrinsics given in comment #7 still valid? I tried to compile F77 code I inherited and got undefined references for itime_ and idate_ (gfortran-4.1.1). If they are still missing, is someone working on those? 
Comment 24 Francois-Xavier Coudert 2006-07-03 12:58:06 UTC
(In reply to comment #23)
> Is the list of missing intrinsics given in comment #7 still valid? I tried to
> compile F77 code I inherited and got undefined references for itime_ and idate_
> (gfortran-4.1.1). If they are still missing, is someone working on those?

I think the list is indeed still valid, as nobody has been (to my knowledge) working on this for some time now. They should not be very difficult to implement (I'd even say fairly easy) but there are just too few people to do the job...

Pasting the list here again:

Access,   fcn,   Check file accessibility.
ChMod,    sub,   Change file modes.
FSeek,    fcn,   Position file (low-level).
GMTime,   fcn,   Convert time to GMT time info.
IDate,    sub,   Get local time info.
Int2,     fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.
Int8,     fcn,   Convert to `INTEGER(KIND=2)' value truncated to whole number.
ITime,    sub,   Get local time of day.
Long,     fcn,   Conversion to `INTEGER(KIND=1)' (archaic).
LShift,   fcn,   Left-shift bits
LStat,    sub and fcn,   Get file information.
LTime,    sub,   Convert time to local time info.
MClock,   fcn,   Get number of clock ticks for process.
MClock8,  fcn,   Get number of clock ticks for process.
RShift,   fcn,   Right-shift bits.
Short,    fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.

CHMOD might be a bit tricky (especially if we don't want to fork and exec), FSEEK needs a bit of thinking from someone knowing the I/O library, but all others probably require no special skill.
Comment 25 Jerry DeLisle 2006-07-03 16:41:29 UTC
FSEEK should be straightforward (ha ha) I will take a shot at that one.
Comment 26 Steve Kargl 2006-07-03 17:17:18 UTC
Subject: Re:  [meta-bug] g77 features lacking in gfortran

On Mon, Jul 03, 2006 at 04:41:30PM -0000, jvdelisle at gcc dot gnu dot org wrote:
> 
> FSEEK should be straightforward (ha ha) I will take a shot at that one.
> 

<hint>
Jerry, with your knowledge of libgfortran, I'd rather see you
work on the F2003 stream IO feature
</hint>

Comment 27 Francois-Xavier Coudert 2006-07-26 12:07:43 UTC
I just got the "missing g77 intrinsics" list down to:

Access,   fcn,   Check file accessibility.
ChMod,    sub,   Change file modes.
FSeek,    fcn,   Position file (low-level).
GMTime,   fcn,   Convert time to GMT time info.
LShift,   fcn,   Left-shift bits
LTime,    sub,   Convert time to local time info.
RShift,   fcn,   Right-shift bits.
Comment 28 Francois-Xavier Coudert 2006-10-02 09:41:07 UTC
The only g77 intrinsic now missing to gfortran is FSEEK (and this is PR 22359).
Comment 29 Patrice Dumas 2006-12-17 18:21:38 UTC
getarg intrinsic which was in g77 also seems to be unimplemented?
Comment 30 Patrice Dumas 2006-12-18 21:39:38 UTC
(In reply to comment #29)
> getarg intrinsic which was in g77 also seems to be unimplemented?
> 

Sorry, it is implemented. What has changed with regard with g77 is that
the associated symbol isn't along getarg_ anymore. I was calling getarg_ 
directly from some C code, therefore it looked like getarg was missing...
Comment 31 Francois-Xavier Coudert 2007-08-16 12:10:42 UTC
Marking this as FIXED, see http://gcc.gnu.org/ml/fortran/2007-08/msg00327.html for details.