public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libfortran/52087] New: program does not follow logical rules
@ 2012-02-02 0:17 ryan.maclellan at ua dot edu
2012-02-02 0:46 ` [Bug libfortran/52087] " kargl at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: ryan.maclellan at ua dot edu @ 2012-02-02 0:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52087
Bug #: 52087
Summary: program does not follow logical rules
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: ryan.maclellan@ua.edu
Created attachment 26549
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26549
minimal source code to reproduce bug (5 lines)
The following program tests if the input logical variable is a valid logical
variable. It only behaves as expected if the two logical tests are separately
in () although from the order of operations I would expect it to work as is.
Incidentally, if I make nt_save .false. or interchange the true and false in
the if statement it does work without the ().
does not write:
program main
logical*4 nt_save/.true./
if ( nt_save.eqv..true. .or. nt_save.eqv..false. ) then
write(*,*) nt_save
endif
end
does write with
if ( (nt_save.eqv..true.) .or. (nt_save.eqv..false.) ) then
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/52087] program does not follow logical rules
2012-02-02 0:17 [Bug libfortran/52087] New: program does not follow logical rules ryan.maclellan at ua dot edu
@ 2012-02-02 0:46 ` kargl at gcc dot gnu.org
2012-02-02 0:58 ` ryan.maclellan at ua dot edu
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: kargl at gcc dot gnu.org @ 2012-02-02 0:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52087
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org 2012-02-02 00:45:45 UTC ---
What are the precedence rules for logical operators?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/52087] program does not follow logical rules
2012-02-02 0:17 [Bug libfortran/52087] New: program does not follow logical rules ryan.maclellan at ua dot edu
2012-02-02 0:46 ` [Bug libfortran/52087] " kargl at gcc dot gnu.org
@ 2012-02-02 0:58 ` ryan.maclellan at ua dot edu
2012-02-02 2:10 ` sgk at troutmask dot apl.washington.edu
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: ryan.maclellan at ua dot edu @ 2012-02-02 0:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52087
--- Comment #2 from Ryan MacLellan <ryan.maclellan at ua dot edu> 2012-02-02 00:57:29 UTC ---
I believe precedence is as follows:
arithmetic expressions evaluated first
followed by relational operators
followed by logical operators
In this case I believe .eqv. are relational operators (equivalent to .eq.) and
.or. is the logical operator. So the .or. should be evaluated last but it
doesn't seem to be. If this is not the design precedence or .eqv. is not
considered a relational operators then I may simply be in error. Otherwise I
think this is a bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/52087] program does not follow logical rules
2012-02-02 0:17 [Bug libfortran/52087] New: program does not follow logical rules ryan.maclellan at ua dot edu
2012-02-02 0:46 ` [Bug libfortran/52087] " kargl at gcc dot gnu.org
2012-02-02 0:58 ` ryan.maclellan at ua dot edu
@ 2012-02-02 2:10 ` sgk at troutmask dot apl.washington.edu
2012-02-02 2:32 ` ryan.maclellan at ua dot edu
2012-02-02 8:36 ` burnus at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2012-02-02 2:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52087
--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-02-02 02:10:04 UTC ---
On Thu, Feb 02, 2012 at 12:57:29AM +0000, ryan.maclellan at ua dot edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52087
>
> --- Comment #2 from Ryan MacLellan <ryan.maclellan at ua dot edu> 2012-02-02 00:57:29 UTC ---
> I believe precedence is as follows:
> arithmetic expressions evaluated first
> followed by relational operators
> followed by logical operators
>
> In this case I believe .eqv. are relational operators (equivalent to .eq.) and
> .or. is the logical operator. So the .or. should be evaluated last but it
> doesn't seem to be. If this is not the design precedence or .eqv. is not
> considered a relational operators then I may simply be in error. Otherwise I
> think this is a bug.
>
See Table 7.7 in the Fortran 2003 standard (Or your favorite
Fortran reference).
Table 7.7: Categories of operations and relative precedence
Category of operation Operators Precedence
Extension defined-unary-op Highest
Numeric ** .
Numeric * or / .
Numeric unary + or - .
Numeric binary + or - .
Character // .
Relational .EQ., .NE., .LT., .LE., .GT., .GE.,
==, /=, <, <=, >, >= .
Logical .NOT. .
Logical .AND. .
Logical .OR. .
Logical .EQV. or .NEQV. .
Extension defined-binary-op Lowest
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/52087] program does not follow logical rules
2012-02-02 0:17 [Bug libfortran/52087] New: program does not follow logical rules ryan.maclellan at ua dot edu
` (2 preceding siblings ...)
2012-02-02 2:10 ` sgk at troutmask dot apl.washington.edu
@ 2012-02-02 2:32 ` ryan.maclellan at ua dot edu
2012-02-02 8:36 ` burnus at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ryan.maclellan at ua dot edu @ 2012-02-02 2:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52087
Ryan MacLellan <ryan.maclellan at ua dot edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #4 from Ryan MacLellan <ryan.maclellan at ua dot edu> 2012-02-02 02:32:08 UTC ---
Apparently .eqv. is a logical expression and not a relational one. Further, it
is lower precedence than .or. so this is not a bug at all and the code behaves
as it should.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/52087] program does not follow logical rules
2012-02-02 0:17 [Bug libfortran/52087] New: program does not follow logical rules ryan.maclellan at ua dot edu
` (3 preceding siblings ...)
2012-02-02 2:32 ` ryan.maclellan at ua dot edu
@ 2012-02-02 8:36 ` burnus at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-02 8:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52087
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-02 08:34:15 UTC ---
(In reply to comment #0)
> if ( (nt_save.eqv..true.) .or. (nt_save.eqv..false.) ) then
Side remark: It often is clearer and avoids precedence issues if one writes
instead:
if (nt_save .or. .not. nt_save) then
The .eqv. and .neqv. operators are then only used when comparing two logical
variables with each other.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-02 8:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-02 0:17 [Bug libfortran/52087] New: program does not follow logical rules ryan.maclellan at ua dot edu
2012-02-02 0:46 ` [Bug libfortran/52087] " kargl at gcc dot gnu.org
2012-02-02 0:58 ` ryan.maclellan at ua dot edu
2012-02-02 2:10 ` sgk at troutmask dot apl.washington.edu
2012-02-02 2:32 ` ryan.maclellan at ua dot edu
2012-02-02 8:36 ` burnus at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).