Re: [fortran,patch] Initial Fortran 2008 support

[Tobias Burnus <burnus at net-b dot de>]

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