[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

sgk at troutmask dot apl.washington.edu gcc-bugzilla@gcc.gnu.org
Wed Feb 8 20:15:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Feb 08, 2017 at 07:32:53PM +0000, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
> 
> --- Comment #8 from Jürgen Reuter <juergen.reuter at desy dot de> ---
> We are defining a real(default) which could be 4, 8, 10 or 16, as these are the
> real kinds supported by gfortran. If default = 10, this happens, but this is
> not per se forbidden, is it?
> 

I don't know.  Spent 15-20 minutes looking through the whizard
svn repository, but can't find what --with-precision=extended
actually does.  I assume that this is causing compiler options
to be set.

program foo

   use iso_fortran_env

   implicit none

   character(len=20), parameter :: fmt = '(I2,1X,I3,1X,I2)'

   real(real_kinds(1)) a
   real(real_kinds(2)) b
   real(real_kinds(3)) c
   real(real_kinds(4)) d
   real(real32) e
   real(real64) f
   real(real128) g

   write(*,fmt) kind(a), digits(a), precision(a)
   write(*,fmt) kind(b), digits(b), precision(b)
   write(*,fmt) kind(c), digits(c), precision(c)
   write(*,fmt) kind(d), digits(d), precision(d)
   write(*,*)
   write(*,fmt) kind(e), digits(e), precision(e)
   write(*,fmt) kind(f), digits(f), precision(f)
   write(*,fmt) kind(g), digits(g), precision(g)

end program foo

With trunk on x86_64-*-freebsd with my patch to fix REAL128,

% gfc7 -o z a.f90 && ./z
 4  24  6
 8  53 15
10  64 18
16 113 33

 4  24  6
 8  53 15
16 113 33

With gfortran 6.3.0 on x86_64-*-freebsd without my patch to fix REAL128

% gfortran6 -static -o z a.f90 && ./z
 4  24  6
 8  53 15
10  64 18
16 113 33

 4  24  6
 8  53 15
10  64 18

If --with-precision=extended is setting -freal-4-real-10, you get

%  gfc7 -o z a.f90 -freal-4-real-10 && ./z
10  64 18
 8  53 15
10  64 18
16 113 33

10  64 18
 8  53 15
16 113 33

which may lead to conforming code suddening becoming nonconforming
due to violation of storage association.


More information about the Gcc-bugs mailing list