[Plplot-devel] Fortran standard compliance checking does not work for gfortran

[Alan W. Irwin]

Hi Arjen:

I had to rework (commit 58dc757) the suggestion in README.developers
about the recommended gfortran compiler options because the prior
suggestion

export FFLAGS='-std=f95 -O3 -fall-intrinsics -fvisibility=hidden -pedantic -Wall -Wextra'

did not work with our new fortran binding.

(As an aside, in my tests I dropped -fvisibility=hidden because I
believe that makes no sense for Fortran code. I also dropped
-fall-intrinsics since I prefer using Wintrinsics-std which is
automatically deployed with -Wall if -fall-intrinsics is not
specified.) So here are the actual flags I tried.

1. export FFLAGS='-O3 -std=f95 -pedantic -Wall -Wextra'

Those options generated a build error (as expected) because the
Fortran 95 standard does not include support for the ISO_C_BINDING
module that we use to implement the new fortran binding.

2. export FFLAGS='-O3 -std=f2003 -pedantic -Wall -Wextra'

Those options generated the following type of build error:

included_plplot_real_interfaces.f90:2601.25:
Included at /home/software/plplot/HEAD/plplot.git/bindings/f95/plplot_double.f90:117:

c_loc(plotentries), size(plotentries, kind=private_plint) )
1
Error: Fortran 2008: Array of interoperable type at (1) to C_LOC which is nonallocatable and neither assumed size nor explicit size

for what I consider to be a spurious reason (see the revised
README.developers for further discussion).

3. export FFLAGS='-O3 -std=f2008 -pedantic -Wall -Wextra'

got rid of the above type of error message, but also generated a
whole new set of build errors.

4. export FFLAGS='-O3 -Wall -Wextra'

does work without any build errors so this is now what I recommend
in README.developers.

To summarize, if you discovered a standards-compliant change
to our new Fortran binding implementation that would allow use of

export FFLAGS='-O3 -std=f2003 -pedantic -Wall -Wextra'

with gfortran, then that would allow our users/developers to at least
do minimal standards compliance checking with gfortran. But if you
feel that is too much trouble and/or the fix would obfuscate our
fortran binding code too much simply to quiet a gfortran build error
that is likely spurious, then I am content with the current
recommendation

export FFLAGS='-O3 -Wall -Wextra'

Of course, the (significant) downside of the current recommendation is
it means our users/developers cannot check Fortran standards
compliance with gfortran and must rely on NAG instead for such
checking.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Alan W. Irwin]

Post by Alan W. Irwin
To summarize, if you discovered a standards-compliant change
to our new Fortran binding implementation that would allow use of
export FFLAGS='-O3 -std=f2003 -pedantic -Wall -Wextra'
with gfortran, then that would allow our users/developers to at least
do minimal standards compliance checking with gfortran. But if you
feel that is too much trouble and/or the fix would obfuscate our
fortran binding code too much simply to quiet a gfortran build error
that is likely spurious, then I am content with the current
recommendation
export FFLAGS='-O3 -Wall -Wextra'
Of course, the (significant) downside of the current recommendation is
it means our users/developers cannot check Fortran standards
compliance with gfortran and must rely on NAG instead for such
checking.

Hi Arjen:

After thinking about this some more I have become concerned that my
gfortran test results are correct, and thus our code is not compliant
with the pure Fortran 2003 standard nor the pure Fortran 2008
standard. For example, you could get those test results if our code is
compliant with a mixture of the Fortran 2003 and Fortran 2008
standards, but with parts not compatible with pure Fortran 2003 and
parts not compatible with pure Fortran 2008.

For now, I would prefer to stick to pure Fortran 2003 on the principle
that that standard is likely better supported by compilers than
Fortran 2008. So if the NAG compiler has options equivalent to
gfortran's -std=f2003 -pedantic to check compliance with the pure
Fortran 2003 standard, it may reveal exactly the same issue discovered
by gfortran, and that would be strong motivation for addressing that
issue.

By the way, the "f95" name is now obviously a misleading term
describing our Fortran binding and examples. Is it time to go through
our entire source tree (including documentation and build system) and
replace _all_ references to "f95" (e.g., bindings/f95, examples/f95,
ENABLE_f95) by the "fortran" equivalent (e.g., bindings/fortran,
examples/fortran, ENABLE_fortran)? I would prefer to replace the
"f95" name by "fortran" rather than "f2003" since that would allow us
to move to pure Fortran 2008 compliance when the time comes without
any further name changes.

Alan

Post by Alan W. Irwin
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
https://lists.sourceforge.net/lists/listinfo/plplot-devel

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Arjen Markus]

Hi Alan,



Hm, I will have to look into this a bit closer - this week is a trifle crowded though, so it will take me some time to get around to it. I agree, as per your later post (got caught by the spam filter for reasons best known to itself), that "f95" is not the correct keyword anymore. So that is indeed another thing to do. Perhaps I should consult the gfortran mailing list about the details.



Regards,



Arjen

-----Original Message-----
Sent: Saturday, April 15, 2017 5:55 AM
To: Arjen Markus; PLplot development list
Subject: Fortran standard compliance checking does not work for gfortran
I had to rework (commit 58dc757) the suggestion in README.developers about the
recommended gfortran compiler options because the prior suggestion
export FFLAGS='-std=f95 -O3 -fall-intrinsics -fvisibility=hidden -pedantic -Wall -
Wextra'
did not work with our new fortran binding.
(As an aside, in my tests I dropped -fvisibility=hidden because I believe that makes
no sense for Fortran code. I also dropped -fall-intrinsics since I prefer using
Wintrinsics-std which is automatically deployed with -Wall if -fall-intrinsics is not
specified.) So here are the actual flags I tried.
1. export FFLAGS='-O3 -std=f95 -pedantic -Wall -Wextra'
Those options generated a build error (as expected) because the Fortran 95
standard does not include support for the ISO_C_BINDING module that we use to
implement the new fortran binding.
2. export FFLAGS='-O3 -std=f2003 -pedantic -Wall -Wextra'
Included at
c_loc(plotentries), size(plotentries, kind=private_plint) )
1
Error: Fortran 2008: Array of interoperable type at (1) to C_LOC which is
nonallocatable and neither assumed size nor explicit size
for what I consider to be a spurious reason (see the revised README.developers
for further discussion).
3. export FFLAGS='-O3 -std=f2008 -pedantic -Wall -Wextra'
got rid of the above type of error message, but also generated a whole new set of
build errors.
4. export FFLAGS='-O3 -Wall -Wextra'
does work without any build errors so this is now what I recommend in
README.developers.
To summarize, if you discovered a standards-compliant change to our new Fortran
binding implementation that would allow use of
export FFLAGS='-O3 -std=f2003 -pedantic -Wall -Wextra'
with gfortran, then that would allow our users/developers to at least do minimal
standards compliance checking with gfortran. But if you feel that is too much trouble
and/or the fix would obfuscate our fortran binding code too much simply to quiet a
gfortran build error that is likely spurious, then I am content with the current
recommendation
export FFLAGS='-O3 -Wall -Wextra'
Of course, the (significant) downside of the current recommendation is it means our
users/developers cannot check Fortran standards compliance with gfortran and
must rely on NAG instead for such checking.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for
stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
PLplot scientific plotting software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.