[Bug fortran/47039] New: Support warnings/errors for non-F features.

[thenlich at users dot sourceforge.net]

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: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The Fortran compiler should have a feature like g95 -std=F which only accepts
code conforming to the F programming language/Fortran subset.

[Bug libfortran/47268] New: Documentation: missing (Optional) keyword for parameters of get_command_argument() and get_environment_variable()

[thenlich at users dot sourceforge.net]

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: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The argument VALUE of the get_command_argument() intrinsic is correctly marked
as optional in the Syntax section, but in the Arguments section the (Optional)
keyword is missing.

Style issue: For the LENGTH and STATUS arguments the keyword is written as
(Option), not (Optional).

The arguments VALUE,LENGTH,STATUS,TRIM_NAME of the get_environment_variable()
intrinsic are correctly marked as optional in the Syntax section, but in the
Arguments section the (Optional) keyword is missing.

[Bug fortran/47327] New: Documentation: Link to GCC Errors and Warnings options broken

[thenlich at users dot sourceforge.net]

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
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The GNU Fortran page (2.4 Options to request or suppress errors and warnings)
http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html contains
a link to (Options to Request or Suppress Errors and Warnings) leading to
http://gcc.gnu.org/onlinedocs/gcc/Error-and-Warning-Options.html#Error-and-Warning-Options
but this page does not exist.

[Bug gcov-profile/47358] New: Decimal number formatting not localized

[thenlich at users dot sourceforge.net]

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: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Percentage values are displayed with a dot as decimal separator instead of the
comma which would be correct for the German locale.

Example:

$ gcov -v
gcov (GCC) 4.3.4 20090804 (release) 1
Copyright (C) 2008 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

$ gcov testcov.c
File: »testcov.c«
50.00% von 6 Zeilen ausgeführt
testcov.c: »testcov.c.gcov« wird erzeugt

Expected output:
...
50,00% von 6 Zeilen ausgeführt
...

[Bug fortran/47377] New: internal compiler error: in fold_convert_loc, at fold-const.c:1906

[thenlich at users dot sourceforge.net]

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
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23045
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23045
Example Fortran source for internal compiler error: in fold_convert_loc, at
fold-const.c:1906

The following command results in internal compiler error.

Expected result: Produce proper source diagnostics/error message for the error.

$ gfortran testgferr.f90
testgferr.f90: In function 'testgferr':
testgferr.f90:3:0: internal compiler error: in fold_convert_loc, at
fold-const.c:1906
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/47394] New: Internal compiler error when error count limit is reached

[thenlich at users dot sourceforge.net]

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: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When compiling a program with -fmax-errors=n and the n-th error is encountered,
an internal compiler error occurs and the gfortran command exits with status 4.

Expected result is: the compiler should report the abortion and exit with the
status code according to the error encountered, like the C compiler does.

Example:
$ echo x > test.f
$ gfortran -fmax-errors=1 test.f
test.f:1.1:

x
 1
Error: Non-numeric character in statement label at (1)
Fatal Error: Error count reached limit of 1.
gfortran.exe: internal compiler error: Aborted (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ echo $?
4

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

Thomas  changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #5 from Thomas  2011-01-24 
08:53:10 UTC ---
Even a partial, incomplete support of module IEEE_ARITHMETIC would be very
useful and much appreciated:

>From http://gcc.gnu.org/ml/gcc/2008-11/msg00372.html

a) To set an IEEE value (NaN, INF, etc.)
b) Check whether a value is NaN, etc.

and IEEE_VALUE(X, IEEE_QUIET_NAN)

So we wouldn't have to resort to non-standard functions like ISNAN()
(http://gcc.gnu.org/onlinedocs/gfortran/ISNAN.html) anymore.

[Bug libfortran/47434] New: Wrong field width for NaN with (F0.n) formatting

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When formatting NaN with a F edit descriptor where the field width is zero, the
string "NaN" is written (field width = 4).

The expected string would be "NaN" (field width = 3, the smallest positive
actual field width that does not result in a field filled with asterisks).

For example: 

program testnan
real :: n = 0.0
n = 0.0 / n
print "(F0.2)", n
print "(F3.2)", n
end program testnan

Output:
NaN
NaN

10.7.2.1
(6) On output, with I, B, O, Z, F, and G editing, the specified value of the
field width w may be zero. In such cases, the processor selects the smallest
positive actual field width that does not result in a field filled with
asterisks. The specified value of w shall not be zero on input.

10.7.2.3.2 F editing
For an internal value that is an IEEE NaN, the output field consists of blanks,
if necessary, followed by the letters 'NaN' and optionally followed by one to w
- 5 alphanumeric processor-dependent characters enclosed in parentheses, right
justified within the field. If w is less than 3, the field is filled with
asterisks.

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[thenlich at users dot sourceforge.net]

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 "(F0.2)", n
print "(F3.2)", n

print "(F0.2)", m
print "(F3.2)", m
end program testnan

Output:
+Inf
Inf
0.00
.00
.00
.00

The expected chosen field width is 3 in all cases, exactly for the same reason
demanded by 10.7.2.1(6)

[Bug fortran/47455] New: internal compiler error: in fold_convert_loc, at fold-const.c: 2028

[thenlich at users dot sourceforge.net]

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
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The following example results in an internal compiler error.

Version: gcc version 4.6.0 20110122 (experimental) (GCC)
Platform: i686-pc-mingw32
Expected result: Produce proper source diagnostics/error message for the error.

module class_t
type :: tx
integer, dimension(:), allocatable :: i
end type tx
type :: t
type(tx), pointer :: x
contains
procedure :: calc
procedure :: find_x
end type t
contains
subroutine calc(this)
class(t), target :: this
this%x = this%find_x()
end subroutine calc
function find_x(this)
class(t), intent(in) :: this
type(tx), pointer :: find_x
find_x => null()
end function find_x
end module class_t

$ gfortran -c class_t.f90
class_t.f90: In function 'calc':
class_t.f90:14:0: internal compiler error: in fold_convert_loc, at
fold-const.c:2028
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/47472] New: Rules printed by -M option contains duplicate slash when -J option is used

[thenlich at users dot sourceforge.net]

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
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Example:

testuse.f90:
program testuse
use testmake
end program testuse

testmake.f90:
module testmake
integer :: i, j
end module testmake

$ gfortran -Jobj -o obj/testmake.o -c testmake.f90
$ gfortran -Jobj -M -cpp testuse.f90
testuse.o: testuse.f90 obj//testmake.mod

Expected output is:
testuse.o: testuse.f90 obj/testmake.mod

[Bug fortran/47485] New: gfortran -M output is incorrect when -MT option is used

[thenlich at users dot sourceforge.net]

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: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When "-MT target" (Change the target of the rule emitted by dependency
generation) is specified, the specified target is added as an additional target
instead of replacing the default one.

Example test.for:
  program test
  print "(a)", "hello world"
  end program

$ gfortran -cpp -M test.for -MT obj/test.o
test.o obj/test.o: test.for

Expected output:
obj/test.o: test.for

[Bug fortran/47486] New: gfortran -M exits with fatal error when -o option is used

[thenlich at users dot sourceforge.net]

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: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When "-o file" is specified, the command exits with an error.

Example test.for:
  program test
  print "(a)", "hello world"
  end program

$ gfortran -cpp -M test.for -o test.d
Fatal Error: output filename specified twice

Expected action:
Write dependency to test.d

Version: gcc version 4.6.0 20110122 (experimental) (GCC)
Platform: i686-pc-mingw32

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[thenlich at users dot sourceforge.net]

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:

Section 10.7.2.1 (General rules) applies to these cases, which demands
specifically:

"... the processor selects the smallest positive actual field width that does
not result in a field filled with asterisks. ..."

The statement from 10.7.2.3.2 "When w is zero, the processor selects the field
width." does only refer to this. IMHO it does not suggest the possibility to
include optional characters (a leading decimal zero or plus sign) which make
the field width larger than required.

In the examples, since w=3 ("F3.2") does not result in a field filled with
asterisks, and is the smallest possible such value, the processor must select a
field width of 3.

Also, it is inconsistent that the following commands should result in a
different output:

print "(F0.2)", 0.0
print "(F0.2)", tiny(0.0)

0.00
.00

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[thenlich at users dot sourceforge.net]

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.

[Bug libfortran/47567] New: Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Fortran 2008, 10.7.2.3.2(9):
For an internal value that is neither an IEEE infinity nor a NaN, the output
field consists of blanks, if necessary, followed by a minus sign if the
internal value is negative, or an optional plus sign otherwise, followed by a
string of digits that contains a decimal symbol and represents the magnitude of
the internal value, as modified by the established scale factor and rounded
(10.7.2.3.7) to d fractional digits. Leading zeros are not permitted except
for an optional zero immediately to the left of the decimal symbol if the
magnitude of the value in the output field is less than one. The optional zero
shall appear if there would otherwise be no digits in the output field.

In gfortran, with an (F0.0) edit descriptor, some small values are formatted as
".", e.g.

print "(F0.0)", 0.0   ! => 0.
print "(F0.0)", 0.001 ! => . expected 0.
print "(F0.0)", 0.01  ! => . expected 0.
print "(F0.0)", 0.1   ! => 0.

Reason: "The optional zero shall appear if there would otherwise be no digits
in the output field."

Any formatting of non-negative values with (F1.n) should always result in
asterisks, because "a string of digits that contains a decimal symbol", where
"the optional zero shall appear if there would otherwise be no digits in the
output field" can never fit in 1. E. g.

print "(F1.0)", 0.0   ! => 0 expected *
print "(F1.0)", 0.001 ! => . expected *
print "(F1.0)", 0.01  ! => . expected *
print "(F1.0)", 0.1   ! => *

Similarly, for negative values and (F2.n):

print "(F2.0)", -0.001 ! => -. expected **
print "(F2.0)", -0.01  ! => -. expected **
print "(F2.0)", -0.1   ! => **

The exact value "0.0" is formatted with a leading zero with (F0.n) formatting,
but this is incorrect, see bug 47434:

print "(F0.2)", 0.0   ! => 0.00 expected .00

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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.1
> to require this to print '0'.
> 
> "Leading zeros are not permitted except for an optional zero immediately to 
> the
> left of the decimal symbol if the magnitude of the value in the output field 
> is
> less than one. The optional zero shall appear if there would otherwise be no
> digits in the output field."
> 
> F2008 draft has the same wording.  Of course this is a little bit in
> contradiction with another requirement that the decimal point be shown.  I can
> easily change this to output the '*', but thought I would mention that what we
> have now was done on purpose and is even commented so in the code.

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)", 0.001 ! => *
print "(F1.0)", 0.01  ! => *
print "(F0.0)", 0.0   ! => 0
print "(F0.0)", 0.001 ! => *
print "(F0.0)", 0.01  ! => *

I don't see anything in the standard which suggests that the exact internal
value 0.0 is to be treated differently from a positive internal value which is
rounded to 0.0 on output, and I don't see a valid reason for doing so.

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  ! => *

In all these cases, there is the same issue, that "the decimal point be shown",
but doesn't fit.

Again, I don't see anything in the standard which suggests that the internal
value 0.0 is to be treated differently from a positive internal value which is
rounded to an integer number on output.

And in my opinion, the rule "optional zero shall appear" is not a contradiction
to "the decimal point be shown". Both are required, and the output just doesn't
fit the field, hence the field shall be filled with asterisks.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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)", 0.001 ! => *
> print "(F1.0)", 0.01  ! => *
> print "(F0.0)", 0.0   ! => 0
> print "(F0.0)", 0.001 ! => *
> print "(F0.0)", 0.01  ! => *

Sorry, but what I meant was that the following should print the same:
print "(F1.0)", 0.0  ! => 0
print "(F1.0)", 0.001 ! => *
print "(F1.0)", 0.01  ! => *

And the following should print the same:
print "(F0.0)", 0.0   ! => 0
print "(F0.0)", 0.001 ! => *
print "(F0.0)", 0.01  ! => *

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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  ! => *

What I meant here was they should all either print * or 0, 1, 2

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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
> exercise is largely academic. I do appreciate the bug reports. Thanks

Thank you for your work on this and for the fast response, which is actually
better than what you get from the "premier" support of some big commercial
compiler vendors.

Of course I agree with you that noone would use (F1.n) editing, that was
exactly my point, see my comment #1: "Any formatting ... with (F1.n) should
always result in asterisks".

However, because of the rule for (F0.n) we need to make clear what is "the
smallest positive actual field width that does not result in a field filled
with asterisks".

print "(F0.0)", 0.0   ! => 0

I'm still pretty sure that this is not compliant to Fortran 2003/2008 and I
would like a convincing explanation why it should be. Of course I can
understand the argument that "0" instead of "0." is useful to express the "real
zero", but I think standard-compliance takes precedence, making it easier for
the user to write portable programs.

In my interpretation, the demand of "a string of digits that contains a decimal
symbol" is equivalent to the syntax:

DIGIT ... DECIMAL-SYMBOL [DIGIT] ...
|
[DIGIT] ... DECIMAL-SYMBOL DIGIT ...

The clause "The optional zero shall appear if there would otherwise be no
digits in the output field." rules out the string becoming just:

DECIMAL-SYMBOL

As I see it, the decimal symbol is not optional and cannot be left out, so the
output "0" is illegal.

The phrase "contains" means that e.g. the Java method
string.contains(decimal_symbol) would return true.

[Bug fortran/47633] New: Result of COMPILER_VERSION() has NULL byte appended

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The string returned by the COMPILER_VERSION function of the ISO_FORTRAN_ENV
module has a NULL byte at the last character position.

Expected result: Just the string, without the extra null byte.

PROGRAM TESTENV
USE ISO_FORTRAN_ENV
CHARACTER(LEN=256) V
INTEGER L
V = COMPILER_VERSION()
L = LEN(COMPILER_VERSION())
PRINT "(A)", V(1:L-1)
PRINT *, ICHAR(V(L:L))
END PROGRAM TESTENV

GCC version 4.6.0 20110205 (experimental) [trunk revision 169855]
   0

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567

Thomas Henlich  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #13 from Thomas Henlich  
2011-02-08 07:16:28 UTC ---
Regardless of the finer points of standard-compliance, the patch breaks the
following:

print "(F0.0)", -0.0   ! => 0 expected -0. (or -0)
print "(F0.1)", -0.0   ! => ** expected -.0 (or -0)
print "(F0.2)", -0.0   ! => *** expected -.00 (or -0)
print "(F0.3)", -0.0   ! =>  expected -.000 (or -0)
end

I think the minus sign of the negative zero is not an optional character and
should be displayed in all cases where it exists (otherwise it does not make
sense to have a signed zero in the first place). I think it falls under the
clause "a minus sign if the internal value is negative".

In no case should the field be filled with asterisks for an F0.n descriptor,
because there will always be a field width large enough to accommodate the
formatted string.

[Bug fortran/47659] New: -Wconversion[-extra] should emit warning for constant expressions

[thenlich at users dot sourceforge.net]

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
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When the options -Wconversion or -Wconversion-extra are in effect, the compiler
does not generate a warning if a constant real expression is converted to a
different real kind

There should be a warning in this case because the conversion can give
surprising results, e.g.:

real(8) d1, d2
d1 = .13 ! <== no warning
d2 = .13d0
print *, d1, d2, d2-d1
end

Output:
  0.1299523162842   0.13000   4.76837158647214210E-009

In this case the option -Wconversion-extra should give a warning on "d1 = .13"
because a constant was specified which does not represent the decimal value
with the same precision as the target variable can hold. The user most likely
wanted to specify "d1 = .13d0"

[Bug fortran/47660] New: Retain warning text of -Wconversion messages when -Wconversion-extra is in effect

[thenlich at users dot sourceforge.net]

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
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


A warning for a construct which is printed for -Wconversion should be printed
with the same text when -Wconversion-extra is in effect.

In other words, when -Wconversion-extra is in effect, conversions which are
likely to change the expression's value should have a distinctly different
warning text than conversions which don't. This makes it easier for the user to
find the most relevant issues in the source code more quickly without running
the compiler two times with -Wconversion and -Wconversion-extra.

For example:
real(4) r1
real(8) r2
integer(4) i
r1 = r2
r1 = 0_8
i = 0._8
end

$ gfortran -Wconversion testconv2.f90
testconv2.f90:4.5:

r1 = r2
 1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
testconv2.f90:5.5:

r1 = 0_8
 1
Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at
(1
)
testconv2.f90:6.4:

i = 0._8
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at
(1
)

$ gfortran -Wconversion-extra testconv2.f90
testconv2.f90:4.5:

r1 = r2
 1
Warning: Conversion from REAL(8) to REAL(4) at (1)
testconv2.f90:5.5:

r1 = 0_8
 1
Warning: Conversion from INTEGER(8) to REAL(4) at (1)
testconv2.f90:6.4:

i = 0._8
1
Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at
(1)


The first two warnings should have the same text in both runs.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567

Thomas Henlich  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #20 from Thomas Henlich  
2011-02-21 13:22:59 UTC ---
print "(F3.0)", -0.0   ! => -0.
print "(F2.0)", -0.0   ! => **
print "(F1.0)", -0.0   ! => 0

print "(F3.1)", -0.0   ! => -.0
print "(F2.1)", -0.0   ! => **
print "(F1.1)", -0.0   ! => 0

I think it's still wrong: It is not possible for any value to fit into a field
of width w, but not into w+1.

Either

1) For the special case of a zero, we consider the minus sign and the decimal
symbol optional (which I think does not conform to the standard), then the
result should be:

print "(F3.0)", -0.0   ! => -0.
print "(F2.0)", -0.0   ! => -0 (or 0. or 0)
print "(F1.0)", -0.0   ! => 0

print "(F3.1)", -0.0   ! => -.0
print "(F2.1)", -0.0   ! => -0 (or .0 or 0)
print "(F1.1)", -0.0   ! => 0

or

2) We never consider the minus sign nor the decimal symbol optional (which I
think is required by the standard), then the result should be:

print "(F0.0)", -0.0   ! => -0.
print "(F3.0)", -0.0   ! => -0.
print "(F2.0)", -0.0   ! => **
print "(F1.0)", -0.0   ! => *

print "(F0.1)", -0.0   ! => -.0
print "(F3.1)", -0.0   ! => -.0
print "(F2.1)", -0.0   ! => **
print "(F1.1)", -0.0   ! => *

[Bug libfortran/47872] New: Alternative syntax for intrinsics should be documented on separate line

[thenlich at users dot sourceforge.net]

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
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The syntax documentation for the ATAN, BESSEL_JN and BESSEL_YN intrinsic
functions lists the alternative calls in one line, e.g.:

RESULT = ATAN(X) RESULT = ATAN(Y, X)

This should be split into separate lines:

RESULT = ATAN(X)
RESULT = ATAN(Y, X)

or separated with a semicolon:

RESULT = ATAN(X); RESULT = ATAN(Y, X)

[Bug web/47875] New: What's new section in GFortran wiki page: Wrong function name: TAN2.

[thenlich at users dot sourceforge.net]

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
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The list of Fortran 2008 features in gfortran 4.5
(http://gcc.gnu.org/wiki/GFortran#GCC4.5) says:

Add ATAN(Y,X) as alias for TAN2(Y,X).

This must be ATAN2, not TAN2, as stated in
http://gcc.gnu.org/onlinedocs/gfortran/ATAN.html#ATAN

[Bug web/47875] What's new section in GFortran wiki page: Wrong function name: TAN2.

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47875

Thomas Henlich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Thomas Henlich  
2011-02-24 08:13:40 UTC ---
Fixed in wiki by reporter.

[Bug libfortran/47894] New: Documentation text for VERIFY intrinsic function is wrong.

[thenlich at users dot sourceforge.net]

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
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The documentation states:

"Verifies that all the characters in a SET are present in a STRING."

but this should read:

"Verifies that no other characters than those in a SET are present in a
STRING."

or:

"Verifies that all the characters in STRING are present in a SET."


Also, the sentence:

"If all characters of SET are found in STRING, the result is zero."

again is wrong and should read:

"If no characters not in SET are found in STRING, the result is zero."

or

"If only characters from SET are found in STRING, the result is zero."

or

"If all characters of STRING are found in SET, the result is zero."

or, as in Fortran 2008:

"The value of the result is zero if each character in STRING is in SET or if
STRING has zero length."

The headline is also misleading:

"VERIFY — Scan a string for the absence of a set of characters"

because the string is actually scanned for the absence (or presence) of
characters NOT in SET (mathematically, that's a complement of SET, which is
also a set, but confusing to read)

Maybe it should read:
"VERIFY — Scan a string for the absence of characters not in a set"

or, as in Fortran 2008:
"Search for a character not in a given set."

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567

Thomas Henlich  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #27 from Thomas Henlich  
2011-02-25 14:00:18 UTC ---
Way to go, still not quite right...

print '(f3.0)', -1E-6  ! => -0.
print '(f0.0)', -1E-6  ! => ** expected -0.

Comprehensive testcase attached.

[Bug libfortran/47894] Documentation text for VERIFY intrinsic function is wrong.

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894

Thomas Henlich  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |

--- Comment #3 from Thomas Henlich  
2011-02-28 07:48:39 UTC ---
The revised first sentence:

"Verifies that all the characters in STRING belong the set of characters in
SET."

is missing a "to" after "belong". All your string are belong to us ;-)

[Bug libfortran/47945] New: REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The last digits of REAL(8) numbers are converted inaccurately on output.

For instance, the output of:

real(8) :: r8
real(16) :: r16

r8 = .14285714285714286d0
r16 = r8
write(*, '(f35.32)') r8
write(*, '(f35.32)') r16
end

is:
 0.142857142857142849218750
 0.14285714285714284921269268124888

but the expected output is:
 0.14285714285714284921269268124888
 0.14285714285714284921269268124888

because the internal 64-bit representation of .14285714285714286 is
approximately equal to 0.14285714285714284921269268124888...

Arguably, an output of 0.14285714285714285000 would equally be
acceptable, because it is the shortest decimal representation of the same
internal value. (This is in fact what the GCC C Compiler on mingw32 does)

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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; however a program should also observe portability
and usability rules and not just pick any number from a valid range, but the
number which is the most useful to the program user: either the one most common
across platforms and other compilers (0.14285714285714284921269268124888) or
the "shortest" one (0.14285714285714285000).

It is very hard to compare long numeric result listings obtained on different
platforms/compilers if some digits (however insignificant) never match.

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945

Thomas Henlich  changed:

   What|Removed |Added

   Severity|normal  |minor

--- Comment #6 from Thomas Henlich  
2011-03-02 06:45:01 UTC ---
I still think it makes sense to demand that the same binary value always
converts to the same decimal number, regardless of compiler vendor, or
platform.

It should even be the same for the same internal value, when the variables are
of different real kinds (which now it isn't, on mingw). Consider:

real(8) :: r8
real(16) :: r16

r8 = .14285714285714286d0
r16 = r8
write(*, '(f35.32)') r8
write(*, '(f35.32)') r16
end

output:
 0.142857142857142849218750
 0.14285714285714284921269268124888

Sometimes it is necessary to specify more decimal digits than necessary in the
edit descriptor because the magnitude of the result may vary. Now, if the same
binary value would always result in the same decimal number, that would make it
easier to compare results obtained from the same program, obtained with two
different compilers or on different platforms (a method used for program
verification).

The Fortran 2008 standard even demands this behaviour (in my interpretation):

===
10.7.2.3.7 I/O rounding mode

2. In what follows, the term "decimal value" means the exact decimal number as
given by the character string, while the term "internal value" means the number
actually stored in the processor.  For example, in dealing with the decimal
constant 0.1, the decimal value is the mathematical quantity 1/10, which has no
exact representation in binary form.  Formatted output of real data involves
conversion from an internal value to a decimal value; formatted input involves
conversion from a decimal value to an internal value.

3.  When the I/O rounding mode is UP, the value resulting from conversion shall
be the smallest representable value that is greater than or equal to the
original value. When the I/O rounding mode is DOWN, the value resulting
from conversion shall be the largest representable value that is less than or
equal to the original value. [etc]
===

In the example, 0.14285714285714284921269268124888 is the largest representable
(with 32 decimal digits) value that is less than the original value (binary
1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal
0.1428571428571428492126926812488818...).

The point is, what the standard demands is the closest approximation that can
be represented with the specified output precision.

The standard does not state that an implementation may truncate the result
after an arbitrary number of decimal digits (even if that number is higher than
the possible precision of the internal bit width used).

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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 behaviour:

#include 
main() {
double d = .14285714285714286;
char str[200];
__mingw_snprintf(str, sizeof(str), "MinGW:  %35.32f", d);
puts(str);
_snprintf(str, sizeof(str), "MSVCRT: %35.32f", d);
puts(str);
return;
}

MinGW:   0.14285714285714284921269268124888
MSVCRT:  0.14285714285714285000

Is there a way to use this in Fortran too?

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567

Thomas Henlich  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #32 from Thomas Henlich  
2011-03-02 14:01:18 UTC ---
No further bugs are known at this time...

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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 reads:

/* Ensure that ANSI conform stdio is used. This needs to be set before
   any system header file is included. */

could it be that it was the intention to set __USE_MINGW_ANSI_STDIO in effect?

So is this a bug in libgfortran.h and it was intended to put
# define _POSIX_SOURCE 1 
there?

[Bug testsuite/47965] New: gfortran testsuite failures on mingw32

[thenlich at users dot sourceforge.net]

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...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Problem 2 reported in Bug 42950 also occurs on mingw32, the others (1, 3-6)
not.

(2) /dev/null test (gfortran.dg/dev_null.F90 and gfortran.dg/write_to_null.F90)
where seemingly

#if defined  _WIN32
#define DEV_NULL "nul"

does not work as one gets:
  Fortran runtime error: File '/dev/null' does not exist

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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 explicitly... */
#  define __USE_MINGW_ANSI_STDIO1
#endif

So _POSIX_SOURCE really seems to be the wrong way and I wonder what the values
of _POSIX and __USE_MINGW_ANSI_STDIO actually are.

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945

Thomas Henlich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #17 from Thomas Henlich  
2011-03-04 06:48:37 UTC ---
The problem has been confirmed to be an issue with the custom snprintf
implementation used in the equation.com distribution and not related to
gfortran/mingw.

In the new snapshot distributed on their website they have fixed this issue,
and are apparently using __mingw_snprintf now, which solves the problem for the
reporter.

Thank you all for your input on this.

Closing.

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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.

[Bug fortran/47984] New: Pointer dummy argument mismatch not detected by Fortran compiler

[thenlich at users dot sourceforge.net]

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
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23539
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23539
Test case

The Fortran compiler does not detect a mismatch between an actual argument (not
a pointer) and a dummy argument in a procedure (which is a pointer, by mistake)
in this example:

program test_pointer
type :: t
integer :: i = 7
end type
type(t), target :: a
call testsub(a%i)
contains
subroutine testsub(p)
integer, pointer, intent(in) :: p
print *, p
end subroutine
end

Result: The program compiles without errors.

Expected result: The compiler should report an error like

test_pointer.f90:6.17:

call testsub(a%i)
 1
Error: Actual argument for 'p' must be a pointer at (1)

[Bug fortran/47984] Pointer dummy argument mismatch not detected by Fortran compiler

[thenlich at users dot sourceforge.net]

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 here.

[Bug libfortran/50105] Possibly: [4.3/4.4/4.5/4.6/4.7 Regression] I/O with g6.5 - wrong number of "**" shown

[thenlich at users dot sourceforge.net]

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?

[Bug fortran/47659] -Wconversion[-extra] should emit warning for constant expressions

[thenlich at users dot sourceforge.net]

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

[Bug other/48111] libquadmath: strtoflt128 bug on MinGW

[thenlich at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48111

Thomas Henlich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Thomas Henlich  ---
Cannot reproduce failure in tests 3 and 7 with gcc version 7.0.0 20161204
(experimental) (GCC)

Closing.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[thenlich at users dot sourceforge.net]

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.0002E-25,  0.)
>  ( -1.0002E-25,  0.) (  1.,  0.)
>  ( -3.4992E-24, -3.4992E-24) ( -4.1998E-24, -1.2703E-23)
>  (  1.,  0.) ( -1.0002E-25,  0.)
>  -
> 
> I have my experimental doing this: case A
>  -
>  (1.,0.) (-0.1000E-24,0.)   
>  (-0.1000E-24,0.)(1.,0.)
>  (-0.3499E-23,-0.3499E-23)   (-0.4200E-23,-0.1270E-22)  
>  (1.,0.) (-0.1000E-24,0.)   
>  -
> 
> I could also do this: case B
>  -
>  (1.,0.  ) (-0.1000E-24,0. )   
>  (-0.1000E-24,0. ) (1.,0.  )
> 
>  (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22)  
>  (1.,0.  ) (-0.1000E-24,0. )   
>  -
> 
> or is there some other arrangement?

I think your case B is invalid, because no spaces are allowed in constants,
i.e. between the parentheses (see above).

There is also case C (right-flush in 2*w+3):
 -
   (1.,0.)  (-0.1000E-24,0.)
  (-0.1000E-24,0.)   (1.,0.)
 (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22)  
   (1.,0.)  (-0.1000E-24,0.)   
 -

The standard says:

"Numeric editing, General rules: ... On output, the representation is right
justified in the field. If the number of characters produced by the editing is
smaller than the field width, leading blanks are inserted in the field."

[Bug fortran/47984] Pointer dummy argument mismatch not detected by Fortran compiler

[thenlich at users dot sourceforge.net]

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.

[Bug libfortran/48047] New: Incorrect output rounding of double precision numbers

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23603
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23603
Test case

The Fortran library does not round real(8) numbers correctly on output if 39
decimal digits are requested and real(16) is supported. This violates IEEE Std
754-2008 which demands that the minimum of supported significant digits for
correct rounding of all supported binary formats (H) is at least H=39 if the
binary128 format is supported.

Thus, GCC misses this requirement by 1 digit.

The attached program fails because the exact value, as given by
quadmath_snprintf(..., (__float128)0.14285714285714285) is
0.142857142857142849212692681248881854116916656494...

IEEE Std 754-2008 says:
===
5.12.2 External decimal character sequences representing finite numbers   
...
For the purposes of discussing the limits on correctly rounded conversion,
define the following quantities:
...
- for binary128, Pmin (binary128) = 36
...
- M = max(Pmin(bf)) for all supported binary formats bf
...

There might be an implementation-defined limit on the number of significant
digits that can be converted with correct rounding to and from supported binary
formats. That limit, H, shall be such that H >= M + 3 and it should be that H
is unbounded.

For all supported binary formats the conversion operations shall support
correctly rounded conversions to or from external character sequences for all
significant digit counts from 1 through H (that is, for all
expressible counts if H is unbounded).
...
===

[Bug libfortran/48054] New: Documentation for LOG intrinsic function is ambiguous

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The documentation for the LOG (Logarithm) function does not mention that this
function calculates the natural logarithm, the logarithm to the base e.

Also the example:
real(8) :: x = 1.0_8
x = log(x)

is not very meaningful, since the result is 0.0 for all logarithm bases.

Suggested fix:

Change the headline and description to

LOG — Natural logarithm function
LOG(X) computes the logarithm of X to base e.

or to (a modified version of the LOG10 doc):
LOG — Base e logarithm function
LOG(X) computes the base e logarithm of X. 

and change the example to
real(8) :: x = 2.718281828_8
which yields (approximately) 1

[Bug libfortran/48047] Incorrect output rounding of double precision numbers

[thenlich at users dot sourceforge.net]

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 for (partial) IEEE 754-2008 compliance seems like a good
thing.

It facilitates writing programs portable to other (IEEE 754-2008 compliant)
compilers.

[Bug libfortran/48047] Incorrect output rounding of double precision numbers

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/48047] Incorrect output rounding of double precision numbers

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047

Thomas Henlich  changed:

   What|Removed |Added

  Attachment #23611|0   |1
is obsolete||

--- Comment #6 from Thomas Henlich  
2011-03-10 09:41:40 UTC ---
Created attachment 23612
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23612
Comprehensive test for IEEE 754-2008 clause 5.12.2 compliant output rounding
(corrected)

[Bug other/48111] New: libquadmath: strtoflt128 bug on MinGW

[thenlich at users dot sourceforge.net]

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...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23649
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23649
Output of test case

The test case from http://gcc.gnu.org/bugzilla/attachment.cgi?id=23382 fails in
very strange ways.

Tested with MinGW gcc version 4.6.0 20110312 (experimental) (GCC) build from
equation.com

Attaching output.

strtoflt128 (".125") test 3BAD
  returns 0.12500029103830463509967191315652712546580005437135696411,
expected 0.125
...
strtoflt128 ("5.9e-76") test 7BAD
  returns 5.908177078951814709694457648319260185199116900204171e-76,
expected 5.859059012423657042231762819e-76

[Bug libfortran/48488] New: Wrong default format for real numbers

[thenlich at users dot sourceforge.net]

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...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


In write.c the intended default format for real numbers is documented as:

/* Output a real number with default format.
   This is 1PG14.7E2 for REAL(4), 1PG23.15E3 for REAL(8),
   1PG28.19E4 for REAL(10) and 1PG43.34E4 for REAL(16).  */
// FX -- FIXME: should we change the default format for __float128-real(16)?

This is reasonable, since it reflects the rounded-down number of decimal
significant digits for each format: 7, 15, 19, 34. Thus any number with less
decimal digits than the maximum precision always retains its original decimal
value which is a useful feature.

But it is implemented incorrectly as the following example shows:

print "(1PG14.7E2)", .3_4 ! 0.300
print *, .3_4 ! 0.3001 expected 0.300

print "(1PG23.15E3)", .3_8 ! 0.300
print *,  .3_8 ! 0.2 expected 0.300

print "(1PG28.19E4)", .3_10 ! 0.300
print *,  .3_10 ! 0.3001 expected (s.a.)

print "(1PG43.34E4)", .3_16 ! 0.3
print *,  .3_16 ! 0.299 exp. (s.a)

[Bug libfortran/48488] Wrong default format for real numbers

[thenlich at users dot sourceforge.net]

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 reals are
> ! wide enough and have enough precision, by checking that values can
> ! be written and read back.

However, the selected width in the current version (8, 17, 20, 35) is not big
enough to guarantee that. See IEEE 754/2008:

For the purposes of discussing the limits on correctly rounded conversion,
define the following quantities:
...
―   for binary32, Pmin(binary32) = 9
―   for binary64, Pmin(binary64) = 17
―   for binary128, Pmin(binary128) = 36
―   for all other binary formats bf, Pmin(bf) = 1 + ceiling(p×log10(2)), where
p is the number of significant bits in bf
...
Conversions from a supported binary format bf to an external character sequence
and back again results in a copy of the original number so long as there are at
least Pmin(bf) significant digits specified and the rounding-direction
attributes in effect during the two conversions are round to nearest
rounding-direction attributes.

I see two possibilities:

A. We aim to make the default format useful for human readers, so that e.g. 0.3
is always represented as 0.3000...
In that case we must choose P(bf) = floor(p×log10(2))

P = {7, 15, 19, 34}

B. We aim to make the default format useful for round-trip conversion, so that
a binary value is always converted to the same binary value.
In that case we must choose P(bf) = 1 + ceiling(p×log10(2))

P = {9, 17, 21, 36}

I personally prefer A.

Currently the values are sort of in the middle (except for real64).

[Bug libfortran/48511] New: Implement Steele-White algorithm for numeric output

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23923
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23923
Demonstration of correct rounding a la Steele-White

In their paper "How to Print Floating-Point Numbers Accurately" [1], Steele &
White describe an algorithm which for a internal binary floating-point number
outputs the shortest external decimal representation of that number which
converts back to the original number.

This should be implemented in libfortran, possibly as a separate I/O rounding
mode.

It would eliminate the problem of getting "odd" numbers, like 0.1776...
when the value 0.1977 is much shorter and represents the same exact binary
value.

Basically, their algorithm does the same as the attached program demonstrates,
only more efficiently.

[1] http://grouper.ieee.org/groups/754/email/pdfq3pavhBfih.pdf

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

[thenlich at users dot sourceforge.net]

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" output?
> 
> Well, the obvious(?) answer is the various descriptors with 0 width.

Not quite:

Since we're not talking about the shortest width (w) but the smallest number of
decimal digits in the fraction (d), only those descriptors where we can select
"a processor-dependent reasonable value for d" can be "shortened":

That would be list-directed and G0 (but not G0.d).

For all others the algorithm is still useful if we append zeros to fill the
required width: it is better to print 0.300 than 0.296

I'm still not sure where the Fortran standard says "a processor-dependent
reasonable value for d" that includes a "processor-dependent reasonable value
for d which also depends on the internal value to be printed" because that
would mess up tabular aligment for printing. This might be a feature users rely
on.

[Bug libfortran/48589] New: Invalid G0/G0.d editing for NaN/infinity

[thenlich at users dot sourceforge.net]

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: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23972
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23972
Test case

For NaN and infinity, the form of the output field for the G0 and G0.d edit
descriptors is set to a fixed width of 25, but Fortran 2008 demands:

10.7.5.2.2
3  For an internal value that is an IEEE infinity or NaN, [...] the form of the
output field for the G0 and G0.d edit descriptors is the same as for F0.0.

[Bug libfortran/48602] New: Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23976
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23976
Test case

Libfortran does not correctly implement the G conversion method from Fortran
2008 10.7.5.2.2(4) for the UP and DOWN I/O rounding modes.

The number of significant digits d is incorrect in some cases where the
magnitude of the internal value is close to a power of 10.

For instance

print "(RU,G15.2)", .991d0
prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with r
= 1 because of UP rounding mode

print "(RD,G15,2)", .996d0
prints 0.9 but expected is 0.99 because .996 < 1 - r * 10**-2 with r = 0
because of DOWN rounding mode

[Bug libfortran/48615] New: Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The E and ES descriptors ignore the I/O rounding mode:

print "(RU,F17.0)", 1.1
print "(RU,G17.1)", 1.1e9
print "(RU,E17.1)", 1.1e9 ! 0.1E+10 expected 0.2E+10
print "(RU,ES17.0)", 1.1e9  ! 1.E+09 expected 2.E+09
print "(RU,EN17.0)", 1.1e9

print "(RD,F17.0)", 1.9
print "(RD,G17.1)", 1.9e9
print "(RD,E17.1)", 1.9e9   ! 0.2E+10 expected 0.1E+10
print "(RD,ES17.0)", 1.9e9  ! 2.E+09 expected 1.E+09
print "(RD,EN17.0)", 1.9e9
end

Fortran 2008:
10.7.2.3.3 E and D editing
4 ...
- x1 x2 ... xd are the d most significant digits of the internal value after
rounding (10.7.2.3.7);

10.7.2.3.5 ES editing
5 ...
- y is a decimal digit representative of the most significant digit of the
internal value after rounding (10.7.2.3.7);
- signifies a decimal symbol (10.6);
- x1 x2 ... xd are the d next most significant digits of the internal value
after rounding;

10.7.2.3.7 I/O rounding mode
3 When the I/O rounding mode is UP, the value resulting from conversion shall
be the smallest representable value that is greater than or equal to the
original value. When the I/O rounding mode is DOWN, the value resulting
from conversion shall be the largest representable value that is less than or
equal to the original value.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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 because of UP rounding mode"
> 
> We are asking for two decimal digits in g15.2 above so 1.00 looks right to me.

No. The d in G editing describes the number of significant digits, not the
number of decimal digits.

Fortran 2008: 10.7.5.2.2 states clearly (first table in clause 4) that for a
value which rounds to a value greater or equal to 1 and smaller than 10 the
equivalent conversion is F(w-n).(d-1) and n blanks.

Thus the number of significant digits is d, because 1 digit comes before the
decimal separator and (d-1) digits after it.

GFortran does it right in most cases, except the ones described in this bug:
UP/DOWN rounding with values close to 1 (or other powers of 10) which would
round differently if COMPATIBLE rounding was in effect.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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. I
> have been exploring the code here but have not spotted it yet.  The issue 
> could
> either be in this formula implementation or in the rounding code which is
> nearby.

Ok, found something: The table has 0.5 hardcoded instead of the correct
(rounding-mode dependent) r. And the code in line 836 (and 858?) also.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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) ||\

This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r.

m < 0.1 - 0.1 * r * rexp_d
m < 0.1 * (1.0 - r * rexp_d)

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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_d) || (rexp_d * (m + r) >= 1.0) ||\
> 
> This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r.
> 
> m < 0.1 - 0.1 * r * rexp_d
> m < 0.1 * (1.0 - r * rexp_d)

Jerry, there is a bug in your patch: You replaced 0.05 with r. This is not
correct. In the original code the constant which is now r had a value of 0.5.
So you must replace 0.05 from the original with 0.1 * r, which can be written
either:

if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\

or

if ((m > 0.0 && m < 0.1 * (1.0 - r * rexp_d)) || (rexp_d * (m + r) >= 1.0) ||\

Please post a corrected patch, so we are testing the same thing.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
>   ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\
> { \
>   newf->format = FMT_E;\
>   newf->u.real.w = w;\
>   newf->u.real.d = d;\
>   newf->u.real.e = e;\
>   nb = 0;\
>   goto finish;\
> }\
> 
> Regression testing now.

Just noticed:

Shouldn't the last term in the if clause be:
compile_options.allow_std & (GFC_STD_F2003 | GFC_STD_F2008)

Fortran 2008 requires the F conversion for a magnitude of 0.0.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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 & GFC_STD_F2003)))\

to:

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 & GFC_STD_F2003)))\

for m == 0.0 this avoids evaluation of (rexp_d * (m + r) >= 1.0)) which is then
always false anyway.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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 "(RD,E15.2)", 0.09_RT
> print "(RD,D15.2)", 0.09_RT
> print "(RD,F15.2)", 0.09_RT
> end
> Gives:
> 
>   8.99967E-002  RD:
>0.89E-01
>0.90E-01
>0.90D-01
>0.08
> 
> I believe the E and D case should be 0.89E-01 and 0.89E-01

I agree.

Let's open a new bug for this. This bug is about the correct choice of format,
not about rounding (this is somewhere else in the code).

[Bug libfortran/48651] DTOA float conversion issue

[thenlich at users dot sourceforge.net]

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
> main ()
> {
>   float num = 0.9;
>   double dnum = 0.9;
>   long double ldnum = 25.6;
>   printf("%50.48f\n", num);
>   printf("%50.48lf, %d\n", num, sizeof(num));
>   printf("%80.78f\n", dnum);
>   printf("%80.78lf, %d\n", dnum, sizeof(dnum));
>   printf("%80.78f\n", ldnum);
>   printf("%80.78lf, %d\n", ldnum, sizeof(ldnum));

Check your format strings, use "lf" only for long double.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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 x
10^-d

and 1 - r x 10^-d <= N must still be true.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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, resulting in an unexpected and in this case invalid
result.

temp = calculate_exp(mid - 1) * (1 - r * rexp_d);

Compare:
$ gcc -O2 write_float.c && ./a.out
d=2
$ gcc -O2 -fexcess-precision=standard write_float.c && ./a.out
d=1

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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 a Cygwin
> installation.

$ uname -a
Linux debivm 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux
$ ~/gcc-4.7-20110409/bin/gcc -O2 write_float.c && ./a.out
d=2
$ ~/gcc-4.7-20110409/bin/gcc -O2 -fexcess-precision=standard write_float.c  &&
./a.out
d=1
$ ~/gcc-4.7-20110409/bin/gcc --version
gcc (GCC) 4.7.0 20110409 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

>uname -a
windows32 theta 2.5.1 2600 i686-pc Intel unknown MinGW

>gcc -O2 write_float.c && .\a.exe
d=2

>gcc -O2 -fexcess-precision=standard write_float.c && .\a.exe
d=1

>gcc --version
gcc (GCC) 4.7.0 20110409 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libfortran/48684] New: Incorrect field alignment with Gw.dEe descriptor

[thenlich at users dot sourceforge.net]

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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


With a Gw.dEe descriptor the output is formatted incorrectly if the F
conversion is selected and an exponent width e>4 is selected.

The conversion in this case is F(n-4).(d-x).n('b')

The constant n is required by Fortran 2008 to be e + 2.

But it is incorrectly calculated by GFortran as min(e, 4) + 2

print "(g15.3e5)", 0.1d0
print "(g15.3e5)", 0.1d12
Output:
0.100
   0.100E+00012

Expected output:
   0.100
   0.100E+00012

[Bug libfortran/48682] Incorrect field justification with Gw.d edit descriptor

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48682

Thomas Henlich  changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #1 from Thomas Henlich  
2011-04-19 14:53:08 UTC ---
The observed behaviour is completely conforming to Fortran 2008:

10.7.5.2.2 Generalized real and complex editing
4 ... Equivalent Conversion: F(w-n).(d-1),n('b')

where b is a blank, n is 4 for Gw.d

and that complete field (including the 4 spaces) is correctly right-justified
according to the mentioned rule in 10.7.2.1

Case closed.

[Bug libfortran/48684] Incorrect field alignment with Gw.dEe descriptor

[thenlich at users dot sourceforge.net]

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).(d-x).n('b')

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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,G15.1)", 0.095d0 ! > 0.1E+00 expected 0.1
print "(RC,F11.1,4X)", 0.095d0

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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 and compile with -mpc32 -mpc64 -mpc80 respectively.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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 the significand into
a buffer (with Ew.d editing). All that would remain is to decide whether to
print the exponent or not (according to a simple integer comparison), otherwise
shift the decimal point to the right place (simple string operation).

E.g.


0.0995 with RU,G0.2
dtoa -> ".10", exponent=0
output -> ".10"

12345000 with RD,G0.4:
dtoa -> ".1234", exponent=8
output -> ".1234E+08" because exponent > d

12345678.95 with RD,G0.9:
dtoa -> ".123456789", exponent=8
output -> "123456789." because exponent < d

[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

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)
  && dtp->u.p.scale_factor != 0))
{
  /* Always convert at full precision to avoid double rounding.  */
  ndigits = MIN_FIELD_WIDTH - 4 - edigits;
}
  else
{
  /* The number of digits is known, so let printf do the rounding.  */
  if (f->format == FMT_ES)
ndigits = f->u.real.d + 1;
  else
ndigits = f->u.real.d;
  if (ndigits > MIN_FIELD_WIDTH - 4 - edigits)
ndigits = MIN_FIELD_WIDTH - 4 - edigits;
}

"let printf do the rounding" means the result will always be rounded according
to the rounding rules of printf, which is for GLIBC: "If the value being
printed cannot be expressed accurately in the specified number of digits, the
value is rounded to the nearest number that fits."

[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

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
- the format is D, E or G; and the scale factor is 0.

I am unsure about the last requirement (scale_factor==0); isn't the number of
digits known even if the scale factor is != 0?

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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_float() is known (at the label 'skip'), if e
is within limits for F editing, revert the formatting to F and add the blanks
at the end.

[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

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

[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615

Thomas Henlich  changed:

   What|Removed |Added

  Attachment #24081|0   |1
is obsolete||

--- Comment #6 from Thomas Henlich  
2011-04-23 17:04:14 UTC ---
Created attachment 24083
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24083
Yet another revised test.

Found more bugs, even with COMPATIBLE rounding.

Tested with the equation.com build (MinGW). Please report if results on other
platforms differ.

Results obtained are in the comments.

[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

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 the output. I am not convinced that
adding one digit will solve the problem of rounding. It will for my first test
case, because it works for the values 1.1 and 1.9. But will it work for values
like 1.1 or 1.9? With your patch, they will be rounded to 1.0 (or 2.0)
by printf so libfortran has no way of knowing that it should round up (or
down).

And we recently set the maximum output width to the minimum value required by
IEEE 754-2008. Increasing that further (as your patch does) will only serve in
reducing the maximum rounding error from 1/1000 to 1/1 (but does not
contribute to fixing this bug)

Can you confirm that the patch fixes all the testcases in attachment 24083?

I still think my comment #2 still applies: We can only use this "shortcut"
rounding if the requested rounding mode equals that of printf, which I found to
be NEAREST with __mingw_printf and COMPATIBLE with MSVC printf. Others, e.g.
glibc probably have one of these modes, but I couldn't yet find out if this
feature is documented at all.

[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

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 be
no better way than always converting the full 40 digits, and then throwing away
most of them.

In Bug 48511 David Gay's dtoa implementation was mentioned. I looked into that
and I think it can be modified to be fully Fortran standard compliant. It
combines digit generation and rounding in one step and is probably
significantly more efficient than our current solution. Will investigate
further.

[Bug libfortran/48684] Incorrect field alignment with Gw.dEe descriptor

[thenlich at users dot sourceforge.net]

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 ifort give:
> >
> > 12345678901234567890
> > 0.100
> >  1.00
> >  10.0
> >  100.
> > 0.100E+4
> > 0.100E+5
> > 0.100E+6
> > 0.100E+7
> > 0.100E+8
> > 0.100E+9
> > 0.100E+00010
> > 0.100E+00011
> > 0.100E+00012
> --- snip ---
> >
> > My question, are the values of 1.0, 10.0, and 100. formatted correctly?
> >

Yes, the number of spaces is e+2=7, so they are aligned correctly.

[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589

Thomas Henlich  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Thomas Henlich  
2011-04-26 06:40:41 UTC ---
Tested ok on snapshot 20110423.

[Bug libfortran/48785] New: BOZ editing of real numbers not working with -std=f2008

[thenlich at users dot sourceforge.net]

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: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The B, O and Z edit descriptors are not accepted for output of real numbers
when Fortran 2008 standard mode is selected.

Fortran 2008 explicitly allows B, O and Z editing for real and complex numbers.
(This is different from Fortran 2003, which only specifies B, O and Z editing
for integer numbers. This has been discussed in Bug 41711.)

10.7.2.4 B, O, and Z editing
1 [...] The corresponding input/output list item shall be of type integer,
real, or complex.
...
4 The value is INT (X) if the input list item is of type integer and REAL (X)
if the input list item is of type real or complex, where X is a
boz-literal-constant that specifies the same bit sequence as the digits of the
input field.

The following program, when compiled with "-std=f2008" fails with:

 011
At line 3 of file test_boz.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Expected INTEGER for item 1 in formatted transfer, got
REAL
(b64)
 ^

program test_boz
print "(b64)", 123
print "(b64)", 1.23
print "(b0)", 123
print "(b0)", 1.23
print "(o24)", 123
print "(o24)", 1.23
print "(o0)", 123
print "(o0)", 1.23
print "(z0)", 123
print "(z0)", 1.23
print "(z16)", 123
print "(z16)", 1.23

print "(b64.64)", 123
print "(b64.64)", 1.23
print "(b0.64)", 123
print "(b0.64)", 1.23
print "(o24.24)", 123
print "(o24.24)", 1.23
print "(o0.24)", 123
print "(o0.24)", 1.23
print "(z0.16)", 123
print "(z0.16)", 1.23
print "(z16.16)", 123
print "(z16.16)", 1.23
end program test_boz

The expected behavior is the same as without the "-std=f2008" option. The
program should output:
 011
  1110011101011110100100
011
1110011101011110100100
 173
  7747270244
173
7747270244
7B
3F9D70A4
  7B
3F9D70A4
0011
001110011101011110100100
0011
001110011101011110100100
0173
007747270244
0173
007747270244
007B
3F9D70A4
007B
3F9D70A4

[Bug libfortran/48787] New: Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When UP output rounding is in effect, the output of F editing is rounded
incorrectly. In the example, real numbers with an exact internal representation
(whole numbers) are rounded up to the next higher value.

program test_ruf
print "(ru,f2.0)", 2.0_4 ! 3. expected 2.
print "(ru,f2.0)", 2.0_8 ! 3. expected 2.
print "(ru,f2.0)", 2.0_10 ! 3. expected 2.
print "(ru,f2.0)", 2.0_16 ! 3. expected 2.
end program test_ruf

Tested with gcc-Version 4.7.0 20110424 (experimental) [trunk revision 172919]
(GCC) 

Fortran 2008:
When the I/O rounding mode is UP, the value resulting from conversion shall be
the smallest representable value that is greater than or equal to the original
value.

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

[thenlich at users dot sourceforge.net]

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 Fortran formats where this is required), thus
mimicking the "regular" printf behaviour; or find the shortest number of digits
that round-trip to the same value (good for G0 editing). This should be worth a
try.

[Bug libfortran/48787] Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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.

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

[thenlich at users dot sourceforge.net]

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
> maybe list directed) output.

For this to be useful, it would require to choose a precision of not more than
P(bf) = floor(p×log10(2)); or floor(p×log10(2)) - 1, I'm not quite sure.

That would be P = {7, 15, 19, 34} or {6, 14, 18, 33}.

We then would have a loss of precision and no guarantee of round-trip
conversion to the same number.