Re: How to document intrinsics with UNSIGNED arguments...
Am 19.10.24 um 10:40 schrieb FX Coudert: Hi, As UNSIGNED has been booted off the F202Y list, I think calling it an extension at this time is fair. Looks good to me. And yes, calling it an extension is fair. I apologise, I had missed this piece of information. If UNSIGNED is > not on track to becoming a feature in the next standard, is there really high value in implementing it in gfortran? Yes, I think so, for several reasons. One is the chicken-and-egg problem: One of the points of the discussion on github was the lack of a major compiler implementing unsigned integers. Well, that is now no longer the case, not that gfortran implements it. The author of f18n has already started working on implementing it, using the same specification that gfortran uses. Two compilers implementing the same extension the same way is more likely to sway the mind of enough people on WG5 to let this pass the next time. Second, the feature is clearly isolated behind a flag; nobody will use it by accident. Third, this was passed by J3 with modifications to my original paper, and the modifications that were made have resulted in something quite solid. There was enough support to let it pass, but apparently it was torpedoed by people who do not believe a general-purpose language should have access to modulo 2^n arithmetic. Fourth, I have already put in the work. Maintenance will very likely be very low, and I certainly will do it. Fifth, if we do nothing now, the can will be kicked down the road another 10 years - the next chance to include this would be in Fortran 203X. Sixth, this is extremely useful - automated writing out of prototypes so interfaces to C can be checked by compilers is a major point, as is having access to 2^n modulo arithmetic. With this, it is no longer necessary to turn to C for such things. Best regards Thomas Fortran as a language is moving from a past where it was a nightmare of > incompatible extensions, into a more standard-based language. I personally> think it is a good evolution. In general, I agree, but not in this particular case. Big extensions (like Cray pointers) have shown in the past how hard they > are to maintain in the long term: lots of dark corners that we never get fully right. Cray pointers were poorly defined from the start, and the only "dark corner" for unsigned integers is whether to allow overflow and use modulo 2^n arithmetic, or prohibit this (and disallow major use cases, which I personally would find silly). Best regards Thomas
[patch, fortran] Fix UNSIGNED ICE on matchting
Hello world,
I have just committed the attached patch as obvious - just recognize
that an UNSIGNED is an error in a complex part.
Fix an ICE with UNSIGNED in match_sym_complex_part.
gcc/fortran/ChangeLog:
PR fortran/117225
* primary.cc (match_sym_complex_part): An UNSIGNED in
a complex part is an error.
gcc/testsuite/ChangeLog:
PR fortran/117225
* gfortran.dg/unsigned_38.f90: New test.
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index c11359a559b..e114bf1375f 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -1471,6 +1471,9 @@ match_sym_complex_part (gfc_expr **result)
goto error;
break;
+case BT_UNSIGNED:
+ goto error;
+
default:
gfc_internal_error ("gfc_match_sym_complex_part(): Bad type");
}
diff --git a/gcc/testsuite/gfortran.dg/unsigned_38.f90 b/gcc/testsuite/gfortran.dg/unsigned_38.f90
new file mode 100644
index 000..0d169ac92d3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unsigned_38.f90
@@ -0,0 +1,6 @@
+! { dg-do compile }
+! { dg-options "-funsigned" }
+program main
+ unsigned, parameter :: u = 7u
+ print *,mod(-(u+1u),u)
+end program main
Re: How to document intrinsics with UNSIGNED arguments...
Hi, >> As UNSIGNED has been booted off the F202Y list, I think calling it >> an extension at this time is fair. > > Looks good to me. And yes, calling it an extension is fair. I apologise, I had missed this piece of information. If UNSIGNED is not on track to becoming a feature in the next standard, is there really high value in implementing it in gfortran? Fortran as a language is moving from a past where it was a nightmare of incompatible extensions, into a more standard-based language. I personally think it is a good evolution. Big extensions (like Cray pointers) have shown in the past how hard they are to maintain in the long term: lots of dark corners that we never get fully right. Just some food for thought, maybe this has been discussed already, and I have missed it. Best, FX
8.260 STAT example fails if compiled with -std=f2008
My Fortran project is based on -std=f2008. The GNU Fortran (For GCC version 15.0.0) manual's 8.260 STAT example does not link if -std=f2008 is on the command line: gfortran -std=f2008 test_stat.f90; ./a.out The ld error is "undefined reference to `stat_'" This is with gfortran -version 12.2.0 and ld -version 2.40 Removing -std=f2008, and the example works as expected. George Wyche
Re: 8.260 STAT example fails if compiled with -std=f2008
Hi,
> My Fortran project is based on -std=f2008. The GNU Fortran (For GCC version
> 15.0.0) manual’s 8.260 STAT example does not link if -std=f2008 is on the
> command line: gfortran -std=f2008 test_stat.f90; ./a.out
> The ld error is “undefined reference to `stat_’”
Our doc (https://gcc.gnu.org/onlinedocs/gfortran/STAT.html) states: "Standard:
GNU extension”
If you compile with -std=f2008 (or any other -std value except gnu or legacy),
the STAT intrinsic is not available. Nor is CTIME. If you compile with -W
-Wall, you will get helpful warnings about this:
test_stat.f90:5:21:
5 | CALL STAT("/etc/passwd", buff, status)
| 1
Warning: The intrinsic 'stat' at (1) is not included in the selected standard
but a GNU Fortran extension and 'stat' will be treated as if declared EXTERNAL.
Use an appropriate '-std=' option or define '-fall-intrinsics' to allow this
intrinsic. [-Wintrinsics-st]
test_stat.f90:5:21: Warning: The intrinsic 'stat' at (1) is not included in the
selected standard but a GNU Fortran extension and 'stat' will be treated as if
declared EXTERNAL. Use an appropriate '-std=' option or define
'-fall-intrinsics' to allow this intrinsic. [-Wintrinsics-std]
test_stat.f90:5:50:
5 | CALL STAT("/etc/passwd", buff, status)
| 1
Warning: The intrinsic 'stat' at (1) is not included in the selected standard
but a GNU Fortran extension and 'stat' will be treated as if declared EXTERNAL.
Use an appropriate '-std=' option or define '-fall-intrinsics' to allow this
intrinsic. [-Wintrinsics-st]
test_stat.f90:16:75:
16 | WRITE (*, FMT="('Last access time:',T30, A19)")
CTIME(buff(9))
|
1
Warning: The intrinsic 'ctime' at (1) is not included in the selected standard
but a GNU Fortran extension and 'ctime' will be treated as if declared
EXTERNAL. Use an appropriate '-std=' option or define '-fall-intrinsics' to
allow this intrinsic. [-Wintrinsics-std]
test_stat.f90:16:75: Warning: The intrinsic 'ctime' at (1) is not included in
the selected standard but a GNU Fortran extension and 'ctime' will be treated
as if declared EXTERNAL. Use an appropriate '-std=' option or define
'-fall-intrinsics' to allow this intrinsic. [-Wintrinsics-std]
test_stat.f90:16:69:
16 | WRITE (*, FMT="('Last access time:',T30, A19)")
CTIME(buff(9))
| 1
Warning: The intrinsic 'ctime' at (1) is not included in the selected standard
but a GNU Fortran extension and 'ctime' will be treated as if declared
EXTERNAL. Use an appropriate '-std=' option or define '-fall-intrinsics' to
allow this intrinsic. [-Wintrinsics-std]
Best,
FX
Re: How to document intrinsics with UNSIGNED arguments...
Am 19.10.24 um 12:12 schrieb FX Coudert: Hi Thomas, Thanks for the clarification. I really hope that it makes it into the standard, > I do not disagree that it is useful, I just really wish we don’t have to maintain> long-term a lot of nonstandard (or worse, standard-incompatible) extensions. I agree there. I was very unpleasantly surprised when I learned that this had not made the WG5 work list. -std=legacy took a lot of ugly work over the years. But the context, > as you explain, is reassuring. I think so, too. And many thanks for the effort of implementation, I know it is far > from trivial. Thanks! Could you post a link to the specification that is currently implemented in gfortran? That is at https://j3-fortran.org/doc/year/24/24-116.txt . In the implementation, I actually made two extensions to it. The first one was to correct an oversight by myself, I had overlooked SUM and PRODUCT when, during the amendment process, I was asked for a list of intrinsics that should apply to UNSIGNED variables. The second is RANDOM_NUMBER - if people want random bits, be it for a simulated throw of dice or for other, non-cryptographic purposes, then this is an obvious candidate. i.e., if I understand correctly, your proposal + the amendments of the committee. Basically, yes. Best regards Thomas
Re: How to document intrinsics with UNSIGNED arguments...
Hi Thomas, Thanks for the clarification. I really hope that it makes it into the standard, I do not disagree that it is useful, I just really wish we don’t have to maintain long-term a lot of nonstandard (or worse, standard-incompatible) extensions. -std=legacy took a lot of ugly work over the years. But the context, as you explain, is reassuring. And many thanks for the effort of implementation, I know it is far from trivial. Could you post a link to the specification that is currently implemented in gfortran? i.e., if I understand correctly, your proposal + the amendments of the committee. Best, FX
