http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #39 from Jerry DeLisle 2011-07-02
01:32:42 UTC ---
Very Good, I will work toward this end.
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=48906
--- Comment #37 from Jerry DeLisle 2011-06-10
17:29:54 UTC ---
Updated patch posted for approval:
http://gcc.gnu.org/ml/fortran/2011-06/msg00097.html
Thomas, thanks for working the Standard issues and your testing.
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=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 #34 from Jerry DeLisle 2011-06-10
16:22:20 UTC ---
Additional note: The standard states:
"Let N be the magnitude of the internal value"
The internal value is to be used to determine the conversion to F formatting. I
think this adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #33 from Jerry DeLisle 2011-06-10
16:16:19 UTC ---
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 0.99 and we expect it to be 1.0.
However
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #32 from Jerry DeLisle 2011-06-07
17:06:03 UTC ---
I managed to get pr20755.f fixed last night with only a minor change and I
found a problem elsewhere for fmt_g0_6.f08 which I am still working on. I will
have a look at your patch in
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 #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 #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 #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 #27 from jvdelisle at charter dot net 2011-06-06 12:36:21 UTC ---
>
> 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.200E-01
> print "(1pg1
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 #25 from jvdelisle at charter dot net 2011-06-06 12:09:48 UTC ---
On 06/06/2011 01:38 AM, thenlich at users dot sourceforge.net wrote:
> For a scale factor 0, we are done. Good work, thank you!
>
> A scale factor != 0 does not work yet,
On 06/06/2011 01:38 AM, thenlich at users dot sourceforge.net wrote:
For a scale factor 0, we are done. Good work, thank you!
A scale factor != 0 does not work yet, you wrote you are still working on it,
is that correct?
I am now. ;)
print "(-2pg12.3)", 0.02 ! 0.200E-01 expected 0.002E+01
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 #23 from Jerry DeLisle 2011-06-03
12:55:21 UTC ---
Patch submitted to list for approval.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
Jerry DeLisle changed:
What|Removed |Added
Attachment #24406|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #21 from Jerry DeLisle 2011-06-01
12:26:28 UTC ---
Regarding comment #18, the test case passes regardless 0f the -std=legacy
option specified at the beginning of the source file. I am questioning why that
option is ignored in current
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 #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
Jerry DeLisle changed:
What|Removed |Added
Attachment #24399|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #17 from Jerry DeLisle 2011-05-31
12:30:00 UTC ---
As you can tell, finding the magic formula with this new approach is not a
trivial effort. ;) My fear is that there is an unlimited number of corner
cases.
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 #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
Jerry DeLisle changed:
What|Removed |Added
Attachment #24364|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #13 from Jerry DeLisle 2011-05-27
14:32:12 UTC ---
OK, thanks for test cases, these are very helpful.
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=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=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 #9 from Jerry DeLisle 2011-05-26
12:53:30 UTC ---
Created attachment 24364
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24364
Preliminary patch
I am getting two testsuite regressions with this patch. At least one of those I
th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #8 from Jerry DeLisle 2011-05-23
19:00:54 UTC ---
Status: I am down to about 5 testsuite failures on the patch for this. There
is a lot if interplay going on, so i will be factoring the code some as part of
the cleanup. Stay tuned.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #7 from Jerry DeLisle 2011-05-19
12:58:34 UTC ---
It was the last case I was having trouble with. I also was getting different
results from different compilers, so I needed to confirm independently. I have
this part working now. Still
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 #5 from Jerry DeLisle 2011-05-19
05:13:25 UTC ---
Thomas,
What are the correct results for this test case:
implicit none
integer, parameter :: RT = 8
write(*, "(rc,f11.2,4x,'
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=48906
--- Comment #3 from Jerry DeLisle 2011-05-10
12:53:07 UTC ---
Status: I have managed to eliminate the OUTPUT_FLOAT_G macro completely and all
floating point operations. What remains is to adjust the trailing blanks. The
patch is simple looking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #1 from Jerry DeLisle 2011-05-06
21:10:07 UTC ---
Repeating Thomas T. suggestion:
"We can treat FMT_G like FMT_E. After the rounding step, i.e. when the final
value of the variable e in output_float() is known (at the label 'skip'),
42 matches
Mail list logo
