get_gcov_type() vs. -fprofile-update=atomic

get_gcov_type() vs. -fprofile-update=atomic

[Sebastian Huber]

Hello,

I would like to use gcov for a multi-threaded program running on an SMP 
machine using a 32-bit SPARC/LEON3 target. This target supports 
HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi. 
Unfortunately we have:

/* Return the type node for gcov_type.  */

tree
get_gcov_type (void)
{
   scalar_int_mode mode
     = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
   return lang_hooks.types.type_for_mode (mode, false);
}

The long long type is 64-bit, the get_gcov_type() returns a 64-bit type. 
This disables the atomic support in tree_profiling().

For what is the gcov type used? Could we add an option to force it to 
32-bit? What would be the consequences?

Another option would be to add something like an 
-fprofile-update=force-atomic option which would resort to libatomic. 
Which would deliver bad performance, however, correct results in a 
multi-threaded program I guess.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Sebastian Huber]

On 09/08/2021 08:51, Sebastian Huber wrote:
> Hello,
> 
> I would like to use gcov for a multi-threaded program running on an SMP 
> machine using a 32-bit SPARC/LEON3 target. This target supports 
> HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi. 
> Unfortunately we have:
> 
> /* Return the type node for gcov_type.  */
> 
> tree
> get_gcov_type (void)
> {
>    scalar_int_mode mode
>      = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
>    return lang_hooks.types.type_for_mode (mode, false);
> }
> 
> The long long type is 64-bit, the get_gcov_type() returns a 64-bit type. 
> This disables the atomic support in tree_profiling().
> 
> For what is the gcov type used? Could we add an option to force it to 
> 32-bit? What would be the consequences?
> 
> Another option would be to add something like an 
> -fprofile-update=force-atomic option which would resort to libatomic. 
> Which would deliver bad performance, however, correct results in a 
> multi-threaded program I guess.

Here is a proposed patch:

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576947.html

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Richard Biener]

On Mon, Aug 9, 2021 at 8:52 AM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> Hello,
>
> I would like to use gcov for a multi-threaded program running on an SMP
> machine using a 32-bit SPARC/LEON3 target. This target supports
> HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
> Unfortunately we have:
>
> /* Return the type node for gcov_type.  */
>
> tree
> get_gcov_type (void)
> {
>    scalar_int_mode mode
>      = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
>    return lang_hooks.types.type_for_mode (mode, false);
> }
>
> The long long type is 64-bit, the get_gcov_type() returns a 64-bit type.
> This disables the atomic support in tree_profiling().
>
> For what is the gcov type used? Could we add an option to force it to
> 32-bit? What would be the consequences?

It's a generic counter used for number of CFG edge traversal tracking.

Can you not implement 64bit atomic support for 32bit SPARC somehow?

>
> Another option would be to add something like an
> -fprofile-update=force-atomic option which would resort to libatomic.
> Which would deliver bad performance, however, correct results in a
> multi-threaded program I guess.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Sebastian Huber]

On 09/08/2021 12:22, Richard Biener wrote:
> On Mon, Aug 9, 2021 at 8:52 AM Sebastian Huber
> <sebastian.huber@embedded-brains.de>  wrote:
>> Hello,
>>
>> I would like to use gcov for a multi-threaded program running on an SMP
>> machine using a 32-bit SPARC/LEON3 target. This target supports
>> HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
>> Unfortunately we have:
>>
>> /* Return the type node for gcov_type.  */
>>
>> tree
>> get_gcov_type (void)
>> {
>>     scalar_int_mode mode
>>       = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
>>     return lang_hooks.types.type_for_mode (mode, false);
>> }
>>
>> The long long type is 64-bit, the get_gcov_type() returns a 64-bit type.
>> This disables the atomic support in tree_profiling().
>>
>> For what is the gcov type used? Could we add an option to force it to
>> 32-bit? What would be the consequences?
> It's a generic counter used for number of CFG edge traversal tracking.

So I guess if this counter overflows, then you get inconsistent 
coverage/profiling information?

> 
> Can you not implement 64bit atomic support for 32bit SPARC somehow?

The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction 
(gcc/config/sparc/sync.md). I don't know how you could implement a 
64-bit atomic support using this without spin locks (this is how 
libatomic support for RTEMS works).

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Richard Biener]

On Mon, Aug 9, 2021 at 12:56 PM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> On 09/08/2021 12:22, Richard Biener wrote:
> > On Mon, Aug 9, 2021 at 8:52 AM Sebastian Huber
> > <sebastian.huber@embedded-brains.de>  wrote:
> >> Hello,
> >>
> >> I would like to use gcov for a multi-threaded program running on an SMP
> >> machine using a 32-bit SPARC/LEON3 target. This target supports
> >> HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
> >> Unfortunately we have:
> >>
> >> /* Return the type node for gcov_type.  */
> >>
> >> tree
> >> get_gcov_type (void)
> >> {
> >>     scalar_int_mode mode
> >>       = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
> >>     return lang_hooks.types.type_for_mode (mode, false);
> >> }
> >>
> >> The long long type is 64-bit, the get_gcov_type() returns a 64-bit type.
> >> This disables the atomic support in tree_profiling().
> >>
> >> For what is the gcov type used? Could we add an option to force it to
> >> 32-bit? What would be the consequences?
> > It's a generic counter used for number of CFG edge traversal tracking.
>
> So I guess if this counter overflows, then you get inconsistent
> coverage/profiling information?

Yes.

> >
> > Can you not implement 64bit atomic support for 32bit SPARC somehow?
>
> The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
> (gcc/config/sparc/sync.md). I don't know how you could implement a
> 64-bit atomic support using this without spin locks (this is how
> libatomic support for RTEMS works).

I see.  Note the above get_gcov_type _could_ use a separate target macro
instead of LONG_LONG_TYPE_SIZE (GCOV_TYPE_SIZE?), that
way targets could opt to use a smaller counter.

Note that it isn't currently feasible to for example use a 32bit gcov type
with =atomic but 64bit with =single since the "ABI" of the gcov data isn't
self-descriptive in this aspect.  But it should be possible to record the
counter size in the meta-data and keep the on-disk format use "big"
counters in theory.

But I guess using 32bit counters on sparc-rtems might be the way to
go ...

Richard.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Sebastian Huber]

On 09/08/2021 13:27, Richard Biener wrote:
>>> Can you not implement 64bit atomic support for 32bit SPARC somehow?
>> The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
>> (gcc/config/sparc/sync.md). I don't know how you could implement a
>> 64-bit atomic support using this without spin locks (this is how
>> libatomic support for RTEMS works).
> I see.  Note the above get_gcov_type_could_  use a separate target macro
> instead of LONG_LONG_TYPE_SIZE (GCOV_TYPE_SIZE?), that
> way targets could opt to use a smaller counter.

Ok, something like this?

diff --git a/gcc/config/sparc/rtemself.h b/gcc/config/sparc/rtemself.h
index fa972af640cc..ac4f70c48c43 100644
--- a/gcc/config/sparc/rtemself.h
+++ b/gcc/config/sparc/rtemself.h
@@ -40,3 +40,5 @@

  /* Use the default */
  #undef LINK_GCC_C_SEQUENCE_SPEC
+
+#define GCOV_TYPE_SIZE 32
diff --git a/gcc/coverage.c b/gcc/coverage.c
index ac9a9fdad228..51297665e7f4 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -146,7 +146,7 @@ tree
  get_gcov_type (void)
  {
    scalar_int_mode mode
-    = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
+    = smallest_int_mode_for_size (GCOV_TYPE_SIZE > 32 ? 64 : 32);
    return lang_hooks.types.type_for_mode (mode, false);
  }

diff --git a/gcc/tree-profile.c b/gcc/tree-profile.c
index 5a74cc96e132..b7f3f445d05b 100644
--- a/gcc/tree-profile.c
+++ b/gcc/tree-profile.c
@@ -250,7 +250,7 @@ gimple_gen_edge_profiler (int edgeno, edge e)
      {
        /* __atomic_fetch_add (&counter, 1, MEMMODEL_RELAXED); */
        tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
-      tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
+      tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
                                       ? BUILT_IN_ATOMIC_FETCH_ADD_8:
                                       BUILT_IN_ATOMIC_FETCH_ADD_4);
        gcall *stmt = gimple_build_call (f, 3, addr, one,
@@ -525,7 +525,7 @@ gimple_gen_time_profiler (unsigned tag)
                           tree_time_profiler_counter);
        gassign *assign = gimple_build_assign (ptr, NOP_EXPR, addr);
        gsi_insert_before (&gsi, assign, GSI_NEW_STMT);
-      tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
+      tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
                                       ? BUILT_IN_ATOMIC_ADD_FETCH_8:
                                       BUILT_IN_ATOMIC_ADD_FETCH_4);
        gcall *stmt = gimple_build_call (f, 3, ptr, one,

> 
> Note that it isn't currently feasible to for example use a 32bit gcov type
> with =atomic but 64bit with =single since the "ABI" of the gcov data isn't
> self-descriptive in this aspect.  But it should be possible to record the
> counter size in the meta-data and keep the on-disk format use "big"
> counters in theory.

The on-disk format shouldn't be an issue since we have:

/* Dump the COUNTER using the DUMP handler called with ARG.  */

static inline void
dump_counter (gcov_type counter,
	      void (*dump_fn) (const void *, unsigned, void *),
	      void *arg)
{
   dump_unsigned ((gcov_unsigned_t)counter, dump_fn, arg);

   if (sizeof (counter) > sizeof (gcov_unsigned_t))
     dump_unsigned ((gcov_unsigned_t)(counter >> 32), dump_fn, arg);
   else
     dump_unsigned (0, dump_fn, arg);
}

> 
> But I guess using 32bit counters on sparc-rtems might be the way to
> go ...

Yes, you somehow just have to make sure that your test programs don't 
overflow the counters.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Richard Biener]

On Mon, Aug 9, 2021 at 2:03 PM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
>
>
> On 09/08/2021 13:27, Richard Biener wrote:
> >>> Can you not implement 64bit atomic support for 32bit SPARC somehow?
> >> The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
> >> (gcc/config/sparc/sync.md). I don't know how you could implement a
> >> 64-bit atomic support using this without spin locks (this is how
> >> libatomic support for RTEMS works).
> > I see.  Note the above get_gcov_type_could_  use a separate target macro
> > instead of LONG_LONG_TYPE_SIZE (GCOV_TYPE_SIZE?), that
> > way targets could opt to use a smaller counter.
>
> Ok, something like this?

Yeah, plus in defaults.h do

#ifndef GCOV_TYPE_SIZE
#define GCOV_TYPE_SIZE (LONG_LONG_TYPE_SIZE > 32 ? 64  : 32)
#endif

and then ...

> diff --git a/gcc/config/sparc/rtemself.h b/gcc/config/sparc/rtemself.h
> index fa972af640cc..ac4f70c48c43 100644
> --- a/gcc/config/sparc/rtemself.h
> +++ b/gcc/config/sparc/rtemself.h
> @@ -40,3 +40,5 @@
>
>   /* Use the default */
>   #undef LINK_GCC_C_SEQUENCE_SPEC
> +
> +#define GCOV_TYPE_SIZE 32
> diff --git a/gcc/coverage.c b/gcc/coverage.c
> index ac9a9fdad228..51297665e7f4 100644
> --- a/gcc/coverage.c
> +++ b/gcc/coverage.c
> @@ -146,7 +146,7 @@ tree
>   get_gcov_type (void)
>   {
>     scalar_int_mode mode
> -    = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
> +    = smallest_int_mode_for_size (GCOV_TYPE_SIZE > 32 ? 64 : 32);

just use

       smallest_int_mode_for_size (GCOV_TYPE_SIZE);

>     return lang_hooks.types.type_for_mode (mode, false);
>   }
>
> diff --git a/gcc/tree-profile.c b/gcc/tree-profile.c
> index 5a74cc96e132..b7f3f445d05b 100644
> --- a/gcc/tree-profile.c
> +++ b/gcc/tree-profile.c
> @@ -250,7 +250,7 @@ gimple_gen_edge_profiler (int edgeno, edge e)
>       {
>         /* __atomic_fetch_add (&counter, 1, MEMMODEL_RELAXED); */
>         tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
> -      tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
> +      tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
>                                        ? BUILT_IN_ATOMIC_FETCH_ADD_8:
>                                        BUILT_IN_ATOMIC_FETCH_ADD_4);

I think those uses should look at the actual gcov_type_node, not at the
target macro again.  So TYPE_PRECISION (gcov_type_node) > 32.

>         gcall *stmt = gimple_build_call (f, 3, addr, one,
> @@ -525,7 +525,7 @@ gimple_gen_time_profiler (unsigned tag)
>                            tree_time_profiler_counter);
>         gassign *assign = gimple_build_assign (ptr, NOP_EXPR, addr);
>         gsi_insert_before (&gsi, assign, GSI_NEW_STMT);
> -      tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
> +      tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
>                                        ? BUILT_IN_ATOMIC_ADD_FETCH_8:
>                                        BUILT_IN_ATOMIC_ADD_FETCH_4);
>         gcall *stmt = gimple_build_call (f, 3, ptr, one,
>
> >
> > Note that it isn't currently feasible to for example use a 32bit gcov type
> > with =atomic but 64bit with =single since the "ABI" of the gcov data isn't
> > self-descriptive in this aspect.  But it should be possible to record the
> > counter size in the meta-data and keep the on-disk format use "big"
> > counters in theory.
>
> The on-disk format shouldn't be an issue since we have:
>
> /* Dump the COUNTER using the DUMP handler called with ARG.  */
>
> static inline void
> dump_counter (gcov_type counter,
>               void (*dump_fn) (const void *, unsigned, void *),
>               void *arg)
> {
>    dump_unsigned ((gcov_unsigned_t)counter, dump_fn, arg);
>
>    if (sizeof (counter) > sizeof (gcov_unsigned_t))
>      dump_unsigned ((gcov_unsigned_t)(counter >> 32), dump_fn, arg);
>    else
>      dump_unsigned (0, dump_fn, arg);
> }

I think that's debugging, relevant is probably
gcov-io.c:gcov_read_counter?  But I'm not too familiar with how the
bits of the gcov infrastructure play together.  gcov-io.h documents
the IO format to some extent.  It looks like there 'gcov_type' is
hard-wired to 64bits?

> >
> > But I guess using 32bit counters on sparc-rtems might be the way to
> > go ...
>
> Yes, you somehow just have to make sure that your test programs don't
> overflow the counters.

Right - thus in principle it would be "nice" to allow to alter this with
a command-line switch (even per TU in case 64bit is slow).

Richard.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Sebastian Huber]

On 09/08/2021 14:13, Richard Biener wrote:
>> Ok, something like this?
> Yeah, plus in defaults.h do
> 
> #ifndef GCOV_TYPE_SIZE
> #define GCOV_TYPE_SIZE (LONG_LONG_TYPE_SIZE > 32 ? 64  : 32)
> #endif

Thanks for your help. I didn't know this file. It gives a nice overview 
what targets can define.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Sebastian Huber]

On 09/08/2021 14:13, Richard Biener wrote:
>>> But I guess using 32bit counters on sparc-rtems might be the way to
>>> go ...
>> Yes, you somehow just have to make sure that your test programs don't
>> overflow the counters.
> Right - thus in principle it would be "nice" to allow to alter this with
> a command-line switch (even per TU in case 64bit is slow).

Setting the gcov type size per TU would require to store this 
information in the object so that libgcov is able to know which type 
size was used (probably somewhere in struct gcov_info). Currently, the 
gcov type size for libgcov is hard coded in "libgcc/libgcov.h":

#if __CHAR_BIT__ == 8
typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI)));
typedef unsigned gcov_position_t __attribute__ ((mode (SI)));
#if GCOV_TYPE_SIZE > 32
typedef signed gcov_type __attribute__ ((mode (DI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (DI)));
#else
typedef signed gcov_type __attribute__ ((mode (SI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
#endif
#else
#if __CHAR_BIT__ == 16
typedef unsigned gcov_unsigned_t __attribute__ ((mode (HI)));
typedef unsigned gcov_position_t __attribute__ ((mode (HI)));
#if GCOV_TYPE_SIZE > 32
typedef signed gcov_type __attribute__ ((mode (SI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
#else
typedef signed gcov_type __attribute__ ((mode (HI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
#endif
#else
typedef unsigned gcov_unsigned_t __attribute__ ((mode (QI)));
typedef unsigned gcov_position_t __attribute__ ((mode (QI)));
#if GCOV_TYPE_SIZE > 32
typedef signed gcov_type __attribute__ ((mode (HI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
#else
typedef signed gcov_type __attribute__ ((mode (QI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (QI)));
#endif
#endif
#endif

Why is the mode attribute used here? Wouldn't this work also?

typedef gcov_unsigned_t __UINT32_TYPE__;
typedef gcov_position_t __UINT32_TYPE__;
#if GCOV_TYPE_SIZE > 32
typedef gcov_type __INT64_TYPE__;
typedef gcov_type_unsigned __UINT64_TYPE__;
#else
typedef gcov_type __INT32_TYPE__;
typedef gcov_type_unsigned __UINT32_TYPE__;
#endif

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Richard Biener]

On Tue, Aug 10, 2021 at 8:07 AM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> On 09/08/2021 14:13, Richard Biener wrote:
> >>> But I guess using 32bit counters on sparc-rtems might be the way to
> >>> go ...
> >> Yes, you somehow just have to make sure that your test programs don't
> >> overflow the counters.
> > Right - thus in principle it would be "nice" to allow to alter this with
> > a command-line switch (even per TU in case 64bit is slow).
>
> Setting the gcov type size per TU would require to store this
> information in the object so that libgcov is able to know which type
> size was used (probably somewhere in struct gcov_info). Currently, the
> gcov type size for libgcov is hard coded in "libgcc/libgcov.h":
>
> #if __CHAR_BIT__ == 8
> typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI)));
> typedef unsigned gcov_position_t __attribute__ ((mode (SI)));
> #if GCOV_TYPE_SIZE > 32
> typedef signed gcov_type __attribute__ ((mode (DI)));
> typedef unsigned gcov_type_unsigned __attribute__ ((mode (DI)));
> #else
> typedef signed gcov_type __attribute__ ((mode (SI)));
> typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
> #endif
> #else
> #if __CHAR_BIT__ == 16
> typedef unsigned gcov_unsigned_t __attribute__ ((mode (HI)));
> typedef unsigned gcov_position_t __attribute__ ((mode (HI)));
> #if GCOV_TYPE_SIZE > 32
> typedef signed gcov_type __attribute__ ((mode (SI)));
> typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
> #else
> typedef signed gcov_type __attribute__ ((mode (HI)));
> typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
> #endif
> #else
> typedef unsigned gcov_unsigned_t __attribute__ ((mode (QI)));
> typedef unsigned gcov_position_t __attribute__ ((mode (QI)));
> #if GCOV_TYPE_SIZE > 32
> typedef signed gcov_type __attribute__ ((mode (HI)));
> typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
> #else
> typedef signed gcov_type __attribute__ ((mode (QI)));
> typedef unsigned gcov_type_unsigned __attribute__ ((mode (QI)));
> #endif
> #endif
> #endif
>
> Why is the mode attribute used here? Wouldn't this work also?

I suppose this is historic.

> typedef gcov_unsigned_t __UINT32_TYPE__;
> typedef gcov_position_t __UINT32_TYPE__;
> #if GCOV_TYPE_SIZE > 32
> typedef gcov_type __INT64_TYPE__;
> typedef gcov_type_unsigned __UINT64_TYPE__;
> #else
> typedef gcov_type __INT32_TYPE__;
> typedef gcov_type_unsigned __UINT32_TYPE__;
> #endif

Or simply use stdint.h names, since this is for the target
GCC arranges for an appropriate stdint header.

blaming a bit yields

commit 9b514d25867f14eb1b430765ba6d5083e592fcd7
Author: Nathan Sidwell <nathan@codesourcery.com>
Date:   Sat May 10 19:02:21 2003 +0000

    defaults.h (GCOV_TYPE_SIZE): Remove.

            * defaults.h (GCOV_TYPE_SIZE): Remove.
...

so - as we're about to re-introduce that let's as Nathan if he remembers
why we removed it ;)  (well, no target overrided the macro)

Richard.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

Re: get_gcov_type() vs. -fprofile-update=atomic

[Sebastian Huber]

On 10/08/2021 09:59, Richard Biener wrote:
> On Tue, Aug 10, 2021 at 8:07 AM Sebastian Huber
> <sebastian.huber@embedded-brains.de> wrote:
>>
>> On 09/08/2021 14:13, Richard Biener wrote:
>>>>> But I guess using 32bit counters on sparc-rtems might be the way to
>>>>> go ...
>>>> Yes, you somehow just have to make sure that your test programs don't
>>>> overflow the counters.
>>> Right - thus in principle it would be "nice" to allow to alter this with
>>> a command-line switch (even per TU in case 64bit is slow).
>>
>> Setting the gcov type size per TU would require to store this
>> information in the object so that libgcov is able to know which type
>> size was used (probably somewhere in struct gcov_info). Currently, the
>> gcov type size for libgcov is hard coded in "libgcc/libgcov.h":
>>
>> #if __CHAR_BIT__ == 8
>> typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI)));
>> typedef unsigned gcov_position_t __attribute__ ((mode (SI)));
>> #if GCOV_TYPE_SIZE > 32
>> typedef signed gcov_type __attribute__ ((mode (DI)));
>> typedef unsigned gcov_type_unsigned __attribute__ ((mode (DI)));
>> #else
>> typedef signed gcov_type __attribute__ ((mode (SI)));
>> typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
>> #endif
>> #else
>> #if __CHAR_BIT__ == 16
>> typedef unsigned gcov_unsigned_t __attribute__ ((mode (HI)));
>> typedef unsigned gcov_position_t __attribute__ ((mode (HI)));
>> #if GCOV_TYPE_SIZE > 32
>> typedef signed gcov_type __attribute__ ((mode (SI)));
>> typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
>> #else
>> typedef signed gcov_type __attribute__ ((mode (HI)));
>> typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
>> #endif
>> #else
>> typedef unsigned gcov_unsigned_t __attribute__ ((mode (QI)));
>> typedef unsigned gcov_position_t __attribute__ ((mode (QI)));
>> #if GCOV_TYPE_SIZE > 32
>> typedef signed gcov_type __attribute__ ((mode (HI)));
>> typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
>> #else
>> typedef signed gcov_type __attribute__ ((mode (QI)));
>> typedef unsigned gcov_type_unsigned __attribute__ ((mode (QI)));
>> #endif
>> #endif
>> #endif
>>
>> Why is the mode attribute used here? Wouldn't this work also?
> 
> I suppose this is historic.
> 
>> typedef gcov_unsigned_t __UINT32_TYPE__;
>> typedef gcov_position_t __UINT32_TYPE__;
>> #if GCOV_TYPE_SIZE > 32
>> typedef gcov_type __INT64_TYPE__;
>> typedef gcov_type_unsigned __UINT64_TYPE__;
>> #else
>> typedef gcov_type __INT32_TYPE__;
>> typedef gcov_type_unsigned __UINT32_TYPE__;
>> #endif
> 
> Or simply use stdint.h names, since this is for the target
> GCC arranges for an appropriate stdint header.

No, including <stdint.h> doesn't work:

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576838.html

The GCC provided <stdint.h> does an

# include_next <stdint.h>

if __STDC_HOSTED__ is defined. Maybe this could be fixed by using 
-ffreestanding if inhibit_libc is defined but I don't want to touch the 
build system if it is not absolutely necessary.

> 
> blaming a bit yields
> 
> commit 9b514d25867f14eb1b430765ba6d5083e592fcd7
> Author: Nathan Sidwell <nathan@codesourcery.com>
> Date:   Sat May 10 19:02:21 2003 +0000
> 
>      defaults.h (GCOV_TYPE_SIZE): Remove.
> 
>              * defaults.h (GCOV_TYPE_SIZE): Remove.
> ...
> 
> so - as we're about to re-introduce that let's as Nathan if he remembers
> why we removed it ;)  (well, no target overrided the macro)

Also the -fprofile-update=atomic didn't exist at the time (it was 
introduced 2016).

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/