Re: flags for different fortran compilers

[Eve-Marie Devaliere]

>> In their original setup, they had support for the following compilers: 
>> xlf95, f95, f90 (SGI IRIX64 MIPSpro, Absoft and  HP-UX), gfortran,
>> ifort, pgf95, lf95, g95.
> Well, maybe you can then fill the table below of possible flags, and
> we can try writing macros for them.
Oh that would be great, and I'd be happy to help... I just don't know
much about fortran unfortunately which makes my task complicated but I
am a fast learner ;-) and willing to search...
>
> If your autoconf is installed in $prefix/bin, then the source of that is
> usually in $prefix/share/autoconf/autoconf/fortran.m4.
Great! thx, found it, I will be looking into that.
>
> Here's a set of notes about flags I could find from looking at manuals
> (cf. <http://www.mail-archive.com/address@hidden/msg16210.html>):
Thanks
I found this too that should be useful..
http://www.fortran-2000.com/ArnaudRecipes/CompilerTricks.html#CompTable_fortran
> - Endian conversion:
>   GCC: -fconvert=big-endian
>   Portland: -byteswapio  -Mbyteswapio (in conjunction with AC_C_BIGENDIAN?)
>   Intel: F_UFMTENDIAN={big|little} environment variable setting
> http://www.tacc.utexas.edu/services/userguides/intel8/fc/f_ug2/cmp_endi.htm
>   HP: -convert big_endian
>      FORT_CONVERT{,<unit>}=Big_Endian environment variables
hmmm, from the rules.macro file I have -convert big_endian for intel ;
they also set "ENDIAN=Little_Endian"
I am hoping to meet with the author of the original install about the
flags setup sometimes soon so that should give me a better idea on what
we need....
for now for the big endian conversion I had (for intel ifort)
# Deal with endianness
AC_C_BIGENDIAN
if test "x$ac_cv_c_bigendian" = "xno"; then # convert to big endian
  FCFLAGS="$FCFLAGS -convert big_endian"
fi
I have seen posts complaining about that too, but it would seem that we
could have a macro that uses AC_C_BIGENDIAN and return the correct
flag??(which may be what you meant with 'in conjunction with
AC_C_BIGENDIAN?'
>
> - Trap handling:
>   GCC: -ffpe-trap=overflow,zero[,invalid,underflow,precision,denormal]
>   Portland: -Ktrap=ovf,divz[,inv,unf,inexact,denorm,fp]
>             -Kieee
>             -Ktrap
>   HP: +FP[V][Z][O][U][I][D]
>     (upper-case enables, lower-case disables
>      invalid fp ops, divide by zero, overflow, underflow, inexact)
>   Lahey: -[n]trap [d][i][o][u]  (divide-by-zero, invalid op. overflow, 
> underflow)
>   IBM: -qflttrap=zerodivide:enable -qsigtrap
>        -qnoflttrap
>         (zerodivide, underflow, overflow, invalid, inexact, enable,
>         imprecise, nanq)
>         -qflttrap without suboptions is equivalent to
>         -qflttrap=inv:inex:ov:und:zero
>         -qsigtrap
>
>    Sun/Oracle: -ftrap=%all,no%inexact
>      %all, %none, common, [no%]invalid, [no%]overflow, [no%]underflow,
>      %[no%]division, [no%]inexact.
>     -ftrap=common is a macro for -ftrap=invalid,overflow,division.
this one is scary...
> - Array bounds checking:
>    GCC: -fbounds-check
>    Intel: -check bounds  or -CB
>    Portland: -Mbounds
>    HP: +check=all  -check_bounds/-nocheck_bounds
>    IBM: -qcheck  -C
>    Sun/Oracle: -C
>    SGI MIPSpro: -C -check_bounds
>
>
> Array bounds checking would seem fairly easy to cover more or less like
> below (modeled more or less like the other tests in fortran.m4); 
wow you already wrote a new macro! :) that;s impressive! :)

> the
> biggest issue would be how to effectively test that array bounds
> checking is actually working: the test source should fail only when
> bounds checking is in place, but pass otherwise.  For now I've merely
> taken some example source found on the net, but that can probably be
> made shorter, and should ideally conform to both fixed-format as well as
> free-format (or adjust itself according to whether AC_FC_FREE_FORMAT has
> been called previously or not).
>
> With these things fixed, the macro can IMVHO go into Autoconf.
>
> Cheers,
> Ralf
>
>
Thank you so  much! I will have a deeper look at all this!... and
probably pull some hair out... ;-)
Cheers,
Eve-Marie