https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #6 from Thomas Henlich ---
(In reply to Jerry DeLisle from comment #5)
> I have been studying this a bit by looking at the 2023 std and functionality
> of printf().
> Specifically printf() provides the 'A' descriptor which can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733
--- Comment #9 from Thomas Henlich ---
I think this standard conformity check is only performed at compile-time, and
can only work if the format is defined in a constant.
So, changing the definition to:
character(4), parameter :: fmt="(g0)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733
--- Comment #7 from Thomas Henlich ---
(In reply to Dominique d'Humieres from comment #6)
> > Please explain, what valid code according to Fortran 2008 does -std=f2008
> > reject?
>
> FAIL: gfortran.dg/fmt_g0_4.f08 -O (test for excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733
--- Comment #5 from Thomas Henlich ---
(In reply to Dominique d'Humieres from comment #4)
> But reject valid too! AFAIU this cannot captured ay the format level.
Please explain, what valid code according to Fortran 2008 does -std=f2008
reject?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733
--- Comment #3 from Thomas Henlich ---
(In reply to Dominique d'Humieres from comment #2)
> Does it look good?
Agreed, that should fix the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #35 from Thomas Henlich ---
I tried to investigate the next issue:
write (aresult,fmt="(G0.10e0)") rn
if (aresult /= "0.313928E-2") stop 52
triggers "E specifier not allowed with g0 descriptor in format string" during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #34 from Thomas Henlich ---
Created attachment 47976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47976=edit
Patch to fix issue with wrong exponent width for w=0
I appear to have found a fix for one of the remaining issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #43 from Thomas Henlich ---
(In reply to Steve Kargl from comment #42)
> gfortran currently does not implement IEEE_FMA along
> with a few additional IEEE_ARITHMETIC features added
> in F2018.
>
> Note, gcc/builtins.def has fma,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #41 from Thomas Henlich ---
One would assume that fast FMA
(https://en.wikipedia.org/wiki/FMA_instruction_set) is or will be available to
the modern Fortran enthusiast, in the year 202x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #40 from Thomas Henlich ---
Now I get it, symmetry is beautiful: Both sin(x) and cos(x) for any x can
always be calculated with one range reduction to 0...45, one call to sincos(),
and a sign transfer for each result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #38 from Thomas Henlich ---
(In reply to Thomas Henlich from comment #37)
> It would make sense to keep optimization in mind:
>
> Several calls to conversions of the same value should be performed only once.
>
> As a special case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #37 from Thomas Henlich ---
It would make sense to keep optimization in mind:
Several calls to conversions of the same value should be performed only once.
As a special case: Calls to compute sind(x) and cosd(x) should be optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #35 from Thomas Henlich ---
(In reply to Steve Kargl from comment #34)
> Even this appears to have some irregularities as my exhaustive
> test in the interval [1.e-8,1) with direct call to sinf() yields
>
This looks like a job for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #33 from Thomas Henlich ---
Going back one step, I wonder if it would be good enough to perform a correctly
rounded conversion from degrees to radians, and just use sin() as is.
...
f = sgn * sin(deg2rad(arg))
end function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #31 from Thomas Henlich ---
I wonder, if some "correct" rounding could further increase accuracy: We know
the sign and "real" magnitude of the difference deg2rad-π/180 and can round the
result of sin() accordingly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948
--- Comment #2 from Thomas Henlich ---
-fall-intrinsics is a nice workaround, but it also enables more than I want.
I just find it not intuitive, that -fdec apparently has the same effect as
-fall-intrinsics for some intrinsics, but -fdec-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #29 from Thomas Henlich ---
(In reply to Steve Kargl from comment #28)
> ! Fold into [0,90] range
...
> if (arg == 180) then
I don't understand how (arg == 180) could be true after folding into [0,90]
range.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948
Thomas Henlich changed:
What|Removed |Added
Severity|normal |minor
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: thenlich at gcc dot gnu.org
Target Milestone: ---
It is surprising that the -std option leads to the -fdec-math option to be
silently ignored, while the -fdec option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #26 from Thomas Henlich ---
Created attachment 47914
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47914=edit
Demonstration of range reduction
There is a danger of some inaccuracy in the degree trigonometric functions
(sind,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47485
Thomas Henlich changed:
What|Removed |Added
Severity|minor |normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Thomas Henlich changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #21 from Thomas Henlich ---
One should also ask: What is the least surprising way to implement the
cotangent function?
If someone uses a (non-standard) function bearing a name similar to "tangent",
they probably expect a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47485
Thomas Henlich changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #19 from Thomas Henlich ---
Regarding the following:
https://stackoverflow.com/questions/3738384/stable-cotangent#56864824
Is there a more stable implementation for the cotangent function than return
1.0/tan(x)?
No.
No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736
--- Comment #7 from Thomas Henlich ---
This should have a test-case added, ideally by renaming an already existing
test-case containing Fortran 2018 features to .f18.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #17 from Thomas Henlich ---
The following should give an error message, not a ICE:
program test_dtrig2
real, parameter :: d = asind(1.1)
print *, d
end
gfortran -fdec-math test_dtrig2.f90
f951.exe: internal compiler error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #16 from Thomas Henlich ---
Additional note:
The issue is not restricted to complex types, but also occurs for real types.
On i686-mingw32, by a factor 2...10 depending on kind.
However I could not measure any slowdown on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #14 from Thomas Henlich ---
Come for the runtime, stay for the ICE!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #6 from Thomas Henlich ---
(In reply to kargl from comment #2)
> Can you post the code you used for testing? Your patch to simplify.c
> affects compile-time constant folding. simplify.c has nothing to do
> with a run-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #5 from Thomas Henlich ---
Created attachment 47884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47884=edit
Test case
Output:
th@THe-Surface:~$ /opt/gcc/bin/gfortran -L/opt/gcc/lib64 -Wl,-rpath
-Wl,/opt/gcc/lib64 -fdec-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #1 from Thomas Henlich ---
Created attachment 47883
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47883=edit
Proposed patch for COTAN speedup
This is basically the same method mpc uses internally to compute mpc_tan (only
Assignee: unassigned at gcc dot gnu.org
Reporter: thenlich at gcc dot gnu.org
Target Milestone: ---
Runtime tests show that the COTAN function (cotangent function, GNU extension)
needs about twice the time as TAN for complex types.
This is surprising, since it basically performs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736
--- Comment #6 from Thomas Henlich ---
Created attachment 47842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47842=edit
Proposed patch to add .f18/.F18 suffix
Add .f18 and .F18 to list of recognized filename suffixes to match the most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736
Thomas Henlich changed:
What|Removed |Added
Priority|P3 |P5
--- Comment #4 from Thomas Henlich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736
--- Comment #2 from Thomas Henlich ---
I don't know why the Fortran compiler doesn't treat all files as free-form
Fortran source files, unless they have a known extension indicating otherwise.
Assignee: unassigned at gcc dot gnu.org
Reporter: thenlich at gcc dot gnu.org
Target Milestone: ---
The Fortran compiler should recognize Fortran source files with the .f18 and
.F18 filename extension.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: thenlich at gcc dot gnu.org
Target Milestone: ---
This example compiles and runs.
But the second part should be rejected with -std=f2008 because these are
Fortran 2018 features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #33 from Thomas Henlich ---
Created attachment 47834
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47834=edit
Proposed fix for test
Proposed test for verifying the correct output after finishing this bug.
Assignee: unassigned at gcc dot gnu.org
Reporter: thenlich at gcc dot gnu.org
Target Milestone: ---
13.7.2.3.6 EX editing
1 The EX edit descriptor produces an output field in the form of a
hexadecimal-significand number.
2 The EXw.d and EXw.dEe edit descriptors indicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725
--- Comment #9 from Thomas Henlich ---
Created attachment 47827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47827=edit
Proposed patch to perform runtime check in fmt_g0_4.f08
This checks ensure that G0.d output is not broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
Bug 90374 depends on bug 36725, which changed state.
Bug 36725 Summary: g0 edit descriptor: Missing compile-time checking for
invalid g0.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725
What|Removed
||thenlich at gcc dot gnu.org
Blocks||90374
Resolution|FIXED |---
--- Comment #8 from Thomas Henlich ---
This bug is now apparently invalid.
"C1007 (R1007) For the G edit descriptor, d shall be spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550
Thomas Henlich changed:
What|Removed |Added
Priority|P3 |P5
Severity|normal
45 matches
Mail list logo
