[Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)

["harper at msor dot vuw.ac.nz" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871

--- Comment #4 from harper at msor dot vuw.ac.nz ---
The reason I sent that bug report is that I had read the manual and
found that -freal-4-real-16 makes the available real kinds 8, 10, 16.
The Fortran standard says selected_real_kind(1) must give the kind with
the smallest available decimal precision that has precison at least 1. 
In the circumstances that is kind 8. The manual refers to promotion of
REAL(KIND=M) entities. Selected_real_kind is an integer entity not a
real one.

On Wed, 10 Jul 2013, dominiq at lps dot ens.fr wrote:

> Date: Wed, 10 Jul 2013 13:07:40 +0000
> From: dominiq at lps dot ens.fr <gcc-bugzilla@gcc.gnu.org>
> To: john.harper@vuw.ac.nz
> Subject: [Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for
>     selected_real_kind(1)
> Resent-Date: Wed, 10 Jul 2013 13:08:02 +0000
> Resent-From: <john.harper@vuw.ac.nz>
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
>
> Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|UNCONFIRMED                 |RESOLVED
>         Resolution|---                         |INVALID
>
> --- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>> gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with
>> selected_real_kind(1) but it ought to give real(8) because that is
>> the smallest decimal precision available with that compiler option.
>> Same problem with -freal-4-real-10 giving real(10) instead of real(8). ...
>
> Why are you expecting that? The manual says:
>
> -freal-4-real-8
> -freal-4-real-10
> -freal-8-real-4
> -freal-8-real-10
> -freal-8-real-16
> Promote all REAL(KIND=M) entities to REAL(KIND=N) entities. If REAL(KIND=N) is
> unavailable, then an error will be issued. All other real kind types are
> unaffected by this option. These options should be used with care and may not
> be suitable for your codes. Areas of possible concern include calls to external
> procedures, alignment in EQUIVALENCE and/or COMMON, generic interfaces, BOZ
> literal constant conversion, and I/O. Inspection of the intermediate
> representation of the translated Fortran code, produced by
> -fdump-tree-original, is suggested.
>
> and your example does exactly that: Closing as INVALID.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>
>
>


-- John Harper, School of Mathematics Statistics and Operations Research
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045