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.
