--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-12-14 07:01
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-14 07:00
---
Subject: Bug 38504
Author: jvdelisle
Date: Sun Dec 14 06:58:38 2008
New Revision: 142748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142748
Log:
2008-12-13 Jerry DeLisle
PR libfortran/3850
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-14 06:52
---
Subject: Bug 38504
Author: jvdelisle
Date: Sun Dec 14 06:50:53 2008
New Revision: 142747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142747
Log:
2008-12-13 Jerry DeLisle
PR libfortran/3850
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-12-13 19:34
---
Testing this.
Index: write.c
===
--- write.c (revision 142574)
+++ write.c (working copy)
@@ -600,9 +600,16 @@ write_decimal (st_parameter_
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-12-13 16:28
---
I have isolated the problem to gfc_itoa. gfc_itoa returns a string. The number
of digits is determined from the strlen of that string. At -m32, that string
length (digits, see below) is off by one. I instrumente
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:42
---
Reduced test case. Fails at -m32
program IntAdtest
integer, parameter :: i8_ = Selected_Int_Kind(18) ! = integer*8
integer(i8_) :: value
value = -9223372036854775807_i8_ -1
write(*, '(i22)') value
end
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:32
---
I have also found on pr38472 some odd behaviour at -m32. That we see this with
an integer output has my concern level up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
--- Comment #6 from burnus at gcc dot gnu dot org 2008-12-13 11:19 ---
For completeness, on my x86-64-linux system I get with 4.4.0, 4.3.0 and with
openSUSE binaries (4.1, 4.2, 4.3, 4.4) always a single "-".
Hmm, OK found something: With -m32 I get "--" but with -m64 (default) I get
"-"
--- Comment #5 from kargl at gcc dot gnu dot org 2008-12-12 16:03 ---
Looking at the -fdump-tree-original, I suspect that the minus sign in
the hex formatted number is redundant. To keep things short, I've removed
the dt_parm setup code. _gfortran_transfer_integer probably outputs -,
th
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-12-12 15:59 ---
> > Sort of confirmed. You are aware that 'value-1' corresponds to
> > '-HUGE(value)-1', which is out of range for integer numbers of that kind?
>
> No. It is in range.
Loose wording on my side, s/range/model/ then
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-12 15:15 ---
(In reply to comment #1)
> Sort of confirmed. You are aware that 'value-1' corresponds to
> '-HUGE(value)-1', which is out of range for integer numbers of that kind?
>
( Ihaven't had my morning coffe, but ...)
No. I
--- Comment #2 from kloedej at knmi dot nl 2008-12-12 14:47 ---
(In reply to comment #1)
> Sort of confirmed. You are aware that 'value-1' corresponds to
> '-HUGE(value)-1', which is out of range for integer numbers of that kind?
Thanks for your reply.
Yes I am aware that defining an in
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-12-12 13:55 ---
Sort of confirmed. You are aware that 'value-1' corresponds to
'-HUGE(value)-1', which is out of range for integer numbers of that kind?
Reduced testcase:
IntAdtest
integer, parameter :: i8_ = Selected_Int_Kind(1
13 matches
Mail list logo
