-fdefault-integer-8 again!-(

[Dominique Dhumieres]

Steve,

> An even more reasonable response is 'Don't expect -fdefault-*-8 to work
> with the testsuite.'  The testsuite is designed to test bug fixes.  If
> you use -fdefault-*-8, then you get what you deserve.
> 
> Check the history of the -fdefault-*-8 options.  I'm the person that got
> rid of the broken -r8, -i8, and some other option that escapes me, and
> got the -fdefault-*-8 options in some sort of working condition.

> These options are dangerous because most people don't understand what
> they can and cannot do.

I won't say they are helped by the documentation (see below).

> That being said, the testsuite is design to test specific bug fixes.  If
> a test fails when given a -fdefault-*-8 option and someone fixes that
> test to work with that option, do they unintentionally break what the
> test was actually testing?

Good point! But is not the reviewing process supposed to handle that?

Practical exercise with the following examples:

(1) replacing

  integer ix, iy

by

  integer(4) ix, iy

in gcc/testsuite/gfortran.dg/nearest_1.f90

! { dg-do run }
! { dg-options "-O0 -ffloat-store" }
! PR fortran/27021
! Original code submitted by Dominique d'Humieres
! Converted to Dejagnu for the testsuite by Steven G. Kargl
program chop
  integer ix, iy
  real o, t, td, tu, x, y
  o = 1.
  t = tiny(o)
  td = nearest(t,-1.0)
  x = td/2.0
  y = nearest(tiny(o),-1.0)/2.0
  ix = transfer(x,ix)
  iy = transfer(y,iy)
  if (ix /= iy) call abort
end program chop

(2) in gcc/testsuite/gfortran.dg/no_range_check_1.f90 (nonstandard 
conforming test), replacing

! { dg-do run }
! { dg-options "-fno-range-check -O0" }
!
! This testcase arose from PR 31262
  integer :: a
  integer(kind=8) :: b
  a = -3
  b = -huge(b) / 7
  a = a ** 73
  b = 7894_8 * b - 78941_8
  if ((-3)**73 /= a) call abort
  if (7894_8 * (-huge(b) / 7) - 78941_8 /= b) call abort

  a = 1234789786453123
  if (a - 1234789786453123 /= a - (-426244989)) call abort
  end

by

! { dg-do run }
! { dg-options "-fno-range-check -O0" }
!
! This testcase arose from PR 31262
  integer(kind=4) :: a
  integer(kind=8) :: b
  a = -3_4
  b = -huge(b) / 7
  a = a ** 73_4
  b = 7894_8 * b - 78941_8
  if ((-3_4)**73_4 /= a) call abort
  if (7894_8 * (-huge(b) / 7) - 78941_8 /= b) call abort

  a = 1234789786453123_4
  if (a - 1234789786453123_4 /= a - (-426244989_4)) call abort
  end

If the consensus is that such changes do not worth the maintainers' time,
then my initial question is answered.  If not, my question was also "what
is the best way to proceed?".

Now what about cases such that
gcc/testsuite/gfortran.dg/alloc_comp_constructor_1.f90, where the option
gives either a change in the bound values or an ICE?

> Not to mention, if the test contains an EQUIVALENCE or COMMON with mixed
> REAL and INTEGER variables, you cannot use -fdefault-real-8 without also
> using -fdefault-integer-8.  There is also an issue with the effect of
> these options on ISO C Binding.  I doubt anyone has looked for example at
> whether -fdefault-integer-8 promotes C_INT to C_LONG or whether it even
> makes sense to do so.

I am not familiar with C, but I don't think it has the concept of default 
type. If this right, then there cannot be interoperability between FORTRAN 
and C with -fdefault-*-8 options. Although probably obvious this could be 
documented.  In the same way, if a COMMON block is shared between two 
files, compiling one with the option and not the other is very likely to 
fail, and so on.

> The grand irony of this whole thread is that Charles Darwin is right.
> Survival of the fittest clearly is not in favor of darwin.

No comments, this was not the point of my mail.

Cheers,

Dominique