Bug 33544

Subject: Re:  New: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran

On 24 Sep 2007 15:48:19 -0000, michael dot a dot richmond at nasa dot
gov <gcc-bugzilla@gcc.gnu.org> wrote:
> When I compile the program listed below with the snapshot version of gfortran
> dated September 24 I get the following spurious warning:
>
> pp.f90:3.15:
> rft = TRANSFER(' ', 0.0)
>               1
> Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 1 <
> result size 4

the warning is correct.

(In reply to comment #0)
> When I compile the program listed below with the snapshot version of gfortran
> dated September 24 I get the following spurious warning:
> pp.f90:3.15:
> rft = TRANSFER(' ', 0.0)
>               1
> Warning: Intrinsic TRANSFER at (1) has partly undefined result:
>          source size 1 < result size 4

pinskia wrote:
> the warning is correct.

To elaborate:
  ' ' is 1 byte long
  0.0 is 4 bytes long
thus transfer initializes only 1 of the 4 bytes of rft, the rest remain unchanged. You need to use "transfer('    ', 0.0)" to initialize all bytes.

If you have a suggestion how to improve the warning message or if you have any other suggestion, I would be grateful.

I tried some compiles and the resulting rft is varying a lot:
4.484155086E-44, -4.1234682E-11, -2.4305621E-28, 1.0774349E+12

Tobias,

We may want to hide the warning behind a -Wshort-transfer option
(or some other appropriate name).  Afterall, if a programmer 
wrote 'rft = transfer(' ', 0.0)', then s/he probably meant it.

> 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.

> 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. 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.

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.  

Subject: Re:  Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran

On 24 Sep 2007 19:59:37 -0000, sgk at troutmask dot apl dot washington
dot edu <gcc-bugzilla@gcc.gnu.org> wrote:
> 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.

Though I will argue that is just bad coding.

-- Pinski

Subject: Re:  Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran

On Mon, Sep 24, 2007 at 09:26:01PM -0000, pinskia at gmail dot com wrote:
> On 24 Sep 2007 19:59:37 -0000, sgk at troutmask dot apl dot washington
> dot edu <gcc-bugzilla@gcc.gnu.org> wrote:
> > 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.
> 
> Though I will argue that is just bad coding.
> 

It doesn't matter if it's bad coding (which I can agree).
AFAIK, the standard says the code is legal.

An analogous message appears when I compile the program listed below with the flag "-fdefault-real-8":

qq.f90:3.15:
rft = TRANSFER('abcd', 0.0)
              1
Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 4 < result size 8

PROGRAM printd
REAL :: rft
rft = TRANSFER('abcd', 0.0)
END PROGRAM printd

(In reply to comment #7)
> It doesn't matter if it's bad coding (which I can agree).
> AFAIK, the standard says the code is legal.

After reading the standard, I concur. I think a warning option should be added, maybe -Wshort-transfer, maybe -Wsurprising...

This does the trick.  I am checking the testsuite for any side effects.


Index: simplify.c
===================================================================
--- simplify.c  (revision 129465)
+++ simplify.c  (working copy)
@@ -4065,7 +4065,7 @@ gfc_simplify_transfer (gfc_expr *source,
       result_size = result_elt_size;
     }
 
-  if (source_size < result_size)
+  if (gfc_option.warn_surprising && source_size < result_size)
     gfc_warning("Intrinsic TRANSFER at %L has partly undefined result: "
                "source size %ld < result size %ld", &source->where,
                (long) source_size, (long) result_size);

Subject: Bug 33544

Author: jvdelisle
Date: Fri Oct 19 14:06:05 2007
New Revision: 129488

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129488
Log:
2007-10-19  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/33544
	* simplify.c (gfc_simplify_transfer): Only warn for short transfer when
	-Wsurprising is given.
	* invoke.texi: Document revised behavior.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/simplify.c

Subject: Bug 33544

Author: jvdelisle
Date: Fri Oct 19 14:09:27 2007
New Revision: 129489

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129489
Log:
2007-10-19  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libfortran/33544
	* gfortran.dg/transfer_check_1.f90: Adjust options.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/transfer_check_1.f90

Fixed.