I am the primary maintainer of an open-source environmental-data
I/O library, and one of my (historically very astute) users reports
that the program below does not behave correctly when compiled with
PGI F90 (of which I don't have a copy). Either replacing the
IF-clause by the logically equivalent "IF ( LVAR ) THEN" or using
an alternate compiler (g95, ifort, sunf95) causes the program to behave
as expected.

What the ??!!? How does a bug this blatant get through testing?

Carlie Coats
Baron Advanced Meteorological Systems

----------------------------------------------------------
PROGRAM TEST_ENVYN

LOGICAL :: ENVYN, LVAR
INTEGER :: ISTAT

LVAR = ENVYN('LVAR','logical variable',.TRUE.,ISTAT)

Carlie J. Coats wrote:

What is the actual bit value of LVAR? If it is not the
same as .TRUE. or .FALSE. then it might be that it is
non-standard, and fails.

LOGICAL LVAR,ENVYN
INTEGER IVAR
EQUIVALENCE(LVAR,IVAR)
LVAR = ENVYN('LVAR','logical variable',.TRUE.,ISTAT)
WRITE(*,'(Z8)') IVAR
END

"Carlie J. Coats" jyarborough.com> wrote in message
news:R1s6k.21310$3j2.2568@trnddc03...

Carlie J. Coats jyarborough.com> wrote:

...

Well, stylistically, I far prefer the simpler "IF (LVAR)", but that
aside...

1. As Glen and James note, if your LVAR is not a properly defined
logical variable, then all bets are off; that would be a program bug,
not a compiler one, even if the program happened to work with many other
compilers. That's the kind of thing that happens with nonstandard code.

James Van Buskirk wrote:
(snip)

I know DEC compilers were allowing integers as operands
of logical operators generating bitwise logical results
in the Fortran 66 days. They would also convert between
INTEGER and LOGICAL transferring the bits over. As well
as I remember, they only tested one bit, though I am not
sure which one.

The bitwise logical functions seem a better way to me.

It would be nice if C had the ^^ and ^^= operators.

-- glen

glen herrmannsfeldt wrote:
...

Well, a^^b would be the same as !a ^ !b. So, a^^=b would
be a = !a ^ !b. Of course if the thing on the left of the assignment
were a lvalue whose generaton involved side-effects, you would
have to introduce a temporary pointer variable. It's C after all.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."

In article comcast.com>,
James Van Buskirk comcast.net> wrote:

I don't read your postings very often, and this statement is a good
example of why. Every compiler team that I'm familiar with has some
real Fortran guys on it, and several of them read this newsgroup.

Just because you think representing LOGICALs has an obvious answer
doesn't mean that they agree with you, especially when you're
arguing against historical choices, and in a rude fashion.

-- greg

On Thu, 19 Jun 2008 12:11:29 GMT, "Carlie J. Coats" jyarborough.com>
wrote:

I suppose that if LVAR's value was not the canonical .TRUE. or .FALSE. value
(that is, it got defined in some manner other than the result of a LOGICAL
assignment or expression) then the standard perhaps is silent on the behavior,
but... Since using IF (LVAR) worked, something very odd is happening and an
inquiry to PGI is in order. Nevertheless, I agree with others that IF(LVAR)
is the preferred syntax.

Some years ago I wrote an article on common misimpressions regarding the
LOGICAL type and its uses, with a special note regarding .EQV.. You can find
it at http://tinyurl.com/4aqgtn

"Richard Maine" wrote in message
news:1iis15t.g71d55uykqlsN%%nospam@see.signature...

Um, no. If we look at n1124.pdf, section 6.3.1.2:

"When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1."

James Van Buskirk comcast.net> wrote:

I vehemently disagree with you on this (which is to say that I agree
with the vendors). There is not a single vendor that fails to "adhere to
the truth tables given in the standard document."

Those truth tables, like every other operation definition in the
standard, apply only to operand values that are "defined" in the precise
sense of the standard. If you have done any form of bit twiddling on the
logical values, then the standard clearly and explicitly says that the
values are not defined.

Once you reference an undefined value, all bets are off. That is the
program violating the standard, not the compiler. The compiler is under
no obligation to detect such problems or to give any consistent results.