[Bug fortran/22495] Different ideas about .true. and .false.

2006-01-29 Thread tkoenig at gcc dot gnu dot org
--- Comment #14 from tkoenig at gcc dot gnu dot org 2006-01-30 06:44 --- Closing, then. Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/22495] Different ideas about .true. and .false.

2006-01-29 Thread kargl at gcc dot gnu dot org
--- Comment #13 from kargl at gcc dot gnu dot org 2006-01-30 00:52 --- WONTFIX works for me. As you originated the PR, I'll you close it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495

[Bug fortran/22495] Different ideas about .true. and .false.

2006-01-29 Thread tkoenig at gcc dot gnu dot org
--- Comment #12 from tkoenig at gcc dot gnu dot org 2006-01-29 23:30 --- Should we mark this as WONTFIX? I'm in favor. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-06 Thread tkoenig at gcc dot gnu dot org
--- Comment #11 from tkoenig at gcc dot gnu dot org 2005-11-06 15:01 --- (In reply to comment #10) > Thomas, can you point to the text in the standard that > prohibits the equivalence of integer and logical. AFAICT, > the 4th constraint in 5.5.1, contradicts your assertation. I was wr

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-05 Thread kargl at gcc dot gnu dot org
--- Comment #10 from kargl at gcc dot gnu dot org 2005-11-06 00:32 --- > Do we care? Equivalencing integer and logical is prohibited > (although we don't warn about this with --std=f95; maybe > that is the error). Thomas, can you point to the text in the standard that prohibits the equ

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-05 Thread tobi at gcc dot gnu dot org
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||documentatio

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-05 Thread tobi at gcc dot gnu dot org
--- Comment #9 from tobi at gcc dot gnu dot org 2005-11-06 00:22 --- One can get quite interesting results out of g77, e.g. [EMAIL PROTECTED]:~/src/tests> cat ugly.f LOGICAL L, M equivalence (i,l) DO i=0,5 M = i PRINT "(5l2)", l, m, l.neqv..true., m.neqv

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-05 Thread kargl at gcc dot gnu dot org
--- Comment #8 from kargl at gcc dot gnu dot org 2005-11-06 00:02 --- The code is illegal, so every compiler has produced a correct result. -- kargl at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-05 Thread tkoenig at gcc dot gnu dot org
--- Comment #7 from tkoenig at gcc dot gnu dot org 2005-11-05 23:20 --- (In reply to comment #6) > I think we should be consistent. g77 also gives inconsistent results with the test program: $ cat logic.f program main implicit none logical :: lo1, lo2 integer :

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-05 Thread tobi at gcc dot gnu dot org
--- Comment #6 from tobi at gcc dot gnu dot org 2005-11-05 23:06 --- I did some further research, and while g77 didn't seem to have documented any of the details of how LOGICALs are implemented, we have the following in gfortran.texi:755: @node Implicitly interconvert LOGICAL and IN

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-05 Thread tkoenig at gcc dot gnu dot org
--- Comment #5 from tkoenig at gcc dot gnu dot org 2005-11-05 22:05 --- Hmm... in this case, I think we should document that only 0 and 1 are valid for logical types, and if the user stuffs anything else into one of our logicals, he is on his own. After we have documented this, we can c

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-02 Thread tobi at gcc dot gnu dot org
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-02 12:37 --- I was curious, and tried below patch, changing .EQV. to .NEQV. in the testcase, and still we don't get the "right" result, since our logical type is a real logical, in that only the lowest bit is considered. I did some

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-01 Thread tobi at gcc dot gnu dot org
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 21:36 --- Actually, the .NEQV. case would be easily fixed, as there's a TRUTH_XOR_EXPR in the middleend. On the other hand .EQV. would require adding some special case logic to gfc_conv_expr_op (admittedly, not difficult logic).

[Bug fortran/22495] Different ideas about .true. and .false.

2005-11-01 Thread tobi at gcc dot gnu dot org
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-01 21:30 --- I'd say we don't care. Results with other compilers: pgf90: 0 F F F 1 T F F 2 F F F 3 T F F 4 F F F ifort: 0 F F F 1 T T

[Bug fortran/22495] Different ideas about .true. and .false.

2005-07-15 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-15 22:19 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E