This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Implementing FSEEK intrinsic, ErrLabel optional argument


Brooks Moses wrote:
There's currently only one G77 intrinsic not implemented in GFortran -- the FSEEK instrinsic. The specification for this in G77 is

CALL FSeek(Unit, Offset, Whence, ErrLab)

where ErrLab is an optional argument described as "'*label', where label is the label of an executable statement."

Steve and I talked about this a bit on IRC earlier this evening, and were strongly considering implementing this with the error label ignored (and letting the subroutine just abort on error conditions) because of the complexities involved in such a thing, but after not thinking about it for a while, I realized there's already a mechanism in place for handling exactly this: alternate returns from subroutines. I should have known, of course, because that's why it's "*label" and not just "label".

(Admittedly, an optional alternate-return argument isn't exactly allowed by the standard, but we can probably finesse it for an intrinsic.)

There aren't any existing intrinsics that have alternate returns, are there? Does anyone have any handy suggestions for how to go about writing one that does?

Ok, PRs 30235 through 30237 later, and I'm beginning to think that Steve's suggestion is the right way to go after all. Alternate return arguments are handled completely differently from other arguments (the expr or sym pointer in the argument list is simply NULL), and the instrinsics machinery doesn't have anything at all in place to deal with that.


Currently, PR 30237 means that if we implented FSEEK as a three-argument intrinsic, and someone put in a alternate-return fourth argument in their code, that extra argument would get ignored, which in this case is as close to the Right Thing as we'll get. However, as soon as someone fixes PR 30237, that will break, and there will be a syntax error about the alternate-return argument instead.

- Brooks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]