https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #13 from Jürgen Reuter <juergen.reuter at desy dot de> --- (In reply to Steve Kargl from comment #12) > On Wed, Feb 08, 2017 at 08:39:43PM +0000, juergen.reuter at desy dot de > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 > > > > --- Comment #11 from Jürgen Reuter <juergen.reuter at desy dot de> --- > > (In reply to Steve Kargl from comment #10) > > > On Wed, Feb 08, 2017 at 07:32:53PM +0000, juergen.reuter at desy dot de > > > > > which may lead to conforming code suddening becoming nonconforming > > > due to violation of storage association. > > > > Interesting. Actually, we are not setting any flags using configure options, > > except for those that libtool sets for us as default (-g -O2). > > In our code, we use everywhere variables defined as > > real(kind=default) :: foo > > complex(kind=default) :: foo, > > and then we use a module kinds.f90 with the definitions: > > !!! available REAL kinds ! prec. ! ISO ! C > > integer, parameter :: single = 4 ! 1.. 6 ! real32 ! c_float > > integer, parameter :: double = 8 ! 7..15 ! real64 ! c_double > > integer, parameter :: extended = 10 ! 16..18 ! real128 ! c_long_double > > integer, parameter :: quadruple = 16 ! 19..33 ! -1 ! c_float128 > > > > When configuring with no flag or --with-precision=double, then in this file > > kind.f90 we > > set > > > > integer, parameter :: default = double > > configuring with --with-precision=extended sets > > integer, parameter :: default = extended > > and configuring with --with-precision=quadruple sets > > integer, parameter :: default = quadruple > > > > The integers above are determined during configure, depending on the > > compiler, > > and are always the same, only default is set depending on the configure > > option. > > The above should be fine. This then suggests that you may have > an unstable algorithm. Are literal constants properly decolorated, > e.g., 1.e0_default? Are kind types included in REAL and CMPLX, > e.g., real(1.e0, default) and cmplx(1, 2, default)? > > Without a reduced testcase, it will be difficult to track down > the problem. > > > Indeed, it looks as if kind=10 would be real128, but as you said this > > is wrong and was fixed by you (I guess it is not yet in the trunk, as > > of r245197 at least). > > You need r245255 to get the fix. There is, however, some discussion > as to whether I should revert the change. Ah ok. Why? Because it is too late for anything than regression fixes now? As far as we can seen all our constants have valid and consistent kind type. Any try to reduce the code, hasn't worked. Putting print statements there are trying to pass the corresponding routine to an output routine to access it without the heavy machinery of the whole program let's the problem go away.
