This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [fortran,patch] Initial Fortran 2008 support
- From: Tobias Burnus <burnus at net-b dot de>
- To: FX Coudert <fxcoudert at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 03 Mar 2008 15:14:23 +0100
- Subject: Re: [fortran,patch] Initial Fortran 2008 support
- References: <B74ED0BD-6377-4EB4-AF14-EB0F6FE83BA6@gmail.com>
FX Coudert wrote:
This patch opens the Fortran 2008 game.
-- documenting our Fortran 2008 support in the doc, referring to the
current draft and WG5 webpage; mentioning that, until the final
standard is published (or, at least voted), our F2008 support follows
the drafts and may be expected to change without warnings or
compatibility, if the committee changes their mind about something
It should not be too bad as we have now a Candiate Draft instead of only
a Working Draft; I think it passed the J3 voting. It still needs to go
through WG5 and then through SC22, but I do not expect major changes.
-- allowing empty CONTAINS in Fortran 2008 mode, not just as a GNU
extension
You could also update the following in fortran/decl.c:
3999: /* Fortran 2008 draft allows BIND(C) for internal procedures. */
4000- if (gfc_current_state () == COMP_CONTAINS
4001- && sym->ns->proc_name->attr.flavor != FL_MODULE
4002- && gfc_notify_std (GFC_STD_GNU, "Extension: BIND(C) attribute
at %L "
4003- "may not be specified for an internal
procedure",
--
4733: /* The following is allowed in the Fortran 2008 draft. */
4734- if (gfc_current_state () == COMP_CONTAINS
4735- && sym->ns->proc_name->attr.flavor != FL_MODULE
4736- && gfc_notify_std (GFC_STD_GNU, "Extension: BIND(C) attribute at "
4737- "%L may not be specified for an internal
procedure",
But it can be done after the patch is in.
There are limitations to this patch
-- No front-end simplification for ERFC_SCALED. I believe it should
have one, as it can be used in initialization expressions (or can it
not?). However, it's a long way from trivial. Moreover, ERF and ERFC
don't have one either, so I don't feel so bad :)
Adding ERF and ERFC sound simple as we have mpfr_erf and mpfr_erfc.
Somehow I think having erfc_scaled should not be too difficult; I think
we need only to calculate erf_scaled = exp(x**2)*erfc(x). If the mpfr
precision for that is high enough, the result should be OK, shouldn't it?
-- The new testcases don't check that we accept/reject correctly the
different intrinsics based on the -std option passed by the user.
That's because I discovered that the front-end actually doesn't check
standard compliance of intrinsics in most cases! I supposed it's
something widely known that I had never realized, and there probably
is a PR about it. Daniel, I think at some point you were working on
that, is it still the case?
Try using -std=... -Wnonstd-intrinsics.
It's regtested on x86_64-linux and includes testcases for all new
features. (They may be expanded upon later, for example when
intrinsics can be checked against the -std option.) OK to commit?
I'm not sure I have not overlooked anything, but it looks OK.
Thanks for the patch.
Tobias
PS: Can you also sent a patch for
http://gcc.gnu.org/gcc-4.4/changes.html and update
http://gcc.gnu.org/wiki/GFortran#news ?
PPS: Another command which should be added at some point is:
EXECUTE_COMMAND_LINE (COMMAND[, WAIT, EXITSTAT, CMDSTAT, CMDMSG])
This should be relatively easy and provides a often missed
functionality. (Unless one uses the SYSTEM vendor intrinsic). I saw that
you were already studying this (-> comp.lang.fortran).
STORAGE_SIZE(A[, KIND]) does the same as SIZEOF and should thus also be
simple.
Other intrinsics: IS_CONTIGUOUS(A), bit-operating intrinsics such as
LEADZ(I) [= leading zero bits] and MASKL.
And in ISO_FORTRAN_ENV:
- CHARACTER_KINDS
- COMPILER_OPTIONS
- COMPILER_VERSION
- INTEGER_KINDS
- INT8, INT16, INT32 and INT64
(cf. C_INT8 etc in ISO_C_BINDING)
- LOGICAL_KINDS
- REAL_KINDS
- IOSTAT_INQUIRE_INTERNAL_UNIT
- REAL32, REAL64, REAL128