[netCDF #FST-907593]: netcdf-4.0 snapshot 2008100702: Fortran

> Hi Ed!
>
> >> --- netcdf-4.0.1-beta2-snapshot2009010202/acinclude.m4.orig
2008-10-06 19:08:25.000000000 +0000
> >> +++ netcdf-4.0.1-beta2-snapshot2009010202/acinclude.m4     2009-01-05
12:49:13.610052000 +0000
> >> @@ -420,9 +420,9 @@
> >> UD_CHECK_CTYPE_FORTRAN(real, float double, REAL)
> >> UD_CHECK_CTYPE_FORTRAN(doubleprecision, double float, DOUBLEPRECISION)
> >>
> >> -  UD_CHECK_FORTRAN_NCTYPE(NCBYTE_T, byte integer*1 integer, byte)
> >> +  UD_CHECK_FORTRAN_NCTYPE(NCBYTE_T, byte integer*1 "integer(kind=1)"
"integer(selected_int_kind(2))" integer, byte)
> >>
> >> -  UD_CHECK_FORTRAN_NCTYPE(NCSHORT_T, integer*2 integer, short)
> >> +  UD_CHECK_FORTRAN_NCTYPE(NCSHORT_T, integer*2 "integer(kind=2)"
"integer(selected_int_kind(4))" integer, short)
> >> dnl        UD_CHECK_FORTRAN_CTYPE(NF_SHORT_T, $NCSHORT_T, short, SHRT_MIN,
SHRT_MAX)
> >>
> >> dnl        UD_CHECK_FORTRAN_NCTYPE(NCLONG_T, integer*4 integer, long)
> >>
> >
> > Howdy Harald!
> >
> > The challenge with this patch is that it breaks the build for F77-only
situations. That is, a F77 compiler is not going to be able to figure out
selected_int_kind(4).
>
> I thought that I understood the logics right.  configure should first
> try integer*2, when it fails it will try integer(kind=2), and then
> integer(selected_int_kind(4)), and finally integer.
> An F77 compiler will probably accept integer*2, and if not then integer.
> An F90 compiler may reject integer*2 because it is illegal in F90,
> but will accept one of the next variants.
>
> The aim is to properly match the C and Fortran types.  With the original
> checks, a strict F90 compiler would always reject integer*2 and only use
> integer, leading to failures in the Fortran self-test.  This is the case
> for the NEC SX compiler.
>
> So I guess you have an F77 compiler where you need a different solution.
>
> > I guess that the ideal would be to see if the fortran compiler is a F90
one, and, if so, use your patched lines, otherwise use the existing lines.
> >
> > I am working on that now, but if you have any other thoughts about this,
please let me know.
>
> Well, I had hoped that my solution was simple and clever enough.
> Maybe it isn't.  Actually I can even conceive a situation where
> integer(kind=..) leads to an unexpected result (with the NAG compiler),
> but integer(selected_int_kind(...)) never should.
>
> Regards,
> Harald

No, sorry, I just didn't see that! You are plenty clever but I am just a
programmer they keep in a cave! ;-)

I have checked in this change and it has passed the first round of tests and a
snapshot is available here:
http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/

Tonight around midnight the daily snapshot will subject this to more testing.

I am also adding g77-only to my main test machine so I can be sure not to break
it.

If you want to wait until tomorrow to try this, you can make sure the test page
is not showing too much red first.

Thanks for your patience Harald!

Ed


Ticket Details
===================
Ticket ID: FST-907593
Department: Support netCDF
Priority: Critical
Status: Closed