BOZ literal constants, a puzzle for us Standard-loving types.

Lectoribus Salutem,

A colleague of mine came up with the following, very simple, and very annoying (if it hits you) error message when using gfortran:

Program:

$ cat bozlitconst.f
program test
integer i
data i / z'FFFF8000' /
print *, i
end

$ /usr/rel/bin/gfortran -c bozlitconst.f
bozlitconst.f:3.26:

data i / z'FFFF8000' /
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)

Relevant quote from the Fortran 2003 Standard:

If a [DATA STATEMENT constant] is a [BOZ literal constant],
the corresponding variable shall be of type INTEGER. The
[BOZ literal constant] is treated as if it were an [INTEGER
literal constant] with a [KIND] that specifies the represen-
tation method with the largest decimal exponent range
supported by the processor.

The error arises from the fact that

1. BOZ literal constants are INTEGERs and, hence, signed numbers.
2. The largest representable INTEGER in gfortran (on AMD64 GNU/Linux
systems) is a 16 byte integer (irrelevant in this case - it would
be just as wrong were it an 8 byte integer).

Therefore:

The BOZ literal constant above is a positive number, and
a positive number of that magnitude can not be represented
by a 32 bit signed integer.

Question to my fellow J3 Committee members: Did we really mean to outlaw this (it has an obvious meaning: stuff the 32 bits that FFFF8000 hex represents into a 32 bit integer and "damn the torpedo's".

g77 accepts it without even warning about it, so this probably means most compilers accept it (g77 was rather late to the game and, consequently, a follower of fashion).

I open for suggestions.

--
Toon Moene - e-mail: toon@xxxxxxxxxxxxxxxxxxxx - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
.

Relevant Pages

  • Re: BOZ literal constants, a puzzle for us Standard-loving types.
    ... [BOZ literal constant] ... The largest representable INTEGER in gfortran (on AMD64 GNU/Linux ... by a 32 bit signed integer. ...
    (comp.lang.fortran)
  • Re: migrating STRUCTURE and RECORD to g77 or gfortran
    ... What is the easiest way to migrate STRUCTURE and RECORD to g77 or gfortran? ... I have a collection of 1980-era sources, originally on VAX Fortran, that must ... derived type feature of Fortran 90 and later versions, ...
    (comp.lang.fortran)
  • Re: weird g77 and gfortran
    ... I have g77 from gcc 3.4.6 and gfortran from gcc 4.3.1, both running on a 2 GHz AMD machine. ... I have repeated the test with a program I use, and now the gfortran-compiled binary is only a few per cent slower than the g77 version, both with -O4. ... Without optimisation option and to my big surprise the g77 version takes about twice as long as the gfortran version. ...
    (comp.lang.fortran)
  • migrating STRUCTURE and RECORD to g77 or gfortran
    ... What is the easiest way to migrate STRUCTURE and RECORD to g77 or gfortran? ... I'm trying to avoid editing the sources, ... they are used as a naming convention to group variables, ...
    (comp.lang.fortran)
  • Re: difference between g77 and gfortran
    ... g77 and gfortran are completely different compilers. ... you have several common errors (such as default real literal constants ... I just downloaded ftncheck, and run the code through it. ...
    (comp.lang.fortran)