This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [fortran,patch] Initial Fortran 2008 support

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.


PS: Can you also sent a patch for and update ?

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.

- INT8, INT16, INT32 and INT64
(cf. C_INT8 etc in ISO_C_BINDING)
- REAL32, REAL64, REAL128

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]