Internal representation of a LOGICAL variable
Tobias Burnus
I have a question with regards to the internal representation of a
LOGICAL variable, especially from point of the gfortran compiler.
First some background: The middle-end part of the GCC compiler has a
boolean data type, which has the values true and false but does not
care about bit patterns. gfortran is using that data type for LOGICAL
variables; very recently it was found that certain expressions were
not optimized ("folded") correctly in the middle end, but these doing
so, the following program:
logical :: b
integer :: i
i = 42
b = transfer(i, b)
i = transfer(b, i)
print *, i
end
prints "1" instead of "42".
My question is now: Is there anything in the standard with regards to
TRANSFER, COMMON, EQUIVALENCE etc. which mandates that the bit pattern
has to be preserved? (My reading of the Fortran 77 to 2008 standard is
that the bit pattern does not need to be preserved.)
Is there any true-world case where it would make sense that the bit
patten is preserved?
Note: Changing the internal representation from boolean to integer
will make the resulting programs slower.
Tobias
PS: One problematic item are Fortran 66's Hollerith (deleted in
Fortran 77, but listed there in Appendix C); as I assume that
assigning Hollerith constants to logical variables is rather the
exception than the rule, I was thinking of having a flag (default off)
to treat logical variables internally as integer variables, which
would preserve the bit pattern. For the assignment of Hollerith
constants to logical variables one could print an error or a warning,
which points to the compiler flag.
Glen Herrmannsfeldt
> I have a question with regards to the internal representation of a
> LOGICAL variable, especially from point of the gfortran compiler.
Fortran requires a default LOGICAL type that is the same size
as default INTEGER and REAL such that COMMON and EQUIVALENCE
work correctly. On most systems that means a 32 bit LOGICAL
variable.
I don't believe that there are any requirements on the
internal bit patterns, though. Among others, it might
be that only one byte or one bit is copied during assignment.
Hollerith was normally done using INTEGER variables. While the
standard allows for LOGICAL or REAL variables, the results
might be system dependent. REAL variables might be normalized
on assignment, which would change Hollerith data.
-- glen
Richard Maine
> I have a question with regards to the internal representation of a
> LOGICAL variable, especially from point of the gfortran compiler.
Ah dear. I suspect another regular poster will pop in here, as this
seems to be one of his pet peeves. I'm surprised that you didn't see the
(quite) long thread on this kind of thing a while back. I am *NOT* - I
repeat not - going to re-enter another debate on the subject. I'll just
say up front that I disagree with every counterexample he has come up
with to try to justify that bit patterns have to work as he expects. I'm
not going to even try to dig into further examples to point out where I
think they are wrong. Do not take my future silence as agreement; it
isn't.
> logical :: b
> integer :: i
> i = 42
> b = transfer(i, b)
> i = transfer(b, i)
> print *, i
> end
> prints "1" instead of "42".
>
> My question is now: Is there anything in the standard with regards to
> TRANSFER, COMMON, EQUIVALENCE etc. which mandates that the bit pattern
> has to be preserved?
Yes. Transfer rather explicitly talks about bit patterns. It also states
a requirement (which I've said before I think to be a mistake) on being
able to do a transfer and then a transfer back and get the same result.
*BUT*, even if you literally follow that requirement, there turn out to
be gaping loopholes that pretty much prevent the user from being able to
count on bit pattern preservation.
In particular, your example above has asignment statements. An
assignment is *NOT* guaranteed to preserve bit patterns. In fact, pretty
much nothing is. Transfer is unusual in talking about bit patterns at
all. (The requirement that transfer and transfer back give the same
result does *NOT* imply a requirement on assignment statements.)
Equivalence, for example, says nothing about bit patterns. What it does
say is that if you equivalence two variables of different types (say a
real and an integer), then defining one of the variables causes the
other to become undefined. recall that referencing an undefined variable
is illegal.
Transfer is subtly different in that it says the resulting value is
processor-dependent instead of undefined.
> PS: One problematic item are Fortran 66's Hollerith (deleted in
> Fortran 77, but listed there in Appendix C); as I assume that
> assigning Hollerith constants to logical variables is rather the
> exception than the rule, I was thinking of having a flag (default off)
> to treat logical variables internally as integer variables, which
> would preserve the bit pattern. For the assignment of Hollerith
> constants to logical variables one could print an error or a warning,
> which points to the compiler flag.
Hollerith constants can't be used in assignment at all - not in any
version of the standard. Recheck Appendix C. It explicitly lists the
only places where Hollerith is allowed. It is a *VERY* restricted list.
An even more careful reading reveals that the things you can validly do
with a variable that is defined with a Hollerith value are equally
restricted. Note the bit in f77 Appendix C that says
"When an entity of type integer, real, or logical is defined with a
Hollerith value, the entity and its associates become undefined for use
as an integer, real, or logical datum."
Think about that a bit and you will realize that it is nonstandard to do
things like assignments from variables that have Hollerith values.
Assignment statements require that the right-hand-size be evaluated and
give a value of an appropriate type. If j has a Hollerith value, then
j = i
is illegal (I'm assuming both i and j are integers) because i is not
defined with an integer value as would be required for this to be valid.
If you really stick strictly to the standard, what you can do with
Holleriths is incredibly restricted. And those of us with experience in
pre-f77 compilers can often relate tales of Hollerith oddities, where
Holleriths didn't always work well with some types on some machines; the
problematic types did vary among machines.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
John Harper
Tobias Burnus <bur...@net-b.de> wrote:
>
>First some background: The middle-end part of the GCC compiler has a
>boolean data type, which has the values true and false but does not
>care about bit patterns. gfortran is using that data type for LOGICAL
>variables; very recently it was found that certain expressions were
>not optimized ("folded") correctly in the middle end, but these doing
>so, the following program:
> logical :: b
> integer :: i
> i = 42
> b = transfer(i, b)
> i = transfer(b, i)
> print *, i
> end
>prints "1" instead of "42".
All four compilers available to me (g95, Sun f95, ifort, gfortran)
print "42" as they should IMHO. My last line of gfortran -v output is:
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
Glen Herrmannsfeldt
(big snip)
> Yes. Transfer rather explicitly talks about bit patterns. It also states
> a requirement (which I've said before I think to be a mistake) on being
> able to do a transfer and then a transfer back and get the same result.
Especially since the standard doesn't require a binary
representation, putting any requirement on bit patterns
seems strange.
> *BUT*, even if you literally follow that requirement, there turn out to
> be gaping loopholes that pretty much prevent the user from being able to
> count on bit pattern preservation.
> In particular, your example above has asignment statements. An
> assignment is *NOT* guaranteed to preserve bit patterns. In fact, pretty
> much nothing is. Transfer is unusual in talking about bit patterns at
> all. (The requirement that transfer and transfer back give the same
> result does *NOT* imply a requirement on assignment statements.)
> Equivalence, for example, says nothing about bit patterns. What it does
> say is that if you equivalence two variables of different types (say a
> real and an integer), then defining one of the variables causes the
> other to become undefined. recall that referencing an undefined variable
> is illegal.
Not that it slowed people down from doing it...
> Transfer is subtly different in that it says the resulting value is
> processor-dependent instead of undefined.
(snip)
> Hollerith constants can't be used in assignment at all - not in any
> version of the standard. Recheck Appendix C. It explicitly lists the
> only places where Hollerith is allowed. It is a *VERY* restricted list.
Lots of variables in DATA statements, the only purpose
being to store constants that couldn't be used in other
places. (The I/O list of WRITE statements being another.)
> An even more careful reading reveals that the things you can validly do
> with a variable that is defined with a Hollerith value are equally
> restricted. Note the bit in f77 Appendix C that says
> "When an entity of type integer, real, or logical is defined with a
> Hollerith value, the entity and its associates become undefined for use
> as an integer, real, or logical datum."
Along with the following from Fortran 66 (10.3):
"At the time of execution of an output statement, every entity
whose value is to be transmitted to the output medium must
be defined unless the output is under control of a format
specification, and the corresponding conversion code is A."
Hollerith constants are allowed in CALL, but I don't see
any description of what actually happens if you use one.
Also, the number of characters that fit in a variable is
system dependent, so should probably be one for portable
code.
> Think about that a bit and you will realize that it is nonstandard to do
> things like assignments from variables that have Hollerith values.
> Assignment statements require that the right-hand-size be evaluated and
> give a value of an appropriate type. If j has a Hollerith value, then
> j = i
> is illegal (I'm assuming both i and j are integers) because i is not
> defined with an integer value as would be required for this to be valid.
> If you really stick strictly to the standard, what you can do with
> Holleriths is incredibly restricted. And those of us with experience in
> pre-f77 compilers can often relate tales of Hollerith oddities, where
> Holleriths didn't always work well with some types on some machines; the
> problematic types did vary among machines.
I don't even see that you can do a comparison in an IF statement,
but I know programs that did that claimed to follow the standard.
-- glen
Tobias Burnus
thanks for your reply.
On 11 Nov., 21:09, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Hollerith was normally done using INTEGER variables. While the
> standard allows for LOGICAL or REAL variables, the results
> might be system dependent. REAL variables might be normalized
> on assignment, which would change Hollerith data.
That's good to know, that reduces the chance that a legacy code
contains those.
On 11 Nov., 21:51, nos...@see.signature (Richard Maine) wrote:
> Yes. Transfer rather explicitly talks about bit patterns. It also states
> a requirement (which I've said before I think to be a mistake) on being
> able to do a transfer and then a transfer back and get the same result.
For constants (= compile-time evaluation) that actually works with
gfortran; for variables it might fail for logical variables - and
possibly depending on the chosen optimization level.
> *BUT*, even if you literally follow that requirement, there turn out to
> be gaping loopholes that pretty much prevent the user from being able to
> count on bit pattern preservation.
That was what I was thinking and hoping for.
> > PS: One problematic item are Fortran 66's Hollerith
>
> Hollerith constants can't be used in assignment at all - not in any
> version of the standard. Recheck Appendix C. It explicitly lists the
> only places where Hollerith is allowed. It is a *VERY* restricted list.
Well, using DATA there is the same problem.
> If you really stick strictly to the standard, what you can do with
> Holleriths is incredibly restricted. And those of us with experience in
> pre-f77 compilers can often relate tales of Hollerith oddities, where
> Holleriths didn't always work well with some types on some machines; the
> problematic types did vary among machines.
(I have to admit I never have used any program with Hollerith.)
The new version of the patch prints now a compile-time warning when
"assigning" (incl. initializing in a DATA statement) a Hollerith
constant to a logical variable or a assigning a transferred non 0 or 1
to logical.
Thanks for reassuring that there is no problem with regards to the
standard and seemingly also not with most legacy or most real-world
code.
On 11 Nov., 22:21, har...@mcs.vuw.ac.nz (John Harper) wrote:
> All four compilers available to me (g95, Sun f95, ifort, gfortran)
> print "42" as they should IMHO. My last line of gfortran -v output is:
> gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
If you use GCC 4.2 to 4.4 with the option -O1 or higher you get a "0";
without optimization (-O0) or with GCC 4.1 one gets "42". Using NAG
f95 one gets the "42" but a warning: "TRANSFER to LOGICAL might
produce invalid value". And if you change "transfer(i,b)" into
"transfer(42, b)", one gets a "1" with g95.
Tobias
Richard Maine
> Richard Maine wrote:
> > Equivalence, for example, says nothing about bit patterns. What it does
> > say is that if you equivalence two variables of different types (say a
> > real and an integer), then defining one of the variables causes the
> > other to become undefined. recall that referencing an undefined variable
> > is illegal.
>
> Not that it slowed people down from doing it...
Of course it didn't slow them down. I've done such things myself plenty
of times. And it almost always works. The exceptions are pretty
arcane... but they exist.
> > Hollerith constants can't be used in assignment at all - not in any
> > version of the standard.
...
> > An even more careful reading reveals that the things you can validly do
> > with a variable that is defined with a Hollerith value are equally
> > restricted.
...
> > Think about that a bit and you will realize that it is nonstandard to do
> > things like assignments from variables that have Hollerith values.
> I don't even see that you can do a comparison in an IF statement,
> but I know programs that did that claimed to follow the standard.
People claim lots of things. That doesn't mean I agree with them. I
can't find any justification for the claim that there is a comparison
operator that the standard says works with Hollerith. (I assume that's
how to interpret the above. There isn't anything at all special about IF
statements; they just use logical expressions, so it is the comparison
operator that would be in question).
e p chandler
> Richard Maine wrote:
[about internal representation of data types as it relates to
conversion between types]
> Also, the number of characters that fit in a variable is
> system dependent, so should probably be one for portable
> code.
Unicode (16 bits) on a PDP-12 (12 bit words)?
>
> > Think about that a bit and you will realize that it is nonstandard to do
> > things like assignments from variables that have Hollerith values.
> > Assignment statements require that the right-hand-size be evaluated and
> > give a value of an appropriate type. If j has a Hollerith value, then
> > j = i
> > is illegal (I'm assuming both i and j are integers) because i is not
> > defined with an integer value as would be required for this to be valid.
> > If you really stick strictly to the standard, what you can do with
> > Holleriths is incredibly restricted. And those of us with experience in
> > pre-f77 compilers can often relate tales of Hollerith oddities, where
> > Holleriths didn't always work well with some types on some machines; the
> > problematic types did vary among machines.
>
> I don't even see that you can do a comparison in an IF statement,
> but I know programs that did that claimed to follow the standard.
>
Yet people wrote code that way. Look at the code for "Original
Adventure". See the contortions needed to stuff "character" data into
integer variables, read them, write them, compare them. IIRC there
were routines to unpack and pack "characters" between machine words
and arrays of integers -- without BIT intrinsics.
Other languages, like COBOL, have always had character data as an
intrinsic type. IIRC Cobol requires that a string of 10 characters
must interoperate with an array containing 10 characters otherwise
REDEFINES (which allows using the same storage in different ways)
fails to work. A table of 3 character month abbreviations has its
VALUE set as a single string (PIC X(36)), but is then accessed as an
array of 12 3 character strings (PIC X(3) OCCURS 12 TIMES).
- e
Glen Herrmannsfeldt
> There isn't anything at all special about IF
> statements; they just use logical expressions, so it is the comparison
> operator that would be in question).
There is also Arithmetic IF to avoid logical expressions.
-- glen
Richard Maine
The only thing it can test is positive/negative/zero. I posted the above
in response to your statement
>>> I don't even see that you can do a comparison in an IF statement,
>>> but I know programs that did that claimed to follow the standard.
If that is still what you are talking about, and you think that the
people in question were claiming that a test for positive/negative/zero
of a Hollerith value was standard conforming, then the claims are not
plausible enough to be worth discussion. If you have changed the subject
without warning, well, then that would be a different subject.
James Van Buskirk
news:1iq8q9d.173a38j11s7drqN%nos...@see.signature...
> Tobias Burnus <bur...@net-b.de> wrote:
>> I have a question with regards to the internal representation of a
>> LOGICAL variable, especially from point of the gfortran compiler.
> I suspect another regular poster will pop in here, as this
> seems to be one of his pet peeves.
I don't have time and energy to accept your invitation just now, nor
will I for a couple of days. Since I haven't yet swayed you or
anyone else to my viewpoint, I will have to simply remain a
majority of one for the time being.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Ian Bush
> "Richard Maine" <nos...@see.signature> wrote in message
>
> news:1iq8q9d.173a38j11s7drqN%nos...@see.signature...
>
> > Tobias Burnus <bur...@net-b.de> wrote:
> >> I have a question with regards to the internal representation of a
> >> LOGICAL variable, especially from point of the gfortran compiler.
> > I suspect another regular poster will pop in here, as this
> > seems to be one of his pet peeves.
>
> I don't have time and energy to accept your invitation just now, nor
> will I for a couple of days. Since I haven't yet swayed you or
> anyone else to my viewpoint, I will have to simply remain a
> majority of one for the time being.
>
Oh c'mon. This is USENET. Please uphold its standards. Surely at the
very least
the lurkers agree with you in email,
Ian
dominiq
dependent, is it legal?
integer :: i(5), j
logical :: l(5), m
i = (/(j-3,j=1,5)/)
write(10) i
close(10)
read(10) l
close(10)
print *, l
print *, i
m = l(1)
write(10) m
close(10)
read(10) j
print *, j, m
end
Note that ifort yields:
F T F T F
-2 -1 0 1 2
-2 F
F is LSB==0, T is LSB==1, and gfortran and g95 yield
T T F T T
-2 -1 0 1 2
-2 T
F is ==0, T is !=0.
Dominique
Richard Maine
> Aknowledging that the output of the following code is "processor"
> dependent, is it legal?
[eliding much]
> integer :: i(5), j
> logical :: l(5), m
...
> write(10) i
...
>read(10) l
No. And to clarify, what is illegal is the code - not the compilers.
This is in the class of illegal code that compilers can do anything
with, so the display of compiler outputs is irrelevant (enough so that I
didn't actually bother to study them).
I mentioned in my prior post that transfer gives results that are
described as processor dependent. Most other ways of getting simillar
effects do not have the processor dependent description; they are just
plain illegal (well, nonstandard). That includes this trick of writing
and reading unformatted data using different types.
So note that, no "processor dependent" is not the technically correct
description of this case. The code is just nonstandard. The distinction
can be subtle. One example of the distinction is that for nonstandard
code, you could potentially get things like a program abort instead of
just "strange" values.
From the f95 standard, in 9.4.4.4.1, Unformatted data transfer
"On input... Each value in the record shall be of the same type as the
corresponding entity in the input list, except [complex versus 2
reals]."
Note that is just plain a requirement. If your code doesn't do that,
nothing is guaranteed. No, an error message isn't guaranteed either.
Although the expected implementation of unformatted I/O involves just
copying the bits, nowhere does the standard actually require that. It
could validly do such things as tag each data item with the appropriate
type and bitch if the type doesn't match during the read; I don't know
of any such implementations, and I'd be quite surprised to see one, but
the standard allows it. That would be a bit like some database
operations, but Fortran unformatted I/O tends to go much more for being
raw than quite that processed (and slow).
In fact, until I drug out the standard to get the above citation, I had
forgotten quite how restrictive the standard is on this one. In
particular, you are not allowed to "cheat" an n-array of character*1
with a scalar character*n.
You also can't "cheat" a derived-type object with a list of its
components; that one I did recall. (This basically allows the processor
to do things like reorder or pad components without having to somehow
compensate in unformatted I/O).
Glen Herrmannsfeldt
> dominiq <dom...@lps.ens.fr> wrote:
(snip)
>>integer :: i(5), j
>>logical :: l(5), m
>>write(10) i
>>read(10) l
> No. And to clarify, what is illegal is the code - not the compilers.
> This is in the class of illegal code that compilers can do anything
> with, so the display of compiler outputs is irrelevant (enough so that I
> didn't actually bother to study them).
The thing about this question is that the standard doesn't
let you do these things because it might not be possible
or reasonably on some computers. If you find such a machine
today it is likely in a museum, though.
> I mentioned in my prior post that transfer gives results that are
> described as processor dependent. Most other ways of getting simillar
> effects do not have the processor dependent description; they are just
> plain illegal (well, nonstandard). That includes this trick of writing
> and reading unformatted data using different types.
As I understand it, the standard requires INTEGER and LOGICAL to use
the same number of file storage units, and also the same number of
memory storage units. The obvious solution is to copy the bits,
though as you say the standard doesn't require that.
WRITE/READ seems slightly more likely to actually copy the
bits than assignment. With 32 bit machines, it doesn't seem
likely that assignment wouldn't copy all the bits, but for 16 bit
machines I know some would only copy 16 bits of an integer that
took up 32 bits in memory.
> So note that, no "processor dependent" is not the technically correct
> description of this case. The code is just nonstandard. The distinction
> can be subtle. One example of the distinction is that for nonstandard
> code, you could potentially get things like a program abort instead of
> just "strange" values.
> From the f95 standard, in 9.4.4.4.1, Unformatted data transfer
> "On input... Each value in the record shall be of the same type as the
> corresponding entity in the input list, except [complex versus 2
> reals]."
To stretch this even farther:
integer :: i(5), k(5), j
logical :: l(5), m
equivalence (k,l)
write(10) i
rewind 10
read(10) l
print *,k
> Note that is just plain a requirement. If your code doesn't do that,
> nothing is guaranteed. No, an error message isn't guaranteed either.
> Although the expected implementation of unformatted I/O involves just
> copying the bits, nowhere does the standard actually require that. It
> could validly do such things as tag each data item with the appropriate
> type and bitch if the type doesn't match during the read; I don't know
> of any such implementations, and I'd be quite surprised to see one, but
> the standard allows it.
There used to be computers that would tag memory locations
to indicate the type of the current value. In that case, it wouldn't
seem surprising to write the tags to disk (or tape).
> That would be a bit like some database
> operations, but Fortran unformatted I/O tends to go much more for being
> raw than quite that processed (and slow).
That sort of goes against the idea of unformatted of being fast.
> In fact, until I drug out the standard to get the above citation, I had
> forgotten quite how restrictive the standard is on this one. In
> particular, you are not allowed to "cheat" an n-array of character*1
> with a scalar character*n.
That one is surprising considering the other places that
you can do that.
> You also can't "cheat" a derived-type object with a list of its
> components; that one I did recall. (This basically allows the processor
> to do things like reorder or pad components without having to somehow
> compensate in unformatted I/O).
-- glen
Jan Vorbrüggen
>> integer :: i
>> i = 42
>> b = transfer(i, b)
>> i = transfer(b, i)
>> print *, i
>> end
>> prints "1" instead of "42".
>>
>> My question is now: Is there anything in the standard with regards to
>> TRANSFER, COMMON, EQUIVALENCE etc. which mandates that the bit pattern
>> has to be preserved?
>
> Yes. Transfer rather explicitly talks about bit patterns. It also states
> a requirement (which I've said before I think to be a mistake) on being
> able to do a transfer and then a transfer back and get the same result.
>
> *BUT*, even if you literally follow that requirement, there turn out to
> be gaping loopholes that pretty much prevent the user from being able to
> count on bit pattern preservation.
>
> In particular, your example above has asignment statements. An
> assignment is *NOT* guaranteed to preserve bit patterns.
My understanding of this particular combination of requirements has been
that only a statement such as
j = transfer (transfer (i, b), j))
need retain the bit pattern such that j == i evaluatues to .TRUE., if
said combination of requirements were to mean anything reasonable at all.
The reasonableness or utility of such a requirement is, of course,
subject to debate.
Jan