https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48111
Thomas Henlich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
--- Comment #12 from Thomas Henlich ---
(In reply to Jerry DeLisle from comment #10)
> gfortran currently does this with default formatting, list directed outout:
> -
> ( 1., 0.) ( -1.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659
--- Comment #7 from Thomas Henlich
2011-09-05 07:55:13 UTC ---
Would it be feasible to generate a warning for line 3 of the following:
real(8) :: a, b
a = 1.4d0
b = a / 1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105
--- Comment #3 from Thomas Henlich
2011-08-17 07:36:54 UTC ---
Maybe we can trace back the change in GFortran between 4.1 and 4.3 and find out
why it was changed?
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
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=49278
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at users dot
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=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 #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=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 #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 #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 #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 #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
--- 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=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 #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
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 #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 #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=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=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=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=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
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=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=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 #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=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=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
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=45823
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at users dot
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=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=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=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=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=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=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=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 #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=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
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=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=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=48787
Thomas Henlich changed:
What|Removed |Added
Attachment #24138|0 |1
is obsolete|
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=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=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=48684
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=48488
Thomas Henlich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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=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
Thomas Henlich changed:
What|Removed |Added
Attachment #24120|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
--- Comment #11 from Thomas Henlich
2011-04-28 10:01:45 UTC ---
(In reply to comment #10)
> As an addendum to the above, one thing we could do with modest effort and
> without importing Gay's code would be to remove trailing zeros for G0 (and
> m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #2 from Thomas Henlich
2011-04-28 06:41:27 UTC ---
Created attachment 24120
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24120
Testcase for F, E, G editing
Bug also applies to E and G editing with non-zero scale factor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
--- Comment #7 from Thomas Henlich
2011-04-27 14:11:10 UTC ---
Gay's routines (http://www.netlib.org/fp/) can handle double, float, extended,
quad; rounding directions may be specified. They can output a given number of
digits (compatible to all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
Summary: Invalid UP rounding with F editing
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libfortran
AssignedTo: unassig...@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785
Summary: BOZ editing of real numbers not working with
-std=f2008
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589
Thomas Henlich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684
--- Comment #6 from Thomas Henlich
2011-04-25 08:46:38 UTC ---
(In reply to comment #5)
> On 04/23/2011 02:27 PM, jvdelisle at gcc dot gnu.org wrote:
> --- snip ---
> >
> > Unpatched gfortran and ifort give:
>
> I meant patched gfortran and ifor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
--- Comment #12 from Thomas Henlich
2011-04-25 08:43:32 UTC ---
The patch submitted to the list is different to the one I based my comments on.
My mistake.
Good work.
With the current method of letting printf do the conversion, there seems to b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
--- Comment #8 from Thomas Henlich
2011-04-24 21:41:16 UTC ---
I don't have access to a build system until Tuesday, so I couldn't test your
patch. But I'm not sure I understand what you are trying to do.
I see that you added one more digit in th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
Thomas Henlich changed:
What|Removed |Added
Attachment #24081|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
--- Comment #4 from Thomas Henlich
2011-04-23 13:19:46 UTC ---
Created attachment 24081
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24081
Revised test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #43 from Thomas Henlich
2011-04-23 11:44:45 UTC ---
It seems the required changes would fit in nicely in output_float():
We can treat FMT_G like FMT_E. After the rounding step, i.e. when the final
value of the variable e in output_fl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
--- Comment #2 from Thomas Henlich
2011-04-23 11:06:28 UTC ---
The second branch (let printf do rounding) should only be choosen if the
requested rounding mode is the same as printf uses (nearest/compatible?) and
either
- the format is ES or
- th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
--- Comment #1 from Thomas Henlich
2011-04-23 07:49:33 UTC ---
I think I found the problematic code in write_float:
if (f->format == FMT_F || f->format == FMT_EN || f->format == FMT_G
|| ((f->format == FMT_D || f->format == FMT_E)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #41 from Thomas Henlich
2011-04-21 16:36:14 UTC ---
Actually it may be even simpler than that:
We already know how many significant digits (d) we want in the output string,
and at what digit to round. So we can write the digits of th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #38 from Thomas Henlich
2011-04-20 12:38:53 UTC ---
As an alternative we might consider leaving the code as it was before and
instead putting
OUTPUT_FLOAT_FMT_G(4)
OUTPUT_FLOAT_FMT_G(8)
OUTPUT_FLOAT_FMT_G(10)
into separate files a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #37 from Thomas Henlich
2011-04-20 06:43:37 UTC ---
The same issue exists with the first comparison (decision between FMT_E and
FMT_F).
Consider:
print "(g35.25)", 0.095d0 ! > 0.95..11..E-01
print "(g35.25)", 0.095_10
print "(RC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684
--- Comment #2 from Thomas Henlich
2011-04-19 14:59:36 UTC ---
(In reply to comment #1)
> Isn't this related to PR 48682 ?
Just a coincidence. BTW PR 48682 can be closed as invalid.
BTW: Above should read: The conversion in this case is F(w-n).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48682
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at users dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684
Summary: Incorrect field alignment with Gw.dEe descriptor
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libfortran
AssignedT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #32 from Thomas Henlich
2011-04-19 06:09:27 UTC ---
(In reply to comment #30)
> I can not reproduce the issue with optimization issue on my linux system
> x86-64.
>
> Thomas, what platform do you see the problem on? I only see it on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #25 from Thomas Henlich
2011-04-18 08:39:17 UTC ---
After some testing, I found the problem to be optimization-related. It seems
the following term is calculated as a long double and not rounded before the
"if (m < temp)" comparison,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #26 from Thomas Henlich
2011-04-18 08:40:12 UTC ---
Created attachment 24027
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24027
Test program for optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #24 from Thomas Henlich
2011-04-18 06:32:06 UTC ---
call check_all(0.995_RT, 15, 2, 0)
This still fails (with RC,G15.2 /= RC,F11.1). We need to look at why.
I am aware that N=.995 is .994... internally, but so is the value 1 - r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #22 from Thomas Henlich
2011-04-18 05:59:14 UTC ---
(In reply to comment #7)
> + case ROUND_ZERO:\
> +r = sign_bit ? 0.0 : 1.0;\
This should read:
r = sign_bit ? 1.0 : 0.0;\
Attaching modified test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #23 from Thomas Henlich
2011-04-18 05:59:55 UTC ---
Created attachment 24025
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24025
Updated test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48651
--- Comment #3 from Thomas Henlich
2011-04-17 18:34:15 UTC ---
(In reply to comment #2)
> hmm, notice the typo! i have set ldnum to 0.0 but it still is printing the
> value of dnum. What am I doing wrong.
>
> $ cat sprint.c
> #include
>
> int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #17 from Thomas Henlich
2011-04-17 13:25:25 UTC ---
(In reply to comment #16)
> I see another rounding issue with this:
>
> integer, parameter :: RT=8
> print *, 0.09_RT, " RD:"
> print "(RD,G15.2)", 0.09_RT
> print "
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #15 from Thomas Henlich
2011-04-16 17:45:05 UTC ---
And maybe for performance improvement we should transform
if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
((m == 0.0) && !(compile_options.allow_std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #14 from Thomas Henlich
2011-04-16 17:28:16 UTC ---
(In reply to comment #13)
> OK, here is what I have settled on for the IF clause after checking the
> factoring.
>
> rexp_d = calculate_exp_ ## x (-d);\
> if ((m > 0.0 && m < 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #10 from Thomas Henlich
2011-04-16 15:46:14 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > - if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0)
> > ||\
> > + if ((m > 0.0 && m < 0.1 - r * rexp_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #8 from Thomas Henlich
2011-04-16 06:42:52 UTC ---
(In reply to comment #7)
> - if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\
> + if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #5 from Thomas Henlich
2011-04-15 20:41:02 UTC ---
(In reply to comment #4)
> OK I knew I was "looking" at it wrong. The formulas you mention we are using
> and are in write_float.def starting at line 798. The table is there as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #3 from Thomas Henlich
2011-04-15 19:58:55 UTC ---
(In reply to comment #2)
> I am missing something here:
>
> "print "(RU,G15.2)", .991d0
> prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with
> r
> = 1 bec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
Summary: Invalid UP/DOWN rounding with E and ES descriptors
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
Summary: Invalid F conversion of G descriptor for values close
to powers of 10
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589
Summary: Invalid G0/G0.d editing for NaN/infinity
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unas
1 - 100 of 159 matches
Mail list logo
