Why does BOZ literal work OK in TRANSFER call but not as declaration with gfortran?

[Nasser M. Abbasi]

I finished making some changes to Fortran openGL 2003 binding to make it
build with std=f2008 and cleaned some other things.

It was using BOZ literals like this

----------------
IMPLICIT NONE
INTEGER, PARAMETER :: GL_CURRENT_BIT = z'00000001' ! 0x00000001
END
---------------

Which causes problem:

gfortran -std=f2008 -c problem2.f90
Error: Extension: BOZ literal at (1) outside a DATA statement and outside INT/REAL/DBLE/CMPLX

So, using the editor I changed all places where it had BOZ like this
to become INT(z'...') and now it worked

------------OK-----
IMPLICIT NONE
INTEGER, PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') ! 0x00000001
END
-------------

But since I used global substitution, it changed one place in the code
where BOZ was used in a TRANSFER, like this:

---------------------
USE, INTRINSIC :: ISO_C_BINDING
IMPLICIT NONE
INTEGER, PARAMETER :: GLbitfield=C_INT
INTEGER(GLbitfield), PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') ! 0x00000001
INTEGER(GLbitfield), PARAMETER :: GL_CLIENT_ALL_ATTRIB_BITS = &
transfer(INT(z'ffffffff'),GL_CURRENT_BIT) ! 0xffffffff
END
---------------------

But this change caused a problem. Now the code failed due to adding INT() around
the BOZ literal inside the transfer:

---------------------------
>gfortran -std=f2008 -c problem.f90
problem.f90:6.17:
transfer(INT(z'ffffffff'),GL_CURRENT_BIT) ! 0xffffffff
Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check
can be disabled with the option -fno-range-check
---------------------------

So, I thought I need to find out what to use in place on INT, like LONG_INT?
in this one place.

But first I said let me just remove INT from this literal BOZ
and see what happens.

When I removed the INT casting from the BOZ inside the TRANSFER, now
it compiled ok. No warning about Arithmetic overflow and BOZ literal
was allowed in this case. I get now no warnings, even when using
all the flags:

>gfortran -std=f2008 -Wall -Wconversion -Wconversion-extra -c problem.f90

--------------------
USE, INTRINSIC :: ISO_C_BINDING
IMPLICIT NONE
INTEGER, PARAMETER :: GLbitfield=C_INT
INTEGER(GLbitfield), PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') ! 0x00000001
INTEGER(GLbitfield), PARAMETER :: GL_CLIENT_ALL_ATTRIB_BITS = &
transfer(z'ffffffff',GL_CURRENT_BIT) ! 0xffffffff
END
--------------------

It seems to be OK. Do I still need to worry about the
Arithmetic overflow? (I guess not, since all builds OK and openGL example
builds and runs ok.

But why is BOZ literal allowed in the transfer and not in the declaration?

The Fortran 2003 binding had thousands of the BOZ literals in its files
and I changed them all by adding INT('z...') so it builds now with std2008.
I also removed the -fno-range-check it had, which I never like to see.

--Nasser

[Ian Harvey]

On 2012-07-23 7:48 PM, Nasser M. Abbasi wrote:
>
> I finished making some changes to Fortran openGL 2003 binding to make it
> build with std=f2008 and cleaned some other things.

...

> So, using the editor I changed all places where it had BOZ like this
> to become INT(z'...') and now it worked
>
> ------------OK-----
> IMPLICIT NONE
> INTEGER, PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') ! 0x00000001
> END
> -------------

A BOZ literal constant represents a sequence of bits. On its own it has
no type - there are multiple ways that sequence of bits could be
interpreted. If you interpreted the sequence of bits as a REAL, then
the value that would be used to initialize the constant may be quite
different from the value that might result if you interpreted the
sequence as an integer.

When used as an argument to the INT intrinsic you are asking the
processor to interpret that bit pattern as a default integer, in that
particular case with the value of the integer given by the bit model
defined in the standard. The INT intrinsic gives meaning to the bits.

> But since I used global substitution, it changed one place in the code
> where BOZ was used in a TRANSFER, like this:
>
> ---------------------
> USE, INTRINSIC :: ISO_C_BINDING
> IMPLICIT NONE
> INTEGER, PARAMETER :: GLbitfield=C_INT
> INTEGER(GLbitfield), PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') !
> 0x00000001
> INTEGER(GLbitfield), PARAMETER :: GL_CLIENT_ALL_ATTRIB_BITS = &
> transfer(INT(z'ffffffff'),GL_CURRENT_BIT) ! 0xffffffff
> END
> ---------------------
>
> But this change caused a problem. Now the code failed due to adding
> INT() around
> the BOZ literal inside the transfer:
>
> ---------------------------
>> gfortran -std=f2008 -c problem.f90
> problem.f90:6.17:
> transfer(INT(z'ffffffff'),GL_CURRENT_BIT) ! 0xffffffff
> Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1).
> This check
> can be disabled with the option -fno-range-check
> ---------------------------

I'm not sure.

The meaning of the most significant bit (in terms of the bit count of
the target type) when the INT intrinsic takes a BOZ literal is processor
dependent (this is wiggle room to easily allow for both twos complement
and signed magnitude representations of negative numbers). But that on
its own doesn't stop a programmer from using that upper bit, they just
can't count on the result of the INT intrinsic being the same from
processor to processor.

(If that bit is not available for use, then the BIT_SIZE intrinsic,
which returns 32 for default integer on gfortran, is broken.)

Note the issue is with the INT intrinsic and not TRANSFER.

>
> So, I thought I need to find out what to use in place on INT, like
> LONG_INT?
> in this one place.
>
> But first I said let me just remove INT from this literal BOZ
> and see what happens.
>
> When I removed the INT casting from the BOZ inside the TRANSFER, now
> it compiled ok. No warning about Arithmetic overflow and BOZ literal
> was allowed in this case. I get now no warnings, even when using
> all the flags:
>
>> gfortran -std=f2008 -Wall -Wconversion -Wconversion-extra -c problem.f90
>
> --------------------
> USE, INTRINSIC :: ISO_C_BINDING
> IMPLICIT NONE
> INTEGER, PARAMETER :: GLbitfield=C_INT
> INTEGER(GLbitfield), PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') !
> 0x00000001
> INTEGER(GLbitfield), PARAMETER :: GL_CLIENT_ALL_ATTRIB_BITS = &
> transfer(z'ffffffff',GL_CURRENT_BIT) ! 0xffffffff
> END
> --------------------
>
> It seems to be OK. Do I still need to worry about the
> Arithmetic overflow? (I guess not, since all builds OK and openGL example
> builds and runs ok.
>
> But why is BOZ literal allowed in the transfer and not in the declaration?

It is not by my reading of the F2008 standard. I suspect the gfortran
developers forgot to put a warning in for its use.

[Nasser M. Abbasi]

Opps, I forgot to mention the versions

>gfortran --version
GNU Fortran (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

On linux 32 bit

thanks,
--Nasser

[James Van Buskirk]

"Nasser M. Abbasi" <n...@12000.org> wrote in message
news:juj6lt$e2k$1...@speranza.aioe.org...

>>gfortran -std=f2008 -c problem.f90
> problem.f90:6.17:
> transfer(INT(z'ffffffff'),GL_CURRENT_BIT) ! 0xffffffff
> Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1).
> This check
> can be disabled with the option -fno-range-check

This has come up before. None of the gfortran developers seem to do
much "bucket of bits" code where one thinks about an integer as just
a set of BIT_SIZE(1) flags. There are deficiencies in the standard
as well: if it can be interpreted in such a way as to reject the
above code, there is some ambiguity. It's even worse with the most
negative number -- there's no easy way to say it in gfortran. The
stuff with TRANSFER works because gfortran interprets a BOZ literal
as an integer with the biggest RANGE. How it works on big-endian
machines is another question. I would want to be warned about BOZ+
TRANSFER just thinking about that issue. Why does BIT_SIZE follow
BLT in the standard (13.7.32 vs. 13.7.31)? Just another of those
bucket of bits shortcomings.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[Tobias Burnus]

On 07/23/2012 11:48 AM, Nasser M. Abbasi wrote

> It was using BOZ literals like this
>
> ----------------
> IMPLICIT NONE
> INTEGER, PARAMETER :: GL_CURRENT_BIT = z'00000001' ! 0x00000001
> END
> ---------------
>
> Which causes problem:
>
> gfortran -std=f2008 -c problem2.f90
> Error: Extension: BOZ literal at (1) outside a DATA statement and
> outside INT/REAL/DBLE/CMPLX

Yes, the "= z'00000001'" is a (common) vendor extension. However, the
error message is not fully correct as Fortran (at least Fortran 2008)
allows BOZ literals also at a few other intrinsics, e.g. to IAND, DBLE
or DSHIFTR.

> But since I used global substitution, it changed one place in the code
> where BOZ was used in a TRANSFER, like this:
>
> ---------------------
> USE, INTRINSIC :: ISO_C_BINDING
> IMPLICIT NONE
> INTEGER, PARAMETER :: GLbitfield=C_INT
> INTEGER(GLbitfield), PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') !
> 0x00000001
> INTEGER(GLbitfield), PARAMETER :: GL_CLIENT_ALL_ATTRIB_BITS = &
> transfer(INT(z'ffffffff'),GL_CURRENT_BIT) ! 0xffffffff
> END
> ---------------------

The problem is that z'FFFFFFFF' doesn't match the bit pattern of a
positive integer of default kind. The standard states:

"If A is a boz-literal-constant, the value of the result is the value
whose bit sequence according to the model in 13.3 is the same as that of
A as modified by padding or truncation according to 13.3.3. The
interpretation of a bit sequence whose most significant bit is 1 is
processor dependent."

Here, gfortran doesn't know whether the overflow to negative values is
on purpose or accidental. As the error message states

Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1).
This check can be disabled with the option -fno-range-check

you can simply use -fno-range-check to silence this error. One can argue
whether gfortran should print an error or not, but given that it shows
the flag to use, I think the current way can be accepted.

I am not sure that the error message is best suited for Fortran 2008,
but it makes sense for Fortran 95, where the BOZ matched the largest
supported integer values:

"If a data-statement-constant is a boz-literal-constant, the
corresponding object shall be of type integer. A data-stmt-constant that
is a boz-literal-constant is treated as if the constant were an
int-literalconstant with a kind-param that specifies the representation
method with the largest decimal exponent range supported by the processor."

By contrast, Fortran 2008 has (for DATA):

"If a data-stmt-constant is a boz-literal-constant, the corresponding
variable shall be of type integer. The boz-literal-constant is treated
as if it were converted by the intrinsic function INT (13.7.81) to type
integer with the kind type parameter of the variable.


As long as the bit pattern fits into a positive number of the integer
kind, everything is fine. The trouble only starts when it doesn't.

> So, I thought I need to find out what to use in place on INT, like
> LONG_INT?

Well, you can use INT(z'FFFFFFFF',kind=int64), however, you have to be
careful whether that leads the bitpattern, which you want
[INT(z'FFFFFFFF') is "-1", i.e. all bit set to one in an INT32
variable]. (Well, in practice is should be on most platforms.)

Thus, you should really consider to use INT and the flag -fno-range-check.

> When I removed the INT casting from the BOZ inside the TRANSFER, now
> it compiled ok. No warning about Arithmetic overflow and BOZ literal
> was allowed in this case.

Unless, I misread the standard, I believe it is just a bug in gfortran
that it does not print an error in that case. If some construct is
supported (for a newer standard or as vendor extension), it is
nontrivial to make sure that the compiler rejected it at all places
where it shouldn't be supported according the standard (or an older
version of the standard).


As only Fortran 2003 started to support BOZ in other places than for
integers in DATA, many compilers support BOZ at other places. It gets
rather hairy if BOZ are used for nonintegers, e.g.
real :: r = z'FFFFFFFF'
Should the bitpattern FFFFFFFF be assigned to "r"? Or should the BOZ be
regarded as integer - and then the integer be assigned? What if one has
r = z'FFFFFFFF' + 1
or
r = z'FFFFFFFF' + 1.0
I think that's rather muddy and should be avoided in favor of using
Fortran 2003/2008's INT/REAL/CMPLX.

In case of gfortran's vendor extension, BOZ are interpreted as listed at
+




I have now filled a gfortran bugreport to track the failing diagnosis
for TRANSFER: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072

Tobias

[Tobias Burnus]

On 07/23/2012 03:38 PM, Tobias Burnus wrote:
> The problem is that z'FFFFFFFF' doesn't match the bit pattern of a
> positive integer of default kind. The standard states:

I should have probably quoted from INT's description instead. See Ian's
description or the following quote (for INT in Fortran 2008) - see the
last sentence.

"If A is a boz-literal-constant, the value of the result is the value
whose bit sequence according to the model in 13.3 is the same as that of
A as modified by padding or truncation according to 13.3.3. The
interpretation of a bit sequence whose most significant bit is 1 is
processor dependent."

(One can discuss whether gfortran should (or may) print an error in this
case, but as -fno-range-check can silence it ...)

> In case of gfortran's vendor extension, BOZ are interpreted as listed at

The missing link is
http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html

Tobias

[glen herrmannsfeldt]

Tobias Burnus <bur...@net-b.de> wrote:
> On 07/23/2012 11:48 AM, Nasser M. Abbasi wrote
>> It was using BOZ literals like this

>> INTEGER, PARAMETER :: GL_CURRENT_BIT = z'00000001' ! 0x00000001

(snip)

> Yes, the "= z'00000001'" is a (common) vendor extension. However, the
> error message is not fully correct as Fortran (at least Fortran 2008)
> allows BOZ literals also at a few other intrinsics, e.g. to IAND, DBLE
> or DSHIFTR.

Those make some sense...

(snip)

> The problem is that z'FFFFFFFF' doesn't match the bit pattern of a
> positive integer of default kind. The standard states:

> "If A is a boz-literal-constant, the value of the result is the value
> whose bit sequence according to the model in 13.3 is the same as that of
> A as modified by padding or truncation according to 13.3.3. The
> interpretation of a bit sequence whose most significant bit is 1 is
> processor dependent."

It says that the significance is processor dependent. That, to me,
doesn't require that the constant be positive.

> Here, gfortran doesn't know whether the overflow to negative
> values is on purpose or accidental. As the error message states

> Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1).
> This check can be disabled with the option -fno-range-check

This seems wrong to me. The whole idea behind BOZ is that you
are giving the desired bit pattern. That is true for positive
or negative (or zero) values.

For one, you might want to specify the bit pattern independent
of the processor treatment of the sign bit, for use with bitwise
operations. (In case you happen to run on a sign magnitude or
ones complement processor.)

How would you specify the bit pattern for negative zero on
a sign magnitude or ones complement machine? If the idea is
to specify by pattern, then that should be allowed.

> you can simply use -fno-range-check to silence this error. One can argue
> whether gfortran should print an error or not, but given that it shows
> the flag to use, I think the current way can be accepted.

Does that mean that it will also ignore range errors for non-BOZ
constants?

> I am not sure that the error message is best suited for Fortran 2008,
> but it makes sense for Fortran 95, where the BOZ matched the largest
> supported integer values:

(snip)

> As long as the bit pattern fits into a positive number of the integer
> kind, everything is fine. The trouble only starts when it doesn't.

Yes the meaning of the bit pattern is processor dependent, but
that shouldn't disqualify it!

>> So, I thought I need to find out what to use in place on INT, like
>> LONG_INT?

> Well, you can use INT(z'FFFFFFFF',kind=int64), however, you have to be
> careful whether that leads the bitpattern, which you want
> [INT(z'FFFFFFFF') is "-1", i.e. all bit set to one in an INT32
> variable]. (Well, in practice is should be on most platforms.)

> Thus, you should really consider to use INT and the
> flag -fno-range-check.

>> When I removed the INT casting from the BOZ inside the TRANSFER, now
>> it compiled ok. No warning about Arithmetic overflow and BOZ literal
>> was allowed in this case.

> Unless, I misread the standard, I believe it is just a bug in gfortran
> that it does not print an error in that case. If some construct is
> supported (for a newer standard or as vendor extension), it is
> nontrivial to make sure that the compiler rejected it at all places
> where it shouldn't be supported according the standard (or an older
> version of the standard).

Is it now a 64 bit integer constant?

> As only Fortran 2003 started to support BOZ in other places than for
> integers in DATA, many compilers support BOZ at other places. It gets
> rather hairy if BOZ are used for nonintegers, e.g.

> real :: r = z'FFFFFFFF'
> Should the bitpattern FFFFFFFF be assigned to "r"? Or should the BOZ be
> regarded as integer - and then the integer be assigned? What if one has
> r = z'FFFFFFFF' + 1
> or
> r = z'FFFFFFFF' + 1.0
> I think that's rather muddy and should be avoided in favor of using
> Fortran 2003/2008's INT/REAL/CMPLX.

Yes, that didn't happen when they were only allowed in DATA statements.

As far as I know, Z constants originated in the IBM S/360 compilers,
where they had the from Z01234567. (No apostrophes.)

That could only happen in DATA statements, otherwise it would
look like a variable name. (Well, if it was shorter it would.)

Some DEC compilers allowed octal constants, and DEC supported
Z constants starting with VAX/VMS. Floating point Z constants
are especially interesting with VAX, as little endian 16 bit
words in big endian order. The Z constant represents the
little endian order bit pattern, such that the
(trap representation) floating negative zero looks like:

DATA ZNEG/Z00008000/


-- glen

[Richard Maine]

James Van Buskirk <not_...@comcast.net> wrote:

> Why does BIT_SIZE follow BLT in the standard (13.7.32 vs. 13.7.31)?

Probably because BLT is short for "Bacon, Lettuce & Tomato"? :-)

Actually, I have no idea what BLT is; possibly some new f2008 thing, or
maybe just one I'm not recalling. It isn't convenient for me to look it
up right now.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Steven G. Kargl]

On Mon, 23 Jul 2012 07:23:32 -0600, James Van Buskirk wrote:

> "Nasser M. Abbasi" <n...@12000.org> wrote in message
> news:juj6lt$e2k$1...@speranza.aioe.org...
>
>>>gfortran -std=f2008 -c problem.f90
>> problem.f90:6.17:
>> transfer(INT(z'ffffffff'),GL_CURRENT_BIT) ! 0xffffffff
>> Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1).
>> This check
>> can be disabled with the option -fno-range-check
>
> This has come up before. None of the gfortran developers seem to do
> much "bucket of bits" code where one thinks about an integer as just
> a set of BIT_SIZE(1) flags. There are deficiencies in the standard
> as well: if it can be interpreted in such a way as to reject the
> above code, there is some ambiguity.

From F2003,

13.7.53 INT (A [, KIND])

Description. Convert to integer type.

Class. Elemental function.

Arguments.

A shall be of type integer, real, or complex, or
a boz-literal-constant .

KIND (optional) shall be a scalar integer initialization expression.

Result Characteristics.
Integer. If KIND is present, the kind type parameter
is that specified by the value of KIND; otherwise, the kind type
parameter is that of default integer type.

Result Value.
....

Case (iv): If A is a boz-literal-constant , it is treated as if it were an
int-literal-constant with a kind-param that specifies the

representation method with the largest decimal exponent
range supported by the processor.

Yes, I'm fully aware that F2008 has changed this to

Case (iv): If A is a boz-literal-constant , the value of the result is the

value whose bit sequence according to the model in 13.3 is
the same as that of A as modified by padding or truncation
according to 13.3.3. The interpretation of a bit sequence
whose most significant bit is 1 is processor dependent.

and 13.3.3 suggests that the padding/truncation depends on the result of INT().

Fortunately, gfortran does not claim to be a Fortran 2008 compiler and almost,
but not quite, claim to be a Fortran 2003 compiler.

--
steve

[Dick Hendrickson]

On 7/23/12 12:10 PM, Richard Maine wrote:
> James Van Buskirk<not_...@comcast.net> wrote:
>
>> Why does BIT_SIZE follow BLT in the standard (13.7.32 vs. 13.7.31)?
>

> Probably because BLT is short for "Bacon, Lettuce& Tomato"? :-)

>
> Actually, I have no idea what BLT is; possibly some new f2008 thing, or
> maybe just one I'm not recalling. It isn't convenient for me to look it
> up right now.
>

I started the ball rolling by sending a note to the editor. I hope he
can sandwich in a fix. My suggestion (fewest edits to the standard) was
to delete the word "alphabetical" from the lead in blather to the list
of function descriptions [F2008, 345:3]. That not only fixes this
problem, but also fixes any similar problems in the section.

Dick Hendrickson

Rickard, it's Bitwise Less Than.

[Nasser M. Abbasi]

I have another follow up on this issue that came up with
the Fortran openGL binding:

One of the example files uses BOZ but in data segment like this:

----------------------------
PROGRAM foo13
data shadowPattern / z'aa'/
END PROGRAM foo13
--------------------------

The above compiles OK in default gfortran. But in std=f2008 it
does not as was mentioned before:

---------------------------------
>gfortran -std=f2008 foo13.f90
foo13.f90:3.26:
data shadowPattern / z'aa'/ 1
Error: Extension: BOZ literal at (1) used to initialize non-integer variable 'shadowpattern'
---------------------------------

The _problem_ is I can't now use the same INT() trick I used before in this
case, since it will not allow me to do that in data:

--------------------------
PROGRAM foo13
data shadowPattern / INT(z'aa')/
END PROGRAM foo13
---------------------------

---------------------
>gfortran -std=f2008 foo13.f90
foo13.f90:2.24:
data shadowPattern / INT(z'aa')/
Error: Symbol 'int' must be a PARAMETER in DATA statement at (1)
-----------------------

I looked at this, but I really do not understand it well. Here is
an example of a page I was reading that talks about this

http://docs.cray.com/books/S-3692-51/html-S-3692-51/zfixedyqmtmpjf.html

how to use PARAMETER here? why it think INT is a symbol here and not
the Intrinsic INT() ? I guess becuase it is inside DATA, then it is
looking at everything there as literal

http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Int-Intrinsic.html

What should be the correct way to handle this issue now if I want to
use std=f2003 or std=f2008 to compile this? I could always
go back to default gfortran to compile this file, but I'd like
to use the same options if possible for all files.

gfortran 4.6.2 on linux.

thanks,
--Nasser
a_fortran_newbie

[Nasser M. Abbasi]

OK, Please ignore this below.

I found a solution:

------------------------------
PROGRAM foo13
implicit none
integer, save :: shadowPattern(1)

data shadowPattern / z'aa'/
END PROGRAM foo13
--------------------------

The above build OK with std=f2008. No need for INT() at all.

gfortran -c -Wall -std=f2008 foo13.f90

I missed the integer, ::shadowPattern(1) to make it happy.

sorry.
case closed.

--Nasser

[Richard Maine]

Nasser M. Abbasi <n...@12000.org> wrote:

> The _problem_ is I can't now use the same INT() trick I used before in this
> case, since it will not allow me to do that in data:

...

> data shadowPattern / INT(z'aa')/

...

>
> how to use PARAMETER here? why it think INT is a symbol here and not
> the Intrinsic INT() ? I guess becuase it is inside DATA, then it is
> looking at everything there as literal

I see elsewhere that you found the solution to your problem by declaring
shadowPattern to be an integer, as was needed.

I'll just add that the syntax of the DATA statement is completely unlike
the syntax of anything else in the language. For the DATA statement,
there really isn't much answer other than just "because" about why you
can't do lots of things. Ok, there actually is a reason, but it is a bit
indirect. Start with the fact that * has a special meaning in a DATA
statement. Because of that, it can't use general expressions. Therefore,
instead of expressions, the DATA statement has its own completely
separate definition of the forms to use. That definition is *VERY*
narrow. Don't try to think of it as a restricted form of anything else;
that's not how it is described. It is its own separate form. You should
assume that nothing is allowed unless you have specifically found it
listed in the syntax for the DATA statement; don't generalize from
anything else.

But realize that you can do initialization without a DATA statement. In
fact, my personal preference is to mostly avoid the DATA statement,
partly because its syntax is so strange, and partly because I prefer to
declare everything about a symbol in a single statement. Instead of
using a DATA statement, use an initializer in the type declaration
statement. It does the same thing, but with a more consistent syntax.

There are some cases where the oddities of DATA syntax happen to fit
well with what one is trying to do, making it much simpler to do with
DATA than with an initializer in a type declaration statement. Those
cases are the only times I personally use the DATA statement at all in
new code.