* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-12 11:58 ` jakub at gcc dot gnu.org
2020-04-01 12:28 ` vincent-gcc at vinc17 dot net
` (8 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-12 11:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|9.3 |9.4
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 9.3.0 has been released, adjusting target milestone.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions jakub at gcc dot gnu.org
@ 2020-04-01 12:28 ` vincent-gcc at vinc17 dot net
2020-04-01 12:41 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2020-04-01 12:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
I can reproduce the issue on my Debian machine. Do you know which values are
passed to MPC?
I've tried with
mpc_init2 (x, 24);
mpc_init2 (y, 24);
mpc_set_ui_ui (x, 10000, 10000, MPC_RNDNN);
mpc_tan (y, x, MPC_RNDNN);
including with a reduced exponent range, but this is very fast. And according
to ldd, the same versions of the GMP/MPFR/MPC libraries are used here with both
GCC and my MPC test.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions jakub at gcc dot gnu.org
2020-04-01 12:28 ` vincent-gcc at vinc17 dot net
@ 2020-04-01 12:41 ` rguenth at gcc dot gnu.org
2020-04-01 13:17 ` vincent-gcc at vinc17 dot net
` (6 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-04-01 12:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
mpc_tan (m, m, 0)
with
(gdb) p *m
$14 = {re = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = 14,
_mpfr_d = 0x3713c48}}, im = {{_mpfr_prec = 24, _mpfr_sign = 1,
_mpfr_exp = 14, _mpfr_d = 0x3710278}}}
(gdb) p *m->re._mpfr_d@4
$36 = {11258999068426240000, 32, 81, 57753152}
(gdb) p *m->im._mpfr_d@4
$37 = {11258999068426240000, 32, 81, 57738592}
I guess there's only one limb, the rest looks garbage. We're using
mpfr_set_str on the re/im part from "0x0.9c4p+14" here.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-04-01 12:41 ` rguenth at gcc dot gnu.org
@ 2020-04-01 13:17 ` vincent-gcc at vinc17 dot net
2020-04-01 13:33 ` vincent-gcc at vinc17 dot net
` (5 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2020-04-01 13:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Richard Biener from comment #6)
> I guess there's only one limb, the rest looks garbage.
Yes, and 11258999068426240000 with _mpfr_exp = 14 corresponds to 10000 as
expected (11258999068426240000 = 10000*2^50).
And even when reusing the input
mpc_init2 (x, 24);
mpc_set_ui_ui (x, 10000, 10000, MPC_RNDNN);
mpc_tan (x, x, 0);
the program terminates immediately.
I'm going to look at this more closely with gdb. But I confirm I can see
mpc_tan in the backtrace.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-04-01 13:17 ` vincent-gcc at vinc17 dot net
@ 2020-04-01 13:33 ` vincent-gcc at vinc17 dot net
2020-04-01 13:38 ` rguenther at suse dot de
` (4 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2020-04-01 13:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #8 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
The exponent range is important. With ltrace, I can see:
3472505 mpfr_set_emin(0xffffffffffff7f22, 0xffffbf92, 0xffffbf92, 46) = 0
3472505 mpfr_set_emax(0x8002, 0xffffbf92, 0x7fb7c2c9c420, 46) = 0
(BTW, this is buggy, mpfr_set_emin and mpfr_set_emax take one argument only).
And with these corresponding particular values
mpfr_set_emin (-32990);
mpfr_set_emax (32770);
my MPC test loops.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-04-01 13:33 ` vincent-gcc at vinc17 dot net
@ 2020-04-01 13:38 ` rguenther at suse dot de
2020-04-01 14:17 ` vincent-gcc at vinc17 dot net
` (3 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: rguenther at suse dot de @ 2020-04-01 13:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 1 Apr 2020, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
>
> --- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
> (In reply to Richard Biener from comment #6)
> > I guess there's only one limb, the rest looks garbage.
>
> Yes, and 11258999068426240000 with _mpfr_exp = 14 corresponds to 10000 as
> expected (11258999068426240000 = 10000*2^50).
>
> And even when reusing the input
>
> mpc_init2 (x, 24);
> mpc_set_ui_ui (x, 10000, 10000, MPC_RNDNN);
> mpc_tan (x, x, 0);
>
> the program terminates immediately.
>
> I'm going to look at this more closely with gdb. But I confirm I can see
> mpc_tan in the backtrace.
It's likely by us doing
mpfr_set_emin (-32990);
mpfr_set_emax (32766);
during startup to work around a similar bug in MPC (IIRC it also
was tan ...).
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-04-01 13:38 ` rguenther at suse dot de
@ 2020-04-01 14:17 ` vincent-gcc at vinc17 dot net
2020-04-01 14:33 ` vincent-gcc at vinc17 dot net
` (2 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2020-04-01 14:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #10 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to rguenther@suse.de from comment #9)
> It's likely by us doing
>
> mpfr_set_emin (-32990);
> mpfr_set_emax (32766);
>
> during startup to work around a similar bug in MPC (IIRC it also
> was tan ...).
I suspect an internal overflow in the MPC computation, in which case doubling
the precision at each iteration won't solve the issue. Setting emax to 14425 or
below avoids the loop, but the real part of the result is slightly incorrect (0
instead of non-zero), though not affecting the binary32 exponent range, as this
value is tiny:
1.0011111100101111e-28854
Changing the exponent range will solve the issue for some values, but I fear
that whatever the exponent range is chosen, there may remain values that will
trigger the bug.
Paul Zimmermann says that this bug is fixed in the MPC development version.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-04-01 14:17 ` vincent-gcc at vinc17 dot net
@ 2020-04-01 14:33 ` vincent-gcc at vinc17 dot net
2020-04-01 15:53 ` vincent-gcc at vinc17 dot net
2020-04-03 12:23 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 10+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2020-04-01 14:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #11 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Vincent Lefèvre from comment #10)
> Paul Zimmermann says that this bug is fixed in the MPC development version.
I could check that the bug is actually fixed, but the does not solve the GCC
issue, as the time complexity is too large. With 10000000 instead of 10000,
you'll still notice that it takes too much time.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-04-01 14:33 ` vincent-gcc at vinc17 dot net
@ 2020-04-01 15:53 ` vincent-gcc at vinc17 dot net
2020-04-03 12:23 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 10+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2020-04-01 15:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #12 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Vincent Lefèvre from comment #11)
> (In reply to Vincent Lefèvre from comment #10)
> > Paul Zimmermann says that this bug is fixed in the MPC development version.
>
> I could check that the bug is actually fixed, but the does not solve the GCC
> issue, as the time complexity is too large. With 10000000 instead of 10000,
> you'll still notice that it takes too much time.
But as Paul says, keeping the exponent range reduced as above allows an
immediate answer. So the solution will be to upgrade to the next MPC version
(not released yet) and do not increase the exponent range (this allows early
underflow/overflow checking, thus may avoid costly computations in some
domains).
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
[not found] <bug-91858-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-04-01 15:53 ` vincent-gcc at vinc17 dot net
@ 2020-04-03 12:23 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-04-03 12:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |MOVED
Status|NEW |RESOLVED
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, thanks for digging into this. -> mpc bug
^ permalink raw reply [flat|nested] 10+ messages in thread