Re: get_gcov_type() vs. -fprofile-update=atomic
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.hu...@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: 'hash_map>'
On Fri, Aug 6, 2021 at 6:58 PM Thomas Schwinge wrote:
>
> Hi!
>
> So I'm trying to do some C++... ;-)
>
> Given:
>
> /* A map from SSA names or var decls to record fields. */
> typedef hash_map field_map_t;
>
> /* For each propagation record type, this is a map from SSA names or var
> decls
>to propagate, to the field in the record type that should be used for
>transmission and reception. */
> typedef hash_map record_field_map_t;
>
> Thus, that's a 'hash_map>'. (I may do that,
> right?) Looking through GCC implementation files, very most of all uses
> of 'hash_map' boil down to pointer key ('tree', for example) and
> pointer/integer value.
You could use
hash_map record_field_map_p;
vec maps;
and record the index into maps which you record the actual maps.
Alternatively use hash_map
Note your code will appear to work until you end up in the situation
where record_field_map_t is resized because hash-map doesn't
std::move elements when re-hashing.
> Then:
>
> record_field_map_t field_map ([...]); // see below
> for ([...])
> {
> tree record_type = [...];
> [...]
> bool existed;
> field_map_t &fields
> = field_map.get_or_insert (record_type, &existed);
> gcc_checking_assert (!existed);
> [...]
> for ([...])
> fields.put ([...], [...]);
> [...]
> }
> [stuff that looks up elements from 'field_map']
> field_map.empty ();
>
> This generally works.
>
> If I instantiate 'record_field_map_t field_map (40);', Valgrind is happy.
> If however I instantiate 'record_field_map_t field_map (13);' (where '13'
> would be the default for 'hash_map'), Valgrind complains:
>
> 2,080 bytes in 10 blocks are definitely lost in loss record 828 of 876
>at 0x483DD99: calloc (vg_replace_malloc.c:762)
>by 0x175F010: xcalloc (xmalloc.c:162)
>by 0xAF4A2C: hash_table simple_hashmap_traits, tree_node*>
> >::hash_entry, false, xcallocator>::hash_table(unsigned long, bool, bool,
> bool, mem_alloc_origin) (hash-table.h:275)
>by 0x15E0120: hash_map simple_hashmap_traits, tree_node*>
> >::hash_map(unsigned long, bool, bool, bool) (hash-map.h:143)
>by 0x15DEE87: hash_map simple_hashmap_traits, tree_node*> >,
> simple_hashmap_traits, hash_map tree_node*, simple_hashmap_traits,
> tree_node*> > > >::get_or_insert(tree_node* const&, bool*) (hash-map.h:205)
>by 0x15DD52C: execute_omp_oacc_neuter_broadcast()
> (omp-oacc-neuter-broadcast.cc:1371)
>[...]
>
> (That's with '#pragma GCC optimize "O0"' at the top of the 'gcc/*.cc'
> file.)
>
> My suspicion was that it is due to the 'field_map' getting resized as it
> incrementally grows (and '40' being big enough for that to never happen),
> and somehow the non-POD (?) value objects not being properly handled
> during that. Working my way a bit through 'gcc/hash-map.*' and
> 'gcc/hash-table.*' (but not claiming that I understand all that, off
> hand), it seems as if my theory is right: I'm able to plug this memory
> leak as follows:
>
> --- gcc/hash-table.h
> +++ gcc/hash-table.h
> @@ -820,6 +820,8 @@ hash_table::expand ()
> {
>value_type *q = find_empty_slot_for_expand (Descriptor::hash
> (x));
> new ((void*) q) value_type (std::move (x));
> + //BAD Descriptor::remove (x); // (doesn't make sense and) a ton of
> "Invalid read [...] inside a block of size [...] free'd"
> + x.~value_type (); //GOOD This seems to work! -- but does it make
> sense?
> }
>
>p++;
>
> However, that doesn't exactly look like a correct fix, does it? I'd
> expect such a manual destructor call in combination with placement new
> (that is being used here, obviously) -- but this is after 'std::move'?
> However, this also survives a smoke-test-like run of parts of the GCC
> testsuite, bootstrap and complete run now ongoing.
>
>
> Grüße
> Thomas
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
> München, HRB 106955
Re: get_gcov_type() vs. -fprofile-update=atomic
On Mon, Aug 9, 2021 at 8:52 AM 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?
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.hu...@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
On 09/08/2021 12:22, Richard Biener wrote:
On Mon, Aug 9, 2021 at 8:52 AM 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?
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.hu...@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
On Mon, Aug 9, 2021 at 12:56 PM Sebastian Huber
wrote:
>
> On 09/08/2021 12:22, Richard Biener wrote:
> > On Mon, Aug 9, 2021 at 8:52 AM 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?
> > 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.hu...@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
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.hu...@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: Benefits of using Sphinx documentation format
On 7/12/21 7:49 PM, Gavin Smith via Gcc wrote:
(Sending mail again, without attachments this time in the hope it gets through.)
I had the discussion about moving documentation of gcc from Sphinx to
Texinfo brought to my attention.
https://gcc.gnu.org/pipermail/gcc/2021-July/236731.html
Speaking as the Texinfo maintainer, I hope to add my views and
understandings of things to this discussion to improve your
understanding of the facts and possibilities, although of course it's
up to you whether you use Texinfo or not.
Hello.
Appreciate your time spent working on the tool and I'm going to briefly reply
your points.
I will work through the points made in that email but haven't read any
of the subsequent discussion yet - I'll follow up on anything else
afterwards.
Benefits:
1) modern looking HTML output (before: [1], after: [2]):
a) syntax highlighting for examples (code, shell commands, etc.)
Syntax highlighting has been achieved with Texinfo before. See
https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html
and
https://lists.gnu.org/archive/html/bug-texinfo/2019-11/msg4.html
With Texinfo 6.8, syntax highlighting in multiple languages is easier
to achieve by giving an argument to the @example command
(https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040example.html).
This puts a class attribute on the HTML element which can then be
picked up by a post-processor. It might also be possible to achieve
syntax highlighting with a customization file used by the Texinfo
tools themselves: see
https://lists.gnu.org/archive/html/bug-texinfo/2021-01/msg00031.html.
If I understand correctly, that would need a further post-processing of the HTML
elements. Sphinx works out of the box and the same output is achieved also for
PDF output.
b) precise anchors, the current Texinfo anchors are not displayed (start
with first line of an option)
c) one can easily copy a link to an anchor (displayed as ¶)
Similar anchors were implemented in Texinfo 6.8. See
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Invoking-texi2any.html
and hover any of the options there with your mouse; you will see the
pilcrow sign appear.
Good.
e) left menu navigation provides better orientation in the manual
Left menu navigation is possible with the new JavaScript interface, in
Texinfo 6.8. There is still a demo at
https://per.bothner.com/tmp/Kawa-txjs-plain/Community.html
and
https://per.bothner.com/tmp/Kawa-txjs/Community.html
To be honest, it looks still quite legacy and I don't want to spend more working
on a custom CSS template and reasonable JS functionality. I would like to take
an existing theme that looks nice and provides reasonable capability. That's
for me
https://github.com/readthedocs/sphinx_rtd_theme
However, I would say that it isn't necessarily always an improvement,
if it is going to be buggy. When I click on the link
https://splichal.eu/gccsphinx-final/html/gcc/gcc-command-options/options-that-control-optimization.html#cmdoption-fstrict-aliasing
the browser doesn't scroll the sidebar so to show the active ToC entry
(although it
is displayed correctly when I refresh the page).
If I open a new tab, a browser correctly scrolls to the option documentation.
The more sophisticated the HTML/JS becomes the more likely there are
these little nits.
f) Sphinx provides internal search capability: [3]
There is a global search facility with the JavaScript interface
although different to that provided by Sphinx, only showing one match
at a time.
As said, it's a limitation to me.
Try
https://per.bothner.com/tmp/Kawa-txjs/index.html
and then press "s" on your keyboard, type in your search string (e.g.
"composable") and it will search through the manual for that string.
To go to the next match, press "s" then Return.
The proviso about "sophisticated" HTML still applies here, though.
2) internal links are also provided in PDF version of the manual
Links already work when viewing a PDF on a computer.
If you want to add additional links that only appear in PDF and HTML
and not in Info, this is easily achieved with a conditional macro,
like
@ifset morelinks
@macro link{arg}
@ref{\arg\}
@end macro
@end ifset
@ifclear morelinks
@macro link{arg}
\arg\
@end macro
@end ifclear
followed by "@set morelinks" or "@clear morelinks" as required.
All right, that would likely require providing more anchors in the existing GCC
documentation.
5) Sphinx is using RST which is quite minimal semantic markup language
This is really an ineffable question of taste on which it is hard to
be convinced, but I have to point out that Texinfo is minimalistic,
with only three special characters (@, { and }).
6) TOC is automatically generated - no nee6d for manual navigation like seen
here: [5]
5] @comment node-name, next, previous, up
@nodeInstalling GCC, Binaries, , Top
This is a completely bogus poin
Re: Benefits of using Sphinx documentation format
On 7/13/21 1:52 PM, Eli Zaretskii via Gcc wrote: From: Richard Biener Date: Tue, 13 Jul 2021 08:24:17 +0200 Cc: Eli Zaretskii , "gcc@gcc.gnu.org" I actually like texinfo (well, because I know it somewhat, compare to sphinx). I think it produces quite decent PDF manuals. I never use the html output (in fact I read our manual using grep & vim in the original .texi form ...). FTR, I almost exclusively use the (Emacs) Info reader to read the manuals in Info format. I never understood those who prefer reading HTML-formatted docs in a Web browser. It's very easy. HTML output is much nice from the visual point of view and everybody uses a browser nowadays. Moreover, one can easily Google for e.g. option name, or provide a link at pages like StackOverflow. That's reality. So I never understood people, let alone developers, who are willing to throw such power out the window and use HTML. I only do that when there's a manual I don't have installed in the Info format (a rare phenomenon) or some other similarly exceptional cases. But I get it that there are strange people who prefer HTML nonetheless. More importantly, the Texinfo developers understand that, and actively work towards making the Texinfo HTML better, with some impressive progress already there, see the latest release 6.8 of Texinfo (Gavin mentioned some of the advances). I've read that and yes, there's a progress. However, I still see a rapid gap in what can be achieved by a mode modern tool like Sphinx. Martin
Re: get_gcov_type() vs. -fprofile-update=atomic
On Mon, Aug 9, 2021 at 2:03 PM Sebastian Huber
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.hu...@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: [PATCH] Port GCC documentation to Sphinx
On 7/12/21 7:18 PM, Martin Sebor wrote:
On 6/29/21 4:09 AM, Martin Liška wrote:
On 6/28/21 5:33 PM, Joseph Myers wrote:
Are formatted manuals (HTML, PDF, man, info) corresponding to this patch
version also available for review?
I've just uploaded them here:
https://splichal.eu/gccsphinx-final/
Martin
I think listing the -Wfoo and -Wno-foo (and analogously the -fbar
and -fno-bar) options is an improvement over prior revisions but when
the positive form is the default the text reads funny. For example:
Thank you!
-fno-inline
Do not expand any functions inline apart from those marked
with the always_inline attribute. This is the default when
not optimizing.
Single functions can be exempted from inlining by marking
them with the noinline attribute.
-finline
Default option value for -fno-inline.
I.e., -finline is not what I would describe as a default value for
-fno-inline.
I would suggest to drop the option name from the text describing
the default, and also replace value with setting (it's really not
a value). It could be as simple as:
-finline
Default setting.
Alternatively, to preserve the connection to the alternate setting:
-finline
Default setting; overrides -fno-inline.
I like the improvement suggestion and I've just adjusted
the generated output to 'Default setting; overrides -fno-inline'.
At some point we talked about also making attributes hyperlinks
(like always_inline and noinline above) but I don't remember
the conclusion. Are you planning to do that? (Would handling
it as part of the transition be easier than doing it later?)
I've provided more links for attributes. However, there are still limitations
that needs to be addressed:
1) I used :option: directive which might be a bit abused (one can eventually
come up with a custom directive.
2) Attributes like 'alias ("target")' do not correctly work with
:option:`alias`,
so the option definition needs to changed to 'alias' and we would have to
provide
syntax description on a next line. It's something I plan working on we merge
it.
Martin
Martin
Re: [PATCH] Port GCC documentation to Sphinx
On 7/13/21 4:54 PM, Tamar Christina wrote: Hi Martin, -Original Message- From: Gcc-patches On Behalf Of Martin Liška Sent: Tuesday, June 29, 2021 11:09 AM To: Joseph Myers Cc: GCC Development ; gcc-patc...@gcc.gnu.org Subject: Re: [PATCH] Port GCC documentation to Sphinx On 6/28/21 5:33 PM, Joseph Myers wrote: Are formatted manuals (HTML, PDF, man, info) corresponding to this patch version also available for review? I've just uploaded them here: https://splichal.eu/gccsphinx-final/ Thanks for doing this 😊 I'm a primary user of the PDFs (easier to work offline) I do like the look and syntax highlighting of the new PDFs, But I do prefer the way the current itemized entries are laid out. See for instance ` vect_interleave` which before would have the description indented on the next line, vs the new docs which puts it on the same line. Very useful comment. Generally when I look at gccint documentation, majority of documented "terms" are marked as @items in the Texinfo. In Sphinx, we should rather use a proper concrete type, like: :c:member: :c:data: :c:var: :c:func: :c:macro: :c:struct: :c:union: :c:enum: :c:enumerator: :c:type: These would improve the documentation when searching for something. I've got it listed for after migration phase. The visual break in my opinion makes it easier to read. It currently looks like a sea of text. Also purely personal I expect, but could the weight of the bold entries be reduced a bit? They look very BOLD to me atm and when there's a lot of them I find it slightly harder to read. That would be about a font selection for Latex, can you please experiment with: https://www.sphinx-doc.org/en/master/latex.html#the-latex-elements-configuration-setting ? Thanks, Martin Cheers, Tamar Martin
Re: get_gcov_type() vs. -fprofile-update=atomic
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.hu...@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/
Porting to gcc 11 / intrinsics
When porting to GCC 11, care must be taken to adjust includes of GCC intrinsic headers due to this change: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148 That should be reflected in: https://gcc.gnu.org/gcc-11/porting_to.html
Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1
On Sat, 7 Aug 2021, Stefan Kanthak wrote:
> Joseph Myers wrote:
> > You should be looking at TS 18661-3 / C2x Annex F for sNaN handling;
>
> I'll do so as soon as GCC drops support for all C dialects before C2x!
>
> Unless you use a time machine and fix the POSIX and ISO C standards
> written in the past you CAN'T neglect all software written before C2x
> modified sNaN handling that relies on the documented behaviour at the
> time it was written.
Pre-C2x versions of C don't cover signaling NaNs at all; they use "NaN" to
mean "quiet NaN" (so signaling NaNs are trap representations). Software
written before C2x thus can't rely on any particular sNaN handling.
The POSIX description of signaling NaNs ("On implementations that support
the IEC 60559:1989 standard floating point, functions with signaling NaN
argument(s) shall be treated as if the function were called with an
argument that is a required domain error and shall return a quiet NaN
result, except where stated otherwise.") is consistent with C2x as regards
trunc (sNaN) needing to return a quiet NaN with INVALID raised. The
problems are (a) POSIX fails to "state otherwise" for the cases (e.g.
fabs, copysign) where a signaling NaN argument should not result in a
quiet NaN with INVALID raised (as per IEEE semantics for those operations)
and (b) the POSIX rule about setting errno to EDOM when (math_errhandling
& MATH_ERRNO) is nonzero is inappropriate for sNaN arguments (incompatible
with the normal approach of generating INVALID and a quiet NaN by passing
NaN arguments through arithmetic) and the C2x approach of being
implementation-defined whether an sNaN input is a domain error is more
appropriate.
--
Joseph S. Myers
jos...@codesourcery.com
Re: get_gcov_type() vs. -fprofile-update=atomic
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.hu...@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/
