http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47039
Summary: Support warnings/errors for non-F features.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47268
Summary: Documentation: missing (Optional) keyword for
parameters of get_command_argument() and
get_environment_variable()
Product: gcc
Version: 4.6.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47327
Summary: Documentation: Link to GCC Errors and Warnings options
broken
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47358
Summary: Decimal number formatting not localized
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47377
Summary: internal compiler error: in fold_convert_loc, at
fold-const.c:1906
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47394
Summary: Internal compiler error when error count limit is
reached
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Thomas changed:
What|Removed |Added
CC||thenlich at users dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434
Summary: Wrong field width for NaN with (F0.n) formatting
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434
--- Comment #2 from Thomas Henlich
2011-01-24 14:37:29 UTC ---
A similar issue occurs with the values +Infinity and 0.0:
program testnan
real :: i, n = 0.0, m = tiny(0.0)
i = 1.0 / n
print "(F0.2)", i
print "(F3.2)", i
print
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455
Summary: internal compiler error: in fold_convert_loc, at
fold-const.c: 2028
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47472
Summary: Rules printed by -M option contains duplicate slash
when -J option is used
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47485
Summary: gfortran -M output is incorrect when -MT option is
used
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47486
Summary: gfortran -M exits with fatal error when -o option is
used
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434
--- Comment #5 from Thomas Henlich
2011-01-27 13:25:15 UTC ---
(In reply to comment #3)
> The copy of the F2008 standard I have says in 10.7.2.3.2 F editing:
>
> "When w is zero, the processor selects the field width."
My interpretation is this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434
--- Comment #9 from Thomas Henlich
2011-01-27 17:55:13 UTC ---
Maybe this should be a command option, possibly defaulting to the current
behaviour unless -std=xx is given.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Summary: Wrong output for small absolute values with F editing
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
--- Comment #6 from Thomas Henlich
2011-02-05 07:40:49 UTC ---
(In reply to comment #3)
> For this special case:
>
> print "(F1.0)", 0.0 ! => 0 expected *
>
> Up to now, we have interpreted the last sentence in F95 10.5.1.2.1 F95
> 10.2.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
--- Comment #7 from Thomas Henlich
2011-02-05 07:45:57 UTC ---
(In reply to comment #6)
> Regardless of this choice, the following should all print the same result,
> which they currently don't.
>
> print "(F1.0)", 0.0 ! => 0
> print "(F1.0)",
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
--- Comment #8 from Thomas Henlich
2011-02-05 07:53:40 UTC ---
(In reply to comment #6)
> In extension, the following should also print the same result:
>
> print "(F1.0)", 0.0 ! => 0
> print "(F1.0)", 1.0 ! => *
> print "(F1.0)", 2.0 ! => *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
--- Comment #12 from Thomas Henlich
2011-02-07 07:01:14 UTC ---
(In reply to comment #11)
> Fixed on trunk. I don't think this is significant enough to justify a
> back-port. I am not sure why anyone would use f1.X for anything, so this
> exerci
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633
Summary: Result of COMPILER_VERSION() has NULL byte appended
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Thomas Henlich changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659
Summary: -Wconversion[-extra] should emit warning for constant
expressions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47660
Summary: Retain warning text of -Wconversion messages when
-Wconversion-extra is in effect
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Thomas Henlich changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47872
Summary: Alternative syntax for intrinsics should be documented
on separate line
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47875
Summary: What's new section in GFortran wiki page: Wrong
function name: TAN2.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47875
Thomas Henlich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894
Summary: Documentation text for VERIFY intrinsic function is
wrong.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
--- Comment #26 from Thomas Henlich
2011-02-25 13:58:51 UTC ---
Created attachment 23467
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23467
Programmatic test case for multiple formats
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Thomas Henlich changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894
Thomas Henlich changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
Summary: REAL(8) output conversion error on MinGW32
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #1 from Thomas Henlich
2011-03-01 14:01:32 UTC ---
Created attachment 23501
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23501
Test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #2 from Thomas Henlich
2011-03-01 14:01:56 UTC ---
Created attachment 23502
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23502
C test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #4 from Thomas Henlich
2011-03-01 14:44:54 UTC ---
(In reply to comment #3)
> 0.142857142857142849218750 is still within the accuracy of IEEE
> double.
> All numbers map to the same IEEE double.
This is technically correct;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
Thomas Henlich changed:
What|Removed |Added
Severity|normal |minor
--- Comment #6 from Thomas Henlich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #9 from Thomas Henlich
2011-03-02 13:49:15 UTC ---
It seems that MinGW has its own implementation of snprintf called
__mingw_snprintf which can be activated by defining __USE_MINGW_ANSI_STDIO
__mingw_snprintf has the desired behaviou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Thomas Henlich changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #12 from Thomas Henlich
2011-03-02 17:54:34 UTC ---
(In reply to comment #11)
> From libgfortran/libgfortran.h:
>
> #if defined __MINGW32__
> # define _POSIX 1
> # define gfc_printf gnu_printf
> #else
Since the comment above that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47965
Summary: gfortran testsuite failures on mingw32
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #16 from Thomas Henlich
2011-03-03 14:58:35 UTC ---
My _mingw.h has the following:
#if defined(_POSIX) && !defined(__USE_MINGW_ANSI_STDIO)
/* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined
* and If user did _not_ specify it explici
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
Thomas Henlich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #18 from Thomas Henlich
2011-03-04 06:53:33 UTC ---
Created attachment 23537
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23537
Test 1 for pedantic IO rounding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #19 from Thomas Henlich
2011-03-04 06:54:03 UTC ---
Created attachment 23538
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23538
Test 2 for pedantic IO rounding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #20 from Thomas Henlich
2011-03-04 06:56:56 UTC ---
Added two tests just in case this comes up again.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47984
Summary: Pointer dummy argument mismatch not detected by
Fortran compiler
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47984
--- Comment #3 from Thomas Henlich
2011-03-04 18:58:06 UTC ---
Sorry, I don't understand why you consider the bug report invalid. You may very
well be correct, but please explain. I am not such a Fortran expert, so I may
have missed something her
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 #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
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=47984
--- Comment #6 from Thomas Henlich
2011-03-07 06:26:24 UTC ---
RTFM, I should have.
Thank you for your help.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047
Summary: Incorrect output rounding of double precision numbers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48054
Summary: Documentation for LOG intrinsic function is ambiguous
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047
--- Comment #4 from Thomas Henlich
2011-03-10 09:36:52 UTC ---
Created attachment 23610
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23610
Patch to fix rounding issue
Proposing this patch (untested) for field width.
Trading 2 extra bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047
--- Comment #5 from Thomas Henlich
2011-03-10 09:39:03 UTC ---
Created attachment 23611
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23611
Comprehensive test for IEEE 754-2008 clause 5.12.2 compliant output rounding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047
Thomas Henlich changed:
What|Removed |Added
Attachment #23611|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48111
Summary: libquadmath: strtoflt128 bug on MinGW
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488
Summary: Wrong default format for real numbers
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488
--- Comment #2 from Thomas Henlich
2011-04-07 11:22:49 UTC ---
Ok, now I found that this was changed in
http://gcc.gnu.org/viewcvs?view=revision&revision=128967
The testcase says:
> ! This tests that the default formats for formatted I/O of rea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
Summary: Implement Steele-White algorithm for numeric output
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
--- Comment #5 from Thomas Henlich
2011-04-10 10:19:47 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Does any of the Fortran edit descriptors require, or for that matter allow,
> > this kind of "shortest decimal representation"
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
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=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
--- 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=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 #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 #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 #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 #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 #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=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 #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=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 #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 #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 #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 #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=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=48682
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at users dot
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=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=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 #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=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=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=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 #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=48615
Thomas Henlich changed:
What|Removed |Added
Attachment #24081|0 |1
is obsolete|
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
--- 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=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=48589
Thomas Henlich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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=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=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
--- 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 #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
1 - 100 of 159 matches
Mail list logo
