Re: [PATCH, part1, v2] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]
On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote: > > Am 16.06.25 um 02:18 schrieb Steve Kargl: > > Harald, > > > > I did a quick glance at the patch and did not see anything that > > jumped out as needing a change. OK to commit. > > > > Earlier today I came to the same conclusion that -1 on overflow is > > probably the right thing to do. Gfortran would need a way to > > supply the value of ERANGE (on all supported targets) so a > > user can write a test. Yes, POSIX seems to define ERANGE as > > 34, but is that guaranteed on non-POSIX targets? > > > After thinking some more, I am struggling with these issues: > > - ERANGE may not be defined, and the value of ERANGE may not >be portable between targets. How to handle that on the >Fortran side? intrinsics/getcwd.c uses ERANGE unconditionally, so it seems all targets that GFortran supports do define ERANGE. As for the value, POSIX does not specify numerical values that the errno constants should take, though it seems 34 is more or less universal on Unix systems. Also it seems windows uses 34. I'd say just use ERANGE if appropriate, and if some target defines it differently then it's up to the user to deal with it. > - my initial proposal to return ERANGE has the potentially confusing >effect that stat(3) may be successful, only the conversion to >integer(kind=4) has an overflow in some component. Is it then >helpful to return ERANGE? Or just return -1 for those components >and document this new behavior? Good point. I'd say set only the overflowing component to -1 and document the behavior. It's possible the user is interested in some component that doesn't overflow, and returning ERANGE would break backwards compatibility? As an aside, I note the documentation for [F,L,]STAT says the VALUES array and STATUS should be INTEGER(4), which isn't correct is it? It should be default kind INTEGER? > And don't forget that returning ERANGE needs adjustment of > testcases, where the only portable solution I have is the > specification of -fdefault-integer-8 ... That might be a topic for a follow-up patch, but it would be useful to be able to use the kind=8 version without having to redefine the default integer size (which might need some additional headscratching to deal with VALUES of INTEGER(kind=8) and STATUS of default kind..). And then the documentation should recommend using that version in order to avoid overflows. -- Janne Blomqvist
[PATCH, part1, v3] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]
Am 17.06.25 um 19:44 schrieb Steve Kargl: On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote: On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote: Am 16.06.25 um 02:18 schrieb Steve Kargl: Harald, I did a quick glance at the patch and did not see anything that jumped out as needing a change. OK to commit. Earlier today I came to the same conclusion that -1 on overflow is probably the right thing to do. Gfortran would need a way to supply the value of ERANGE (on all supported targets) so a user can write a test. Yes, POSIX seems to define ERANGE as 34, but is that guaranteed on non-POSIX targets? After thinking some more, I am struggling with these issues: - ERANGE may not be defined, and the value of ERANGE may not be portable between targets. How to handle that on the Fortran side? intrinsics/getcwd.c uses ERANGE unconditionally, so it seems all targets that GFortran supports do define ERANGE. As for the value, POSIX does not specify numerical values that the errno constants should take, though it seems 34 is more or less universal on Unix systems. Also it seems windows uses 34. I'd say just use ERANGE if appropriate, and if some target defines it differently then it's up to the user to deal with it. I think your last sentence is the problem with returning ERANGE. If gfortran returns ERANGE, then gfortran should also have a facility that a user can query for the actual value. Walt mentions PXF in another reply. I have a copy of IEEE Std 1003.9-1992 (aka POSIX FORTRAN77 Language Interface - Part 1). I never found the time to implement (parts of) it. It should also be noted that on FreeBSD (and likely other UNIX-like systems), one finds % man 2 stat ... RETURN VALUES Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. Note, ERANGE is not documented as a value to which errno can be set. - my initial proposal to return ERANGE has the potentially confusing effect that stat(3) may be successful, only the conversion to integer(kind=4) has an overflow in some component. Is it then helpful to return ERANGE? Or just return -1 for those components and document this new behavior? Good point. I'd say set only the overflowing component to -1 and document the behavior. It's possible the user is interested in some component that doesn't overflow, and returning ERANGE would break backwards compatibility? As an aside, I note the documentation for [F,L,]STAT says the VALUES array and STATUS should be INTEGER(4), which isn't correct is it? It should be default kind INTEGER? We probably want to make these GNU extensions generic. I did this for kill() and there are additional patches in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372 for umask() and unlink(). And don't forget that returning ERANGE needs adjustment of testcases, where the only portable solution I have is the specification of -fdefault-integer-8 ... That might be a topic for a follow-up patch, but it would be useful to be able to use the kind=8 version without having to redefine the default integer size (which might need some additional headscratching to deal with VALUES of INTEGER(kind=8) and STATUS of default kind..). And then the documentation should recommend using that version in order to avoid overflows. Personally, I would like to see -fdefault-integer-8 deprecated, but that ship sailed long ago. Most intrinsic subprograms specified in the Fortran are generic. Perhaps, gfortran's extension should follow suit. OK, here is the conservative version along what Janne suggested, with a documentation update: as a matter of fact, we currently do support only default integer (which is kind=4, unless -fdefault-integer-8 is specified) in the frontend, We return -1 for elements where there would be overflow, but nothing like ERANGE or so in STATUS. If someone strongly feels that an error should be returned, and a mechanism to make it possible to portably detect this, this should become a separate PR. With this version, no tweaking of existing tests is needed. I intend to commit this within the next 24-48 hours as part 1 if it is ok. Thanks, Harald From 6fa2c8adae313d481b8bc56b7a2cb5cebdd6d95a Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Tue, 17 Jun 2025 21:09:32 +0200 Subject: [PATCH] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480] The GNU intrinsics STAT/LSTAT/FSTAT were inherited from g77, but changed the names of some keywords: FILE became NAME, and SARRAY became VALUES, which are the keywords documented in the gfortran manual. Adjust code and libgfortran error messages to reflect this change. Furthermore, add compile-time checking that INTENT(OUT) arguments are definable, and that array VALUES has at least size 13. Document that integer arguments are of default kind, and that overflows in conversion to integer return -1 in VALUES. PR
Re: [PATCH, part1, v2] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]
The old POSIX Fortran spec defined the PXFCONST subroutine and IPXFCONST function to provide portable access to constants such as ERANGE. Perhaps adding them to the gfortran library would be useful? Walter Sent from my iPhone > On Jun 17, 2025, at 4:05 AM, Janne Blomqvist > wrote: > > On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote: >> >>> Am 16.06.25 um 02:18 schrieb Steve Kargl: >>> Harald, >>> >>> I did a quick glance at the patch and did not see anything that >>> jumped out as needing a change. OK to commit. >>> >>> Earlier today I came to the same conclusion that -1 on overflow is >>> probably the right thing to do. Gfortran would need a way to >>> supply the value of ERANGE (on all supported targets) so a >>> user can write a test. Yes, POSIX seems to define ERANGE as >>> 34, but is that guaranteed on non-POSIX targets? >>> >> After thinking some more, I am struggling with these issues: >> >> - ERANGE may not be defined, and the value of ERANGE may not >> be portable between targets. How to handle that on the >> Fortran side? > > intrinsics/getcwd.c uses ERANGE unconditionally, so it seems all > targets that GFortran supports do define ERANGE. As for the value, > POSIX does not specify numerical values that the errno constants > should take, though it seems 34 is more or less universal on Unix > systems. Also it seems windows uses 34. I'd say just use ERANGE if > appropriate, and if some target defines it differently then it's up to > the user to deal with it. > >> - my initial proposal to return ERANGE has the potentially confusing >> effect that stat(3) may be successful, only the conversion to >> integer(kind=4) has an overflow in some component. Is it then >> helpful to return ERANGE? Or just return -1 for those components >> and document this new behavior? > > Good point. I'd say set only the overflowing component to -1 and > document the behavior. It's possible the user is interested in some > component that doesn't overflow, and returning ERANGE would break > backwards compatibility? > > As an aside, I note the documentation for [F,L,]STAT says the VALUES > array and STATUS should be INTEGER(4), which isn't correct is it? It > should be default kind INTEGER? > >> And don't forget that returning ERANGE needs adjustment of >> testcases, where the only portable solution I have is the >> specification of -fdefault-integer-8 ... > > That might be a topic for a follow-up patch, but it would be useful to > be able to use the kind=8 version without having to redefine the > default integer size (which might need some additional headscratching > to deal with VALUES of INTEGER(kind=8) and STATUS of default kind..). > And then the documentation should recommend using that version in > order to avoid overflows. > > -- > Janne Blomqvist >
Re: [PATCH, part1, v2] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote: > On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote: > > > > Am 16.06.25 um 02:18 schrieb Steve Kargl: > > > Harald, > > > > > > I did a quick glance at the patch and did not see anything that > > > jumped out as needing a change. OK to commit. > > > > > > Earlier today I came to the same conclusion that -1 on overflow is > > > probably the right thing to do. Gfortran would need a way to > > > supply the value of ERANGE (on all supported targets) so a > > > user can write a test. Yes, POSIX seems to define ERANGE as > > > 34, but is that guaranteed on non-POSIX targets? > > > > > After thinking some more, I am struggling with these issues: > > > > - ERANGE may not be defined, and the value of ERANGE may not > >be portable between targets. How to handle that on the > >Fortran side? > > intrinsics/getcwd.c uses ERANGE unconditionally, so it seems all > targets that GFortran supports do define ERANGE. As for the value, > POSIX does not specify numerical values that the errno constants > should take, though it seems 34 is more or less universal on Unix > systems. Also it seems windows uses 34. I'd say just use ERANGE if > appropriate, and if some target defines it differently then it's up to > the user to deal with it. I think your last sentence is the problem with returning ERANGE. If gfortran returns ERANGE, then gfortran should also have a facility that a user can query for the actual value. Walt mentions PXF in another reply. I have a copy of IEEE Std 1003.9-1992 (aka POSIX FORTRAN77 Language Interface - Part 1). I never found the time to implement (parts of) it. It should also be noted that on FreeBSD (and likely other UNIX-like systems), one finds % man 2 stat ... RETURN VALUES Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. Note, ERANGE is not documented as a value to which errno can be set. > > - my initial proposal to return ERANGE has the potentially confusing > >effect that stat(3) may be successful, only the conversion to > >integer(kind=4) has an overflow in some component. Is it then > >helpful to return ERANGE? Or just return -1 for those components > >and document this new behavior? > > Good point. I'd say set only the overflowing component to -1 and > document the behavior. It's possible the user is interested in some > component that doesn't overflow, and returning ERANGE would break > backwards compatibility? > > As an aside, I note the documentation for [F,L,]STAT says the VALUES > array and STATUS should be INTEGER(4), which isn't correct is it? It > should be default kind INTEGER? We probably want to make these GNU extensions generic. I did this for kill() and there are additional patches in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372 for umask() and unlink(). > > > And don't forget that returning ERANGE needs adjustment of > > testcases, where the only portable solution I have is the > > specification of -fdefault-integer-8 ... > > That might be a topic for a follow-up patch, but it would be useful to > be able to use the kind=8 version without having to redefine the > default integer size (which might need some additional headscratching > to deal with VALUES of INTEGER(kind=8) and STATUS of default kind..). > And then the documentation should recommend using that version in > order to avoid overflows. Personally, I would like to see -fdefault-integer-8 deprecated, but that ship sailed long ago. Most intrinsic subprograms specified in the Fortran are generic. Perhaps, gfortran's extension should follow suit. -- Steve
