Re: [PATCH] Port GCC documentation to Sphinx

[Richard Sandiford via Gcc]

Hans-Peter Nilsson  writes:
> I've read the discussion downthread, but I seem to miss (a recap
> of) the benefits of moving to Sphinx.  Maybe other have too and
> it'd be a good idea to repeat them?  Otherwise, the impression
> is not so good, as all I see is bits here and there getting lost
> in translation.

Better cross-referencing is one big feature.  IMO this subthread has
demonstrated why the limitations of info formatting have held back
the amount of cross-referencing in the online html.  (And based on
emperical evidence, I get the impression that far more people use
the online html docs than the info docs.)

E.g. quoting from Richard's recent patch:

  @item -fmove-loop-stores
  @opindex fmove-loop-stores
  Enables the loop store motion pass in the GIMPLE loop optimizer.  This
  moves invariant stores to after the end of the loop in exchange for
  carrying the stored value in a register across the iteration.
  Note for this option to have an effect @option{-ftree-loop-im} has to 
  be enabled as well.  Enabled at level @option{-O1} and higher, except 
  for @option{-Og}.

In the online docs, this will just be plain text.  Anyone who doesn't
know what -ftree-loop-im is will have to search for it manually.

Adding the extra references to the html (and pdf) output but dropping
them from the info sounds like a good compromise.

Thanks,
Richard

Re: ubsan built-in function types

[Richard Biener via Gcc]

On Fri, Jul 2, 2021 at 6:33 PM Martin Sebor via Gcc  wrote:
>
> Most sanitizer built-in argument types are all of pointer types.
> For example:
>
>BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS
> as
>BT_FN_VOID_PTR_PTR_PTR
>
> or
>
>BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE
> as
>BT_FN_VOID_PTR_PTR.
>
> But some calls to these functions are made with some arguments
> of integer types.  For instance, the sanitized code for the shift
> expression below:
>
>int f (int i, int j)
>{
>  return i << j;
>}
>
> is this:
>
> :
>_9 = (unsigned long) j.0_13;
>_10 = (unsigned long) i.1_15;
># .MEM_17 = VDEF <.MEM_16(D)>
>__builtin___ubsan_handle_shift_out_of_bounds (&*.Lubsan_data0, _10, _9);
>
> As a result, gimple_call_builtin_p() returns false for such calls
> because the arguments don't match the expected types.  Assuming
> the function types are that way on purpose, is it expected that
> gimple_call_builtin_p() fail for these calls?

This API uses gimple_builtin_call_types_compatible to guard these
kind of mismatches which makes consumers not need to do extensive
argument verification checks.  So, yes.

> If so, what's
> the recommended way to test a statement to see if it's a sanitizer
> built-in?

Use the head part of the above API:

bool
gimple_call_builtin_p (const gimple *stmt, enum built_in_function code)
{
  tree fndecl;
  if (is_gimple_call (stmt)
  && (fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
  && fndecl_built_in_p (fndecl, code))

and return true instead of checking for compatible types.

> ASAN uses gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)) to see
> if a statement is the result of instrumentation (in
> has_stmt_been_instrumented_p) and this test fails for the same
> reason.  I don't know if it matters, I was just looking for
> a way to check that succeeds even for these calls.
>
> Thanks
> Martin

Re: [PATCH] Port GCC documentation to Sphinx

[Eli Zaretskii via Gcc]

> From: Richard Sandiford 
> Cc: Eli Zaretskii ,  gcc@gcc.gnu.org,  gcc-patc...@gcc.gnu.org, 
>  jos...@codesourcery.com
> Date: Mon, 05 Jul 2021 10:17:38 +0100
> 
> Hans-Peter Nilsson  writes:
> > I've read the discussion downthread, but I seem to miss (a recap
> > of) the benefits of moving to Sphinx.  Maybe other have too and
> > it'd be a good idea to repeat them?  Otherwise, the impression
> > is not so good, as all I see is bits here and there getting lost
> > in translation.
> 
> Better cross-referencing is one big feature.

See below: the Info format has some features in addition to
cross-references that can make this a much smaller issue.  HTML has
just the cross-references, so "when you are a hammer, every problem
looks like a nail".

> IMO this subthread has demonstrated why the limitations of info
> formatting have held back the amount of cross-referencing in the
> online html.

I disagree with this conclusion, see below.

> (And based on emperical evidence, I get the impression that far more
> people use the online html docs than the info docs.)

HTML browsers currently lack some features that make Info the format
of choice for me when I need to use the documentation efficiently.
The most important feature I miss in HTML browsers is the index
search.  A good manual usually has extensive index (or indices) which
make it very easy to find a specific topic one is looking for,
i.e. use the manual as a reference (as opposed as a first-time
reading, when you read large portions of the manual in sequence).

Another important feature is regexp search across multiple sections
(with HTML you'd be forced to download the manual as a single large
file for that, and then you'll probably miss regexps).

Yet another feature which, when needed, is something to kill for, is
the "info apropos" command, which can search all the manuals on your
system and build a menu from the matching sections found in different
manuals.  And there are a few more.

(Texinfo folks are working on JavaScript code to add some missing
capabilities to Web browsers, but that effort is not yet complete.)

> E.g. quoting from Richard's recent patch:
> 
>   @item -fmove-loop-stores
>   @opindex fmove-loop-stores
>   Enables the loop store motion pass in the GIMPLE loop optimizer.  This
>   moves invariant stores to after the end of the loop in exchange for
>   carrying the stored value in a register across the iteration.
>   Note for this option to have an effect @option{-ftree-loop-im} has to 
>   be enabled as well.  Enabled at level @option{-O1} and higher, except 
>   for @option{-Og}.
> 
> In the online docs, this will just be plain text.  Anyone who doesn't
> know what -ftree-loop-im is will have to search for it manually.

First, even if there are no cross-references, manual search is not the
best way.  It is much easier to use index-search:

  i ftree TAB

will display a list of options that you could be after, and you can
simply choose from the list, or type a bit more until you have a
single match.

Moreover, adding cross-references is easy:

  @item -fmove-loop-stores
  @opindex fmove-loop-stores
  Enables the loop store motion pass in the GIMPLE loop optimizer.  This
  moves invariant stores to after the end of the loop in exchange for
  carrying the stored value in a register across the iteration.
  Note for this option to have an effect @option{-ftree-loop-im}
  (@pxref{Optimize Options, -ftree-loop-im}) 
  ^^
  has be enabled as well.  Enabled at level @option{-O1} and higher,
  except for @option{-Og}.

If this looks like too much work, a simple Texinfo macro (two, if you
want an anchor where you point) will do.

> Adding the extra references to the html (and pdf) output but dropping
> them from the info sounds like a good compromise.

But that's not what happens.  And besides, how would you decide which
cross-references to drop and which to retain in Info?

Re: [PATCH] Port GCC documentation to Sphinx

[Richard Sandiford via Gcc]

Eli Zaretskii  writes:
>> Hans-Peter Nilsson  writes:
>> > I've read the discussion downthread, but I seem to miss (a recap
>> > of) the benefits of moving to Sphinx.  Maybe other have too and
>> > it'd be a good idea to repeat them?  Otherwise, the impression
>> > is not so good, as all I see is bits here and there getting lost
>> > in translation.
>> 
>> Better cross-referencing is one big feature.
>
> See below: the Info format has some features in addition to
> cross-references that can make this a much smaller issue.  HTML has
> just the cross-references, so "when you are a hammer, every problem
> looks like a nail".
>
>> IMO this subthread has demonstrated why the limitations of info
>> formatting have held back the amount of cross-referencing in the
>> online html.
>
> I disagree with this conclusion, see below.
>
>> (And based on emperical evidence, I get the impression that far more
>> people use the online html docs than the info docs.)
>
> HTML browsers currently lack some features that make Info the format
> of choice for me when I need to use the documentation efficiently.
> The most important feature I miss in HTML browsers is the index
> search.  A good manual usually has extensive index (or indices) which
> make it very easy to find a specific topic one is looking for,
> i.e. use the manual as a reference (as opposed as a first-time
> reading, when you read large portions of the manual in sequence).
>
> Another important feature is regexp search across multiple sections
> (with HTML you'd be forced to download the manual as a single large
> file for that, and then you'll probably miss regexps).
>
> Yet another feature which, when needed, is something to kill for, is
> the "info apropos" command, which can search all the manuals on your
> system and build a menu from the matching sections found in different
> manuals.  And there are a few more.
>
> (Texinfo folks are working on JavaScript code to add some missing
> capabilities to Web browsers, but that effort is not yet complete.)

Whether info or HTML is the better format isn't the issue though.  The
point is that we do have HTML output that is (emperically) widely used.
And at the moment it isn't as good as it could be.

The question that I was replying to was: what is the benefit of moving
to Sphinx?  And one of the answers is that it improves the HTML output.

>> E.g. quoting from Richard's recent patch:
>> 
>>   @item -fmove-loop-stores
>>   @opindex fmove-loop-stores
>>   Enables the loop store motion pass in the GIMPLE loop optimizer.  This
>>   moves invariant stores to after the end of the loop in exchange for
>>   carrying the stored value in a register across the iteration.
>>   Note for this option to have an effect @option{-ftree-loop-im} has to 
>>   be enabled as well.  Enabled at level @option{-O1} and higher, except 
>>   for @option{-Og}.
>> 
>> In the online docs, this will just be plain text.  Anyone who doesn't
>> know what -ftree-loop-im is will have to search for it manually.
>
> First, even if there are no cross-references, manual search is not the
> best way.  It is much easier to use index-search:
>
>   i ftree TAB
>
> will display a list of options that you could be after, and you can
> simply choose from the list, or type a bit more until you have a
> single match.

Here too I was talking about this being plain text in the online docs,
i.e. in the HTML.

In HTML the user-friendly way of letting users answer the question
“what on earth is -ftree-loop-im” is to have “-ftree-loop-im” be a
hyperlink that goes straight to the documentation of the option.
Same for PDF when viewed digitally.

One of the things that the move to Sphinx does is give us those
hyperlinks.

> Moreover, adding cross-references is easy:
>
>   @item -fmove-loop-stores
>   @opindex fmove-loop-stores
>   Enables the loop store motion pass in the GIMPLE loop optimizer.  This
>   moves invariant stores to after the end of the loop in exchange for
>   carrying the stored value in a register across the iteration.
>   Note for this option to have an effect @option{-ftree-loop-im}
>   (@pxref{Optimize Options, -ftree-loop-im}) 
>   ^^
>   has be enabled as well.  Enabled at level @option{-O1} and higher,
>   except for @option{-Og}.
>
> If this looks like too much work, a simple Texinfo macro (two, if you
> want an anchor where you point) will do.

But this would be redundant in HTML: “foo (see foo)”.

Also, the benefit of hyperlinks in HTML (not info) is that they can be
used outside of prose, such as in lists, without interrupting the flow.

>> Adding the extra references to the html (and pdf) output but dropping
>> them from the info sounds like a good compromise.
>
> But that's not what happens.

Not in the original patch, sure, but it's what I think Martin was
suggesting as a compromise (maybe I misunderstood).  The comment above
was supposed to be in support of doing that.

It sounds like those who use the i

Re: daily report on extending static analyzer project [GSoC]

[Ankur Saini via Gcc]

I forgot to send the daily report yesterday, so this one covers the work done 
on both days

AIM : 

- make the analyzer call the function with the updated call-string 
representation ( even the ones that doesn’t have a superedge )
- make the analyzer figure out the point of return from the function called 
without the superedge
- make the analyser figure out the correct point to return back in the caller 
function
- make enode and eedge representing the return call
- test the changes on the example I created before
- speculate what GCC generates for a vfunc call and discuss how can we use it 
to our advantage

—

PROGRESS  ( changes can be seen on "refs/users/arsenic/heads/analyzer_extension 
“ branch of the repository ) :

- Thanks to the new call-string representation, I was able to push calls to the 
call stack which doesn’t have a superedge and was successfully able to see the 
calls happening via the function pointer.

- To detect the returning point of the function I used the fact that such 
supernodes would contain an EXIT bb, would not have any return superedge and 
would still have a pending call-stack. 

- Now the next part was to find out the destination node of the return, for 
this I again made use of the new call string and created a custom accessor to 
get the caller and callee supernodes of the return call, then I extracted the 
gcall* from the caller supernode to ulpdate the program state, 

- now that I have got next state and next point, it was time to put the final 
piece of puzzle together and create exploded node and edge representing the 
returning call.

- I tested the changes on the the following program where the analyzer was 
earlier giving a false negative due to not detecting call via a function pointer

```
#include 
#include 

void fun(int *int_ptr)
{
free(int_ptr);
}

int test()
{
int *int_ptr = (int*)malloc(sizeof(int));
void (*fun_ptr)(int *) = &fun;
(*fun_ptr)(int_ptr);

return 0;
}

void test_2()
{
  test();
}
```
( compiler explorer link : https://godbolt.org/z/9KfenGET9 
 )

and results were showing success where the analyzer was now able to 
successfully detect, call and return from the function that was called via the 
function pointer and no longer reported the memory leak it was reporting 
before. : )

- I think I should point this out, in the process I created a lot of custom 
function to access/alter some data which was not possible before.

- now that calls via function pointer are taken care of, it was time to see 
what exactly happen what GCC generates when a function is dispatched 
dynamically, and as planned earlier, I went to  ipa-devirt.c ( devirtualizer’s 
implementation of GCC ) to investigate.

- althogh I didn’t understood everything that was happening there but here are 
some of the findings I though might be interesting for the project :- 
> the polymorphic call is called with a OBJ_TYPE_REF which contains 
otr_type( a type of class whose method is called) and otr_token (the index into 
virtual table where address is taken)
> the devirtualizer builds a type inheritance graph to keep track of 
entire inheritance hierarchy
> the most interesting function I found was 
“possible_polymorphic_call_targets()” which returns the vector of all possible 
targets of polymorphic call represented by a calledge or a gcall.
> what I understood the devirtualizer do is to search in these 
polymorphic calls and filter out the the calls which are more likely to be 
called ( known as likely calls ) and then turn them into speculative calls 
which are later turned into direct calls.

- another thing I was curious to know was, how would analyzer behave when 
encountered with a polymorphic call now that we are splitting the superedges at 
every call. 

the results were interesting, I was able to see analyzer splitting supernodes 
for the calls right away but this time they were not connected via a 
intraprocedural edge making the analyzer crashing at the callsite ( I would 
look more into it tomorrow ) 

the example I used was : -
```
struct A
{
virtual int foo (void) 
{
return 42;
}
};

struct B: public A
{
  int foo (void) 
{ 
return 0;
}
};

int test()
{
struct B b, *bptr=&b;
bptr->foo();
return bptr->foo();
}
```
( compiler explorer link : https://godbolt.org/z/d986ab7MY 
 )

—

STATUS AT THE END OF THE DAY :- 

- make the analyzer call the function with the updated call-string 
representation ( even the ones that doesn’t have a superedge ) (done)
- make the analyzer figure out the point of return from the function called 
without the superedge (done)
- make the analyser figure out the correct point to return back in the caller 
function (done)
- make enode and eedge representing the return call (done)
- test the changes on the example I created before (done)
- speculate what GCC generates for a vfunc call

Atomic operations on floating-point data types

[Thomas Schwinge]

Hi!

Per  we've found that GCC's nvptx back end
doesn't make use of the PTX 32-bit floating-point add instruction,
,
as declared in 'gcc/config/nvptx/nvptx.md:atomic_fetch_addsf'.

Trying '__atomic_fetch_add (&a, b, __ATOMIC_RELAXED);' (also outside of
the nvptx target context), I found this works fine for integer types, but
emits "error: operand type ‘float *’ is incompatible with argument 1 of
‘__atomic_fetch_add’".  In 'gcc/doc/extend.texi' we read for
'__atomic_fetch_add' referring to '__atomic_add_fetch' that "The object
pointed to by the first argument must be of integer or pointer type",
which explains where the error diagnostic is coming from.  That's
'gcc/c-family/c-common.c:sync_resolve_size', and dates back to 2005
PR14311 "builtins for atomic operations needed" commit r98154 (Git
commit 48ae6c138ca30c4c5e876a0be47c9a0b5c8bf5c2).  (I haven't studied
that in detail, yet.)

But: why, what's the rationale?  Are potential floating point exceptions
the problem, maybe?  "Simply, because nobody bothered implementing it
(common hardware doesn't provide it)" certainly is fine as an answer -- I
just wanted to make sure I'm not missing some "obvious detail".

As far as that's relevant here, I do understand that floating-point
'a + (b + c)' may be different from '(a + b) + c' etc.; '-ffast-math'
doesn't seem to help here.  (Have not yet worked out how to adequately
model in GCC the PTX ISA stating that the "Current implementation of
'atom.add.f32' on global memory flushes subnormal inputs and results to
sign-preserving zero; whereas 'atom.add.f32' on shared memory supports
subnormal inputs and results and doesn't flush them to zero".)


Grüße
 Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf

Re: Atomic operations on floating-point data types

[Joseph Myers]

On Mon, 5 Jul 2021, Thomas Schwinge wrote:

> But: why, what's the rationale?  Are potential floating point exceptions
> the problem, maybe?  "Simply, because nobody bothered implementing it

__atomic_* more or less correspond to some of the atomic_* operations in 
, which only include atomic_fetch_* for integer types.

Atomic compound assignment for floating-point arithmetic is thus only 
possible in C via direct use of compound assignment operators on _Atomic 
objects - and thus only with seq_cst memory order.

It would be reasonable to have built-in function support for 
floating-point compound assignment, in order to allow an explicit memory 
order to be specified.  If that were to be supported for non-C languages, 
there's a lot of code in c-typeck.c:build_atomic_assign (including the use 
of targetm.atomic_assign_expand_fenv to deal with exceptions issues) that 
would need factoring out in some way to be usable for non-C.  (Unless you 
want at least one of (a) explicit memory order or (b) non-C languages, 
just using compound assignment operators on _Atomic objects suffices.)

It's less clear if the built-in functions handling floating-point like 
that should be the existing __atomic_fetch_* (cf. bug 64843 discussing how 
__atomic_fetch_add does not do the multiplication by element size for 
pointer types, and, if pointer types are to be supported for 
atomic_fetch_add,  might be a better place to deal with that 
adjustment than making the built-in function handle it).

-- 
Joseph S. Myers
jos...@codesourcery.com