Hi,
>> Why looping over fields? The class type is a simple type with only one
>> member (and it should be an integer, we can assert that).
>
> I wanted to make sure it has exactly one field.
> The ieee_arithmetic.F90 module in libgfortran surely does that, but I've
> been worrying about some user overriding that module with something
> different.
In Fortran world it would be a rare and crazy thing to do, but I see. Could you
add a comment (pointing out to the type definition in libgfortran)?
> The libgfortran version had default: label:
> switch (type) \
> { \
> case IEEE_SIGNALING_NAN: \
> return __builtin_nans ## SUFFIX (""); \
> case IEEE_QUIET_NAN: \
> return __builtin_nan ## SUFFIX (""); \
> case IEEE_NEGATIVE_INF: \
> return - __builtin_inf ## SUFFIX (); \
> case IEEE_NEGATIVE_NORMAL: \
> return -42; \
> case IEEE_NEGATIVE_DENORMAL: \
> return -(GFC_REAL_ ## TYPE ## _TINY) / 2; \
> case IEEE_NEGATIVE_ZERO: \
> return -(GFC_REAL_ ## TYPE) 0; \
> case IEEE_POSITIVE_ZERO: \
> return 0; \
> case IEEE_POSITIVE_DENORMAL: \
> return (GFC_REAL_ ## TYPE ## _TINY) / 2; \
> case IEEE_POSITIVE_NORMAL: \
> return 42; \
> case IEEE_POSITIVE_INF: \
> return __builtin_inf ## SUFFIX (); \
> default: \
> return 0; \
> } \
> and I've tried to traslate that into what it generates.
OK, that makes sense. But:
> There is at least the IEEE_OTHER_VALUE (aka 0) value
> that isn't covered in the switch, but it is just an integer
> under the hood, so it could have any other value.
I think I originally included the default for IEEE_OTHER_VALUE, but the
standard says IEEE_OTHER_VALUE as an argument to IEE_VALUE is not allowed. If
removing the default would make the generated code shorter, I suggest we do it;
otherwise let’s keep it.
With those two caveats, the patch is OK. We shouldn’t touch the library code
for now, but when the patch is committed we can add the removal of IEEE_VALUE
and IEEE_CLASS from the library to this list:
https://gcc.gnu.org/wiki/LibgfortranAbiCleanup
FX
