[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from Francois-Xavier Coudert --- (In reply to kargl from comment #8) > Big bummer. It is not possible to brute force a fix by > adding ~1700 lines to ieee/ieee_arithmetic.c. Definitely not. But a function conv_intrinsic_ieee_selected_real_kind() in trans-intrinsic.c will take care of the argument conversion. Assigned to me.
[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #10 from kargl at gcc dot gnu.org --- Created attachment 37215 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37215=edit simplify diff There is a run-on error, but someone else that cares can fix it.
[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- (In reply to kargl from comment #3) > To use IEEE_SELECTED_REAL_KIND in an initialization expression > with arbitrary integer kind type parameter requires a rewrite > of simplify_ieee_selected_real_kind in simplify.c. This isn't > too terribly hard. > > The fix for the use of IEEE_SELECTED_REAL_KIND as a generic > intrinsic subprogram in a non-initialization expression appears > to be much more difficult. It probably means that 125 explicit > interfaces need to be added to the IEEE_ARITHMETIC module. I > won't pursue this avenue. I was looking at this yesterday. It is implemented in ieee_arithmetic.F90 and I think can be done with generic type bound procedures. According to the comment in the code, the ieee_arithmetic.F90 file is generated, but it is not clear to me where the generation of the .F90 is specified.
[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #5) > (In reply to Jerry DeLisle from comment #4) > > I was looking at this yesterday. It is implemented in ieee_arithmetic.F90 > > and I think can be done with generic type bound procedures. > > There's also a simplifier for the compile-time version. See comment 3. The simplifier is fairly easy to rewrite; although it does take some time to work out the semantics of keyword usage. > > According to > > the comment in the code, the ieee_arithmetic.F90 file is generated, but it > > is not clear to me where the generation of the .F90 is specified. > > It is not automatically generated. I believe that one should force type conversion in external_spec_function. All valid values fit in a REAL(4). The only problem might be integer wrap-around semantics.
[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 --- Comment #5 from Francois-Xavier Coudert --- (In reply to Jerry DeLisle from comment #4) > I was looking at this yesterday. It is implemented in ieee_arithmetic.F90 > and I think can be done with generic type bound procedures. There's also a simplifier for the compile-time version. > According to > the comment in the code, the ieee_arithmetic.F90 file is generated, but it > is not clear to me where the generation of the .F90 is specified. It is not automatically generated.
[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 --- Comment #7 from kargl at gcc dot gnu.org --- > I believe that one should force type conversion in > external_spec_function. All valid values fit in > a REAL(4). The only problem might be integer > wrap-around semantics. Bummer that doesn't work. :(
[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #7) > > I believe that one should force type conversion in > > external_spec_function. All valid values fit in > > a REAL(4). The only problem might be integer > > wrap-around semantics. > > Bummer that doesn't work. :( Big bummer. It is not possible to brute force a fix by adding ~1700 lines to ieee/ieee_arithmetic.c.
[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Summary|ICE when compiling some |IEEE_SELECTED_REAL_KIND is |tests in gfortran.dg/ieee/ |not generic |with -fdefault-integer-8 or | |-finteger-4-integer-8 | --- Comment #3 from kargl at gcc dot gnu.org --- To use IEEE_SELECTED_REAL_KIND in an initialization expression with arbitrary integer kind type parameter requires a rewrite of simplify_ieee_selected_real_kind in simplify.c. This isn't too terribly hard. The fix for the use of IEEE_SELECTED_REAL_KIND as a generic intrinsic subprogram in a non-initialization expression appears to be much more difficult. It probably means that 125 explicit interfaces need to be added to the IEEE_ARITHMETIC module. I won't pursue this avenue.
