This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/33544] Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran



------- Comment #5 from sgk at troutmask dot apl dot washington dot edu  2007-09-24 19:59 -------
Subject: Re:  Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran

On Mon, Sep 24, 2007 at 07:17:54PM -0000, burnus at gcc dot gnu dot org wrote:
> 
> 
> ------- Comment #4 from burnus at gcc dot gnu dot org  2007-09-24 19:17 -------
> > We may want to hide the warning behind a -Wshort-transfer option
> > (or some other appropriate name).
> Maybe; I think having a warning by default would be more reasonable but it
> should be hideable.

I don't fell strongly either way, but I do agree one should be able to
turn off/on the warning.

> > Afterall, if a programmer wrote 'rft = transfer(' ', 0.0)',
> > then s/he probably meant it.
> 
> I sincerely doubt that the programmer meant that this piece of code produces
> different results depending on the compiler and possibly some random value in
> memory.

It may not produce random values each time (see below).  Michael (a user) 
did file a bug report, and knowing him for previous bug reports and posts
elsewhere on the net, I suspect he did intend the short transfer.

> For the given example, many compilers seem to initialize the result
> with zero; example:
> 
> PROGRAM printd
> REAL :: rft
> rft = TRANSFER(' ', 0.0)
> print *, rft
> rft = TRANSFER(' '//achar(0)//achar(0)//achar(0), 0.0)
> print *, rft
> END PROGRAM printd
> 
> The second transfer produces: 4.4841551E-44
> g95, ifort and openf95 seem to produce the same result also for the first
> TRANSFER.
> gfortran, NAG f95 and sunf95 have, however, a different result every time.
> 
> Thus, if one wants to argue that the programmer intended a certain value, I
> would argue that it is the one using a zero-padded SOURCE.

The programmer for whatever reason could be using rft as temporary storage.
Yes, I know it's a hypothetical situation, but the following is legal code
and should not give a warning.

program m
  character c
  real rft
  rft = transfer(' ', 0.)
!  print *, rft              <-- Uncommenting may make this invalid code
  c = transfer(rft, c)
  if (c .eq. ' ') print *, 'space'
end program

Note, if I uncomment the print statement, on x86_64-*-freebsd, it prints
a NaN every time I execute the program.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33544


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]