http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
Thomas Henlich changed:
What|Removed |Added
Attachment #24120|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #8 from Thomas Henlich
2011-04-30 11:58:36 UTC ---
> I think for rounding up we need to test if ALL the cut off digits are zeros.
One more thought: It might be (statistically) faster to scan the digits from
last to first than vice ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #10 from Thomas Henlich
2011-04-30 15:56:35 UTC ---
The start to scan is the digit corresponding to d+1.
e.g.
PRINT "(RU,F0.4)", .162548148
-> .1626 because48148 > 0
PRINT "(RU,F0.4)", 3.1415926536
->
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488
Thomas Henlich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047
Thomas Henlich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684
Thomas Henlich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785
--- Comment #2 from Thomas Henlich
2011-05-02 12:58:42 UTC ---
Created attachment 24162
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24162
Proposed patch for input/output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785
--- Comment #3 from Thomas Henlich
2011-05-02 13:01:33 UTC ---
Created attachment 24163
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24163
Test case for input/output of real numbers with B/O/Z editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #14 from Thomas Henlich
2011-05-02 13:24:27 UTC ---
Created attachment 24164
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24164
Revised patch including rounding down negative numbers
Sorry, my bug report should have been more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
Thomas Henlich changed:
What|Removed |Added
Attachment #24138|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785
--- Comment #6 from Thomas Henlich
2011-05-02 14:10:22 UTC ---
Can you elaborate on this?
Previously we allowed the format with -std=gnu.
Now we want to allow it with -std=gnu or -std=f2008. So we call require_type()
only if neither of these op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785
--- Comment #8 from Thomas Henlich
2011-05-02 15:12:06 UTC ---
(In reply to comment #7)
O, I see. The important part is in
set_default_std_flags (void)
{
gfc_option.allow_std = GFC_STD_F95_OBS | GFC_STD_F95_DEL
| GFC_STD_F2003 | GFC_STD_F2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
Summary: Invalid spaces in list-directed output of complex
constants
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #49 from Thomas Henlich
2011-05-04 12:48:28 UTC ---
(In reply to comment #47)
> (In reply to comment #46)
> > I have started on the second phase of this effort which is to get rid of the
> > floating point issue on -m32 machines.
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
--- Comment #4 from Thomas Henlich
2011-05-05 06:50:13 UTC ---
(In reply to comment #3)
> neither 0PFw.d nor 1PEw.dEe allow it). However, AFAICS leading blanks are
> still
> allowed as they are part of the real parts, the prohibition against emb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
--- Comment #13 from Thomas Henlich
2011-05-05 10:57:33 UTC ---
G95 is actually using this method for list-directed output.
print *, .3, .33, .333, ., .3, .33, .333
g95 => 0.3 0.33 0.333 0. 0.3 0.33 0.333
gfortra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
--- Comment #8 from Thomas Henlich
2011-05-05 13:31:47 UTC ---
(In reply to comment #6)
> Also, See below. Does this give the expected output?
>
> print *, (1.0, 0.0)
> end
>
> $ ./a.out
> (1.,.)
I personally prefer the opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925
Summary: Code cleanup in write_float.def
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassig.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #4 from Thomas Henlich
2011-05-10 17:16:47 UTC ---
Way to go! I'll be happy to test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48958
Summary: Add runtime diagnostics for SIZE intrinsic function
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960
Summary: OPEN statement modifies NEWUNIT variable on error
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961
Summary: EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961
--- Comment #2 from Thomas Henlich
2011-05-11 16:38:52 UTC ---
The program is executed, as the called program "hello.exe" prints "Hello
world". After that hello.exe returns and the runtime error occurs.
Further testing shows that it is executed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at users dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
Summary: FRACTION und EXPONENT return invalid results for
infinity/NaN
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #2 from Thomas Henlich
2011-05-12 17:34:27 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> >
> > Bug 1:
> > The program does not compile without -fno-range-check.
> >
>
> Can you explain why you think that this is a b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #11 from Thomas Henlich
2011-05-13 09:13:01 UTC ---
Mind the change between F2003 and F2008:
F2003:
FRACTION(+Inf) = +Inf
FRACTION(-Inf) = -Inf
F2008:
FRACTION(+Inf) = NaN
FRACTION(-Inf) = NaN
And I think what "If X is an IEEE NaN,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961
--- Comment #8 from Thomas Henlich
2011-05-14 12:54:26 UTC ---
Maybe I'm wrong, but I'm not sure the current implementation of asynchronous
execution is very efficient (on Unix systems):
We fork() and then call system(), which forks again and ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961
--- Comment #11 from Thomas Henlich
2011-05-15 09:13:28 UTC ---
(In reply to comment #9)
> Thus, I do not see how one can solve this better than currently done.
We might call system() in a separate thread instead of a separate process which
is m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961
--- Comment #12 from Thomas Henlich
2011-05-15 09:26:02 UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > Thus, I do not see how one can solve this better than currently done.
>
> We might call system() in a separate thread instea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010
Summary: Result of MOD and MODULO intrinsic has wrong sign
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49011
Summary: Wrong repeat count in error message for REPEAT
intrinsic
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010
--- Comment #5 from Thomas Henlich
2011-05-17 05:51:56 UTC ---
The fmod behaviour is correct for x < 0 according to N1548:
double fmod(double x, double y);
float fmodf(float x, float y);
The fmod functions return the value x−ny, for some intege
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010
--- Comment #7 from Thomas Henlich
2011-05-17 11:57:31 UTC ---
I suppose we could still use __builtin_fmod if we reset the sign bit if the
result is -0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49024
Summary: REAL*16 ERFC_SCALED inaccuracy
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #6 from Thomas Henlich
2011-05-19 08:05:32 UTC ---
(In reply to comment #5)
As a general rule, d specifies the number of significant digits in the result,
i.e. the number of digits counting from the first non-zero digit.
So in the e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #10 from Thomas Henlich
2011-05-27 07:15:16 UTC ---
The test cases from above still fail (but with a different result):
print "(ru,g15.2)", .099d0 ! 1.0E-01 expected 0.10
print "(rc,g15.1)", .095d0 ! 1.E-01 expected 0.1
pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #11 from Thomas Henlich
2011-05-27 08:55:14 UTC ---
The scale factor is applied to F editing, but it shouldn't. See Fortran 2008:
NOTE 10.20
The scale factor has no effect on output unless the magnitude of the datum to
be edited is o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188
Summary: Mismatch between -fsign-zero documentation and
formatted output
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #12 from Thomas Henlich
2011-05-27 13:12:32 UTC ---
The following examples fail:
print "(rc,g10.2,'<')", 99.5 ! 10. expected 0.10E+03
print "(rc,g10.2,'<')", 995. ! 1.0E+03 expected 0.10E+04
print "(rc,g10.3,'<')", 999.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188
Thomas Henlich changed:
What|Removed |Added
Severity|normal |minor
--- Comment #2 from Thomas Henlich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #15 from Thomas Henlich
2011-05-31 06:05:19 UTC ---
I hadn't really thought of that, but now I see what a PITA a scale factor > 0
is going to be (scale factor < 0 is simply padding with zeros and shifting
digits):
We have to ignore t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #16 from Thomas Henlich
2011-05-31 06:28:25 UTC ---
print "(rc,g11.1)", 2. ! 0.2E+01 expected 2.
print "(rc,g11.2)", 20. ! 0.20E+02 expected 20.
print "(rc,g11.3)", 200. ! 0.200E+03 expected 200.
print "(rc,g11.4)", 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #19 from Thomas Henlich
2011-06-01 06:26:27 UTC ---
> Also, the test case, pr20755.f was originally intended to pass only with
> -std=legacy. This is to mimic g77 which does not ignore the scale factor. At
> least recently, gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #20 from Thomas Henlich
2011-06-01 08:12:31 UTC ---
(In reply to comment #18)
> Created attachment 24406 [details]
> New updated patch
>
> This updated patch takes care of Comment #16.
Unfortunately, now the other testcases fail aga
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #24 from Thomas Henlich
2011-06-06 08:38:13 UTC ---
(In reply to comment #23)
> Patch submitted to list for approval.
For a scale factor 0, we are done. Good work, thank you!
A scale factor != 0 does not work yet, you wrote you are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #26 from Thomas Henlich
2011-06-06 12:27:38 UTC ---
(In reply to comment #25)
> My confusion seems to be when scale factor is to be ignored and when not, I
> will give the standard another read.
As it happens, you're not the only o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #28 from Thomas Henlich
2011-06-06 12:41:55 UTC ---
I had a look at the code and what I think we should do is the following:
If G editing and a scale factor p != 0 is in effect, split the rounding step
into 2 steps:
First, check if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #29 from Thomas Henlich
2011-06-06 12:47:58 UTC ---
(In reply to comment #27)
> >
> > print "(-2pg12.3)", 0.02 ! 0.200E-01 expected 0.002E+01
> > print "(-1pg12.3)", 0.02 ! 0.200E-01 expected 0.020E+00
> > print "(0pg12.3)", 0.02 ! 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #30 from Thomas Henlich
2011-06-07 06:56:13 UTC ---
Created attachment 24454
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24454
Patch for scale factor. PUBLIC DOMAIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #31 from Thomas Henlich
2011-06-07 06:56:54 UTC ---
(In reply to comment #30)
> Created attachment 24454 [details]
> Patch for scale factor. PUBLIC DOMAIN
A had a go at this. Feel free to improve.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #35 from Thomas Henlich
2011-06-10 16:56:02 UTC ---
(In reply to comment #33)
> The last test case I am working is fmt_g0_6.f08.
>
> The apparent failing case is:
>
> print "(rc,g15.2)", 0.995000_8
>
> Which is resulting in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #36 from Thomas Henlich
2011-06-10 17:01:34 UTC ---
(In reply to comment #34)
> Additional note: The standard states:
>
> "Let N be the magnitude of the internal value"
>
> The internal value is to be used to determine the conversi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #22 from Thomas Henlich
2011-06-17 13:22:42 UTC ---
This is kind of bad:
print "(RU,F7.0)", 7500.0 ! 8. expected 7500.
print "(RD,F7.0)", -7500.0 ! -8. expected -7500.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #24 from Thomas Henlich
2011-06-20 07:15:19 UTC ---
(In reply to comment #22)
> This is kind of bad:
>
> print "(RU,F7.0)", 7500.0 ! 8. expected 7500.
> print "(RD,F7.0)", -7500.0 ! -8. expected -7500.
I've traced the bug down to th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #26 from Thomas Henlich
2011-06-23 06:13:12 UTC ---
Created attachment 24583
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24583
More tests for rounding
If it helps, I added some more tests for this.
By removing the code lines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at users dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #38 from Thomas Henlich
2011-07-01 09:22:48 UTC ---
The Fortran standards committee has voted to edit the standard:
http://j3-fortran.org/doc/meeting/195/11-174r2.txt
This makes our current approach standard compliant (with the corr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659
--- Comment #4 from Thomas Henlich
2011-08-08 06:07:33 UTC ---
It is not safe to omit the warning for integers: the constant could have been
truncated to an integer, as in:
real(8) :: r8
r8 = 12345678.9
print *, r8
=> 12345679.0
101 - 159 of 159 matches
Mail list logo
