User account creation filtered due to spam.
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
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).
(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.
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.
Added PR 18902 because complex division isn't scaled at the moment (it is in g77).
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.
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).
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!
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.
(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.
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.
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.
(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
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.
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.
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.
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.
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.
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.)
(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
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.
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
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
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?
(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.
FSEEK should be straightforward (ha ha) I will take a shot at that one.
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>
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.
The only g77 intrinsic now missing to gfortran is FSEEK (and this is PR 22359).
getarg intrinsic which was in g77 also seems to be unimplemented?
(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...
Marking this as FIXED, see http://gcc.gnu.org/ml/fortran/2007-08/msg00327.html for details.