https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #12 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> --- (In reply to kargl from comment #11) > One of these is no like the others. Yes, the behavior is documented, > and the unlike other result is likely the result that is no desired > unless the user enjoys chancing numerical precision issues. $ cat foo.f90 program foo implicit none real(kind=4) :: a, b real :: x, y x = 1. y = 3.14159 a = 1._4 b = 3.14159_4 print *, a / b print *, x/ y end program foo $ gfortran foo.f90 && ./a.out 0.318310142 0.318310142 $ gfortran foo.f90 -fdefault-real-8 && ./a.out 0.318310142 0.31831015504887655 $ gfortran foo.f90 -freal-4-real-8 && ./a.out 0.31831015504887655 0.31831015504887655 Looks pretty consistent for me if proper types are used to match the kinds used in constants like 3.14159_4. The same would apply for plain DOUBLE PRECISION and 3.14159D numerical constants. Is this the only catch for -fdefault-* family of options? > You need to use -fdefault-real-8 -fdefault-double-8 when compiling both > files. How is the 2nd invocation of gfortran to know that your first > invocation of gfortran used incompatible options? Incompatible how? As far as executable linking is concerned the final link could be performed by plain ld(1) on both foo.o and bar.o (or foo.o libbar.a) provided that user links in the libgfortran.so too. The -fdump-tree-original -c outputs on both sources indicate that dump trees are identical (including calls to _gfortran_reshape_r8() in libgfortran.so).
