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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jul 11, 2013 at 10:30:04PM +0000, harper at msor dot vuw.ac.nz wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
> 
> --- Comment #5 from harper at msor dot vuw.ac.nz ---
> I have now found two more oddities of type promotion but I don't claim 
> that these are gfortran bugs, only that the mmanual might need amending.
> 
> Oddity 1. Although -freal-4-real-8 does what the manual implies with
> the program below (making the real kinds 8,10,16 on an x86_64 system),
> -fdefault-real-8 keeps the available kinds at 4,8,10,16 but merely
> changes the defaults. I suggest that the following sentence 
> be added to the manual sewction on -fdefault-real-8 at the end:
> 
> If "REAL(KIND=4)" is a real type available with no -f options, then it
> remains available with -fdefault-real-8 though not with -freal-4-real-8.
> 
> Oddity 2. If one uses -fdefault-double-8 in a system where default real
> was 4 bytes wide then one must also use -fdefault-real-8. The manual
> entries for -fdefault-double-8 and -fdefault-real-8 are both silent 
> on what happens if -fdefault-double-8 is given but -fdefault-real-8 is 
> not. I won't suggest an amendment here because I don't know what happens 
> in a system whose default real with no -f options was 8 bytes wide.

I am not at all surprised by your findings.  I would personally
like to deprecate the -fdefault-* options.  These options do
not necessarily do what a user may expect.  The options require
care with EQUIVALENCE, COMMON, and may even require one to
rebuild the runtime library (if one is doing double precision
IO).  Most users don't understand the limitations, and simply
use these options as a quick-n-dirty way to port single
precision code to double precision.  Unfortunately, the -fdefault-*
options are too ingrained into peoples brains.

The -freal-* options were a later attempt to try to fix
the deficiencies with the -fdefault-* options.  These 
family of option should not be mixed.  I suppose this
should be documented.

Reply via email to