Re: Code or compiler bug re: TRANSFER intrinsic?

From: Richard Maine (nospam_at_see.signature)
Date: 08/16/04 

Date: 16 Aug 2004 08:49:44 -0700

Paul Van Delst <paul.vandelst@noaa.gov> writes:

> jan van oosterwijk wrote:
> > Paul Van Delst <paul.vandelst@noaa.gov> wrote in message news:<cfirmp$54a$1@news.nems.noaa.gov>...

> >> Output = TRANSFER( Byte_Equivalent( N:1:-1), Output )

> > IMHO you are using TRANSFER in a totally correct way.

> However, the IBM reply I got was
>
> "It looks like an ambiguity in the definition of what TRANSFER does
> and I don't know whether this is a bug or a different interpretation
> of the fortran standard. TRANSFER is supposed to move bits from the
> first argument to its LHS which is of the same type and kind as the
> second argument. I have not found the ability to move bits in a
> different order (i.e byte flipping) documented."

I don't see a problem with the code either, though I have some
agreement with IBM's statement. I'll note:

1. In earlier days of f90, I used TRANSFER more often, and I found it
   to be one of the biggest sources of compiler bugs. Almost every
   compiler I tried had a bug relating to it somewhere. That was
   a while ago, and I haven't seen those bugs so much recently. I
   think that's mostly because the compilers eventually got it under
   control, but it might also be partly because I use it so rarely
   now that I don't push the compilers as far.

2. Performance of TRANSFER tends to be abysmal. As a result, I've
   tended to use EQUIVALENCE tricks instead of transfer tricks. I
   don't do a lot of those either, but a few isolated cases.

3. On IBM's comment - I'd interpret the argument to TRANSFER as
   being already re-ordered. That would be part of the argument
   association process instead of part of TRANSFER itself. But
   then, that relates to a separate matter that I've recently
   been harping on in J3 - that the standard uses the term "actual
   argument" for 2 different things, which causes confusions. One
   of those things is what gets written in the "actual argument list";
   the other is what gets associated with the dummy argument. In
   many cases, the two are the same, but not always. In particular,
   when the actual argument is a pointer and the dummy is not, the
   dummy gets associated with the target of the actual argument
   instead of with the actual argument itself. But other places
   in the standard talk about "the actual argument that is associated
   with the dummy".

   Anyway, in a way I agree that the definition of TRANSFER is a
   bit vague in some cases such as this. What is the "bit pattern"
   of the actual argument? One could easily imagine the bit paattern
   of a contiguous copy of the actual argument... but that business
   about making copies is just a common implementation choice rather
   than something specified in the standard. I'm not sure what
   it means to talk about the bit pattern of a strided array. 

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Relevant Pages

  • Re: #define and (brackets)
    ... Minor compiler vendors are free to join if they are so inclined, ... analysis hasn't changed between the two versions of the standard. ... This bug is a minor bug in an obscure ...
    (microsoft.public.vc.language)
  • Re: Code or compiler bug re: TRANSFER intrinsic?
    ... >>of the fortran standard. ... > compiler I tried had a bug relating to it somewhere. ... I only need the code for byteswapping a single 4-byte integer (and, occasionally, ... > the other is what gets associated with the dummy argument. ...
    (comp.lang.fortran)
  • Re: Visual C++ aliasing issue
    ... This is definitely a bug, ... The C/C++ compiler should assume pointer ... If I believed your program violated the standard, ... assembler code as in the original. ...
    (microsoft.public.vc.language)
  • Re: Warnings in lcc-win
    ... In that case at the default warning level it does not conform to the C standard. ... It is relevant because Jacob has repeatedly stated that his compiler has a mode in which it conforms to one of the versions of the C standard. ... If it does not generate a diagnostic in that mode then this is a bug in his compiler. ...
    (comp.lang.c)
  • Re: Converting CString to Integer
    ... Can you find the bug in your function? ... standard functions like strtol when possible. ... Where did I say anything about STL? ... >compatible with the compiler. ...
    (microsoft.public.vc.mfc)