Very Computer

by **Takashi Ichiha** » Wed, 18 Dec 1996 04:00:00

Hi folks

I noticed recently that Digital fortran compiler has introduced
incompatibility to the previous DEC fortran compiler and and also
other vender's platforms.

Following is a sample test program to show this incompatibility.

c sample program: test3.for
integer*4 i4a,i4b,i4c
i4a= '120000'O
i4b= '120000'O / 2
i4c= '120000'O / int(2)
write(*,*) i4a,i4b,i4c
end
c

(A) Result using the following environment

o DEC Fortran V6.2-108 (VAX) on Open VMS VAX V6.1
o DEC Fortran V6.3-711 (AXP) on Open VMS AXP V6.2
o Digital Fortran 77 V7.0-6 on Open VMS AXP V6.2
o DEC Fortran V3.8-711 on OSF/1 3.2A
o HP FORTRAN 77 Ver: B.10.20
o IBM AIX XL Fortran Compiler Version 03.02.0002.0000
o IBM AIX XL Fortran Compiler Version 03.02.0004.0000
o Silicon Graphics Fortran 77 version 5.2
o Absoft FORTRAN 77 on Linux
o AND, MANY OTHER PLATFORMS

$run test3

40960 20480 20480

I think this result is normal.

(B) result using the following environment (most recent Digital Fortran)

o DEC Fortran V6.3-155 (VAX) on Open VMS V6.2 VAX,
o Digital Fortran V6.4-165 (VAX) on Open VMS V6.2 VAX,
o AND, ALL FUTURE RELEASE OF DIGITAL FORTRAN (as DEC told us...)

$run tes3

40960 -12288 20480

-----------------------------------------------------------------------

Local DEC support center told us that DEC has changed the
specification of the Fortran Compiler with the release of DEC
Fortran VAX V6.3 (as can be found "sys$help:FORT063.RELEASE_NOTES :
2.1.1.6 Sign Extension of Untyped Bit Constants" ) and hereafter all
the DEC fortman compiler (including AXP and VAX, VMS and UNIX) is
going to be resulted as (B).

I cannot believe why this silly change was introduced. This
change made a lot of confusion for the compatibility with the
previous DEC/VAX fortran. Also this change introduced serious
incompatibility with the other vender's fortran.

Takashi Ichihara

by **Steve Lion** » Wed, 18 Dec 1996 04:00:00

We considered the older behavior to be incorrect, but we admit that it relies
on a lot of not-well-specified behavior.

What is the type of a bit constant? They're not in Fortran 77 at all,
and are allowed in Fortran 90 only in initialization (DATA) expressions,
so none of that is relevant.

Here's what the Digital Fortran 77 Language Reference Manual has to say about
bit constants:

Bit constants have no data type until they are used. When used,
they assume a data type based on their use.

When the bit constant is used with a binary operator, including
the assignment operator, the datatype of the constant is the
data type of the other operand.

The case in question concerns the expression:

'120000'O / 2

What is its type? Well, what is the type of the constant 2? As has been
implemented in Digital Fortran back to VAX-11 FORTRAN-IV-PLUS V1.0 in 1978,
it's INTEGER*2:

The value of an integer constant is normally INTEGER*2, INTEGER*4
or INTEGER*8 (Alpha only). If a value is within the INTEGER*2
range (-32768:32767 or 0:65535), it is treated as an INTEGER*2 value...

Therefore, the bit constant assumes the type INTEGER*2. Since in this
representation, the sign bit is on, the constant represents a negative
value, and the division has a negative result (Fortran doesn't have
unsigned arithmetic.) That negative result is then sign-extended to
INTEGER*4 for the assignment.

Amusingly, if the expression had been written instead as:

'120000'O / '2'O

this would be an INTEGER*4 expression because of the other rule that says if
there is no other typed operand, INTEGER*4 is assumed.

Now I'll be the first to admit that this "typing" of integer constants is
not obvious, and it often gets us into trouble, but that's the documented
behavior and we wanted to make sure that we were consistent. Other
compilers might not have this notion of INTEGER*2 typing for small integer
constants and would not run into this problem. But I maintain that the
current VAX compiler behavior is reasonable and consistent with the
documentation and behavior of the compiler in other areas for the past 19 years.

Our Alpha Fortran 77 compiler does not currently do this - it treats the
bit constant as a zero-extended INTEGER*4 (or perhaps INTEGER*8) value.
To add to the confusion, our Fortran 90 compiler now honors the Fortran 90
integer constant typing rules which say that the constant 2 is "default
integer", meaning INTEGER*4 (by default), so there you get the result you
seem to expect. It's not clear yet whether or not we'll change the
Alpha Fortran 77 compiler to match the VAX behavior - this is something
we're still discussing. I'd certainly be interested in observations from
others on the issue, keeping in mind our documented treatment of small
integer constants.
--

Fortran Development http://www.digital.com/info/slionel.html
Digital Equipment Corporation
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"

For information on Digital Fortran, see http://www.digital.com/info/hpc/fortran/

by **Petrie L** » Thu, 19 Dec 1996 04:00:00

Does this mean that on the VAX, if I

call sub1 ( x, n, 1 )
^

where sub1 is

subroutine sub1 ( x, n, i )
dimension x(n)
integer i
...
end

that "i" is going to be a number > 2**16?
This doesn't seem reasonable to me, even if it is
18 year old behavior.

--
Lester M. Petrie

ORNL-CPED
423-574-5259

by **Ron Shepa** » Thu, 19 Dec 1996 04:00:00

>Does this mean that on the VAX, if I

> call sub1 ( x, n, 1 )
> ^

>where sub1 is

> subroutine sub1 ( x, n, i )
> dimension x(n)
> integer i
> ...
> end

>that "i" is going to be a number > 2**16?
>This doesn't seem reasonable to me, even if it is
>18 year old behavior.

No, default integers on a VAX are INTEGER*4. I'm not sure where the
INTEGER*2 value got into this discussion. Was there an implicit statement
or something that I missed?

$.02 -Ron Shepard

by **John Hasca** » Thu, 19 Dec 1996 04:00:00

}|>c sample program: test3.for
}|> integer*4 i4a,i4b,i4c
}|> i4a= '120000'O
}|> i4b= '120000'O / 2
}|> i4c= '120000'O / int(2)
}|> write(*,*) i4a,i4b,i4c
}|> end

most systems give:

Quote:}|> 40960 20480 20480

new dec f77 gives:

Quote:}|> 40960 -12288 20480
}We considered the older behavior to be incorrect, but we admit that it relies
}on a lot of not-well-specified behavior.

[history on the type of bit constants]

Quote:}The case in question concerns the expression:
} '120000'O / 2
}What is its type? Well, what is the type of the constant 2? As has been
}implemented in Digital Fortran back to VAX-11 FORTRAN-IV-PLUS V1.0 in 1978,
}it's INTEGER*2:
}Therefore, the bit constant assumes the type INTEGER*2. Since in this
}representation, the sign bit is on, the constant represents a negative
}value, and the division has a negative result (Fortran doesn't have
}unsigned arithmetic.) That negative result is then sign-extended to
}INTEGER*4 for the assignment.
}Our Alpha Fortran 77 compiler does not currently do this - it treats the
}bit constant as a zero-extended INTEGER*4 (or perhaps INTEGER*8) value.
}To add to the confusion, our Fortran 90 compiler now honors the Fortran 90
}integer constant typing rules which say that the constant 2 is "default
}integer", meaning INTEGER*4 (by default), so there you get the result you
}seem to expect. It's not clear yet whether or not we'll change the
}Alpha Fortran 77 compiler to match the VAX behavior - this is something
}we're still discussing. I'd certainly be interested in observations from
}others on the issue, keeping in mind our documented treatment of small
}integer constants.

It seems to me that the careful programmer would write:

i4b= '00000120000'O / 2

if that is what they wanted rather than hoping that:

i4b= '120000'O / 2

would be sign-extended the way they hoped. However, it
isn't clear to me from the explanation above whether or
not that would give the expected answer or not. Will
the fact that "2" has a type of INTEGER*2 force
'00000120000'O to be INTEGER*2 too? And if so, what about
'10000120000'O?

John
--
John Hascall, Software Engr. Shut up, be happy. The conveniences you
ISU Computation Center demanded are now mandatory. -Jello Biafra

http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud

by **Steve Lion** » Fri, 20 Dec 1996 04:00:00

Quote:(Petrie L M) writes:

No, it doesn't. The behavior I referred to explicitly relates to use of
constants in an expression with a binary operator. In contexts such as
an actual argument, the largest integer type is used.
--

Fortran Development http://www.digital.com/info/slionel.html
Digital Equipment Corporation
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"

For information on Digital Fortran, see http://www.digital.com/info/hpc/fortran/

by **Steve Lion** » Fri, 20 Dec 1996 04:00:00

||>
|> It seems to me that the careful programmer would write:
|>
|> i4b= '00000120000'O / 2
|>
|> if that is what they wanted rather than hoping that:
|>
|> i4b= '120000'O / 2
|>
|> would be sign-extended the way they hoped. However, it
|> isn't clear to me from the explanation above whether or
|> not that would give the expected answer or not. Will
|> the fact that "2" has a type of INTEGER*2 force
|> '00000120000'O to be INTEGER*2 too? And if so, what about
|> '10000120000'O?

The leading zeroes will be ignored. The larger constant will get an error.
Not very pretty...

We've been discussing this issue among the Fortran engineering team, and we've
concluded that the current VAX behavior isn't what we want. It will take
me a while to determine just how it all ought to work without breaking
programs that rely on the "small integer constant" behavior. Bit constants,
in particular, should assume the largest integer type. The goal will be to
match the Alpha compiler's behavior in this regard.
--

Fortran Development http://www.digital.com/info/slionel.html
Digital Equipment Corporation
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"

For information on Digital Fortran, see http://www.digital.com/info/hpc/fortran/

Very Computer

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants

Recent Digital Fortan incompatibility for Sign Extension of Untyped Bit Constants