--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-13 13:59 ---
*** Bug 29814 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:05
---
(In reply to comment #4)
> Can this PR be closed?
I'd say yes.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2006-09-29 20:52 ---
Can this PR be closed? How BOZ constants are interpreted is in accordance with
the F95 standard's DATA statement. The extension of BOZs in assignments does
change the intrepretation. With a slightly modified program
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-14 17:29 ---
Remove "wrong-code" keyword because gfortran is doing
the correct thing with a BOZ-literal-constant with the
exception of permitting BOZ-literal-constant in non-DATA
statements.
--
kargl at gcc dot gnu dot org chan
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-14 17:25 ---
Gfortran is doing the right thing with respect to
a BOZ-literal-constant (other than a BOZ can only
be used in a DATA statement per the F95 standard,
so the code is invalid).
If you look at the definition of BOZ in th
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-12 23:53 ---
(In reply to comment #0)
> (And why is hexadecimal shown as 0 in the dump?)
Because that means TREE_OVERFLOW is set for some reason.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Re
