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/