Re: -fdefault-integer-8 again!-(

[Jack Howarth <howarth at bromo dot med dot uc dot edu>]

On Mon, Dec 01, 2008 at 06:50:33PM +0100, Dominique Dhumieres wrote:
> 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

Dominique,
     I don't see how anyone could object to patches for testcases that make
them robust in the case of -fdefault-real-8. It's just that the gfortran
maintainers don't have time for that themselves.
                   Jack