I applied this patch. Aaron's patch, AFAICT, would repeatedly fopen the error
file.
nathan
2016-06-05 Aaron Conole
Nathan Sidwell
PR libgcc/71400
* libgcov-driver-system.c (__gcov_error_file): Disable if IN_GCOV_TOOL.
(get_gcov_error_file): Check __gcov_error_file before trying t
> It breaks profiledbootstrap:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71400
I am including a patch that should fix the issues introduced by my
patch. I have confirmed behavior on my system, and built with
profiledbootstrap as well as bootstrap.
libgcc/ChangeLog:
2016-06-04 Aaron Conol
"H.J. Lu" writes:
> On Mon, May 23, 2016 at 11:16 AM, Aaron Conole wrote:
>> Nathan Sidwell writes:
>>
>>> On 05/19/16 14:40, Aaron Conole wrote:
Nathan Sidwell writes:
>>>
>> +FILE *__gcov_error_file = NULL;
>
> Unless I'm missing something, isn't this only accessed from this
On Mon, May 23, 2016 at 11:16 AM, Aaron Conole wrote:
> Nathan Sidwell writes:
>
>> On 05/19/16 14:40, Aaron Conole wrote:
>>> Nathan Sidwell writes:
>>
> +FILE *__gcov_error_file = NULL;
Unless I'm missing something, isn't this only accessed from this file?
(So could be stati
Nathan Sidwell writes:
> On 05/19/16 14:40, Aaron Conole wrote:
>> Nathan Sidwell writes:
>
+FILE *__gcov_error_file = NULL;
>>>
>>> Unless I'm missing something, isn't this only accessed from this file?
>>> (So could be static with a non-underbarred name)
>>
>> Ack.
>
> I have a vague memo
On 05/19/2016 05:14 PM, Nathan Sidwell wrote:
On 05/19/16 15:25, Jeff Law wrote:
On 05/19/2016 12:40 PM, Aaron Conole wrote:
I'm happy to report that I did send in some FSF paperwork this week.
Hopefully it is on record now, but even if it isn't I live a train ride
away from the FSF headquart
On 05/19/16 14:40, Aaron Conole wrote:
Nathan Sidwell writes:
+FILE *__gcov_error_file = NULL;
Unless I'm missing something, isn't this only accessed from this file?
(So could be static with a non-underbarred name)
Ack.
I have a vague memory that perhaps the __gcov_error_file is seen fr
On 05/19/16 15:25, Jeff Law wrote:
On 05/19/2016 12:40 PM, Aaron Conole wrote:
I'm happy to report that I did send in some FSF paperwork this week.
Hopefully it is on record now, but even if it isn't I live a train ride
away from the FSF headquarters so I'd be happy to take the time to make
su
On 05/19/2016 12:40 PM, Aaron Conole wrote:
Nathan Sidwell writes:
On 02/24/16 16:52, Aaron Conole wrote:
The previous gcov behavior was to always output errors on the stderr channel.
This is fine for most uses, but some programs will require stderr to be
untouched by libgcov for certain test
Nathan Sidwell writes:
> On 02/24/16 16:52, Aaron Conole wrote:
>> The previous gcov behavior was to always output errors on the stderr channel.
>> This is fine for most uses, but some programs will require stderr to be
>> untouched by libgcov for certain tests. This change allows configuring
>>
On 02/24/16 16:52, Aaron Conole wrote:
The previous gcov behavior was to always output errors on the stderr channel.
This is fine for most uses, but some programs will require stderr to be
untouched by libgcov for certain tests. This change allows configuring
the gcov output via an environment va
> On 04/29/16 11:08, Aaron Conole wrote:
>
> >Perhaps I've poorly explained what I want. I want to be able to pipe
> >gcov error messages to a different file for post-processing / reporting
> >elsewhere. I don't want them mixed with the application's messages. Do
> >you think this kind of generic
On 04/29/16 11:08, Aaron Conole wrote:
Perhaps I've poorly explained what I want. I want to be able to pipe
gcov error messages to a different file for post-processing / reporting
elsewhere. I don't want them mixed with the application's messages. Do
you think this kind of generic flexibility is
Nathan Sidwell writes:
> On 04/27/16 16:59, Aaron Conole wrote:
>> Apologies for the top post. Pinging on this again. It still applies
>> cleanly, so no need to resubmit, I think. Is there anything else missing
>> or required before this can go in?
>
> I'm not convinced this is a desirable featur
On 04/27/16 16:59, Aaron Conole wrote:
Apologies for the top post. Pinging on this again. It still applies
cleanly, so no need to resubmit, I think. Is there anything else missing
or required before this can go in?
I'm not convinced this is a desirable feature. IIRC your rationale for it was
Apologies for the top post. Pinging on this again. It still applies
cleanly, so no need to resubmit, I think. Is there anything else missing
or required before this can go in?
Thanks,
-Aaron
Aaron Conole writes:
> The previous gcov behavior was to always output errors on the stderr channel.
> T
Ping on this; what are the next steps?
Thanks
Aaron Conole writes:
> The previous gcov behavior was to always output errors on the stderr channel.
> This is fine for most uses, but some programs will require stderr to be
> untouched by libgcov for certain tests. This change allows configuring
>
The previous gcov behavior was to always output errors on the stderr channel.
This is fine for most uses, but some programs will require stderr to be
untouched by libgcov for certain tests. This change allows configuring
the gcov output via an environment variable which will be used to open
the app
18 matches
Mail list logo
