NAG compiler stumbles over c_default_float

[Juergen Reuter]

The configure setup with --with-precision=quadruple leads to c_default_float = -1, c_default_complex = -1 for NAG. model_data.f90 compilation stumbles over this.

[Juergen Reuter]

What seems to be missing is the test for c_long_double and c_long_double_complex that was assigned for precision better than c_double in the case of C types.

[Juergen Reuter]

The following happens here: TO's script correctly detected the existence of quadruple precision in Fortran for nagger, and correctly detected that there is no c_long_double in nagfor. What shall we do!? Please comment!!! This leaves basically no choice as to disable quadruple precision for nagfor as the O'Mega interface and many other things rely on c_default_float. Please comment!

[Bijan Chokoufe Nejad]

Well, isn't c_long_double the analogue of extended precision, which is not supported by nagfor? On x86 it should be only 80bit. Is there a true 128 bit float available in nagfor for C?

[Juergen Reuter]

Funnily, it's not. c_long_double is (per C standard, guess it's C99, not C89) only "more precise" than c_double. For gcc/gfortran, BACN, you are right, there c_long_double corresponds to extended and c_float128 to quadruple, but for icc/ifort c_long_double corresponds to quadruple precision. For nagfor, none of these two types exists.

[Juergen Reuter]

To summarize our general discussions: we all agree that quadruple precision is not really important for the NAG compiler, on the other hand our way of dealing with libraries demands the presence of the C precision corresponding to the requested Fortran precision. So TO promised to extend the configure check to the case such that both the Fortran and (bind) C precision type have to be present in order to let configure pass.

[Juergen Reuter]

This is caught now in r7124. For nagfor 'quadruple' is vetoed because of the missing corresponding C type with the same precision.