Re: replacing the backwards threader and more

[Aldy Hernandez via Gcc]

On 6/30/21 12:16 AM, Martin Sebor wrote:

On 6/28/21 6:32 PM, Aldy Hernandez wrote:
I had changed my approach to passing -Wno-free-nonheap-object in the 
Makefile. Can you try disabling the Makefile bit and bootstrapping, 
cause that was still failing.


I see.  I just tested it and my patch does let the existing #pragma
suppress the warning.  I just pinged the core patch yesterday so
once it and the rest of the series gets approved there will be no
need for the Makefile workaround.


Thanks for taking care of this.
Aldy

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

On 6/29/21 12:50 PM, Richard Earnshaw wrote:



On 29/06/2021 11:09, 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



In the HTML version of the gcc manual the sidebar has an "Option index" link but no link 
to the general index.  When you follow that link the page contents is just a link to the 
"index" where everything is all lumped together.

If we can't have separate indexes for options and general entries, I think it 
would make more sense for the Option index link to be removed entirely.


Fully agree with you. Thanks for the feedback and I've changed that to the 
standard Sphinx section,
see e.g. https://splichal.eu/gccsphinx-final/html/gcc/indices-and-tables.html

Martin



R.

Re: replacing the backwards threader and more

[Martin Sebor via Gcc]

On 6/28/21 6:32 PM, Aldy Hernandez wrote:
I had changed my approach to passing -Wno-free-nonheap-object in the 
Makefile. Can you try disabling the Makefile bit and bootstrapping, 
cause that was still failing.


I see.  I just tested it and my patch does let the existing #pragma
suppress the warning.  I just pinged the core patch yesterday so
once it and the rest of the series gets approved there will be no
need for the Makefile workaround.

Martin



Thanks.
Aldy

On Tue, Jun 29, 2021, 00:29 Martin Sebor > wrote:


On 6/28/21 12:17 AM, Aldy Hernandez wrote:
 >
 >
 > On 6/25/21 7:19 PM, Martin Sebor wrote:
 >> On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote:
 >>> Hi folks.
 >>>
 >>> I'm done with benchmarking, testing and cleanups, so I'd like
to post
 >>> my patchset for review.  However, before doing so, I'd like to
 >>> address a handful of meta-issues that may affect how I post these
 >>> patches.
 >>>
 >>> Trapping on differences
 >>> ===
 >>>
 >>> Originally I wanted to contribute verification code that would
trap
 >>> if the legacy code threaded any edges the new code couldn't (to be
 >>> removed after a week).  However, after having tested on various
 >>> architectures and only running once into a missing thread, I'm
 >>> leaning towards omitting the verification code, since it's
fragile,
 >>> time consuming, and quite hacky.
 >>>
 >>> For the record, I have tested on x86-64, aarch64, ppc64 and
ppc64le.
 >>> There is only one case, across bootstrap and regression tests
where
 >>> the verification code is ever tripped (discussed below).
 >>>
 >>> Performance
 >>> ===
 >>>
 >>> I re-ran benchmarks as per our callgrind suite, and the penalty
with
 >>> the current pipeline is 1.55% of overall compilation time.  As is
 >>> being discussed, we should be able to mitigate this
significantly by
 >>> removing other threading passes.
 >>>
 >>> Failing testcases
 >>> =
 >>>
 >>> I have yet to run into incorrect code being generated, but I
have had
 >>> to tweak a considerable number of tests.  I have verified every
 >>> single discrepancy and documented my changes in the testsuite
when it
 >>> merited doing so.  However, there are a couple tests that trigger
 >>> regressions and I'd like to ask for guidance on how to address
them.
 >>>
 >>> 1. gcc.c-torture/compile/pr83510.c
 >>>
 >>> I would like to XFAIL this.
 >>>
 >>> What happens here is that thread1 threads a switch statement such
 >>> that the various cases have been split into different independent
 >>> blocks. One of these blocks exposes an arr[i_27] access which is
 >>> later propagated by VRP to be arr[10].  This is an invalid access,
 >>> but the array bounds code doesn't know it is an unreachable path.
 >>
 >> The test has a bunch of loops that iterate over the 10 array
elements.
 >> There have been bug reports about loop unrolling causing false
positives
 >> -Warray-bounds (e.g., PR 92539, 92110, or 86341) so this could be
 >> the same issue.
 >>
 >>>
 >>> However, it is not until dom2 that we "know" that the value of the
 >>> switch index is such that the path to arr[10] is unreachable.  For
 >>> that matter, it is not until dom3 that we remove the
unreachable path.
 >>
 >> If you do XFAIL it can you please isolate a small test case and open
 >> a bug and make it a -Warray-bounds blocker?
 >
 > Will do.
 >
 >>
 >>>
 >>> 2. -Wfree-nonheap-object
 >>>
 >>> This warning is triggered while cleaning up an auto_vec.  I see
that
 >>> the va_heap::release() inline is wrapped with a pragma ignore
 >>> "-Wfree-nonheap-object", but this is not sufficient because jump
 >>> threading may alter uses in such a way that
may_emit_free_warning()
 >>> will warn on the *inlined* location, thus bypassing the pragma.
 >>>
 >>> I worked around this with a mere:
 >>>
 >>>  > @@ -13839,6 +13839,7 @@ maybe_emit_free_warning (tree exp)
     location_t loc = tree_inlined_location (exp);
  +  loc = EXPR_LOCATION (exp);
 >>>
 >>> but this causes a ton of Wfree-nonheap* tests to fail.  I think
 >>> someone more knowledgeable should address this (msebor??).
 >>
 >> This sounds like the same problem as PR 98871.  Does the patch below
 >> fix it?
 >> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572515.html
 >> If so, I suggest getting that patch in first to avoid testsuite
 >> failures.  If it doesn't fix it I'll look into it before you commit
 >> your changes.
 >
 > The latest patch in the above thread does not apply.  Do you have
a more
 > recent patc

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

[David Malcolm via Gcc]

On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote:
> AIM for today : 
> 
> - filter out the the nodes which already have an supergraph edge
> representing the call to avoid creating another edge for call
> - create enode for destination
> - create eedge representing the call itself
> 
> —
> 
> PROGRESS :
> 
> - in order to filter out only the relevant edges, I simply used the
> fact that the edge that we care about will not have any call_graph
> edge associated with it. ( means “sedge->get_any_callgraph_edge()"
> would return NULL )
> 
> - I was also successfully able to create the enode and connect it
> with an eedge representing the call and was able to see it calling
> the correct function on some examples. :)
> 
> - But the problem now is returning from the function, which turned
> out bigger then I though it was. 
> 
> - In order to tackle this problem, I first tried to update the
> call_string with the call, but the only way to push a call to the
> string I found was via “call_string::push_call()” function which
> finds the return_superedge from the cgraph_edge representing the
> return call ( which we don’t have )
> 
> so I decided to make an overload of "call_string::push_call()” which
> directly takes a return_superedge and push it the underlying vector
> of edges instead of taking it from the calling edge. It looks
> something like this :-
> 
> File:  {$SCR_DIR}/gcc/analyzer/call-string.cc
> 
> 158: void
> 159: call_string::push_call(const return_superedge *return_sedge)
> 160: {
> 161:   gcc_assert (return_sedge);
> 162:   m_return_edges.safe_push (return_sedge);
> 163: }

Looks reasonable.

> 
> I also created a temporary return_superedge ( as we now have the
> source and destination ), and try to update the call_string with it
> just to find out that call_string is private to program_point. 

I confess I'm having a little difficulty visualizing what the superedge
looks like with this new edge.


FWIW you can use the accessor:
  program_point::get_call_string ()
to get it in const form:
  const call_string &get_call_string () const { return m_call_string; }

but it sounds like you're trying to change things.



The purpose of class call_string is to track the stack of call sites,
so that when we return from a function, we return to the correct call
site.

I wonder if class call_string could be updated so that rather than
capturing a vec of superedges:
  auto_vec m_return_edges;
it captures a vec of gcall *?

Then you wouldn't need a superedge ahead of time for the return from
the call.

I'm not sure if that would work, but that might be another approach you
could try, and might be simplest.  I'm not sure.

I *think* we only use the return_superedge within
program_point::on_edge, comparing against the successor edge, but that
code could be rewritten to look at which gcall * is associated with the
edge.

(again, I'm not sure, but maybe it's simpler)


> So my plan for next day would be to create a custom function to the
> program_point class the update the call stack and return back to
> correct spot. 
> 
> If there is a better way of doing it then do let me know.
> 
> STATUS AT THE END OF THE DAY :- 
> 
> - filter out the the nodes which already have an supergraph edge
> representing the call ( Done )
> - create enode for destination ( Done )
> - create eedge representing the call itself ( Done ? )
> 
> —
> 
> P.S. it has been over a week since I sent a mail to
> overse...@gcc.gnu.org  regarding the
> ssh key incident and I haven’t got any response form them till now,
> does this usually take this long for them to respond ? or does this
> means I didn’t provide some information to them that I should have.
> Is there something else I can do regarding this problem ?

I'd try resending the email.

Hope this is helpful
Dave

Re: Using source-level annotations to help GCC detect buffer overflows

[David Brown]

On 29/06/2021 17:50, Martin Sebor wrote:
> On 6/29/21 6:27 AM, David Brown wrote:
>> On 28/06/2021 21:06, Martin Sebor via Gcc wrote:
>>> I wrote an article for the Red Hat Developer blog about how
>>> to annotate code to get the most out of GCC's access checking
>>> warnings like -Warray-bounds, -Wformat-overflow, and
>>> -Wstringop-overflow.  The article published last week:
>>>
>>> https://developers.redhat.com/articles/2021/06/25/use-source-level-annotations-help-gcc-detect-buffer-overflows
>>>
>>>
>>
>> Thanks for that write-up - and of course thank you to whoever
>> implemented these attributes!
>>
>> The caveat that the access attributes are lost when a function is
>> inlined is an important one.  As a user who appreciates all the checks I
>> can get, it is disappointing - but I assume there are good reasons for
>> that limitation.  I can merely hope that will change in future gcc
>> versions.
> 
> There's nothing the attribute could obviously attach to after a call
> has been inlined.  An extreme example is a function whose argument
> isn't used:
> 
>   __attribute__ ((access (write_only, 1, 2))) void
>   f (char *p, int n) { }
> 
> (The function might have a body in the original source that could
> be eliminated from the IL based on the values of other arguments.)

Could these attributes not be attached to the arguments when the
function is called, or the parameters when the function is expanded?
After all, in cases such as the "access" attribute it is not the
function as such that has the access hints, it is the parameters of the
function.

(I'm talking here based on absolutely no knowledge of how this is
implemented, but it's always possible that a different view, unbiased by
knowing the facts, can inspire new ideas.)

> 
> Calls to it that are not inlined will be checked but those that are
> won't be.  This could be improved by doing the checking also before
> inlining but at a cost of some false positives for code that's later
> determined to be unreachable.  I don't have a sense of how bad it
> might be so it's something to try.  This class of false positives
> could also be dealt with by queuing up the warnings (e.g., by
> emitting them into the IL via __builtin_warning) and issuing them
> only if they survive dead code elimination.  This is something I'd
> like to try to tackle for GCC 12.
> 

I fully appreciate that some checks can be easier earlier in the
process, others later.  It might even be helpful to do similar checks at
more than one stage, and combine the results.

>>
>> I believe it would make sense to add this information to the gcc manual
>> page for common function attributes.  There are quite a number of
>> attributes that are useful for static checking, such as
>> "warn_unused_result" and "nonnull".  Are these also dropped if the
>> function is inlined?
> 
> I agree the documentation could stand to be made clearer on this
> point.  In general, I think it would be helpful to give users
> more guidance about what to expect from attributes as well as
> warnings: which ones are purely lexical and which ones flow-
> sensitive and so inherently susceptible to false positives and
> negatives, and to what extent.

It could be difficult to quantify that kind of thing, but sometimes
guidance could be useful.  (There is already such information for some
warning flags, especially those that support multiple levels.)

Certainly since first reading about the "access" attributes, I have been
considering adding them to my current project.  I have also been mulling
around in my head possibilities of making variadic templates in C++ that
add access attributes in the right places for some kinds of pointers -
but now that I know the attributes will get dropped for inline
functions, and such templates would involve inline functions, there is
little point.  (Maybe I will still figure a neat way to do this for
external functions - it just won't be useful in as many places.)

> 
> Whether an attribute has an effect depends on the compilation stage
> where it's handled.  warn_unused_result is handled very early (well
> before inlining) so it always has the expected effect.  Attribute
> nonnull is handled both early (to catch the simple cases) and also
> later, after inlining, to benefit from some flow analysis, so its
> effect is lost if the function it attaches to is inlined.  Attribute
> access is handled very late and so it suffers from this problem
> even more.
> 

I suppose some attributes are not needed for inline functions, since the
compiler has the full function definition and can figure some things out
itself.  That would apply to "pure" and "const" functions, I expect.
And if you want a parameter to be non-null, it's possible to do a check
inside the function:

extern void __attribute__((error("Nonnull check failed")))
nonnull_check_failed(void);

#define nonnull(x) \
do { \
if (__builtin_constant_p(!(x))) { \
if (!(x)) nonnull_check_failed(); \
   

Re: [PATCH] Port GCC documentation to Sphinx

[Eli Zaretskii via Gcc]

> Date: Tue, 29 Jun 2021 19:57:11 +0300
> From: Eli Zaretskii via Gcc 
> Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, jos...@codesourcery.com
> 
> Or how about this:
> 
>   `Overall Options'
> 
>See Options Controlling the Kind of Output.
> 
>*note -c. *note -S. *note -E. *note -o. ‘`file'’
>*note -dumpbase. ‘`dumpbase'’ *note -dumpbase-ext.
>‘`auxdropsuf'’ *note -dumpdir. ‘`dumppfx'’ ‘-x’ ‘`language'’
>*note -v. *note -###. *note –help.‘[=`class'[,...]]’
>*note –target-help. *note –version. *note -pass-exit-codes
>. *note -pipe. *note -specs.‘=`file'’ *note -wrapper
>.‘@`file'’ *note -ffile-prefix-map.‘=`old'=`new'’ *note
>-fplugin.‘=`file'’ ‘-fplugin-arg-’‘`name'=`arg'’
>‘-fdump-ada-spec’‘[-`slim']’ *note -fada-spec-parent.‘=`unit'’
>*note -fdump-go-spec.‘=`file'’

I see that when I copied text into the mail, the "see" that Emacs
displays got replaced by "*note" (which is what actually appears in
the Info file).  So if you want to understand my references to the
ubiquitous "see", imagine that each "*note" is displayed as "see".

Apologies for any confusion.

Re: [PATCH] Port GCC documentation to Sphinx

[Eli Zaretskii via Gcc]

> From: Martin Liška 
> Date: Tue, 29 Jun 2021 12:09:23 +0200
> Cc: GCC Development , gcc-patc...@gcc.gnu.org
> 
> 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.

I'm an Info junkie, so I grabbed gcc.info from there and skimmed
through it.  Please allow me a few unsolicited comments:

1. It sounds like Sphinx is heavily biased towards HTML format, and as
   result uglifies the Info format?

For example, many cross-references (AFAIU introduced as part of
migration to Sphinx) make the text illegible in Emacs.  Example:

  This standard, in both its forms, is commonly known as `C89', or
  occasionally as `C90', from the dates of ratification.  To select this
  standard in GCC, use one of the options *note -ansi *note -std
  .‘=c90’ or *note -std.‘=iso9899:1990’; to obtain all the diagnostics
  required by the standard, you should also specify *note -pedantic.
  (or *note -pedantic-errors. if you want them to be errors rather
  than warnings).  See *note Options Controlling C Dialect.
  [...]
  An amendment to the 1990 standard was published in 1995.  This amendment
  added digraphs and ‘__STDC_VERSION__’ to the language, but otherwise
  concerned the library.  This amendment is commonly known as `AMD1'; the
  amended standard is sometimes known as `C94' or `C95'.  To select this
  standard in GCC, use the option *note -std.‘=iso9899:199409’ (with,
  as for other standard versions, *note -pedantic. to receive all
  required diagnostics).

Or how about this:

  `Overall Options'

   See Options Controlling the Kind of Output.

   *note -c. *note -S. *note -E. *note -o. ‘`file'’
   *note -dumpbase. ‘`dumpbase'’ *note -dumpbase-ext.
   ‘`auxdropsuf'’ *note -dumpdir. ‘`dumppfx'’ ‘-x’ ‘`language'’
   *note -v. *note -###. *note –help.‘[=`class'[,...]]’
   *note –target-help. *note –version. *note -pass-exit-codes
   . *note -pipe. *note -specs.‘=`file'’ *note -wrapper
   .‘@`file'’ *note -ffile-prefix-map.‘=`old'=`new'’ *note
   -fplugin.‘=`file'’ ‘-fplugin-arg-’‘`name'=`arg'’
   ‘-fdump-ada-spec’‘[-`slim']’ *note -fada-spec-parent.‘=`unit'’
   *note -fdump-go-spec.‘=`file'’

In the first line, the emphasis became quotes, which sounds sub-optimal.
In the second line, the hyperlink was lost.
And the rest is not really readable.

Compare this with the original:

  _Overall Options_
   *Note Options Controlling the Kind of Output.
-c  -S  -E  -o FILE  -x LANGUAGE
-v  -###  --help[=CLASS[,...]]  --target-help  --version
-pass-exit-codes  -pipe  -specs=FILE  -wrapper
@FILE  -ffile-prefix-map=OLD=NEW
-fplugin=FILE  -fplugin-arg-NAME=ARG
-fdump-ada-spec[-slim]  -fada-spec-parent=UNIT  -fdump-go-spec=FILE

(Admittedly, Emacs by default hides some of the text of a
cross-reference, but not hiding them in this case produces an even
less legible text.)

In general, it is a well-known rule that Texinfo documentation should
NOT use @ref{foo} as if @ref will disappear without a trace, leaving
just the hyperlink to 'foo'.  Looks like the rewritten manual uses
that a lot.

This "see" consistently gets in the way throughout the entire manual.
A few more examples:

   -- Option: -flocal-ivars

   Default option value for *note -fno-local-ivars.
   ...
   For example *note -std.‘=gnu90 -Wpedantic’ warns about C++ style
   ‘//’ comments, while *note -std.‘=gnu99 -Wpedantic’ does not.
   ...
   If this option is not provided but *note -Wabi.‘=`n'’ is, that
   version is used for compatibility aliases.
   ...
   Below *note -std.‘=c++20’, *note -fconcepts. enables
   support for the C++ Extensions for Concepts Technical
   Specification, ISO 19217 (2015).
   ...
  gcov [ *note -v. | *note –version. ] [ ‘-h’ | *note –help. ]


2. The translation of @var produces double-quoting in Info, here's an
   example:

  The usual way to run GCC is to run the executable called ‘gcc’, or
  ‘`machine'-gcc’ when cross-compiling, or ‘`machine'-gcc-`version'’ to
  run a specific version of GCC.

vs, the old

   The usual way to run GCC is to run the executable called 'gcc', or
  'MACHINE-gcc' when cross-compiling, or 'MACHINE-gcc-VERSION' to run a
  specific version of GCC.

I think the new variant is less readable and more confusing, because
it isn't clear whether the quotes are part of the text.  Here's an
extreme example:

  ‘@`file'’

   Read command-line options from ‘`file'’.  The options read are
   inserted in place of the original ‘@`file'’ option.  If ‘`file'’
   does not exist, or cannot be read, then the option will be treated
   literally, and not removed.


3. Some cross-references lost the hyperlinks:

  See option-index, for an index to GCC’s options.

  ("option-index" was a hyperlink

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

[Ankur Saini via Gcc]

AIM for today : 

- filter out the the nodes which already have an supergraph edge representing 
the call to avoid creating another edge for call
- create enode for destination
- create eedge representing the call itself

—

PROGRESS :

- in order to filter out only the relevant edges, I simply used the fact that 
the edge that we care about will not have any call_graph edge associated with 
it. ( means “sedge->get_any_callgraph_edge()" would return NULL )

- I was also successfully able to create the enode and connect it with an eedge 
representing the call and was able to see it calling the correct function on 
some examples. :)

- But the problem now is returning from the function, which turned out bigger 
then I though it was. 

- In order to tackle this problem, I first tried to update the call_string with 
the call, but the only way to push a call to the string I found was via 
“call_string::push_call()” function which finds the return_superedge from the 
cgraph_edge representing the return call ( which we don’t have )

so I decided to make an overload of "call_string::push_call()” which directly 
takes a return_superedge and push it the underlying vector of edges instead of 
taking it from the calling edge. It looks something like this :-

File:  {$SCR_DIR}/gcc/analyzer/call-string.cc 
158: void
159: call_string::push_call(const return_superedge *return_sedge)
160: {
161:   gcc_assert (return_sedge);
162:   m_return_edges.safe_push (return_sedge);
163: }

I also created a temporary return_superedge ( as we now have the source and 
destination ), and try to update the call_string with it just to find out that 
call_string is private to program_point. 

So my plan for next day would be to create a custom function to the 
program_point class the update the call stack and return back to correct spot. 

If there is a better way of doing it then do let me know.

STATUS AT THE END OF THE DAY :- 

- filter out the the nodes which already have an supergraph edge representing 
the call ( Done )
- create enode for destination ( Done )
- create eedge representing the call itself ( Done ? )

—

P.S. it has been over a week since I sent a mail to overse...@gcc.gnu.org 
 regarding the ssh key incident and I haven’t got 
any response form them till now, does this usually take this long for them to 
respond ? or does this means I didn’t provide some information to them that I 
should have. Is there something else I can do regarding this problem ?

Thank you
- Ankur

Re: GCC documentation: porting to Sphinx

[Arnaud Charlet]

> >In particular can you explain the motivation behind all the changes in the
> >gcc/ada/doc directory?
> 
> Sure:
> 1) All Sphinx manuals live in a directory where index page is called 
> index.rst. That's why
> I moved e.g. this: gcc/ada/doc/{gnat_rm.rst => gnat_rm/index.rst}
> 2) I moved latex_elements.py to ada_latex_elements.py as it clashes with 
> Sphinx global variable
> you modify in Sphinx config files
> 3) I created a shared Ada config (adabaseconf.py) that extends 
> doc/baseconf.py and sets what
> is shared in between 3 Ada manuals.
> 4) gnu_free_documentation_license.rst is taken from $root/doc/

OK, this is really lots of changes, if we could minimize these changes
that would be best (and sorry but posting a link to a tarball also doesn't
help reviews, it was actually better with a link to a git repo previously...
At least the Ada part itself shouldn't be too big in particular once
simplified so could be posted standalone).

Arno

Re: Using source-level annotations to help GCC detect buffer overflows

[Martin Sebor via Gcc]

On 6/29/21 6:27 AM, David Brown wrote:

On 28/06/2021 21:06, Martin Sebor via Gcc wrote:

I wrote an article for the Red Hat Developer blog about how
to annotate code to get the most out of GCC's access checking
warnings like -Warray-bounds, -Wformat-overflow, and
-Wstringop-overflow.  The article published last week:

https://developers.redhat.com/articles/2021/06/25/use-source-level-annotations-help-gcc-detect-buffer-overflows



Thanks for that write-up - and of course thank you to whoever
implemented these attributes!

The caveat that the access attributes are lost when a function is
inlined is an important one.  As a user who appreciates all the checks I
can get, it is disappointing - but I assume there are good reasons for
that limitation.  I can merely hope that will change in future gcc versions.


There's nothing the attribute could obviously attach to after a call
has been inlined.  An extreme example is a function whose argument
isn't used:

  __attribute__ ((access (write_only, 1, 2))) void
  f (char *p, int n) { }

(The function might have a body in the original source that could
be eliminated from the IL based on the values of other arguments.)

Calls to it that are not inlined will be checked but those that are
won't be.  This could be improved by doing the checking also before
inlining but at a cost of some false positives for code that's later
determined to be unreachable.  I don't have a sense of how bad it
might be so it's something to try.  This class of false positives
could also be dealt with by queuing up the warnings (e.g., by
emitting them into the IL via __builtin_warning) and issuing them
only if they survive dead code elimination.  This is something I'd
like to try to tackle for GCC 12.



I believe it would make sense to add this information to the gcc manual
page for common function attributes.  There are quite a number of
attributes that are useful for static checking, such as
"warn_unused_result" and "nonnull".  Are these also dropped if the
function is inlined?


I agree the documentation could stand to be made clearer on this
point.  In general, I think it would be helpful to give users
more guidance about what to expect from attributes as well as
warnings: which ones are purely lexical and which ones flow-
sensitive and so inherently susceptible to false positives and
negatives, and to what extent.

Whether an attribute has an effect depends on the compilation stage
where it's handled.  warn_unused_result is handled very early (well
before inlining) so it always has the expected effect.  Attribute
nonnull is handled both early (to catch the simple cases) and also
later, after inlining, to benefit from some flow analysis, so its
effect is lost if the function it attaches to is inlined.  Attribute
access is handled very late and so it suffers from this problem
even more.

The new attribute malloc (to associate allocators with deallocators)
is also handled very late but it deals with the same problem by
disabling inlining.  This was done to avoid false positives, not
to prevent false negatives, but it works for both.  Disabling
inlining is obviously suboptimal and wouldn't be appropriate for
simple accessor functions but for memory allocation it seems like
an acceptable tradeoff.

The inlining problem is not unique to attributes that affect
warnings.  It impacts all function (and function type) attributes,
including those that affect optimization.  Those that specifically
change optimization options disable inlining to avoid meaningless
mismatches between options controlling the codegen of the caller
and those intended to control the codegen for the callee.

Martin

Re: Unique identifier across different partitions (LTO)

[Martin Liška]

Hi.


Has anyone had any experience doing something similar? I would be
interested in seeing similar examples and use cases.


You likely need something similar to what I need:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570953.html

Martin



Thanks!

Unique identifier across different partitions (LTO)

[Erick Ochoa via Gcc]

Hello,

I'm trying to generate unique identifiers for some trees at link time.
I understand that there are already some unique identifiers in
declarations (DECL_UID) and perhaps others. Do all trees have unique
identifiers or only declarations?

Alternatively, if they don't have unique identifiers, again, I am
trying to generate my own at link time. I originally was thinking
about just having a counter and incrementing it every time I add a
tree of interest to this data structure that I use to keep track of
trees. However, with the parallel LTO framework, this would mean that
identifiers will be duplicated across different partitions. Has anyone
done something similar where information across partitions needs to be
communicated?

What I was thinking of as an alternative to communicating this
information across partitions is to record the process id then use
this information to generate a unique identifier based on the counter
and the process id that is processing the partition. This derived
identifier would be generated during WPA time.

Has anyone had any experience doing something similar? I would be
interested in seeing similar examples and use cases.

Thanks!

Re: Using source-level annotations to help GCC detect buffer overflows

[David Brown]

On 28/06/2021 21:06, Martin Sebor via Gcc wrote:
> I wrote an article for the Red Hat Developer blog about how
> to annotate code to get the most out of GCC's access checking
> warnings like -Warray-bounds, -Wformat-overflow, and
> -Wstringop-overflow.  The article published last week:
> 
> https://developers.redhat.com/articles/2021/06/25/use-source-level-annotations-help-gcc-detect-buffer-overflows
> 

Thanks for that write-up - and of course thank you to whoever
implemented these attributes!

The caveat that the access attributes are lost when a function is
inlined is an important one.  As a user who appreciates all the checks I
can get, it is disappointing - but I assume there are good reasons for
that limitation.  I can merely hope that will change in future gcc versions.

I believe it would make sense to add this information to the gcc manual
page for common function attributes.  There are quite a number of
attributes that are useful for static checking, such as
"warn_unused_result" and "nonnull".  Are these also dropped if the
function is inlined?

Re: [PATCH] Port GCC documentation to Sphinx

[Richard Earnshaw via Gcc]

On 29/06/2021 11:09, 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



In the HTML version of the gcc manual the sidebar has an "Option index" 
link but no link to the general index.  When you follow that link the 
page contents is just a link to the "index" where everything is all 
lumped together.


If we can't have separate indexes for options and general entries, I 
think it would make more sense for the Option index link to be removed 
entirely.


R.

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

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