https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Summary|[14 Regression] |[11/12/13/14 Regression]
|testsuite/std/ranges/iota/m |testsuite/std/ranges/iota/m
|ax_size_type.cc 5x times |ax_size_type.cc 5x times
|slower |slower
Target Milestone|--- |11.5
Last reconfirmed| |2024-01-02
--- Comment #8 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #3)
> There's one single regression event, bringing the host runtime to about 1.63
> seconds. Then some time later, an additional 0.1 second was added
> (accumulated).
> I did not look into that latter regression. The big one is clouded by a
> large range of commits where max_size_type failed, due to
> r14-159-g03cebd304955a6.
> This was fixed in r14-205-g83470a5cd4c3d2, at which time there the big
> regression is seen for the first time. That is also the "cause" for the
> commit, because applying that commit to r14-158-g7d115e01411156 shows the
> same number as for r14-205-g83470a5cd4c3d2.
Interesting, thanks for bisecting this. Before r14-205, the two main loops in
max_size_type.cc were effectively dead in the signed case because the 'signed'
qualifier in
using hw_type = std::conditional_t<signed_p, signed rep_t, rep_t>;
was being silently dropped (until r14-159, after which it was correctly
rejected). This meant that when signed_p is true, the for loop
for (hw_type i = min; i <= max; i++)
was equivalent to
for (unsigned __int128 i = -1000; i <= 1000; i++)
so the loop body was never run! When r14-205 fixed that, the total number of
loop iterations increased by approximately 4x (2x due to symmetry with
unsigned, 2x due to the loop range being -limit...limit instead of 0...limit)
which is roughly consistent with a 5x increase in test execution time.
> Maybe the higher number for the execution time is actually the "right" one
> and the range > should be cut down to -100..100 for *all* targets?
That sounds good to me.. I can prepare a simple patch for that, which probably
should be backported to all release branches that r14-205 was backported to.
