This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/34345] gfortran compiles SLATEC library, but the executable fails
- From: "kargl at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Dec 2007 04:39:49 -0000
- Subject: [Bug fortran/34345] gfortran compiles SLATEC library, but the executable fails
- References: <bug-34345-15478@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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 integer and converts to real for the case of f95
> and treats it as a direct map to real for f2003.
>
> Should we take a vote?
My vote is gfortran is doing the correct thing. The user
needs to read and understand the standard. Then, the
the user can use TRANSFER() as intended by J3.
In particular, a DATA statement is essentially an assignment.
In an assignment the RHS is evaluated without reference to the
LHS type, kind type parameter, or rank.
If you want to promote a BOZ to some glorified representation
of any numeric value, then you'll need to introduce BT_BOZ,
and add a member to gfc_symbol to hold the BOZ string and do
the conversion to the what the user wants at the last moment.
This, of course, violates the independence of the RHS-LHS
assumption.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34345