public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
@ 2016-08-10 10:43 Martin Liška
  2016-08-10 12:53 ` Nathan Sidwell
  0 siblings, 1 reply; 29+ messages in thread
From: Martin Liška @ 2016-08-10 10:43 UTC (permalink / raw)
  To: GCC Patches; +Cc: Nathan Sidwell, Jan Hubicka

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

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 99 (I did the same for __gcov_init). However, I'm not sure whether it's possible
that a ctor defined in a source file can be potentially executed before __gcov_init (w/ the default
priority)?

Patch survives:
make check -k -j10 RUNTESTFLAGS="gcov.exp"
make check -k -j10 RUNTESTFLAGS="tree-prof.exp"

I've just also verified that a DSO gcov dump works as before. I'm attaching a test-case which 
tests both static ctors/dtors, as well as C++ ctors/dtors.

Thoughts?
Martin

[-- Attachment #2: 0001-gcov-dump-in-a-static-dtor-instead-of-in-an-atexit-h.patch --]
[-- Type: text/x-patch, Size: 4993 bytes --]

From 0e7f660b77628533679e6302a3f4b444166fc365 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Wed, 10 Aug 2016 12:18:45 +0200
Subject: [PATCH] gcov: dump in a static dtor instead of in an atexit handler

gcc/testsuite/ChangeLog:

2016-08-10  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* g++.dg/gcov/pr16855.C: New test.

gcc/ChangeLog:

2016-08-10  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* coverage.c (build_gcov_exit_decl): New function.
	(coverage_obj_init): Call the function and generate __gcov_exit
	destructor.

libgcc/ChangeLog:

2016-08-10  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* libgcov-driver.c (__gcov_init): Do not register a atexit
	handler.
	(__gcov_exit): Rename from gcov_exit.
	* libgcov.h (__gcov_exit): Declare.
---
 gcc/coverage.c                      | 27 +++++++++++++++++++++++++--
 gcc/testsuite/g++.dg/gcov/pr16855.C | 37 +++++++++++++++++++++++++++++++++++++
 libgcc/libgcov-driver.c             |  5 ++---
 libgcc/libgcov.h                    |  3 +++
 4 files changed, 67 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/gcov/pr16855.C

diff --git a/gcc/coverage.c b/gcc/coverage.c
index d4d371e..da7f915 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1054,8 +1054,30 @@ build_init_ctor (tree gcov_info_type)
   stmt = build_call_expr (init_fn, 1, stmt);
   append_to_statement_list (stmt, &ctor);
 
-  /* Generate a constructor to run it.  */
-  cgraph_build_static_cdtor ('I', ctor, DEFAULT_INIT_PRIORITY);
+  /* Generate a constructor to run it (with priority 99).  */
+  cgraph_build_static_cdtor ('I', ctor, DEFAULT_INIT_PRIORITY - 1);
+}
+
+/* Generate the destructor function to call __gcov_exit.  */
+
+static void
+build_gcov_exit_decl (void)
+{
+  tree init_fn = build_function_type_list (void_type_node, void_type_node,
+					   NULL);
+  init_fn = build_decl (BUILTINS_LOCATION, FUNCTION_DECL,
+			get_identifier ("__gcov_exit"), init_fn);
+  TREE_PUBLIC (init_fn) = 1;
+  DECL_EXTERNAL (init_fn) = 1;
+  DECL_ASSEMBLER_NAME (init_fn);
+
+  /* Generate a call to __gcov_exit ().  */
+  tree dtor = NULL;
+  tree stmt = build_call_expr (init_fn, 0);
+  append_to_statement_list (stmt, &dtor);
+
+  /* Generate a destructor to run it (with priority 99).  */
+  cgraph_build_static_cdtor ('D', dtor, DEFAULT_INIT_PRIORITY - 1);
 }
 
 /* Create the gcov_info types and object.  Generate the constructor
@@ -1113,6 +1135,7 @@ coverage_obj_init (void)
   DECL_NAME (gcov_info_var) = get_identifier (name_buf);
 
   build_init_ctor (gcov_info_type);
+  build_gcov_exit_decl ();
 
   return true;
 }
diff --git a/gcc/testsuite/g++.dg/gcov/pr16855.C b/gcc/testsuite/g++.dg/gcov/pr16855.C
new file mode 100644
index 0000000..ec72e99
--- /dev/null
+++ b/gcc/testsuite/g++.dg/gcov/pr16855.C
@@ -0,0 +1,37 @@
+/* { dg-options "-fprofile-arcs -ftest-coverage" } */
+/* { dg-do run { target native } } */
+
+#include <iostream>
+using namespace std;
+class Test {
+public:
+	Test(void){
+	cout<< "In Test ctor" << endl;			  /* count(1) */
+	}
+	~Test(void){
+	cout<< "In Test dtor" << endl;			  /* count(1) */
+	}
+}T1;
+
+void uncalled(void){
+	cout<< "In uncalled" << endl;			  /* count(#####) */
+}
+int main(void){
+// Test T2;
+cout<< "In main" << endl;				  /* count(1) */
+return 0;
+}
+
+#include <stdio.h>
+
+__attribute__((constructor))
+static void construct_navigationBarImages() {
+  fprintf (stderr,  "((construct_navigationBarImages))"); /* count(1) */
+}
+
+__attribute__((destructor))
+static void destroy_navigationBarImages() {
+  fprintf (stderr,  "((destroy_navigationBarImages))");	  /* count(1) */
+}
+
+/* { dg-final { run-gcov branches { -b pr16855.C } } } */
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index d51397e..84471bd 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -872,8 +872,8 @@ struct gcov_root __gcov_root;
 struct gcov_master __gcov_master = 
   {GCOV_VERSION, 0};
 
-static void
-gcov_exit (void)
+void
+__gcov_exit (void)
 {
   __gcov_dump_one (&__gcov_root);
   if (__gcov_root.next)
@@ -906,7 +906,6 @@ __gcov_init (struct gcov_info *info)
 		__gcov_master.root->prev = &__gcov_root;
 	      __gcov_master.root = &__gcov_root;
 	    }
-	  atexit (gcov_exit);
 	}
 
       info->next = __gcov_root.list;
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 80f13e2..113f877 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -235,6 +235,9 @@ extern void __gcov_dump_one (struct gcov_root *) ATTRIBUTE_HIDDEN;
 /* Register a new object file module.  */
 extern void __gcov_init (struct gcov_info *) ATTRIBUTE_HIDDEN;
 
+/* GCOV exit function registered via a static destructor.  */
+extern void __gcov_exit (void) ATTRIBUTE_HIDDEN;
+
 /* Called before fork, to avoid double counting.  */
 extern void __gcov_flush (void) ATTRIBUTE_HIDDEN;
 
-- 
2.9.2


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-08-10 10:43 [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler Martin Liška
@ 2016-08-10 12:53 ` Nathan Sidwell
  2016-08-10 12:55   ` Nathan Sidwell
  2016-08-12 14:08   ` Martin Liška
  0 siblings, 2 replies; 29+ messages in thread
From: Nathan Sidwell @ 2016-08-10 12:53 UTC (permalink / raw)
  To: Martin Liška, GCC Patches; +Cc: Jan Hubicka

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 destructor (__gcov_exit), which has
> priority 99 (I did the same for __gcov_init). However, I'm not sure whether it's possible
> that a ctor defined in a source file can be potentially executed before __gcov_init (w/ the default
> priority)?
>
> Patch survives:
> make check -k -j10 RUNTESTFLAGS="gcov.exp"
> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>
> I've just also verified that a DSO gcov dump works as before. I'm attaching a test-case which
> tests both static ctors/dtors, as well as C++ ctors/dtors.

Does a coverage bootstrap (--enable-coverage) still succeed?

I think this is a good idea, but we should document the changed behavior. (I 
don't think the current behaviour's documented).


nathan

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-08-10 12:53 ` Nathan Sidwell
@ 2016-08-10 12:55   ` Nathan Sidwell
  2016-08-12 14:08   ` Martin Liška
  1 sibling, 0 replies; 29+ messages in thread
From: Nathan Sidwell @ 2016-08-10 12:55 UTC (permalink / raw)
  To: Martin Liška, GCC Patches; +Cc: Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-08-10 12:53 ` Nathan Sidwell
  2016-08-10 12:55   ` Nathan Sidwell
@ 2016-08-12 14:08   ` Martin Liška
  2016-09-26 15:40     ` Martin Liška
  1 sibling, 1 reply; 29+ messages in thread
From: Martin Liška @ 2016-08-12 14:08 UTC (permalink / raw)
  To: Nathan Sidwell, GCC Patches; +Cc: Jan Hubicka

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 simply
>> replacing atexit handler (gcov_exit) with a new static destructor (__gcov_exit), which has
>> priority 99 (I did the same for __gcov_init). However, I'm not sure whether it's possible
>> that a ctor defined in a source file can be potentially executed before __gcov_init (w/ the default
>> priority)?
>>
>> Patch survives:
>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>
>> I've just also verified that a DSO gcov dump works as before. I'm attaching a test-case which
>> tests both static ctors/dtors, as well as C++ ctors/dtors.
> 
> Does a coverage bootstrap (--enable-coverage) still succeed?

Well, looks results are more unstable than I thought.
Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly generates different results.
I'll dig in after weekend.

Martin

> 
> I think this is a good idea, but we should document the changed behavior. (I don't think the current behaviour's documented).
> 
> 
> nathan

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-08-12 14:08   ` Martin Liška
@ 2016-09-26 15:40     ` Martin Liška
  2016-09-27 10:58       ` Nathan Sidwell
  2016-09-29  9:24       ` Rainer Orth
  0 siblings, 2 replies; 29+ messages in thread
From: Martin Liška @ 2016-09-26 15:40 UTC (permalink / raw)
  To: Nathan Sidwell, GCC Patches; +Cc: Jan Hubicka

[-- Attachment #1: Type: text/plain, Size: 3884 bytes --]

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 constructor/destructor attributes. I done that by simply
>>> replacing atexit handler (gcov_exit) with a new static destructor (__gcov_exit), which has
>>> priority 99 (I did the same for __gcov_init). However, I'm not sure whether it's possible
>>> that a ctor defined in a source file can be potentially executed before __gcov_init (w/ the default
>>> priority)?
>>>
>>> Patch survives:
>>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>>
>>> I've just also verified that a DSO gcov dump works as before. I'm attaching a test-case which
>>> tests both static ctors/dtors, as well as C++ ctors/dtors.
>>
>> Does a coverage bootstrap (--enable-coverage) still succeed?
> 
> Well, looks results are more unstable than I thought.
> Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly generates different results.
> I'll dig in after weekend.
> 
> Martin

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:

--- /tmp/r1/ggc-page.c.gcov	2016-09-26 16:54:53.060921496 +0200
+++ /tmp/r2/ggc-page.c.gcov	2016-09-26 16:55:52.470058958 +0200
@@ -636,8 +636,8 @@
         -:  631:#else
    307718:  632:  page_table table = G.lookup;
    307718:  633:  uintptr_t high_bits = (uintptr_t) p & ~ (uintptr_t) 0xffffffff;
-   307718:  634:  while (table->high_bits != high_bits)
-    #####:  635:    table = table->next;
+   307794:  634:  while (table->high_bits != high_bits)
+       38:  635:    table = table->next;
    307718:  636:  base = &table->table[0];
         -:  637:#endif
         -:  638:
@@ -661,15 +661,15 @@
         -:  656:#else
         -:  657:  page_table table;
      2134:  658:  uintptr_t high_bits = (uintptr_t) p & ~ (uintptr_t) 0xffffffff;
-     2134:  659:  for (table = G.lookup; table; table = table->next)
-     2133:  660:    if (table->high_bits == high_bits)
-     2133:  661:      goto found;
+     2322:  659:  for (table = G.lookup; table; table = table->next)
+     2320:  660:    if (table->high_bits == high_bits)
+     2132:  661:      goto found;
         -:  662:
         -:  663:  /* Not found -- allocate a new table.  */
-        1:  664:  table = XCNEW (struct page_table_chain);
-        1:  665:  table->next = G.lookup;
-        1:  666:  table->high_bits = high_bits;
-        1:  667:  G.lookup = table;
+        2:  664:  table = XCNEW (struct page_table_chain);
+        2:  665:  table->next = G.lookup;
+        2:  666:  table->high_bits = high_bits;
+        2:  667:  G.lookup = table;
      2134:  668:found:
      2134:  669:  base = &table->table[0];
         -:  670:#endif
--- /tmp/r1/ggc-page.c.gcov	2016-09-26 16:54:53.060921496 +0200
+++ /tmp/r2/ggc-page.c.gcov	2016-09-26 16:58:22.440931009 +0200
@@ -679,7 +679,7 @@
      2134:  674:  L2 = LOOKUP_L2 (p);
         -:  675:
      2134:  676:  if (base[L1] == NULL)
-        3:  677:    base[L1] = XCNEWVEC (page_entry *, PAGE_L2_SIZE);
+        2:  677:    base[L1] = XCNEWVEC (page_entry *, PAGE_L2_SIZE);
         -:  678:
      2134:  679:  base[L1][L2] = entry;
      2134:  680:}

It's reasonable to me that it can change. However, the patch I would like to install
does not cause any new differences.

Martin

> 
>>
>> I think this is a good idea, but we should document the changed behavior. (I don't think the current behaviour's documented).

I'm adding a new hunk that documents the behavior.

Is the patch ready to be installed?
Thanks,
Martin

>>
>>
>> nathan
> 


[-- Attachment #2: 0001-gcov-dump-in-a-static-dtor-instead-of-in-an-atexit-h-v2.patch --]
[-- Type: text/x-patch, Size: 5950 bytes --]

From 686e65a923288c2c5055a9edb61e6f0648d6a2a3 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Wed, 10 Aug 2016 12:18:45 +0200
Subject: [PATCH] gcov: dump in a static dtor instead of in an atexit handler

gcc/testsuite/ChangeLog:

2016-08-10  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* g++.dg/gcov/pr16855.C: New test.

gcc/ChangeLog:

2016-08-10  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* coverage.c (build_gcov_exit_decl): New function.
	(coverage_obj_init): Call the function and generate __gcov_exit
	destructor.
	* doc/gcov.texi: Document when __gcov_exit function is called.

libgcc/ChangeLog:

2016-08-10  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* libgcov-driver.c (__gcov_init): Do not register a atexit
	handler.
	(__gcov_exit): Rename from gcov_exit.
	* libgcov.h (__gcov_exit): Declare.
---
 gcc/coverage.c                      | 27 +++++++++++++++++++--
 gcc/doc/gcov.texi                   |  4 ++++
 gcc/testsuite/g++.dg/gcov/pr16855.C | 47 +++++++++++++++++++++++++++++++++++++
 libgcc/libgcov-driver.c             |  5 ++--
 libgcc/libgcov.h                    |  3 +++
 5 files changed, 81 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/gcov/pr16855.C

diff --git a/gcc/coverage.c b/gcc/coverage.c
index 30cdc69..0b8c0b3 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1055,8 +1055,30 @@ build_init_ctor (tree gcov_info_type)
   stmt = build_call_expr (init_fn, 1, stmt);
   append_to_statement_list (stmt, &ctor);
 
-  /* Generate a constructor to run it.  */
-  cgraph_build_static_cdtor ('I', ctor, DEFAULT_INIT_PRIORITY);
+  /* Generate a constructor to run it (with priority 99).  */
+  cgraph_build_static_cdtor ('I', ctor, DEFAULT_INIT_PRIORITY - 1);
+}
+
+/* Generate the destructor function to call __gcov_exit.  */
+
+static void
+build_gcov_exit_decl (void)
+{
+  tree init_fn = build_function_type_list (void_type_node, void_type_node,
+					   NULL);
+  init_fn = build_decl (BUILTINS_LOCATION, FUNCTION_DECL,
+			get_identifier ("__gcov_exit"), init_fn);
+  TREE_PUBLIC (init_fn) = 1;
+  DECL_EXTERNAL (init_fn) = 1;
+  DECL_ASSEMBLER_NAME (init_fn);
+
+  /* Generate a call to __gcov_exit ().  */
+  tree dtor = NULL;
+  tree stmt = build_call_expr (init_fn, 0);
+  append_to_statement_list (stmt, &dtor);
+
+  /* Generate a destructor to run it (with priority 99).  */
+  cgraph_build_static_cdtor ('D', dtor, DEFAULT_INIT_PRIORITY - 1);
 }
 
 /* Create the gcov_info types and object.  Generate the constructor
@@ -1114,6 +1136,7 @@ coverage_obj_init (void)
   DECL_NAME (gcov_info_var) = get_identifier (name_buf);
 
   build_init_ctor (gcov_info_type);
+  build_gcov_exit_decl ();
 
   return true;
 }
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index a0a7af7..626d441 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -598,6 +598,10 @@ facilities to restrict profile collection to the program region of
 interest. Calling @code{__gcov_reset(void)} will clear all profile counters
 to zero, and calling @code{__gcov_dump(void)} will cause the profile information
 collected at that point to be dumped to @file{.gcda} output files.
+By default, every instrumented application calls __gcov_dump function
+via a static destructor with priority equal to 99.  That would guarantee
+that all user defined destructors, as well as function handlers registered
+by atexit, would be executed before gcov dump function is executed.
 
 @c man end
 
diff --git a/gcc/testsuite/g++.dg/gcov/pr16855.C b/gcc/testsuite/g++.dg/gcov/pr16855.C
new file mode 100644
index 0000000..91801d4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/gcov/pr16855.C
@@ -0,0 +1,47 @@
+/* { dg-options "-fprofile-arcs -ftest-coverage" } */
+/* { dg-do run { target native } } */
+
+#include <stdlib.h>
+
+int a;
+
+void foo()
+{
+  a = 123;						  /* count(1) */
+}
+
+#include <iostream>
+using namespace std;
+class Test {
+public:
+	Test(void){
+	cout<< "In Test ctor" << endl;			  /* count(1) */
+	}
+	~Test(void){
+	cout<< "In Test dtor" << endl;			  /* count(1) */
+	}
+}T1;
+
+void uncalled(void){
+	cout<< "In uncalled" << endl;			  /* count(#####) */
+}
+int main(void){
+atexit (&foo);
+// Test T2;
+cout<< "In main" << endl;				  /* count(1) */
+return 0;
+}
+
+#include <stdio.h>
+
+__attribute__((constructor))
+static void construct_navigationBarImages() {
+  fprintf (stderr,  "((construct_navigationBarImages))"); /* count(1) */
+}
+
+__attribute__((destructor))
+static void destroy_navigationBarImages() {
+  fprintf (stderr,  "((destroy_navigationBarImages))");	  /* count(1) */
+}
+
+/* { dg-final { run-gcov branches { -b pr16855.C } } } */
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index d51397e..84471bd 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -872,8 +872,8 @@ struct gcov_root __gcov_root;
 struct gcov_master __gcov_master = 
   {GCOV_VERSION, 0};
 
-static void
-gcov_exit (void)
+void
+__gcov_exit (void)
 {
   __gcov_dump_one (&__gcov_root);
   if (__gcov_root.next)
@@ -906,7 +906,6 @@ __gcov_init (struct gcov_info *info)
 		__gcov_master.root->prev = &__gcov_root;
 	      __gcov_master.root = &__gcov_root;
 	    }
-	  atexit (gcov_exit);
 	}
 
       info->next = __gcov_root.list;
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 25147de..c5f0732 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -235,6 +235,9 @@ extern void __gcov_dump_one (struct gcov_root *) ATTRIBUTE_HIDDEN;
 /* Register a new object file module.  */
 extern void __gcov_init (struct gcov_info *) ATTRIBUTE_HIDDEN;
 
+/* GCOV exit function registered via a static destructor.  */
+extern void __gcov_exit (void) ATTRIBUTE_HIDDEN;
+
 /* Called before fork, to avoid double counting.  */
 extern void __gcov_flush (void) ATTRIBUTE_HIDDEN;
 
-- 
2.9.2


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-26 15:40     ` Martin Liška
@ 2016-09-27 10:58       ` Nathan Sidwell
  2016-09-27 11:09         ` Martin Liška
  2016-09-29  9:24       ` Rainer Orth
  1 sibling, 1 reply; 29+ messages in thread
From: Nathan Sidwell @ 2016-09-27 10:58 UTC (permalink / raw)
  To: Martin Liška, GCC Patches; +Cc: Jan Hubicka

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 profile collection to the program 
region of
  interest. Calling @code{__gcov_reset(void)} will clear all profile counters
  to zero, and calling @code{__gcov_dump(void)} will cause the profile information
  collected at that point to be dumped to @file{.gcda} output files.
+By default, every instrumented application calls __gcov_dump function
+via a static destructor with priority equal to 99.  That would guarantee
+that all user defined destructors, as well as function handlers registered
+by atexit, would be executed before gcov dump function is executed.

'by default'  This suggests there's a non-default behaviour, but I can't see it 
nor how to enable it.  Perhaps:

"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."

?

nathan

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-27 10:58       ` Nathan Sidwell
@ 2016-09-27 11:09         ` Martin Liška
  2016-09-27 11:11           ` Nathan Sidwell
  0 siblings, 1 reply; 29+ messages in thread
From: Martin Liška @ 2016-09-27 11:09 UTC (permalink / raw)
  To: Nathan Sidwell, GCC Patches; +Cc: Jan Hubicka

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 like your wording, I installed the patch as r240529.

Martin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-27 11:09         ` Martin Liška
@ 2016-09-27 11:11           ` Nathan Sidwell
  0 siblings, 0 replies; 29+ messages in thread
From: Nathan Sidwell @ 2016-09-27 11:11 UTC (permalink / raw)
  To: Martin Liška, GCC Patches; +Cc: Jan Hubicka

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 with atexit."
>>
>> ?
>
> Hello.
>
> I like your wording, I installed the patch as r240529.

thanks!

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-26 15:40     ` Martin Liška
  2016-09-27 10:58       ` Nathan Sidwell
@ 2016-09-29  9:24       ` Rainer Orth
  2016-09-29 12:54         ` Martin Liška
  1 sibling, 1 reply; 29+ messages in thread
From: Rainer Orth @ 2016-09-29  9:24 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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 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 99 (I did the same for __gcov_init). However, I'm not sure
>>>> whether it's possible
>>>> that a ctor defined in a source file can be potentially executed before
>>>> __gcov_init (w/ the default
>>>> priority)?
>>>>
>>>> Patch survives:
>>>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>>>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>>>
>>>> I've just also verified that a DSO gcov dump works as before. I'm
>>>> attaching a test-case which
>>>> tests both static ctors/dtors, as well as C++ ctors/dtors.
>>>
>>> Does a coverage bootstrap (--enable-coverage) still succeed?
>> 
>> Well, looks results are more unstable than I thought.
>> Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly
>> generates different results.
>> I'll dig in after weekend.
>> 
>> Martin
[...]
>>> I think this is a good idea, but we should document the changed
>>> behavior. (I don't think the current behaviour's documented).
>
> I'm adding a new hunk that documents the behavior.
>
> Is the patch ready to be installed?

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 #####:should be 1
+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  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++14  line 21: is #####:should be 1
+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  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++98  line 21: is #####:should be 1

I haven't looked closer yet, but notice that you require constructor
priority support which isn't available everywhere (it is on Solaris 12,
but not before).

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-29  9:24       ` Rainer Orth
@ 2016-09-29 12:54         ` Martin Liška
  2016-09-29 13:14           ` Nathan Sidwell
  2016-09-30  9:31           ` Rainer Orth
  0 siblings, 2 replies; 29+ messages in thread
From: Martin Liška @ 2016-09-29 12:54 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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
>>>>> 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 99 (I did the same for __gcov_init). However, I'm not sure
>>>>> whether it's possible
>>>>> that a ctor defined in a source file can be potentially executed before
>>>>> __gcov_init (w/ the default
>>>>> priority)?
>>>>>
>>>>> Patch survives:
>>>>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>>>>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>>>>
>>>>> I've just also verified that a DSO gcov dump works as before. I'm
>>>>> attaching a test-case which
>>>>> tests both static ctors/dtors, as well as C++ ctors/dtors.
>>>>
>>>> Does a coverage bootstrap (--enable-coverage) still succeed?
>>>
>>> Well, looks results are more unstable than I thought.
>>> Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly
>>> generates different results.
>>> I'll dig in after weekend.
>>>
>>> Martin
> [...]
>>>> I think this is a good idea, but we should document the changed
>>>> behavior. (I don't think the current behaviour's documented).
>>
>> I'm adding a new hunk that documents the behavior.
>>
>> Is the patch ready to be installed?
> 
> 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 #####:should be 1
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  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++14  line 21: is #####:should be 1
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  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++98  line 21: is #####:should be 1
> 
> I haven't looked closer yet, but notice that you require constructor
> priority support which isn't available everywhere (it is on Solaris 12,
> but not before).
> 
> 	Rainer
> 

Hello.

Sorry for the test-breakage. The issue is really connected to fact that current trunk relies
on support of dtor priority. The former implementation called the function __gcov_exit via atexit.
If I understand correctly, fully support of static ctors/dtors, C++ ctors/dtors, with combination
of atexit cannot be done on a target w/o ctor/dtor priorities.

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?

Thoughts?

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-29 12:54         ` Martin Liška
@ 2016-09-29 13:14           ` Nathan Sidwell
  2016-09-29 13:16             ` Nathan Sidwell
  2016-09-30  9:31           ` Rainer Orth
  1 sibling, 1 reply; 29+ messages in thread
From: Nathan Sidwell @ 2016-09-29 13:14 UTC (permalink / raw)
  To: Martin Liška, Rainer Orth; +Cc: GCC Patches, Jan Hubicka

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.  Probably overkill if there's exactly one target 
impacted.

nathan

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-29 13:14           ` Nathan Sidwell
@ 2016-09-29 13:16             ` Nathan Sidwell
  2016-09-29 14:04               ` Martin Liška
  0 siblings, 1 reply; 29+ messages in thread
From: Nathan Sidwell @ 2016-09-29 13:16 UTC (permalink / raw)
  To: Martin Liška, Rainer Orth; +Cc: GCC Patches, Jan Hubicka

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 priorities?
>
> or a dg_effective_target test.  Probably overkill if there's exactly one target
> impacted.

already there : effective_target_init_priority

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-29 13:16             ` Nathan Sidwell
@ 2016-09-29 14:04               ` Martin Liška
  0 siblings, 0 replies; 29+ messages in thread
From: Martin Liška @ 2016-09-29 14:04 UTC (permalink / raw)
  To: Nathan Sidwell, Rainer Orth; +Cc: GCC Patches, Jan Hubicka

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

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 test conditional
>>> just for main
>>> targets which support priorities?
>>
>> or a dg_effective_target test.  Probably overkill if there's exactly one target
>> impacted.
> 
> already there : effective_target_init_priority

Nice that we have it. Looks it's going to be very first usage of the effective target.
I'm suggesting patch which also changes debugging messages to make it more readable.

Ready for trunk?
Thanks,
Martin

[-- Attachment #2: 0001-Use-effective-target-for-pr16855.patch --]
[-- Type: text/x-patch, Size: 2094 bytes --]

From cd66f6f9b9c68267698720dcf350b140d86f4201 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Thu, 29 Sep 2016 15:39:08 +0200
Subject: [PATCH] Use effective target for pr16855

gcc/testsuite/ChangeLog:

2016-09-29  Martin Liska  <mliska@suse.cz>

	* g++.dg/gcov/pr16855.C: Add init_priority as an effective
	target.
---
 gcc/testsuite/g++.dg/gcov/pr16855.C | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/g++.dg/gcov/pr16855.C b/gcc/testsuite/g++.dg/gcov/pr16855.C
index 91801d4..8167176 100644
--- a/gcc/testsuite/g++.dg/gcov/pr16855.C
+++ b/gcc/testsuite/g++.dg/gcov/pr16855.C
@@ -1,13 +1,15 @@
 /* { dg-options "-fprofile-arcs -ftest-coverage" } */
 /* { dg-do run { target native } } */
+/* { dg-require-effective-target init_priority  } */
 
 #include <stdlib.h>
+#include <stdio.h>
 
 int a;
 
 void foo()
 {
-  a = 123;						  /* count(1) */
+  fprintf (stderr, "atexit handler foo()\n"); 		  /* count(1) */
 }
 
 #include <iostream>
@@ -15,10 +17,10 @@ using namespace std;
 class Test {
 public:
 	Test(void){
-	cout<< "In Test ctor" << endl;			  /* count(1) */
+	fprintf (stderr, "In Test ctor\n");		  /* count(1) */
 	}
 	~Test(void){
-	cout<< "In Test dtor" << endl;			  /* count(1) */
+	fprintf (stderr, "In Test dtor\n");		  /* count(1) */
 	}
 }T1;
 
@@ -27,8 +29,7 @@ void uncalled(void){
 }
 int main(void){
 atexit (&foo);
-// Test T2;
-cout<< "In main" << endl;				  /* count(1) */
+fprintf (stderr, "In main\n");				  /* count(1) */
 return 0;
 }
 
@@ -36,12 +37,12 @@ return 0;
 
 __attribute__((constructor))
 static void construct_navigationBarImages() {
-  fprintf (stderr,  "((construct_navigationBarImages))"); /* count(1) */
+  fprintf (stderr,  "((construct_navigationBarImages))\n"); /* count(1) */
 }
 
 __attribute__((destructor))
 static void destroy_navigationBarImages() {
-  fprintf (stderr,  "((destroy_navigationBarImages))");	  /* count(1) */
+  fprintf (stderr,  "((destroy_navigationBarImages))\n");  /* count(1) */
 }
 
 /* { dg-final { run-gcov branches { -b pr16855.C } } } */
-- 
2.9.2


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-29 12:54         ` Martin Liška
  2016-09-29 13:14           ` Nathan Sidwell
@ 2016-09-30  9:31           ` Rainer Orth
  2016-09-30 11:48             ` Martin Liška
  2016-09-30 12:26             ` Nathan Sidwell
  1 sibling, 2 replies; 29+ messages in thread
From: Rainer Orth @ 2016-09-30  9:31 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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 #####:should be 1
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 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++14  line 21: is #####:should be 1
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 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++98  line 21: is #####:should be 1
>> 
>> I haven't looked closer yet, but notice that you require constructor
>> priority support which isn't available everywhere (it is on Solaris 12,
>> but not before).
>> 
>> 	Rainer
>> 
>
> Hello.
>
> Sorry for the test-breakage. The issue is really connected to fact that
> current trunk relies
> on support of dtor priority. The former implementation called the function
> __gcov_exit via atexit.
> If I understand correctly, fully support of static ctors/dtors, C++
> ctors/dtors, with combination
> of atexit cannot be done on a target w/o ctor/dtor priorities.

understood.  However, Solaris 12 *does* have support for constructor
priorities and the testcase still fails, so there's more going on here.

> 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?
>
> Thoughts?

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 with an
appropriate message instead of just creating confusing non-working
executables.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-30  9:31           ` Rainer Orth
@ 2016-09-30 11:48             ` Martin Liška
  2016-09-30 12:48               ` Rainer Orth
  2016-09-30 12:26             ` Nathan Sidwell
  1 sibling, 1 reply; 29+ messages in thread
From: Martin Liška @ 2016-09-30 11:48 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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: g++.dg/gcov/pr16855.C  -std=gnu++11  line 21: is #####:should be 1
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 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++14  line 21: is #####:should be 1
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 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++98  line 21: is #####:should be 1
>>>
>>> I haven't looked closer yet, but notice that you require constructor
>>> priority support which isn't available everywhere (it is on Solaris 12,
>>> but not before).
>>>
>>> 	Rainer
>>>
>>
>> Hello.
>>
>> Sorry for the test-breakage. The issue is really connected to fact that
>> current trunk relies
>> on support of dtor priority. The former implementation called the function
>> __gcov_exit via atexit.
>> If I understand correctly, fully support of static ctors/dtors, C++
>> ctors/dtors, with combination
>> of atexit cannot be done on a target w/o ctor/dtor priorities.
> 
> 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 me --target=x,
so that I can at least check created assembly?

> 
>> 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?
>>
>> Thoughts?
> 
> 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 with an
> appropriate message instead of just creating confusing non-working
> executables.

More precisely, it does not work reliably on constructor and destructors as
we depend on an order how are ctor/dtors executed. We had the same behavior even
before my patch, but documenting that definitely worth for doing. I'll do a patch.

Martin

> 
> 	Rainer
> 

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-30  9:31           ` Rainer Orth
  2016-09-30 11:48             ` Martin Liška
@ 2016-09-30 12:26             ` Nathan Sidwell
  1 sibling, 0 replies; 29+ messages in thread
From: Nathan Sidwell @ 2016-09-30 12:26 UTC (permalink / raw)
  To: Rainer Orth, Martin Liška; +Cc: GCC Patches, Jan Hubicka

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 with an
> appropriate message instead of just creating confusing non-working
> executables.

It should either
1) emit a non-prioritized static ctor
2) or use the older atexit mechanism.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-30 11:48             ` Martin Liška
@ 2016-09-30 12:48               ` Rainer Orth
  2016-09-30 13:07                 ` Martin Liška
  2016-10-06 19:00                 ` [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler Martin Liška
  0 siblings, 2 replies; 29+ messages in thread
From: Rainer Orth @ 2016-09-30 12:48 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

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 me --target=x,
> so that I can at least check created assembly?

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).

Here's the gcov -b pr16855.C output

File '/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr16855.C'
Lines executed:73.91% of 23
Branches executed:100.00% of 4
Taken at least once:50.00% of 4
Calls executed:71.43% of 14
Creating 'pr16855.C.gcov'

File '/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/amd64/libstdc++-v3/include/iostream'
Lines executed:100.00% of 1
No branches
Calls executed:100.00% of 2
Creating 'iostream.gcov'

File '/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/amd64/libstdc++-v3/include/i386-pc-solaris2.12/bits/gthr-default.h'
Lines executed:0.00% of 3
No branches
No calls
Creating 'gthr-default.h.gcov'


compared to what I get on Linux/x86_64:

File '/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr16855.C'
Lines executed:86.96% of 23
Branches executed:100.00% of 4
Taken at least once:50.00% of 4
Calls executed:85.71% of 14
Creating 'pr16855.C.gcov'

File '/var/gcc/regression/trunk/4.7.4-gcc-gas-gld/build/x86_64-pc-linux-gnu/libstdc++-v3/include/iostream'
Lines executed:100.00% of 1
No branches
Calls executed:100.00% of 2
Creating 'iostream.gcov'

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University



[-- Attachment #2: pr16855.s --]
[-- Type: text/plain, Size: 17981 bytes --]

	.file	"pr16855.C"
	.globl	a
	.bss
	.align 4
	.type	a, @object
	.size	a, 4
a:
	.zero	4
	.text
	.globl	_Z3foov
	.type	_Z3foov, @function
_Z3foov:
.LFB5:
	pushq	%rbp
.LCFI0:
	movq	%rsp, %rbp
.LCFI1:
	movq	__gcov0._Z3foov(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z3foov(%rip)
	movl	$123, a(%rip)
	nop
	popq	%rbp
.LCFI2:
	ret
.LFE5:
	.size	_Z3foov, .-_Z3foov
	.data
	.align 4
	.type	_ZL16__gthread_active, @object
	.size	_ZL16__gthread_active, 4
_ZL16__gthread_active:
	.long	-1
	.text
	.type	_ZL17__gthread_triggerv, @function
_ZL17__gthread_triggerv:
.LFB286:
	pushq	%rbp
.LCFI3:
	movq	%rsp, %rbp
.LCFI4:
	movq	__gcov0._ZL17__gthread_triggerv(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZL17__gthread_triggerv(%rip)
	movl	$1, _ZL16__gthread_active(%rip)
	nop
	popq	%rbp
.LCFI5:
	ret
.LFE286:
	.size	_ZL17__gthread_triggerv, .-_ZL17__gthread_triggerv
	.local	_ZStL8__ioinit
	.comm	_ZStL8__ioinit,1,1
	.section	.rodata
.LC0:
	.string	"In Test ctor"
	.section	.text._ZN4TestC2Ev%_ZN4TestC5Ev,"ax",@progbits
	.group	_ZN4TestC5Ev,.text._ZN4TestC2Ev%_ZN4TestC5Ev,#comdat
	.align 2
	.weak	_ZN4TestC2Ev
	.type	_ZN4TestC2Ev, @function
_ZN4TestC2Ev:
.LFB1036:
	pushq	%rbp
.LCFI6:
	movq	%rsp, %rbp
.LCFI7:
	subq	$16, %rsp
	movq	%rdi, -8(%rbp)
	movq	__gcov0._ZN4TestC2Ev(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZN4TestC2Ev(%rip)
	movl	$.LC0, %esi
	movl	$_ZSt4cout, %edi
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	movq	%rax, %rdx
	movq	__gcov0._ZN4TestC2Ev+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZN4TestC2Ev+8(%rip)
	movl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_, %esi
	movq	%rdx, %rdi
	call	_ZNSolsEPFRSoS_E
	movq	__gcov0._ZN4TestC2Ev+16(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZN4TestC2Ev+16(%rip)
	nop
	leave
.LCFI8:
	ret
.LFE1036:
	.size	_ZN4TestC2Ev, .-_ZN4TestC2Ev
	.weak	_ZN4TestC1Ev
	.set	_ZN4TestC1Ev,_ZN4TestC2Ev
	.section	.rodata
.LC1:
	.string	"In Test dtor"
	.section	.text._ZN4TestD2Ev%_ZN4TestD5Ev,"ax",@progbits
	.group	_ZN4TestD5Ev,.text._ZN4TestD2Ev%_ZN4TestD5Ev,#comdat
	.align 2
	.weak	_ZN4TestD2Ev
	.type	_ZN4TestD2Ev, @function
_ZN4TestD2Ev:
.LFB1039:
	pushq	%rbp
.LCFI9:
	movq	%rsp, %rbp
.LCFI10:
	subq	$16, %rsp
	movq	%rdi, -8(%rbp)
	movq	__gcov0._ZN4TestD2Ev(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZN4TestD2Ev(%rip)
	movl	$.LC1, %esi
	movl	$_ZSt4cout, %edi
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	movq	%rax, %rdx
	movq	__gcov0._ZN4TestD2Ev+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZN4TestD2Ev+8(%rip)
	movl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_, %esi
	movq	%rdx, %rdi
	call	_ZNSolsEPFRSoS_E
	movq	__gcov0._ZN4TestD2Ev+16(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZN4TestD2Ev+16(%rip)
	nop
	leave
.LCFI11:
	ret
.LFE1039:
	.size	_ZN4TestD2Ev, .-_ZN4TestD2Ev
	.weak	_ZN4TestD1Ev
	.set	_ZN4TestD1Ev,_ZN4TestD2Ev
	.globl	T1
	.bss
	.type	T1, @object
	.size	T1, 1
T1:
	.zero	1
	.section	.rodata
.LC2:
	.string	"In uncalled"
	.text
	.globl	_Z8uncalledv
	.type	_Z8uncalledv, @function
_Z8uncalledv:
.LFB1041:
	pushq	%rbp
.LCFI12:
	movq	%rsp, %rbp
.LCFI13:
	movq	__gcov0._Z8uncalledv(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z8uncalledv(%rip)
	movl	$.LC2, %esi
	movl	$_ZSt4cout, %edi
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	movq	%rax, %rdx
	movq	__gcov0._Z8uncalledv+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z8uncalledv+8(%rip)
	movl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_, %esi
	movq	%rdx, %rdi
	call	_ZNSolsEPFRSoS_E
	movq	__gcov0._Z8uncalledv+16(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z8uncalledv+16(%rip)
	nop
	popq	%rbp
.LCFI14:
	ret
.LFE1041:
	.size	_Z8uncalledv, .-_Z8uncalledv
	.section	.rodata
.LC3:
	.string	"In main"
	.text
	.globl	main
	.type	main, @function
main:
.LFB1042:
	pushq	%rbp
.LCFI15:
	movq	%rsp, %rbp
.LCFI16:
	movq	__gcov0.main(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0.main(%rip)
	movl	$_Z3foov, %edi
	call	atexit
	movq	__gcov0.main+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0.main+8(%rip)
	movl	$.LC3, %esi
	movl	$_ZSt4cout, %edi
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	movq	%rax, %rdx
	movq	__gcov0.main+16(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0.main+16(%rip)
	movl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_, %esi
	movq	%rdx, %rdi
	call	_ZNSolsEPFRSoS_E
	movl	$0, %edx
	movq	__gcov0.main+24(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0.main+24(%rip)
	movl	%edx, %eax
	popq	%rbp
.LCFI17:
	ret
.LFE1042:
	.size	main, .-main
	.section	.rodata
	.align 8
.LC4:
	.string	"((construct_navigationBarImages))"
	.text
	.type	_ZL29construct_navigationBarImagesv, @function
_ZL29construct_navigationBarImagesv:
.LFB1043:
	pushq	%rbp
.LCFI18:
	movq	%rsp, %rbp
.LCFI19:
	movq	__gcov0._ZL29construct_navigationBarImagesv(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZL29construct_navigationBarImagesv(%rip)
	movl	$__iob+256, %ecx
	movl	$33, %edx
	movl	$1, %esi
	movl	$.LC4, %edi
	call	fwrite
	movq	__gcov0._ZL29construct_navigationBarImagesv+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZL29construct_navigationBarImagesv+8(%rip)
	nop
	popq	%rbp
.LCFI20:
	ret
.LFE1043:
	.size	_ZL29construct_navigationBarImagesv, .-_ZL29construct_navigationBarImagesv
	.section	.init_array,"aw"
	.align 8
	.quad	_ZL29construct_navigationBarImagesv
	.section	.rodata
	.align 8
.LC5:
	.string	"((destroy_navigationBarImages))"
	.text
	.type	_ZL27destroy_navigationBarImagesv, @function
_ZL27destroy_navigationBarImagesv:
.LFB1044:
	pushq	%rbp
.LCFI21:
	movq	%rsp, %rbp
.LCFI22:
	movq	__gcov0._ZL27destroy_navigationBarImagesv(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZL27destroy_navigationBarImagesv(%rip)
	movl	$__iob+256, %ecx
	movl	$31, %edx
	movl	$1, %esi
	movl	$.LC5, %edi
	call	fwrite
	movq	__gcov0._ZL27destroy_navigationBarImagesv+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._ZL27destroy_navigationBarImagesv+8(%rip)
	nop
	popq	%rbp
.LCFI23:
	ret
.LFE1044:
	.size	_ZL27destroy_navigationBarImagesv, .-_ZL27destroy_navigationBarImagesv
	.section	.fini_array,"aw"
	.align 8
	.quad	_ZL27destroy_navigationBarImagesv
	.text
	.type	_Z41__static_initialization_and_destruction_0ii, @function
_Z41__static_initialization_and_destruction_0ii:
.LFB1053:
	pushq	%rbp
.LCFI24:
	movq	%rsp, %rbp
.LCFI25:
	subq	$16, %rsp
	movl	%edi, -4(%rbp)
	movl	%esi, -8(%rbp)
	movq	__gcov0._Z41__static_initialization_and_destruction_0ii(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z41__static_initialization_and_destruction_0ii(%rip)
	cmpl	$1, -4(%rbp)
	jne	.L12
	movq	__gcov0._Z41__static_initialization_and_destruction_0ii+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z41__static_initialization_and_destruction_0ii+8(%rip)
	cmpl	$65535, -8(%rbp)
	jne	.L12
	movq	__gcov0._Z41__static_initialization_and_destruction_0ii+16(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z41__static_initialization_and_destruction_0ii+16(%rip)
	movl	$_ZStL8__ioinit, %edi
	call	_ZNSt8ios_base4InitC1Ev
	movq	__gcov0._Z41__static_initialization_and_destruction_0ii+24(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z41__static_initialization_and_destruction_0ii+24(%rip)
	movl	$__dso_handle, %edx
	movl	$_ZStL8__ioinit, %esi
	movl	$_ZNSt8ios_base4InitD1Ev, %edi
	call	__cxa_atexit
	movq	__gcov0._Z41__static_initialization_and_destruction_0ii+32(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z41__static_initialization_and_destruction_0ii+32(%rip)
	movl	$T1, %edi
	call	_ZN4TestC1Ev
	movq	__gcov0._Z41__static_initialization_and_destruction_0ii+40(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z41__static_initialization_and_destruction_0ii+40(%rip)
	movl	$__dso_handle, %edx
	movl	$T1, %esi
	movl	$_ZN4TestD1Ev, %edi
	call	__cxa_atexit
	movq	__gcov0._Z41__static_initialization_and_destruction_0ii+48(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._Z41__static_initialization_and_destruction_0ii+48(%rip)
.L12:
	nop
	leave
.LCFI26:
	ret
.LFE1053:
	.size	_Z41__static_initialization_and_destruction_0ii, .-_Z41__static_initialization_and_destruction_0ii
	.type	_GLOBAL__sub_I_a, @function
_GLOBAL__sub_I_a:
.LFB1054:
	pushq	%rbp
.LCFI27:
	movq	%rsp, %rbp
.LCFI28:
	movq	__gcov0._GLOBAL__sub_I_a(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._GLOBAL__sub_I_a(%rip)
	movl	$65535, %esi
	movl	$1, %edi
	call	_Z41__static_initialization_and_destruction_0ii
	movq	__gcov0._GLOBAL__sub_I_a+8(%rip), %rax
	addq	$1, %rax
	movq	%rax, __gcov0._GLOBAL__sub_I_a+8(%rip)
	popq	%rbp
.LCFI29:
	ret
.LFE1054:
	.size	_GLOBAL__sub_I_a, .-_GLOBAL__sub_I_a
	.section	.init_array
	.align 8
	.quad	_GLOBAL__sub_I_a
	.local	__gcov0._GLOBAL__sub_I_a
	.comm	__gcov0._GLOBAL__sub_I_a,16,16
	.local	__gcov0._Z41__static_initialization_and_destruction_0ii
	.comm	__gcov0._Z41__static_initialization_and_destruction_0ii,56,32
	.local	__gcov0._ZL27destroy_navigationBarImagesv
	.comm	__gcov0._ZL27destroy_navigationBarImagesv,16,16
	.local	__gcov0._ZL29construct_navigationBarImagesv
	.comm	__gcov0._ZL29construct_navigationBarImagesv,16,16
	.local	__gcov0.main
	.comm	__gcov0.main,32,32
	.local	__gcov0._Z8uncalledv
	.comm	__gcov0._Z8uncalledv,24,16
	.local	__gcov0._ZN4TestD2Ev
	.comm	__gcov0._ZN4TestD2Ev,24,16
	.local	__gcov0._ZN4TestC2Ev
	.comm	__gcov0._ZN4TestC2Ev,24,16
	.local	__gcov0._ZL17__gthread_triggerv
	.comm	__gcov0._ZL17__gthread_triggerv,8,8
	.local	__gcov0._Z3foov
	.comm	__gcov0._Z3foov,8,8
	.text
	.type	_GLOBAL__sub_I_65534_0_a, @function
_GLOBAL__sub_I_65534_0_a:
.LFB1055:
	pushq	%rbp
.LCFI30:
	movq	%rsp, %rbp
.LCFI31:
	movl	$.LPBX0, %edi
	call	__gcov_init
	popq	%rbp
.LCFI32:
	ret
.LFE1055:
	.size	_GLOBAL__sub_I_65534_0_a, .-_GLOBAL__sub_I_65534_0_a
	.section	.init_array.65534,"aw"
	.align 8
	.quad	_GLOBAL__sub_I_65534_0_a
	.text
	.type	_GLOBAL__sub_D_65534_1_a, @function
_GLOBAL__sub_D_65534_1_a:
.LFB1056:
	pushq	%rbp
.LCFI33:
	movq	%rsp, %rbp
.LCFI34:
	call	__gcov_exit
	popq	%rbp
.LCFI35:
	ret
.LFE1056:
	.size	_GLOBAL__sub_D_65534_1_a, .-_GLOBAL__sub_D_65534_1_a
	.section	.fini_array.65534,"aw"
	.align 8
	.quad	_GLOBAL__sub_D_65534_1_a
	.data
	.align 32
	.type	__gcov_._GLOBAL__sub_I_a, @object
	.size	__gcov_._GLOBAL__sub_I_a, 40
__gcov_._GLOBAL__sub_I_a:
	.quad	.LPBX0
	.long	311529084
	.long	-1160638343
	.long	-1061440962
	.zero	4
	.long	2
	.zero	4
	.quad	__gcov0._GLOBAL__sub_I_a
	.section	.rodata
	.align 8
.LC6:
	.string	"/var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/g++/pr16855.gcda"
	.data
	.align 32
	.type	.LPBX0, @object
	.size	.LPBX0, 120
.LPBX0:
	.long	1094135909
	.zero	4
	.quad	0
	.long	2064656319
	.zero	4
	.quad	.LC6
	.quad	__gcov_merge_add
	.quad	0
	.quad	0
	.quad	0
	.quad	0
	.quad	0
	.quad	0
	.quad	0
	.quad	0
	.long	10
	.zero	4
	.quad	.LPBX1
	.align 32
	.type	__gcov_._Z41__static_initialization_and_destruction_0ii, @object
	.size	__gcov_._Z41__static_initialization_and_destruction_0ii, 40
__gcov_._Z41__static_initialization_and_destruction_0ii:
	.quad	.LPBX0
	.long	1716483252
	.long	1405260618
	.long	-1510436741
	.zero	4
	.long	7
	.zero	4
	.quad	__gcov0._Z41__static_initialization_and_destruction_0ii
	.align 32
	.type	__gcov_._ZL27destroy_navigationBarImagesv, @object
	.size	__gcov_._ZL27destroy_navigationBarImagesv, 40
__gcov_._ZL27destroy_navigationBarImagesv:
	.quad	.LPBX0
	.long	718788813
	.long	-857923150
	.long	-1061440962
	.zero	4
	.long	2
	.zero	4
	.quad	__gcov0._ZL27destroy_navigationBarImagesv
	.align 32
	.type	__gcov_._ZL29construct_navigationBarImagesv, @object
	.size	__gcov_._ZL29construct_navigationBarImagesv, 40
__gcov_._ZL29construct_navigationBarImagesv:
	.quad	.LPBX0
	.long	821780314
	.long	-973158557
	.long	-1061440962
	.zero	4
	.long	2
	.zero	4
	.quad	__gcov0._ZL29construct_navigationBarImagesv
	.align 32
	.type	__gcov_.main, @object
	.size	__gcov_.main, 40
__gcov_.main:
	.quad	.LPBX0
	.long	108032747
	.long	413760696
	.long	-212105353
	.zero	4
	.long	4
	.zero	4
	.quad	__gcov0.main
	.align 32
	.type	__gcov_._Z8uncalledv, @object
	.size	__gcov_._Z8uncalledv, 40
__gcov_._Z8uncalledv:
	.quad	.LPBX0
	.long	630873414
	.long	-1428788906
	.long	-206267174
	.zero	4
	.long	3
	.zero	4
	.quad	__gcov0._Z8uncalledv
	.align 32
	.type	__gcov_._ZN4TestD2Ev, @object
	.size	__gcov_._ZN4TestD2Ev, 40
__gcov_._ZN4TestD2Ev:
	.quad	.LPBX0
	.long	736975145
	.long	1436802483
	.long	-206267174
	.zero	4
	.long	3
	.zero	4
	.quad	__gcov0._ZN4TestD2Ev
	.align 32
	.type	__gcov_._ZN4TestC2Ev, @object
	.size	__gcov_._ZN4TestC2Ev, 40
__gcov_._ZN4TestC2Ev:
	.quad	.LPBX0
	.long	1343124029
	.long	-1029297960
	.long	-206267174
	.zero	4
	.long	3
	.zero	4
	.quad	__gcov0._ZN4TestC2Ev
	.align 32
	.type	__gcov_._ZL17__gthread_triggerv, @object
	.size	__gcov_._ZL17__gthread_triggerv, 40
__gcov_._ZL17__gthread_triggerv:
	.quad	.LPBX0
	.long	1990447152
	.long	1732228950
	.long	-1540324424
	.zero	4
	.long	1
	.zero	4
	.quad	__gcov0._ZL17__gthread_triggerv
	.align 32
	.type	__gcov_._Z3foov, @object
	.size	__gcov_._Z3foov, 40
__gcov_._Z3foov:
	.quad	.LPBX0
	.long	373765646
	.long	96049329
	.long	-1540324424
	.zero	4
	.long	1
	.zero	4
	.quad	__gcov0._Z3foov
	.align 32
	.type	.LPBX1, @object
	.size	.LPBX1, 80
.LPBX1:
	.quad	__gcov_._GLOBAL__sub_I_a
	.quad	__gcov_._Z41__static_initialization_and_destruction_0ii
	.quad	__gcov_._ZL27destroy_navigationBarImagesv
	.quad	__gcov_._ZL29construct_navigationBarImagesv
	.quad	__gcov_.main
	.quad	__gcov_._Z8uncalledv
	.quad	__gcov_._ZN4TestD2Ev
	.quad	__gcov_._ZN4TestC2Ev
	.quad	__gcov_._ZL17__gthread_triggerv
	.quad	__gcov_._Z3foov
	.section	.eh_frame,"a",@unwind
.Lframe1:
	.long	.LECIE1-.LSCIE1
.LSCIE1:
	.long	0
	.byte	0x3
	.string	"zR"
	.byte	0x1
	.byte	0x78
	.byte	0x10
	.byte	0x1
	.byte	0x3
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.byte	0x90
	.byte	0x1
	.align 8
.LECIE1:
.LSFDE1:
	.long	.LEFDE1-.LASFDE1
.LASFDE1:
	.long	.LASFDE1-.Lframe1
	.long	.LFB5
	.long	.LFE5-.LFB5
	.byte	0
	.byte	0x4
	.long	.LCFI0-.LFB5
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI1-.LCFI0
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI2-.LCFI1
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE1:
.LSFDE3:
	.long	.LEFDE3-.LASFDE3
.LASFDE3:
	.long	.LASFDE3-.Lframe1
	.long	.LFB286
	.long	.LFE286-.LFB286
	.byte	0
	.byte	0x4
	.long	.LCFI3-.LFB286
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI4-.LCFI3
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI5-.LCFI4
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE3:
.LSFDE5:
	.long	.LEFDE5-.LASFDE5
.LASFDE5:
	.long	.LASFDE5-.Lframe1
	.long	.LFB1036
	.long	.LFE1036-.LFB1036
	.byte	0
	.byte	0x4
	.long	.LCFI6-.LFB1036
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI7-.LCFI6
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI8-.LCFI7
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE5:
.LSFDE7:
	.long	.LEFDE7-.LASFDE7
.LASFDE7:
	.long	.LASFDE7-.Lframe1
	.long	.LFB1039
	.long	.LFE1039-.LFB1039
	.byte	0
	.byte	0x4
	.long	.LCFI9-.LFB1039
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI10-.LCFI9
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI11-.LCFI10
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE7:
.LSFDE9:
	.long	.LEFDE9-.LASFDE9
.LASFDE9:
	.long	.LASFDE9-.Lframe1
	.long	.LFB1041
	.long	.LFE1041-.LFB1041
	.byte	0
	.byte	0x4
	.long	.LCFI12-.LFB1041
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI13-.LCFI12
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI14-.LCFI13
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE9:
.LSFDE11:
	.long	.LEFDE11-.LASFDE11
.LASFDE11:
	.long	.LASFDE11-.Lframe1
	.long	.LFB1042
	.long	.LFE1042-.LFB1042
	.byte	0
	.byte	0x4
	.long	.LCFI15-.LFB1042
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI16-.LCFI15
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI17-.LCFI16
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE11:
.LSFDE13:
	.long	.LEFDE13-.LASFDE13
.LASFDE13:
	.long	.LASFDE13-.Lframe1
	.long	.LFB1043
	.long	.LFE1043-.LFB1043
	.byte	0
	.byte	0x4
	.long	.LCFI18-.LFB1043
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI19-.LCFI18
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI20-.LCFI19
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE13:
.LSFDE15:
	.long	.LEFDE15-.LASFDE15
.LASFDE15:
	.long	.LASFDE15-.Lframe1
	.long	.LFB1044
	.long	.LFE1044-.LFB1044
	.byte	0
	.byte	0x4
	.long	.LCFI21-.LFB1044
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI22-.LCFI21
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI23-.LCFI22
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE15:
.LSFDE17:
	.long	.LEFDE17-.LASFDE17
.LASFDE17:
	.long	.LASFDE17-.Lframe1
	.long	.LFB1053
	.long	.LFE1053-.LFB1053
	.byte	0
	.byte	0x4
	.long	.LCFI24-.LFB1053
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI25-.LCFI24
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI26-.LCFI25
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE17:
.LSFDE19:
	.long	.LEFDE19-.LASFDE19
.LASFDE19:
	.long	.LASFDE19-.Lframe1
	.long	.LFB1054
	.long	.LFE1054-.LFB1054
	.byte	0
	.byte	0x4
	.long	.LCFI27-.LFB1054
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI28-.LCFI27
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI29-.LCFI28
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE19:
.LSFDE21:
	.long	.LEFDE21-.LASFDE21
.LASFDE21:
	.long	.LASFDE21-.Lframe1
	.long	.LFB1055
	.long	.LFE1055-.LFB1055
	.byte	0
	.byte	0x4
	.long	.LCFI30-.LFB1055
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI31-.LCFI30
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI32-.LCFI31
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE21:
.LSFDE23:
	.long	.LEFDE23-.LASFDE23
.LASFDE23:
	.long	.LASFDE23-.Lframe1
	.long	.LFB1056
	.long	.LFE1056-.LFB1056
	.byte	0
	.byte	0x4
	.long	.LCFI33-.LFB1056
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.long	.LCFI34-.LCFI33
	.byte	0xd
	.byte	0x6
	.byte	0x4
	.long	.LCFI35-.LCFI34
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.align 8
.LEFDE23:
	.hidden	__dso_handle
	.ident	"GCC: (GNU) 7.0.0 20160930 (experimental) [trunk revision 240649]"
	.section	.text._ZN4TestC2Ev%_ZN4TestC5Ev,"ax",@progbits
_ZN4TestC5Ev:
	.section	.text._ZN4TestD2Ev%_ZN4TestD5Ev,"ax",@progbits
_ZN4TestD5Ev:

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-30 12:48               ` Rainer Orth
@ 2016-09-30 13:07                 ` Martin Liška
  2016-09-30 13:13                   ` Rainer Orth
                                     ` (2 more replies)
  2016-10-06 19:00                 ` [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler Martin Liška
  1 sibling, 3 replies; 29+ messages in thread
From: Martin Liška @ 2016-09-30 13:07 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

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 mistake in dtor priority
(I used 65534 instead of desired 99). Please try to test it on Solaris 12
with the attached patch. I'll send the patch to ML soon.

Can you please test whether it makes any change on a solaris target w/o
prioritized ctors/dtors?

Thanks,
Martin

[-- Attachment #2: fix-gcov-exit.patch --]
[-- Type: text/x-patch, Size: 491 bytes --]

diff --git a/gcc/coverage.c b/gcc/coverage.c
index 0b8c0b3..a759831 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1078,7 +1078,7 @@ build_gcov_exit_decl (void)
   append_to_statement_list (stmt, &dtor);
 
   /* Generate a destructor to run it (with priority 99).  */
-  cgraph_build_static_cdtor ('D', dtor, DEFAULT_INIT_PRIORITY - 1);
+  cgraph_build_static_cdtor ('D', dtor, MAX_RESERVED_INIT_PRIORITY - 1);
 }
 
 /* Create the gcov_info types and object.  Generate the constructor

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-30 13:07                 ` Martin Liška
@ 2016-09-30 13:13                   ` Rainer Orth
  2016-10-03 13:03                   ` Rainer Orth
  2016-10-07  8:22                   ` [PATCH][OBVIOUS] Really set priority to 99 for __gcov_exit Martin Liška
  2 siblings, 0 replies; 29+ messages in thread
From: Rainer Orth @ 2016-09-30 13:13 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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, I have a stupid mistake in dtor priority
> (I used 65534 instead of desired 99). Please try to test it on Solaris 12
> with the attached patch. I'll send the patch to ML soon.
>
> Can you please test whether it makes any change on a solaris target w/o
> prioritized ctors/dtors?

sure: I've added your patch to my source tree for the running bootstraps
and will have builds on Solaris 12 (with constructor priority) and S10/11
(without) available in a few hours.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-30 13:07                 ` Martin Liška
  2016-09-30 13:13                   ` Rainer Orth
@ 2016-10-03 13:03                   ` Rainer Orth
  2016-10-03 14:40                     ` Martin Liška
  2016-10-07  8:22                   ` [PATCH][OBVIOUS] Really set priority to 99 for __gcov_exit Martin Liška
  2 siblings, 1 reply; 29+ messages in thread
From: Rainer Orth @ 2016-10-03 13:03 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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, I have a stupid mistake in dtor priority
> (I used 65534 instead of desired 99). Please try to test it on Solaris 12
> with the attached patch. I'll send the patch to ML soon.

unfortunately, the patch makes no difference on Solaris 12.  The test
even FAILs when using gas/gld, which is a different/independent
implementation of constructor priority.

> Can you please test whether it makes any change on a solaris target w/o
> prioritized ctors/dtors?

It doesn't: the test PASSes on Solaris 10 and 11 with and without your
patch.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-10-03 13:03                   ` Rainer Orth
@ 2016-10-03 14:40                     ` Martin Liška
  0 siblings, 0 replies; 29+ messages in thread
From: Martin Liška @ 2016-10-03 14:40 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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, the gas
>>> build is still running).
>>
>> Hi. Sorry, I have a stupid mistake in dtor priority
>> (I used 65534 instead of desired 99). Please try to test it on Solaris 12
>> with the attached patch. I'll send the patch to ML soon.
> 
> unfortunately, the patch makes no difference on Solaris 12.  The test
> even FAILs when using gas/gld, which is a different/independent
> implementation of constructor priority.

Ok, can you please send me x.S file for Solaris 12?

> 
>> Can you please test whether it makes any change on a solaris target w/o
>> prioritized ctors/dtors?
> 
> It doesn't: the test PASSes on Solaris 10 and 11 with and without your
> patch.

I see, that would require the former approach using atexit, which would be
chosen depending on whether target supports prioritized dtors or not.

Martin

> 
> 	Rainer
> 

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-09-30 12:48               ` Rainer Orth
  2016-09-30 13:07                 ` Martin Liška
@ 2016-10-06 19:00                 ` Martin Liška
  2016-10-13 13:46                   ` Rainer Orth
  1 sibling, 1 reply; 29+ messages in thread
From: Martin Liška @ 2016-10-06 19:00 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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 --enable-valgrind-annotations --prefix=/home/marxin/bin/gcc2 --disable-multilib --disable-libsanitizer --target=i386-pc-solaris2.12

and I get for:
cat /tmp/priority.c
void __attribute__ ((constructor(150))) foo()
{
}

void __attribute__ ((constructor(151))) bar()
{
}

int main()
{
   return 0;
}

$ ./xgcc -B. /tmp/priority.c -fprofile-generate -S
/tmp/priority.c:2:1: error: constructor priorities are not supported
  {
  ^
/tmp/priority.c:6:1: error: constructor priorities are not supported
  {
  ^

I guess even cross compiler should detect whether the target supports ctor/dtor priorities.
May I ask you for assembly file of a native compiler with the suggested patch?

Thanks,
Martin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [PATCH][OBVIOUS] Really set priority to 99 for __gcov_exit
  2016-09-30 13:07                 ` Martin Liška
  2016-09-30 13:13                   ` Rainer Orth
  2016-10-03 13:03                   ` Rainer Orth
@ 2016-10-07  8:22                   ` Martin Liška
  2 siblings, 0 replies; 29+ messages in thread
From: Martin Liška @ 2016-10-07  8:22 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

Hi.

This is a small fix where I use a proper macro to set priority to 99.
I'll commit the patch after tests will finish.

Martin

[-- Attachment #2: 0001-Really-set-priority-to-99-for-__gcov_exit.patch --]
[-- Type: text/x-patch, Size: 914 bytes --]

From ee8799b82fd769574c64489db31a494635da5f42 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Fri, 30 Sep 2016 14:48:31 +0200
Subject: [PATCH] Really set priority to 99 for __gcov_exit

gcc/ChangeLog:

2016-09-30  Martin Liska  <mliska@suse.cz>

	* coverage.c (build_gcov_exit_decl): Fix priority what
	should be really 99.
---
 gcc/coverage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/coverage.c b/gcc/coverage.c
index 0b8c0b3..a759831 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1078,7 +1078,7 @@ build_gcov_exit_decl (void)
   append_to_statement_list (stmt, &dtor);
 
   /* Generate a destructor to run it (with priority 99).  */
-  cgraph_build_static_cdtor ('D', dtor, DEFAULT_INIT_PRIORITY - 1);
+  cgraph_build_static_cdtor ('D', dtor, MAX_RESERVED_INIT_PRIORITY - 1);
 }
 
 /* Create the gcov_info types and object.  Generate the constructor
-- 
2.9.2


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-10-06 19:00                 ` [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler Martin Liška
@ 2016-10-13 13:46                   ` Rainer Orth
  2016-10-13 14:01                     ` Martin Liška
  0 siblings, 1 reply; 29+ messages in thread
From: Rainer Orth @ 2016-10-13 13:46 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

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 cross-compiler:
> $ ../configure --disable-bootstrap --enable-languages=c,c++,fortran --enable-valgrind-annotations --prefix=/home/marxin/bin/gcc2 --disable-multilib --disable-libsanitizer --target=i386-pc-solaris2.12
>
> and I get for:
> cat /tmp/priority.c
> void __attribute__ ((constructor(150))) foo()
> {
> }
>
> void __attribute__ ((constructor(151))) bar()
> {
> }
>
> int main()
> {
>   return 0;
> }
>
> $ ./xgcc -B. /tmp/priority.c -fprofile-generate -S
> /tmp/priority.c:2:1: error: constructor priorities are not supported
>  {
>  ^
> /tmp/priority.c:6:1: error: constructor priorities are not supported
>  {
>  ^
>
> I guess even cross compiler should detect whether the target supports ctor/dtor priorities.

maybe it could, but right now acinclude.m4 (gcc_AC_INITFINI_ARRAY) has
this for crosses:

    AC_MSG_CHECKING(cross compile... guessing)
    gcc_cv_initfini_array=no

You could work around this by overriding configure with
--enable-initfini-array.

> May I ask you for assembly file of a native compiler with the suggested patch?

Sure: this time from an i386-pc-solaris2.12 compiler configured to use
gas and ld.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University



[-- Attachment #2: pr16855.s --]
[-- Type: text/plain, Size: 17596 bytes --]

	.file	"pr16855.C"
	.globl	a
	.bss
	.align 4
	.type	a, @object
	.size	a, 4
a:
	.zero	4
	.text
	.globl	_Z3foov
	.type	_Z3foov, @function
_Z3foov:
.LFB55:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	movl	__gcov0._Z3foov, %eax
	movl	__gcov0._Z3foov+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z3foov
	movl	%edx, __gcov0._Z3foov+4
	movl	$123, a
	nop
	popl	%ebp
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE55:
	.size	_Z3foov, .-_Z3foov
	.data
	.align 4
	.type	_ZL16__gthread_active, @object
	.size	_ZL16__gthread_active, 4
_ZL16__gthread_active:
	.long	-1
	.text
	.type	_ZL17__gthread_triggerv, @function
_ZL17__gthread_triggerv:
.LFB336:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	movl	__gcov0._ZL17__gthread_triggerv, %eax
	movl	__gcov0._ZL17__gthread_triggerv+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZL17__gthread_triggerv
	movl	%edx, __gcov0._ZL17__gthread_triggerv+4
	movl	$1, _ZL16__gthread_active
	nop
	popl	%ebp
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE336:
	.size	_ZL17__gthread_triggerv, .-_ZL17__gthread_triggerv
	.local	_ZStL8__ioinit
	.comm	_ZStL8__ioinit,1,1
	.section	.rodata
.LC0:
	.string	"In Test ctor"
	.section	.text._ZN4TestC2Ev,"axG",@progbits,_ZN4TestC5Ev,comdat
	.align 2
	.weak	_ZN4TestC2Ev
	.type	_ZN4TestC2Ev, @function
_ZN4TestC2Ev:
.LFB1086:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	movl	__gcov0._ZN4TestC2Ev, %eax
	movl	__gcov0._ZN4TestC2Ev+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZN4TestC2Ev
	movl	%edx, __gcov0._ZN4TestC2Ev+4
	subl	$8, %esp
	pushl	$.LC0
	pushl	$_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	addl	$16, %esp
	movl	%eax, %ecx
	movl	__gcov0._ZN4TestC2Ev+8, %eax
	movl	__gcov0._ZN4TestC2Ev+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZN4TestC2Ev+8
	movl	%edx, __gcov0._ZN4TestC2Ev+12
	subl	$8, %esp
	pushl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	pushl	%ecx
	call	_ZNSolsEPFRSoS_E
	addl	$16, %esp
	movl	__gcov0._ZN4TestC2Ev+16, %eax
	movl	__gcov0._ZN4TestC2Ev+20, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZN4TestC2Ev+16
	movl	%edx, __gcov0._ZN4TestC2Ev+20
	nop
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1086:
	.size	_ZN4TestC2Ev, .-_ZN4TestC2Ev
	.weak	_ZN4TestC1Ev
	.set	_ZN4TestC1Ev,_ZN4TestC2Ev
	.section	.rodata
.LC1:
	.string	"In Test dtor"
	.section	.text._ZN4TestD2Ev,"axG",@progbits,_ZN4TestD5Ev,comdat
	.align 2
	.weak	_ZN4TestD2Ev
	.type	_ZN4TestD2Ev, @function
_ZN4TestD2Ev:
.LFB1089:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	movl	__gcov0._ZN4TestD2Ev, %eax
	movl	__gcov0._ZN4TestD2Ev+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZN4TestD2Ev
	movl	%edx, __gcov0._ZN4TestD2Ev+4
	subl	$8, %esp
	pushl	$.LC1
	pushl	$_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	addl	$16, %esp
	movl	%eax, %ecx
	movl	__gcov0._ZN4TestD2Ev+8, %eax
	movl	__gcov0._ZN4TestD2Ev+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZN4TestD2Ev+8
	movl	%edx, __gcov0._ZN4TestD2Ev+12
	subl	$8, %esp
	pushl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	pushl	%ecx
	call	_ZNSolsEPFRSoS_E
	addl	$16, %esp
	movl	__gcov0._ZN4TestD2Ev+16, %eax
	movl	__gcov0._ZN4TestD2Ev+20, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZN4TestD2Ev+16
	movl	%edx, __gcov0._ZN4TestD2Ev+20
	nop
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1089:
	.size	_ZN4TestD2Ev, .-_ZN4TestD2Ev
	.weak	_ZN4TestD1Ev
	.set	_ZN4TestD1Ev,_ZN4TestD2Ev
	.globl	T1
	.bss
	.type	T1, @object
	.size	T1, 1
T1:
	.zero	1
	.section	.rodata
.LC2:
	.string	"In uncalled"
	.text
	.globl	_Z8uncalledv
	.type	_Z8uncalledv, @function
_Z8uncalledv:
.LFB1091:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	movl	__gcov0._Z8uncalledv, %eax
	movl	__gcov0._Z8uncalledv+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z8uncalledv
	movl	%edx, __gcov0._Z8uncalledv+4
	subl	$8, %esp
	pushl	$.LC2
	pushl	$_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	addl	$16, %esp
	movl	%eax, %ecx
	movl	__gcov0._Z8uncalledv+8, %eax
	movl	__gcov0._Z8uncalledv+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z8uncalledv+8
	movl	%edx, __gcov0._Z8uncalledv+12
	subl	$8, %esp
	pushl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	pushl	%ecx
	call	_ZNSolsEPFRSoS_E
	addl	$16, %esp
	movl	__gcov0._Z8uncalledv+16, %eax
	movl	__gcov0._Z8uncalledv+20, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z8uncalledv+16
	movl	%edx, __gcov0._Z8uncalledv+20
	nop
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1091:
	.size	_Z8uncalledv, .-_Z8uncalledv
	.section	.rodata
.LC3:
	.string	"In main"
	.text
	.globl	main
	.type	main, @function
main:
.LFB1092:
	.cfi_startproc
	leal	4(%esp), %ecx
	.cfi_def_cfa 1, 0
	andl	$-16, %esp
	pushl	-4(%ecx)
	pushl	%ebp
	.cfi_escape 0x10,0x5,0x2,0x75,0
	movl	%esp, %ebp
	pushl	%ecx
	.cfi_escape 0xf,0x3,0x75,0x7c,0x6
	subl	$4, %esp
	movl	__gcov0.main, %eax
	movl	__gcov0.main+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0.main
	movl	%edx, __gcov0.main+4
	subl	$12, %esp
	pushl	$_Z3foov
	call	atexit
	addl	$16, %esp
	movl	__gcov0.main+8, %eax
	movl	__gcov0.main+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0.main+8
	movl	%edx, __gcov0.main+12
	subl	$8, %esp
	pushl	$.LC3
	pushl	$_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	addl	$16, %esp
	movl	%eax, %ecx
	movl	__gcov0.main+16, %eax
	movl	__gcov0.main+20, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0.main+16
	movl	%edx, __gcov0.main+20
	subl	$8, %esp
	pushl	$_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	pushl	%ecx
	call	_ZNSolsEPFRSoS_E
	addl	$16, %esp
	movl	$0, %ecx
	movl	__gcov0.main+24, %eax
	movl	__gcov0.main+28, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0.main+24
	movl	%edx, __gcov0.main+28
	movl	%ecx, %eax
	movl	-4(%ebp), %ecx
	.cfi_def_cfa 1, 0
	leave
	.cfi_restore 5
	leal	-4(%ecx), %esp
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1092:
	.size	main, .-main
	.section	.rodata
	.align 4
.LC4:
	.string	"((construct_navigationBarImages))"
	.text
	.type	_ZL29construct_navigationBarImagesv, @function
_ZL29construct_navigationBarImagesv:
.LFB1093:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	movl	__gcov0._ZL29construct_navigationBarImagesv, %eax
	movl	__gcov0._ZL29construct_navigationBarImagesv+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZL29construct_navigationBarImagesv
	movl	%edx, __gcov0._ZL29construct_navigationBarImagesv+4
	pushl	$__iob+32
	pushl	$33
	pushl	$1
	pushl	$.LC4
	call	fwrite
	addl	$16, %esp
	movl	__gcov0._ZL29construct_navigationBarImagesv+8, %eax
	movl	__gcov0._ZL29construct_navigationBarImagesv+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZL29construct_navigationBarImagesv+8
	movl	%edx, __gcov0._ZL29construct_navigationBarImagesv+12
	nop
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1093:
	.size	_ZL29construct_navigationBarImagesv, .-_ZL29construct_navigationBarImagesv
	.section	.init_array,"aw"
	.align 4
	.long	_ZL29construct_navigationBarImagesv
	.section	.rodata
	.align 4
.LC5:
	.string	"((destroy_navigationBarImages))"
	.text
	.type	_ZL27destroy_navigationBarImagesv, @function
_ZL27destroy_navigationBarImagesv:
.LFB1094:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	movl	__gcov0._ZL27destroy_navigationBarImagesv, %eax
	movl	__gcov0._ZL27destroy_navigationBarImagesv+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZL27destroy_navigationBarImagesv
	movl	%edx, __gcov0._ZL27destroy_navigationBarImagesv+4
	pushl	$__iob+32
	pushl	$31
	pushl	$1
	pushl	$.LC5
	call	fwrite
	addl	$16, %esp
	movl	__gcov0._ZL27destroy_navigationBarImagesv+8, %eax
	movl	__gcov0._ZL27destroy_navigationBarImagesv+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._ZL27destroy_navigationBarImagesv+8
	movl	%edx, __gcov0._ZL27destroy_navigationBarImagesv+12
	nop
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1094:
	.size	_ZL27destroy_navigationBarImagesv, .-_ZL27destroy_navigationBarImagesv
	.section	.fini_array,"aw"
	.align 4
	.long	_ZL27destroy_navigationBarImagesv
	.text
	.type	_Z41__static_initialization_and_destruction_0ii, @function
_Z41__static_initialization_and_destruction_0ii:
.LFB1103:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii, %eax
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z41__static_initialization_and_destruction_0ii
	movl	%edx, __gcov0._Z41__static_initialization_and_destruction_0ii+4
	cmpl	$1, 8(%ebp)
	jne	.L12
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+8, %eax
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z41__static_initialization_and_destruction_0ii+8
	movl	%edx, __gcov0._Z41__static_initialization_and_destruction_0ii+12
	cmpl	$65535, 12(%ebp)
	jne	.L12
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+16, %eax
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+20, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z41__static_initialization_and_destruction_0ii+16
	movl	%edx, __gcov0._Z41__static_initialization_and_destruction_0ii+20
	subl	$12, %esp
	pushl	$_ZStL8__ioinit
	call	_ZNSt8ios_base4InitC1Ev
	addl	$16, %esp
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+24, %eax
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+28, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z41__static_initialization_and_destruction_0ii+24
	movl	%edx, __gcov0._Z41__static_initialization_and_destruction_0ii+28
	subl	$4, %esp
	pushl	$__dso_handle
	pushl	$_ZStL8__ioinit
	pushl	$_ZNSt8ios_base4InitD1Ev
	call	__cxa_atexit
	addl	$16, %esp
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+32, %eax
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+36, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z41__static_initialization_and_destruction_0ii+32
	movl	%edx, __gcov0._Z41__static_initialization_and_destruction_0ii+36
	subl	$12, %esp
	pushl	$T1
	call	_ZN4TestC1Ev
	addl	$16, %esp
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+40, %eax
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+44, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z41__static_initialization_and_destruction_0ii+40
	movl	%edx, __gcov0._Z41__static_initialization_and_destruction_0ii+44
	subl	$4, %esp
	pushl	$__dso_handle
	pushl	$T1
	pushl	$_ZN4TestD1Ev
	call	__cxa_atexit
	addl	$16, %esp
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+48, %eax
	movl	__gcov0._Z41__static_initialization_and_destruction_0ii+52, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._Z41__static_initialization_and_destruction_0ii+48
	movl	%edx, __gcov0._Z41__static_initialization_and_destruction_0ii+52
.L12:
	nop
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1103:
	.size	_Z41__static_initialization_and_destruction_0ii, .-_Z41__static_initialization_and_destruction_0ii
	.type	_GLOBAL__sub_I_a, @function
_GLOBAL__sub_I_a:
.LFB1104:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	movl	__gcov0._GLOBAL__sub_I_a, %eax
	movl	__gcov0._GLOBAL__sub_I_a+4, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._GLOBAL__sub_I_a
	movl	%edx, __gcov0._GLOBAL__sub_I_a+4
	subl	$8, %esp
	pushl	$65535
	pushl	$1
	call	_Z41__static_initialization_and_destruction_0ii
	addl	$16, %esp
	movl	__gcov0._GLOBAL__sub_I_a+8, %eax
	movl	__gcov0._GLOBAL__sub_I_a+12, %edx
	addl	$1, %eax
	adcl	$0, %edx
	movl	%eax, __gcov0._GLOBAL__sub_I_a+8
	movl	%edx, __gcov0._GLOBAL__sub_I_a+12
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1104:
	.size	_GLOBAL__sub_I_a, .-_GLOBAL__sub_I_a
	.section	.init_array
	.align 4
	.long	_GLOBAL__sub_I_a
	.local	__gcov0._GLOBAL__sub_I_a
	.comm	__gcov0._GLOBAL__sub_I_a,16,8
	.local	__gcov0._Z41__static_initialization_and_destruction_0ii
	.comm	__gcov0._Z41__static_initialization_and_destruction_0ii,56,32
	.local	__gcov0._ZL27destroy_navigationBarImagesv
	.comm	__gcov0._ZL27destroy_navigationBarImagesv,16,8
	.local	__gcov0._ZL29construct_navigationBarImagesv
	.comm	__gcov0._ZL29construct_navigationBarImagesv,16,8
	.local	__gcov0.main
	.comm	__gcov0.main,32,32
	.local	__gcov0._Z8uncalledv
	.comm	__gcov0._Z8uncalledv,24,8
	.local	__gcov0._ZN4TestD2Ev
	.comm	__gcov0._ZN4TestD2Ev,24,8
	.local	__gcov0._ZN4TestC2Ev
	.comm	__gcov0._ZN4TestC2Ev,24,8
	.local	__gcov0._ZL17__gthread_triggerv
	.comm	__gcov0._ZL17__gthread_triggerv,8,8
	.local	__gcov0._Z3foov
	.comm	__gcov0._Z3foov,8,8
	.text
	.type	_GLOBAL__sub_I_65534_0_a, @function
_GLOBAL__sub_I_65534_0_a:
.LFB1105:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	subl	$12, %esp
	pushl	$.LPBX0
	call	__gcov_init
	addl	$16, %esp
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1105:
	.size	_GLOBAL__sub_I_65534_0_a, .-_GLOBAL__sub_I_65534_0_a
	.section	.init_array.65534,"aw"
	.align 4
	.long	_GLOBAL__sub_I_65534_0_a
	.text
	.type	_GLOBAL__sub_D_65534_1_a, @function
_GLOBAL__sub_D_65534_1_a:
.LFB1106:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$8, %esp
	call	__gcov_exit
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE1106:
	.size	_GLOBAL__sub_D_65534_1_a, .-_GLOBAL__sub_D_65534_1_a
	.section	.fini_array.65534,"aw"
	.align 4
	.long	_GLOBAL__sub_D_65534_1_a
	.data
	.align 4
	.type	__gcov_._GLOBAL__sub_I_a, @object
	.size	__gcov_._GLOBAL__sub_I_a, 24
__gcov_._GLOBAL__sub_I_a:
	.long	.LPBX0
	.long	311529084
	.long	-1160638343
	.long	-1061440962
	.long	2
	.long	__gcov0._GLOBAL__sub_I_a
	.section	.rodata
	.align 4
.LC6:
	.string	"/var/gcc/regression/trunk/12-gcc-gas/build/gcc/testsuite/g++/pr16855.gcda"
	.data
	.align 32
	.type	.LPBX0, @object
	.size	.LPBX0, 60
.LPBX0:
	.long	1094135909
	.long	0
	.long	-1102553019
	.long	.LC6
	.long	__gcov_merge_add
	.long	0
	.long	0
	.long	0
	.long	0
	.long	0
	.long	0
	.long	0
	.long	0
	.long	10
	.long	.LPBX1
	.align 4
	.type	__gcov_._Z41__static_initialization_and_destruction_0ii, @object
	.size	__gcov_._Z41__static_initialization_and_destruction_0ii, 24
__gcov_._Z41__static_initialization_and_destruction_0ii:
	.long	.LPBX0
	.long	1716483252
	.long	1405260618
	.long	-1510436741
	.long	7
	.long	__gcov0._Z41__static_initialization_and_destruction_0ii
	.align 4
	.type	__gcov_._ZL27destroy_navigationBarImagesv, @object
	.size	__gcov_._ZL27destroy_navigationBarImagesv, 24
__gcov_._ZL27destroy_navigationBarImagesv:
	.long	.LPBX0
	.long	718788813
	.long	-857923150
	.long	-1061440962
	.long	2
	.long	__gcov0._ZL27destroy_navigationBarImagesv
	.align 4
	.type	__gcov_._ZL29construct_navigationBarImagesv, @object
	.size	__gcov_._ZL29construct_navigationBarImagesv, 24
__gcov_._ZL29construct_navigationBarImagesv:
	.long	.LPBX0
	.long	821780314
	.long	-973158557
	.long	-1061440962
	.long	2
	.long	__gcov0._ZL29construct_navigationBarImagesv
	.align 4
	.type	__gcov_.main, @object
	.size	__gcov_.main, 24
__gcov_.main:
	.long	.LPBX0
	.long	108032747
	.long	413760696
	.long	-212105353
	.long	4
	.long	__gcov0.main
	.align 4
	.type	__gcov_._Z8uncalledv, @object
	.size	__gcov_._Z8uncalledv, 24
__gcov_._Z8uncalledv:
	.long	.LPBX0
	.long	630873414
	.long	-1428788906
	.long	-206267174
	.long	3
	.long	__gcov0._Z8uncalledv
	.align 4
	.type	__gcov_._ZN4TestD2Ev, @object
	.size	__gcov_._ZN4TestD2Ev, 24
__gcov_._ZN4TestD2Ev:
	.long	.LPBX0
	.long	736975145
	.long	1436802483
	.long	-206267174
	.long	3
	.long	__gcov0._ZN4TestD2Ev
	.align 4
	.type	__gcov_._ZN4TestC2Ev, @object
	.size	__gcov_._ZN4TestC2Ev, 24
__gcov_._ZN4TestC2Ev:
	.long	.LPBX0
	.long	1343124029
	.long	-1029297960
	.long	-206267174
	.long	3
	.long	__gcov0._ZN4TestC2Ev
	.align 4
	.type	__gcov_._ZL17__gthread_triggerv, @object
	.size	__gcov_._ZL17__gthread_triggerv, 24
__gcov_._ZL17__gthread_triggerv:
	.long	.LPBX0
	.long	524515078
	.long	-696491031
	.long	-1540324424
	.long	1
	.long	__gcov0._ZL17__gthread_triggerv
	.align 4
	.type	__gcov_._Z3foov, @object
	.size	__gcov_._Z3foov, 24
__gcov_._Z3foov:
	.long	.LPBX0
	.long	373765646
	.long	96049329
	.long	-1540324424
	.long	1
	.long	__gcov0._Z3foov
	.align 32
	.type	.LPBX1, @object
	.size	.LPBX1, 40
.LPBX1:
	.long	__gcov_._GLOBAL__sub_I_a
	.long	__gcov_._Z41__static_initialization_and_destruction_0ii
	.long	__gcov_._ZL27destroy_navigationBarImagesv
	.long	__gcov_._ZL29construct_navigationBarImagesv
	.long	__gcov_.main
	.long	__gcov_._Z8uncalledv
	.long	__gcov_._ZN4TestD2Ev
	.long	__gcov_._ZN4TestC2Ev
	.long	__gcov_._ZL17__gthread_triggerv
	.long	__gcov_._Z3foov
	.hidden	__dso_handle
	.ident	"GCC: (GNU) 7.0.0 20161007 (experimental) [trunk revision 240853]"

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-10-13 13:46                   ` Rainer Orth
@ 2016-10-13 14:01                     ` Martin Liška
  2016-10-13 14:05                       ` Rainer Orth
  0 siblings, 1 reply; 29+ messages in thread
From: Martin Liška @ 2016-10-13 14:01 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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 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 --enable-valgrind-annotations --prefix=/home/marxin/bin/gcc2 --disable-multilib --disable-libsanitizer --target=i386-pc-solaris2.12
>>
>> and I get for:
>> cat /tmp/priority.c
>> void __attribute__ ((constructor(150))) foo()
>> {
>> }
>>
>> void __attribute__ ((constructor(151))) bar()
>> {
>> }
>>
>> int main()
>> {
>>   return 0;
>> }
>>
>> $ ./xgcc -B. /tmp/priority.c -fprofile-generate -S
>> /tmp/priority.c:2:1: error: constructor priorities are not supported
>>  {
>>  ^
>> /tmp/priority.c:6:1: error: constructor priorities are not supported
>>  {
>>  ^
>>
>> I guess even cross compiler should detect whether the target supports ctor/dtor priorities.
> 
> maybe it could, but right now acinclude.m4 (gcc_AC_INITFINI_ARRAY) has
> this for crosses:
> 
>     AC_MSG_CHECKING(cross compile... guessing)
>     gcc_cv_initfini_array=no
> 
> You could work around this by overriding configure with
> --enable-initfini-array.

Good, I've just done that.

> 
>> May I ask you for assembly file of a native compiler with the suggested patch?
> 
> Sure: this time from an i386-pc-solaris2.12 compiler configured to use
> gas and ld.
> 
> 	Rainer
> 

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	_GLOBAL__sub_D_00099_1_foo
	.data
	.align 4
	.type	.LPBX1, @object
	.size	.LPBX1, 12

Which looks good. I guess the sent snippet is before r240857, where I fixed the
priority to 99. Can you please test it with current trunk?

Thanks,
Martin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-10-13 14:01                     ` Martin Liška
@ 2016-10-13 14:05                       ` Rainer Orth
  2016-10-13 14:27                         ` Martin Liška
  0 siblings, 1 reply; 29+ messages in thread
From: Rainer Orth @ 2016-10-13 14:05 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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	_GLOBAL__sub_D_00099_1_foo
> 	.data
> 	.align 4
> 	.type	.LPBX1, @object
> 	.size	.LPBX1, 12
>
> Which looks good. I guess the sent snippet is before r240857, where I fixed the
> priority to 99. Can you please test it with current trunk?

no, it's from r240990 unlike I'm completely mistaken.  However, current
trunk bootstraps are running as we speak.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-10-13 14:05                       ` Rainer Orth
@ 2016-10-13 14:27                         ` Martin Liška
  2016-10-13 14:31                           ` Rainer Orth
  0 siblings, 1 reply; 29+ messages in thread
From: Martin Liška @ 2016-10-13 14:27 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-10-13 14:27                         ` Martin Liška
@ 2016-10-13 14:31                           ` Rainer Orth
  2016-10-13 14:44                             ` Martin Liška
  0 siblings, 1 reply; 29+ messages in thread
From: Rainer Orth @ 2016-10-13 14:31 UTC (permalink / raw)
  To: Martin Liška; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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 support constructor
priorities).

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler
  2016-10-13 14:31                           ` Rainer Orth
@ 2016-10-13 14:44                             ` Martin Liška
  0 siblings, 0 replies; 29+ messages in thread
From: Martin Liška @ 2016-10-13 14:44 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Nathan Sidwell, GCC Patches, Jan Hubicka

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 shows
> the failures, both with ld and gld (both of which support constructor
> priorities).
> 
> 	Rainer
> 

I see. So please send me some example of a binary that still fails
on Solaris 12.

Thanks,
Martin

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2016-10-13 14:44 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-10 10:43 [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler Martin Liška
2016-08-10 12:53 ` Nathan Sidwell
2016-08-10 12:55   ` Nathan Sidwell
2016-08-12 14:08   ` Martin Liška
2016-09-26 15:40     ` Martin Liška
2016-09-27 10:58       ` Nathan Sidwell
2016-09-27 11:09         ` Martin Liška
2016-09-27 11:11           ` Nathan Sidwell
2016-09-29  9:24       ` Rainer Orth
2016-09-29 12:54         ` Martin Liška
2016-09-29 13:14           ` Nathan Sidwell
2016-09-29 13:16             ` Nathan Sidwell
2016-09-29 14:04               ` Martin Liška
2016-09-30  9:31           ` Rainer Orth
2016-09-30 11:48             ` Martin Liška
2016-09-30 12:48               ` Rainer Orth
2016-09-30 13:07                 ` Martin Liška
2016-09-30 13:13                   ` Rainer Orth
2016-10-03 13:03                   ` Rainer Orth
2016-10-03 14:40                     ` Martin Liška
2016-10-07  8:22                   ` [PATCH][OBVIOUS] Really set priority to 99 for __gcov_exit Martin Liška
2016-10-06 19:00                 ` [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler Martin Liška
2016-10-13 13:46                   ` Rainer Orth
2016-10-13 14:01                     ` Martin Liška
2016-10-13 14:05                       ` Rainer Orth
2016-10-13 14:27                         ` Martin Liška
2016-10-13 14:31                           ` Rainer Orth
2016-10-13 14:44                             ` Martin Liška
2016-09-30 12:26             ` Nathan Sidwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).