http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
--- Comment #15 from Tobias Burnus ---
As follow up: Recent Intel Fortran Compilers have the fixed it - but one
currently has to use -standard-semantics in order to get the compatible result.
[I don't know which options Intel uses for the Math Ke
--- Comment #14 from jb at gcc dot gnu dot org 2010-04-25 19:04 ---
The GFortran behavior is now documented on 4.4, 4.5, and trunk. Closing as
fixed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jb at gcc dot gnu dot org 2010-04-25 19:01 ---
Subject: Bug 40539
Author: jb
Date: Sun Apr 25 19:01:06 2010
New Revision: 158707
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158707
Log:
PR fortran/40539 Document LOGICAL representation
Modified:
branch
--- Comment #12 from jb at gcc dot gnu dot org 2010-04-07 18:08 ---
Subject: Bug 40539
Author: jb
Date: Wed Apr 7 18:07:48 2010
New Revision: 158081
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158081
Log:
PR fortran/40539 Document LOGICAL representation
Modified:
branch
--- Comment #11 from jb at gcc dot gnu dot org 2010-04-07 18:01 ---
Subject: Bug 40539
Author: jb
Date: Wed Apr 7 18:01:24 2010
New Revision: 158080
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158080
Log:
PR fortran/40539 Document LOGICAL representation
Modified:
trunk/
--- Comment #10 from jb at gcc dot gnu dot org 2010-04-04 10:56 ---
I've been thinking a bit about this issue. Some observations
- There are a lot of compilers, and many ways of representing logicals. Being
compatible with some or all of them is, IMO, a stillborn idea. And even if we'd
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-24 18:11 ---
> > It would be nice to have an option to turn off that fast inversion, at least
> > for compatibility. Or at least to make -O0 case compatible.
> How do other vendor's (Sun, Pathscale, Absoft, etc) represent .true.
>
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-24 17:59 ---
Alexander, I just filled Issue 553679 at premier.intel.com as associated bug. I
realized that the issue is even bigger:
C99's 6.3.1.2 has "When any scalar value is converted to _Bool, the result is 0
if the value co
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-06-24 17:33 ---
Wait I don't think we should support this at all because the ABI between
gfortran and ifort are way different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
--- Comment #6 from kargl at gcc dot gnu dot org 2009-06-24 17:23 ---
(In reply to comment #5)
>
> The real problem with the issue is that code compiled with GFORTRAN could have
> issues if linked with a vendor library. I'm experiencing ones with Intel®
> MKL.
>
> It would be nice to h
--- Comment #5 from alexander dot v dot kobotov at intel dot com
2009-06-24 16:02 ---
Thanks a lot, there is indeed different values for true:
For GFORTRAN: true = 1, false = 0
For Intel Fortran: true = -1, false = 0.
In IF expression both true values works, but NOT operand in GFORTRAN
--- Comment #4 from alexander dot v dot kobotov at intel dot com
2009-06-24 15:04 ---
Created an attachment (id=18059)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18059&action=view)
LSAME asm and object for Intel64 arch.
lsame.f from reproducer compiled with Intel 9.1 Fortran c
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-24 13:45 ---
I think the problem relates to what is regarded as TRUE and what is regarded as
FALSE by the compilers (the following output has been produced by
transfer(.true.,0), transfer(.false.,0)):
gfortran has: .true. = 1,
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-24 12:37 ---
Not a self-contained bug report: Impossible to reproduce unless you have the
intel compiler. Maybe you can attach the assembler output of ifort?
--
steven at gcc dot gnu dot org changed:
What|Remov
--- Comment #1 from alexander dot v dot kobotov at intel dot com
2009-06-24 12:12 ---
Created an attachment (id=18056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18056&action=view)
The reproducer sources zipped
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
15 matches
Mail list logo
