--- Comment #8 from burnus at gcc dot gnu dot org 2007-12-08 21:59 ---
FIXED on the trunk (4.3.0).
gfortran now transfers
DATA DMACH(2) / Z'7FEF' /
bitwise for real/complex variables. Note: For -std=f95/f2003 this is rejected.
For details how non-standard BOZ are (now) i
--- Comment #7 from burnus at gcc dot gnu dot org 2007-12-08 21:47 ---
Subject: Bug 34345
Author: burnus
Date: Sat Dec 8 21:46:56 2007
New Revision: 130713
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130713
Log:
2007-12-08 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #6 from burnus at gcc dot gnu dot org 2007-12-06 21:34 ---
> > but the committee seems the have lost track of why programs need specific
> > bit patterns and how they are used.
>
> See the TRANSFER intrinsic. I think J3 recognized the problems with
> specify a bit pattern.
--- Comment #5 from kargl at gcc dot gnu dot org 2007-12-06 19:13 ---
(In reply to comment #4)
> I have several programs (f77 and f90) that do this and their intent is clear -
> just put the bit patterns into to words as requested - no data conversion - no
> range checking.
Which is of
--- Comment #4 from dir at lanl dot gov 2007-12-06 14:56 ---
I have several programs (f77 and f90) that do this and their intent is clear -
just put the bit patterns into to words as requested - no data conversion - no
range checking. BOZ seems to have been created for this purpose, but
--- Comment #3 from kargl at gcc dot gnu dot org 2007-12-06 04:39 ---
(In reply to comment #2)
> Reading through PR 18026 I am convinced this is a duplicate. We need to
> decide
> how we want to handle this situation. It looks like at least one other
> compiler treats the boz as an in
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-06 03:42
---
Reading through PR 18026 I am convinced this is a duplicate. We need to decide
how we want to handle this situation. It looks like at least one other
compiler treats the boz as an integer and converts to real fo
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-05 12:55 ---
I think the problem is the interpretation of:
DATA DMACH(1) / Z'0010' /
as DMACH is REAL. The Fortran standard only allows BOZ in DATA for integers.
Fortran 2003 also allows, e.g.,
real :: r =
