On 10/13/2016 04:31 PM, Rainer Orth wrote:
> Hi Martin,
>
>> Good! How does it look with the former solaris targets that does not support
>> prioritized ctors?
>
> still no failures there, neither with ld (which lacks constructor
> priority support) nor with gld (which has it). Only Solaris 12
Hi Martin,
> Good! How does it look with the former solaris targets that does not support
> prioritized ctors?
still no failures there, neither with ld (which lacks constructor
priority support) nor with gld (which has it). Only Solaris 12 shows
the failures, both with ld and gld (both of which
On 10/13/2016 04:04 PM, Rainer Orth wrote:
> no, it's from r240990 unlike I'm completely mistaken. However, current
> trunk bootstraps are running as we speak.
>
> Rainer
Good! How does it look with the former solaris targets that does not support
prioritized ctors?
Thanks,
Martin
Hi Martin,
> Just running my previous example (priotity.c), I can see with -S:
>
> _GLOBAL__sub_D_00099_1_foo:
> jmp __gcov_exit
> .size _GLOBAL__sub_D_00099_1_foo, .-_GLOBAL__sub_D_00099_1_foo
> .section.fini_array.00099,"aw"
> .align 4
> .long
On 10/13/2016 03:46 PM, Rainer Orth wrote:
> Hi Martin,
>
> sorry for the long delay: I've been extremely busy the last two weeks.
Hello
Never mind, still plenty of time before we'll release 7.1.0 :)
>
>> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>>> this would be i386-pc-solaris2.12. I'm
Hi Martin,
sorry for the long delay: I've been extremely busy the last two weeks.
> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>> this would be i386-pc-solaris2.12. I'm not sure if the constructor
>> priority detection works in a cross scenario.
>
> Hi.
>
> By the way, I tried to test the
On 09/30/2016 02:31 PM, Rainer Orth wrote:
this would be i386-pc-solaris2.12. I'm not sure if the constructor
priority detection works in a cross scenario.
Hi.
By the way, I tried to test the cross-compiler:
$ ../configure --disable-bootstrap --enable-languages=c,c++,fortran
On 10/03/2016 03:03 PM, Rainer Orth wrote:
> Hi Martin,
>
>> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>>> this would be i386-pc-solaris2.12. I'm not sure if the constructor
>>> priority detection works in a cross scenario.
>>>
>>> I'm attaching the resulting assembly (although for Solaris as,
Hi Martin,
> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>> this would be i386-pc-solaris2.12. I'm not sure if the constructor
>> priority detection works in a cross scenario.
>>
>> I'm attaching the resulting assembly (although for Solaris as, the gas
>> build is still running).
>
> Hi. Sorry,
Hi Martin,
> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>> this would be i386-pc-solaris2.12. I'm not sure if the constructor
>> priority detection works in a cross scenario.
>>
>> I'm attaching the resulting assembly (although for Solaris as, the gas
>> build is still running).
>
> Hi. Sorry,
On 09/30/2016 02:31 PM, Rainer Orth wrote:
> this would be i386-pc-solaris2.12. I'm not sure if the constructor
> priority detection works in a cross scenario.
>
> I'm attaching the resulting assembly (although for Solaris as, the gas
> build is still running).
Hi. Sorry, I have a stupid
Hi Martin,
>> understood. However, Solaris 12 *does* have support for constructor
>> priorities and the testcase still fails, so there's more going on here.
>
> I see, however I don't have access to such a machine. I would appreciate
> if you help me to debug what's going on. Can you please send
On 09/30/16 05:22, Rainer Orth wrote:
While this would take care of the testsuite failures, this creates a
terrible user experience outside of the testsuite: if we know that
-fprofile-arcs -ftest-coverage cannot work on targets without
constructor priority support, the compiler should error out
On 09/30/2016 11:22 AM, Rainer Orth wrote:
> Hi Martin,
>
>>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>>>
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL:
Hi Martin,
>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>>
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>> counts, 0 i
>> n branch percentages, 0 in return percentages, 0 in intermediate format
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 line 21: is
On 09/29/2016 03:00 PM, Nathan Sidwell wrote:
> On 09/29/16 08:54, Nathan Sidwell wrote:
>> On 09/29/16 08:49, Martin Liška wrote:
>>> Ideally we should have a macro for each target telling whether it supports
>>> priorities or not.
>>> However, we probably don't have? I would suggest to make the
On 09/29/16 08:54, Nathan Sidwell wrote:
On 09/29/16 08:49, Martin Liška wrote:
Ideally we should have a macro for each target telling whether it supports
priorities or not.
However, we probably don't have? I would suggest to make the test conditional
just for main
targets which support
On 09/29/16 08:49, Martin Liška wrote:
Ideally we should have a macro for each target telling whether it supports
priorities or not.
However, we probably don't have? I would suggest to make the test conditional
just for main
targets which support priorities?
or a dg_effective_target test.
On 09/29/2016 11:00 AM, Rainer Orth wrote:
> Hi Martin,
>
>> On 08/12/2016 04:08 PM, Martin Liška wrote:
>>> On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
On 08/10/16 06:43, Martin Liška wrote:
> Hello.
>
> There are multiple PRs (mentioned in ChangeLog) which suffer from
>
Hi Martin,
> On 08/12/2016 04:08 PM, Martin Liška wrote:
>> On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
>>> On 08/10/16 06:43, Martin Liška wrote:
Hello.
There are multiple PRs (mentioned in ChangeLog) which suffer from
missing capability of gcov
to save counters for
On 09/27/16 07:07, Martin Liška wrote:
On 09/27/2016 12:55 PM, Nathan Sidwell wrote:
"Instrumented applications use a static destructor with priority 99 to invoke
the __gcov_dump function. Thus __gcov_dump is executed after all
user defined static destructors, as well as handlers registered
On 09/27/2016 12:55 PM, Nathan Sidwell wrote:
>
> "Instrumented applications use a static destructor with priority 99 to invoke
> the __gcov_dump function. Thus __gcov_dump is executed after all
> user defined static destructors, as well as handlers registered with atexit."
>
> ?
Hello.
I
On 09/26/16 11:22, Martin Liška wrote:
Hi.
So the I found reason of inconsistencies, running multiple times -fselftest is
enough to
find that memory allocation related functions can be executed different times.
Small example:
thanks for checking.
@@ -598,6 +598,10 @@ facilities to restrict
On 08/12/2016 04:08 PM, Martin Liška wrote:
> On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
>> On 08/10/16 06:43, Martin Liška wrote:
>>> Hello.
>>>
>>> There are multiple PRs (mentioned in ChangeLog) which suffer from missing
>>> capability of gcov
>>> to save counters for functions with
On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
> On 08/10/16 06:43, Martin Liška wrote:
>> Hello.
>>
>> There are multiple PRs (mentioned in ChangeLog) which suffer from missing
>> capability of gcov
>> to save counters for functions with constructor/destructor attributes. I
>> done that by
On 08/10/16 08:53, Nathan Sidwell wrote:
I think this is a good idea, but we should document the changed behavior. (I
don't think the current behaviour's documented).
oh, gcov_exit is a user callable routine. You'll have to keep it available.
On 08/10/16 06:43, Martin Liška wrote:
Hello.
There are multiple PRs (mentioned in ChangeLog) which suffer from missing
capability of gcov
to save counters for functions with constructor/destructor attributes. I done
that by simply
replacing atexit handler (gcov_exit) with a new static
Hello.
There are multiple PRs (mentioned in ChangeLog) which suffer from missing
capability of gcov
to save counters for functions with constructor/destructor attributes. I done
that by simply
replacing atexit handler (gcov_exit) with a new static destructor
(__gcov_exit), which has
priority
28 matches
Mail list logo
