On 24.07.2012 21:13, Steven Bosscher wrote:
AFAIR the qsort is just for getting a stable ordering over two pools to find
the leaked regsets afterwards, the type of ordering doesn't matter.
What matters is that the compare function gives a reliable result. You
can't subtract pointers like that
On Tue, Jul 24, 2012 at 7:13 PM, Steven Bosscher stevenb@gmail.com wrote:
AFAIR the qsort is just for getting a stable ordering over two pools to find
the leaked regsets afterwards, the type of ordering doesn't matter.
What matters is that the compare function gives a reliable result. You
On Wed, Jul 25, 2012 at 1:49 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Oh, bigger bitmap_head? That's bad ... :/ So much for '#ifdefs are bad' :/
Bigger bitmap_head isn't a problem. A bigger bitmap_element would be bad.
For GGC allocated bitmaps, nothing changed (rounding, etc.).
On Wed, Jul 25, 2012 at 1:59 PM, Steven Bosscher stevenb@gmail.com wrote:
On Wed, Jul 25, 2012 at 1:49 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Oh, bigger bitmap_head? That's bad ... :/ So much for '#ifdefs are bad' :/
Bigger bitmap_head isn't a problem. A bigger
On Mon, Jul 23, 2012 at 7:01 PM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This large patch makes GATHER_STATISTICS always take a value, 0
(disabled) or 1 (enabled), and turns all related #ifdef code into
conditional branches.
This slightly increases the data section of cc1, but
Hello!
This large patch makes GATHER_STATISTICS always take a value, 0
(disabled) or 1 (enabled), and turns all related #ifdef code into
conditional branches.
This slightly increases the data section of cc1, but only marginally.
There is no impact on compile time, because all tests are
On Tue, Jul 24, 2012 at 3:08 PM, Uros Bizjak ubiz...@gmail.com wrote:
This patch (r189803) regressed a bunch of tests on x86_64 [1], [2].
[1] http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02066.html
[2] http://gcc.gnu.org/ml/gcc-regression/2012-07/msg00177.html
These are all
On Tue, Jul 24, 2012 at 4:37 PM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Jul 24, 2012 at 3:08 PM, Uros Bizjak ubiz...@gmail.com wrote:
This patch (r189803) regressed a bunch of tests on x86_64 [1], [2].
[1] http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02066.html
[2]
On 2012.07.23 at 19:01 +0200, Steven Bosscher wrote:
Hello,
This large patch makes GATHER_STATISTICS always take a value, 0
(disabled) or 1 (enabled), and turns all related #ifdef code into
conditional branches.
This slightly increases the data section of cc1, but only marginally.
There
On Tue, Jul 24, 2012 at 6:21 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2012.07.23 at 19:01 +0200, Steven Bosscher wrote:
Hello,
This large patch makes GATHER_STATISTICS always take a value, 0
(disabled) or 1 (enabled), and turns all related #ifdef code into
conditional
Hello,
On 24.07.2012 18:56, Steven Bosscher wrote:
On Tue, Jul 24, 2012 at 4:37 PM, Steven Bosscherstevenb@gmail.com wrote:
On Tue, Jul 24, 2012 at 3:08 PM, Uros Bizjakubiz...@gmail.com wrote:
This patch (r189803) regressed a bunch of tests on x86_64 [1], [2].
[1]
AFAIR the qsort is just for getting a stable ordering over two pools to find
the leaked regsets afterwards, the type of ordering doesn't matter.
What matters is that the compare function gives a reliable result. You
can't subtract pointers like that for qsort.
After consulting the experts on
On 07/23/2012 01:01 PM, Steven Bosscher wrote:
This large patch makes GATHER_STATISTICS always take a value, 0
(disabled) or 1 (enabled), and turns all related #ifdef code into
conditional branches.
Did you test this with --enable-gather-detailed-mem-stats? It didn't
build for me, so I fixed
On Tue, Jul 24, 2012 at 7:53 PM, Jason Merrill ja...@redhat.com wrote:
On 07/23/2012 01:01 PM, Steven Bosscher wrote:
This large patch makes GATHER_STATISTICS always take a value, 0
(disabled) or 1 (enabled), and turns all related #ifdef code into
conditional branches.
Did you test this
14 matches
Mail list logo
