https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #52 from akrl at gcc dot gnu.org ---
Yeah sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #50 from akrl at gcc dot gnu.org ---
Hi,
I've opened a dedicated bug for the discussed build issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #49 from Fritz Reese ---
(In reply to ktkachov from comment #48)
> (In reply to CVS Commits from comment #45)
[...]
>
> I think this broke the build for bare-metal (newlib) targets like
> aarch64-none-elf:
>
> libgfortran/intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #47 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:faa0817311f43e0d4d223d53c816b0c74ec35c4e
commit r10-7631-gfaa0817311f43e0d4d223d53c816b0c74ec35c4e
Author: Tobias Burnus
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Fritz Reese changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #45 from CVS Commits ---
The master branch has been updated by Fritz Reese :
https://gcc.gnu.org/g:57391ddaf39f7cb85825c32e83feb1435889da51
commit r10-7603-g57391ddaf39f7cb85825c32e83feb1435889da51
Author: Fritz Reese
Date: Tue A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Fritz Reese changed:
What|Removed |Added
Status|ASSIGNED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Fritz Reese changed:
What|Removed |Added
Attachment #47883|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC|kargl at gcc dot gnu.org |
--- Comment #44 from k
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, fmaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #42 from Steve Kargl ---
On Wed, Mar 04, 2020 at 04:35:02PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #41 from Thomas Henlich ---
> One would assume that fast 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 #39 from Steve Kargl ---
On Wed, Mar 04, 2020 at 12:07:18PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> On the other hand side, always folding sind(45...90) to cosd(45...0) and
>
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: C
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 #36 from Steve Kargl ---
On Mon, Mar 02, 2020 at 11:20:56AM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #35 from Thomas Henlich ---
> (In reply to Steve Kargl from c
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 F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #34 from Steve Kargl ---
On Fri, Feb 28, 2020 at 09:30:25AM +, thenlich at gcc dot gnu.org wrote:
>
> Going back one step, I wonder if it would be good enough
> to perform a correctly rounded conversion from degrees to
> radians,
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 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #32 from Steve Kargl ---
On Thu, Feb 27, 2020 at 05:53:38PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #31 from Thomas Henlich ---
> I wonder, if some "correct" rou
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=93871
--- Comment #30 from Steve Kargl ---
On Thu, Feb 27, 2020 at 07:31:43AM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #29 from Thomas Henlich ---
> (In reply to Steve Kargl from c
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=93871
--- Comment #28 from Steve Kargl ---
On Wed, Feb 26, 2020 at 04:02:23PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> > This is a best effort to still be able to use the standard library functions
> > but also get an increased accura
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #27 from Steve Kargl ---
On Wed, Feb 26, 2020 at 12:58:21PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #26 from Thomas Henlich ---
> Created attachment 47914
> --
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&action=edit
Demonstration of range reduction
There is a danger of some inaccuracy in the degree trigonometric functions
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #25 from Steve Kargl ---
On Wed, Feb 26, 2020 at 12:59:31AM +, kargl at gcc dot gnu.org wrote:
>
> * trans-intrinsic.c (rad2deg, deg2rad, gfc_conv_intrinsic_atrigd,
> gfc_conv_intrinsic_trigd, gfc_conv_intrinsic_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #24 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #23)
> Created attachment 47913 [details]
> Diff that replaces handling of degree trig functions.
Fritz,
I have attached a patch that completely replaces how you h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #23 from kargl at gcc dot gnu.org ---
Created attachment 47913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47913&action=edit
Diff that replaces handling of degree trig functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #22 from Steve Kargl ---
On Tue, Feb 25, 2020 at 07:32:31AM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #21 from Thomas Henlich ---
> One should also ask: What is th
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 sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #20 from joseph at codesourcery dot com ---
Note that for tiny arguments, tan should raise the underflow exception,
whereas cot should not raise underflow, but maybe you're not concerned
about exceptions raised.
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 machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #18 from Richard Biener ---
Given there's no cotan or ccotan in libm indeed the solution looks like somehow
exploiting sincos. Not sure how exactly that can be done.
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: Segme
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 i686-pc-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #15 from Steve Kargl ---
On Sat, Feb 22, 2020 at 10:17:17AM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #14 from Thomas Henlich ---
> Come for the runtime, stay for
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 #13 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:58:59PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #11 from Steve Kargl ---
> On Fri, Feb 21, 2020 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #12 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:40:22PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Ugh, this diff fixes constant-folding (without your mpc_sincos) patch.
>
> Index: gcc/fortran/simplify.c
> ===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #11 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:44:25PM +, foreese at gcc dot gnu.org wrote:
>
> --- Comment #10 from Fritz Reese ---
> Thomas, thank you for discovering this. Steve, thanks for your investigative
> work and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Fritz Reese changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #9 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:33:04PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #8 from Steve Kargl ---
> On Fri, Feb 21, 2020 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #8 from Steve Kargl ---
On Fri, Feb 21, 2020 at 08:19:01PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> program foo
> complex, parameter :: z = cotan((1.,1.))
> print *, z
> end program foo
>
Something is definitel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #7 from Steve Kargl ---
On Fri, Feb 21, 2020 at 07:45:39PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #6 from Thomas Henlich ---
> (In reply to kargl from comment #
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 evaluation
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&action=edit
Test case
Output:
th@THe-Surface:~$ /opt/gcc/bin/gfortran -L/opt/gcc/lib64 -Wl,-rpath
-Wl,/opt/gcc/lib64 -fdec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #4 from Steve Kargl ---
On Fri, Feb 21, 2020 at 06:53:18PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to kargl from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #3 from kargl at gcc dot gnu.org ---
(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 e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
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&action=edit
Proposed patch for COTAN speedup
This is basically the same method mpc uses internally to compute mpc_tan (onl
55 matches
Mail list logo
