On Fri, 3 Jul 2020, Rainer Orth wrote:
> I'm seeing the same on both i386-pc-solaris2.11 and
> sparc-sun-solaris2.11. It's in stage2, so the bootstrap compiler
> (gcc 8 in my case) should be immaterial.
Yes, that's what I meant (but did not articulate well).
> The following patch allowed bootst
Hi.
I'm going to install the following, tested with -m32.
Martin
>From 6c9e35a569f5a46fed7c8de6ac22545cb845a913 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 3 Jul 2020 13:45:45 +0200
Subject: [PATCH] gcov-dump: fix build for i386
gcc/ChangeLog:
PR bootstrap/96046
* gcov-dump.c (ta
On 7/3/20 10:46 AM, Rainer Orth wrote:
Hi Gerald,
On Thu, 2 Jul 2020, Martin Liška wrote:
All right, you convinced me and I'm going to install the patch.
I'm fraid this may have broke i386-unknown-freebsd-11.4 (with clang 10.0
as bootstrap compiler, though that doesn't appear to be the trigg
Hi Gerald,
> On Thu, 2 Jul 2020, Martin Liška wrote:
>> All right, you convinced me and I'm going to install the patch.
>
> I'm fraid this may have broke i386-unknown-freebsd-11.4 (with clang 10.0
> as bootstrap compiler, though that doesn't appear to be the trigger here):
>
> /scratch/tmp/gerald
On Thu, 2 Jul 2020, Martin Liška wrote:
> All right, you convinced me and I'm going to install the patch.
I'm fraid this may have broke i386-unknown-freebsd-11.4 (with clang 10.0
as bootstrap compiler, though that doesn't appear to be the trigger here):
/scratch/tmp/gerald/OBJ-0702-1130/./prev-g
On 7/1/20 4:01 PM, Jan Hubicka wrote:
On 7/1/20 3:15 AM, Martin Liška wrote:
On 6/30/20 3:24 PM, Nathan Sidwell wrote:
On 6/30/20 8:53 AM, Martin Liška wrote:
Yes, if there's a real need for a solid compression, then I would use a
generic compressor of a final streamed file.
for avoidance
> On 7/1/20 3:15 AM, Martin Liška wrote:
> > On 6/30/20 3:24 PM, Nathan Sidwell wrote:
> > > On 6/30/20 8:53 AM, Martin Liška wrote:
>
> > Yes, if there's a real need for a solid compression, then I would use a
> > generic compressor of a final streamed file.
>
> for avoidance of doubt, I'm good
On 7/1/20 3:15 AM, Martin Liška wrote:
On 6/30/20 3:24 PM, Nathan Sidwell wrote:
On 6/30/20 8:53 AM, Martin Liška wrote:
Yes, if there's a real need for a solid compression, then I would use a
generic compressor of a final streamed file.
for avoidance of doubt, I'm good with your current so
On 6/30/20 3:24 PM, Nathan Sidwell wrote:
On 6/30/20 8:53 AM, Martin Liška wrote:
Hey.
The bug reported confirmed that using the direct merging provides a solid
speed and so I don't insist on this patch. Using a generic compression algorithm
would be a better solution anyway.
Thanks for the r
On 6/30/20 8:53 AM, Martin Liška wrote:
Hey.
The bug reported confirmed that using the direct merging provides a solid
speed and so I don't insist on this patch. Using a generic compression
algorithm
would be a better solution anyway.
Thanks for the reminder. I won't insist on the generic c
Hey.
The bug reported confirmed that using the direct merging provides a solid
speed and so I don't insist on this patch. Using a generic compression algorithm
would be a better solution anyway.
Martin
On 6/17/20 2:57 PM, Nathan Sidwell wrote:
On 6/17/20 2:44 AM, Martin Liška wrote:
Hello.
As mentioned in the PR, gcda files tend to occupy a large disk space
when each running process streams to its own directory. The test-case
in the PR has very low coverage and so that the data file contain
a
On 6/17/20 2:44 AM, Martin Liška wrote:
Hello.
As mentioned in the PR, gcda files tend to occupy a large disk space
when each running process streams to its own directory. The test-case
in the PR has very low coverage and so that the data file contain
a lot of zero records.
The patch is attempt
Hello.
As mentioned in the PR, gcda files tend to occupy a large disk space
when each running process streams to its own directory. The test-case
in the PR has very low coverage and so that the data file contain
a lot of zero records.
The patch is attempt to not stream these zero COUNTERS:
a-tr
14 matches
Mail list logo
