Re: GCC documentation: porting to Sphinx

[Martin Liška]

On 6/29/21 5:54 PM, Arnaud Charlet wrote:

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...


All right, ideally please pull my branch:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v4

which I force push once I rebase it. One can fetch the branch with:
$ git fetch origin refs/users/marxin/heads/sphinx-v4


At least the Ada part itself shouldn't be too big in particular once
simplified so could be posted standalone).


Sorry, but the patch is still 400 kB when using zstd -22. Actually, the change 
is very small
if you ignore renames of the 3 files:

 gcc/ada/gnat-style.texi|   954
 gcc/ada/gnat_rm.texi   | 29822
 gcc/ada/gnat_ugn.texi  | 29232

The only significant change is refactoring of the conf.py config.

Martin



Arno

How to get the global namespace (DECL_CONTEXT) at LTO during LGEN?

[Erick Ochoa via Gcc]

Hello,

I am wondering if there's a way to get the global namespace at LTO
during LGEN in each of the partitions being processed. I believe that
during parse time for c/c++ there is a global_namespace macro or
variable that can be used, but I don't think that it is possible to
use at link time.

Thanks!

Re: How to get the global namespace (DECL_CONTEXT) at LTO during LGEN?

[Richard Biener via Gcc]

On Wed, Jun 30, 2021 at 10:23 AM Erick Ochoa via Gcc  wrote:
>
> Hello,
>
> I am wondering if there's a way to get the global namespace at LTO
> during LGEN in each of the partitions being processed. I believe that
> during parse time for c/c++ there is a global_namespace macro or
> variable that can be used, but I don't think that it is possible to
> use at link time.

There can be many - walking DECL_CONTEXT will eventually
lead to a TRANSLATION_UNIT_DECL (but there can be some
with NULL, I don't remember if we force-associate ones not
associated with a TU by the frontends)

Richard.

> Thanks!

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

On 6/29/21 6:57 PM, Eli Zaretskii wrote:

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.


Hey!



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


I really welcome them!



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


Hopefully not :)



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.)


If I'm correct, it's exactly what's documented in Sphinx FAQ here:
https://www.sphinx-doc.org/en/master/faq.html#displaying-links

and there's a suggested Emacs code snippet that should help with links.
Does it help?



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

Re: [PATCH] Port GCC documentation to Sphinx

[Richard Earnshaw via Gcc]

On 30/06/2021 05:47, Martin Liška wrote:

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.





Thanks.  Given that the manual is nominally in American English, it 
might be better to use the term "indexes" rather than "indices".


https://grammarist.com/usage/indexes-indices/

R.

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

On 6/30/21 12:11 PM, Martin Liška wrote:

Seems correct to be, but it's likely not. Let me investigate that.


It's a real issue in Sphinx. I've just addressed that with:
https://github.com/sphinx-doc/sphinx/pull/9390

Cheers,
Martin

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

On 6/30/21 12:14 PM, Richard Earnshaw wrote:



On 30/06/2021 05:47, Martin Liška wrote:

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.





Thanks.  Given that the manual is nominally in American English, it might be better to use the term 
"indexes" rather than "indices".


Sure, fixed (while preserving the filename, we have multi copies of it).

Martin



https://grammarist.com/usage/indexes-indices/

R.

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

On 6/29/21 6:57 PM, Eli Zaretskii wrote:

5. There's some strange bug with symbols inside parentheses.  For
example:

   In GNU C and C++, you can use function attributes to specify certain
   function properties that may help the compiler optimize calls or check
   code more carefully for correctness.  For example, you can use
   attributes to specify that a function never returns ( ‘noreturn’ ),
   returns a value depending only on the values of its arguments ( ‘const’
   ), or has ‘printf’ -style arguments ( ‘format’ ).

See the extra blanks inside parens?  The old format was nicer:

   In GNU C and C++, you can use function attributes to specify certain
   function properties that may help the compiler optimize calls or check
   code more carefully for correctness.  For example, you can use
   attributes to specify that a function never returns ('noreturn'),
   returns a value depending only on the values of its arguments ('const'),
   or has 'printf'-style arguments ('format').


This issues is resolved now. Good point!

Martin

[RISCV] Call for topics: RISC-V GNU Toolchain Biweekly Sync-up call (July 1, 2021)

[吴伟]

Hi all,

We may skip tomorrow's RISC-V GNU Biweekly meeting, for not so many
topics were collected. Please reply this email if you have several
topics to discuss, otherwise I'd like to skip tomorrow's meeting.

-- 
Best wishes,
Wei Wu (吴伟)

Re: [PATCH] Port GCC documentation to Sphinx

[Eli Zaretskii via Gcc]

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška 
> Date: Wed, 30 Jun 2021 12:11:03 +0200
> 
> > (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.)
> 
> If I'm correct, it's exactly what's documented in Sphinx FAQ here:
> https://www.sphinx-doc.org/en/master/faq.html#displaying-links
> 
> and there's a suggested Emacs code snippet that should help with links.
> Does it help?

It helps some, but not all of the issues disappear.  For example,
stuff like this is still hard to read:

  To select this standard in GCC, use one of the options -ansi
 -
  -std.‘=c90’ or -std.‘=iso9899:1990’
     

The quotes around the option values don't help.

Also, using the method proposed by Sphinx FAQ would need a change in
Emacs, which will take time to propagate.  So my suggestion is to
minimize the use of such "inline" hyperlinks.

> >‘@`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.
> 
> I can confirm that, so e.g.
> Show :samp:`Samp with a {variable}.`
> 
> is transformed into:
> Show @code{Samp with a @emph{variable}.}
> 
> Default info formatting is selected as:
> 
> @definfoenclose strong,`,'
> @definfoenclose emph,`,'
> 
> We can adjust 'emph' formatting to nil, what do you think?

Something like that, yes.  But the problem is: how will you format it
instead?  The known alternatives, _foo_ and *foo* both use punctuation
characters, which will get in the way similarly to the quotes.  Can
you format those in caps, like makeinfo does?

> > 4. Menus lost the short descriptions of the sub-sections.  Example:
> > 
> >* Designated Initializers
> >* Case Ranges
> >* Cast to a Union Type
> >* Mixed Declarations, Labels and Code
> >* Declaring Attributes of Functions
> > 
> > vs
> > 
> >* Designated Inits::Labeling elements of initializers.
> >* Case Ranges:: 'case 1 ... 9' and such.
> >* Cast to Union::   Casting to union type from any member of the 
> > union.
> >* Mixed Declarations::  Mixing declarations and code.
> >* Function Attributes:: Declaring that functions have no side effects,
> >   or that they can never return.
> > 
> > Looks like some bug to me.
> > 
> > Note also that nodes are now called by the same name as the section,
> > which means node names generally got much longer.  Is that really a
> > good idea?
> 
> Well, I intentionally removed these and used simple TOC tree links
> which take display text for a section title.

I would suggest to discuss these decisions first, perhaps on the
Texinfo mailing list?  I'm accustomed to these short descriptions, but
I'm not sure how important they are for others.

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

On 6/29/21 6:57 PM, Eli Zaretskii wrote:

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.


For this one, I've just created the following pull request:
https://github.com/sphinx-doc/sphinx/pull/9391

Cheers,
Martin

Re: [PATCH] Port GCC documentation to Sphinx

[Eli Zaretskii via Gcc]

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška 
> Date: Wed, 30 Jun 2021 15:28:40 +0200
> 
> >‘@`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.
> 
> For this one, I've just created the following pull request:
> https://github.com/sphinx-doc/sphinx/pull/9391

Thanks, but does that mean @var will no longer stand out in the
produced Info format?  That'd be sub-optimal, I think, because a clear
reference to a meta-syntactic variable will be lost.

Re: [PATCH] Port GCC documentation to Sphinx

[Martin Liška]

On 6/30/21 3:38 PM, Eli Zaretskii wrote:

Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
From: Martin Liška 
Date: Wed, 30 Jun 2021 15:28:40 +0200


‘@`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.


For this one, I've just created the following pull request:
https://github.com/sphinx-doc/sphinx/pull/9391


Thanks, but does that mean @var will no longer stand out in the
produced Info format?  That'd be sub-optimal, I think, because a clear
reference to a meta-syntactic variable will be lost.


Yes. An alternative approach for:
Show :samp:`Samp with a {variable}.`

can be using @var{variable}, resulting with the following info output:
Show ‘Samp with a VARIABLE.’

Does it seem reasonable?
Thanks,
Martin

Are DECL_UIDs for the same across partitions during LGEN?

[Erick Ochoa via Gcc]

Hi,

I am still working on understanding the LTO framework and how the
gimple representation works across multiple partitions. I found myself
printing all global variables and printing their DECL_UID. I noticed
that for some variables, their DECL_UIDs were different across
different partitions. That is, a single global variable has different
DECL_UIDs in different partitions. Is this the correct behaviour? My
understanding of DECL_UID is that for every declaration there is a
unique identifier, but is this not the case during LTO?

I am building a transformation on top of releases/gcc-11, maybe newer
commits address this, but I haven't seen a discussion in this mailing
list. Perhaps in patches, but I don't follow that mailing list too
closely.

Thanks, any help is appreciated!

Re: [RISCV] Call for topics: RISC-V GNU Toolchain Biweekly Sync-up call (July 1, 2021)

[吴伟]

Hi all,

Agenda:
1. Relax the ISA string order checking for -march
 - https://github.com/riscv/riscv-toolchain-conventions/pull/14Zfinx ABI
 - https://github.com/riscv/riscv-elf-psabi-doc/pull/189Mapping symbol
 - https://sourceware.org/pipermail/binutils/2021-May/116803.htmlRFC:
New attribute for reserved register
 - Initial demand comes from overlay ABI, but it seems could be
generalized for more general purpose.
2. Status update for Unratified Specs
3. Free Discussion.

Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting.

Topic: RISC-V GNU Toolchian Biweekly Sync-up
Time: Jul 1, 2021 11:00 PM Singapore

Please download and import the following iCalendar (.ics) files to
your calendar system.
Weekly: 
https://zoom.com.cn/meeting/tZ0ufuqurjsjH9XTthkNg3MffX-QsRBuVBET/ics?icsToken=98tyKuGhrTIpHNSVuRyGRpx5A4r4b-7ziGJEgvplqAvtCA5UMS7wMNoPA6FNMs3m

Join Zoom Meeting
https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09

Meeting ID: 893 9360 0951
Passcode: 899662


On Wed, Jun 30, 2021 at 8:48 PM Wei Wu (吴伟)  wrote:
>
> Hi all,
>
> We may skip tomorrow's RISC-V GNU Biweekly meeting, for not so many
> topics were collected. Please reply this email if you have several
> topics to discuss, otherwise I'd like to skip tomorrow's meeting.
>
> --
> Best wishes,
> Wei Wu (吴伟)



--
Best wishes,
Wei Wu (吴伟)

Re: Are DECL_UIDs for the same across partitions during LGEN?

[Richard Biener via Gcc]

On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc  
wrote:
>Hi,
>
>I am still working on understanding the LTO framework and how the
>gimple representation works across multiple partitions. I found myself
>printing all global variables and printing their DECL_UID. I noticed
>that for some variables, their DECL_UIDs were different across
>different partitions. That is, a single global variable has different
>DECL_UIDs in different partitions. Is this the correct behaviour? 

Yes. 

My
>understanding of DECL_UID is that for every declaration there is a
>unique identifier, but is this not the case during LTO?

It's also true for WPA and LTrans a variables UID is just not the same in all 
of them because there's no way to ensure that. 

>I am building a transformation on top of releases/gcc-11, maybe newer
>commits address this, but I haven't seen a discussion in this mailing
>list. Perhaps in patches, but I don't follow that mailing list too
>closely.
>
>Thanks, any help is appreciated!

Re: [PATCH] Port GCC documentation to Sphinx

[Eli Zaretskii via Gcc]

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška 
> Date: Wed, 30 Jun 2021 16:04:32 +0200
> 
> > Thanks, but does that mean @var will no longer stand out in the
> > produced Info format?  That'd be sub-optimal, I think, because a clear
> > reference to a meta-syntactic variable will be lost.
> 
> Yes. An alternative approach for:
> Show :samp:`Samp with a {variable}.`
> 
> can be using @var{variable}, resulting with the following info output:
> Show ‘Samp with a VARIABLE.’
> 
> Does it seem reasonable?

Yes, the latter sounds reasonable.

Thanks.

Re: Are DECL_UIDs for the same across partitions during LGEN?

[Erick Ochoa via Gcc]

On Wed, 30 Jun 2021 at 17:06, Richard Biener  wrote:
>
> On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc  
> wrote:
> >Hi,
> >
> >I am still working on understanding the LTO framework and how the
> >gimple representation works across multiple partitions. I found myself
> >printing all global variables and printing their DECL_UID. I noticed
> >that for some variables, their DECL_UIDs were different across
> >different partitions. That is, a single global variable has different
> >DECL_UIDs in different partitions. Is this the correct behaviour?
>
> Yes.
>
> My
> >understanding of DECL_UID is that for every declaration there is a
> >unique identifier, but is this not the case during LTO?
>
> It's also true for WPA and LTrans a variables UID is just not the same in all 
> of them because there's no way to ensure that.
>

So how would I be able to say that two different declarations are the
same variable?

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

[Martin Sebor via Gcc]

On 6/29/21 12:31 PM, David Brown wrote:

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.)


Attaching these attributes to function parameters is an interesting
idea that might be worth exploring.  We've talked about letting
attribute access apply to variables for other reasons (detecting
attempts to modify immutable objects, as I mention in the article).
so your suggestion would be in line with that.  Associating two
variables that aren't parameters might be tricky.





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.)


Unfortunately, with extensive inlining and templates, C++ support
for these attributes is less robust than it ideally would be.
Improving it is on my to do list.


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

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

[David Malcolm via Gcc]

On Wed, 2021-06-30 at 21:39 +0530, Ankur Saini wrote:
> 
> 
> > On 30-Jun-2021, at 1:23 AM, David Malcolm 
> > wrote:
> > 
> > On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote:
> > 

[...]

> > > P.S. it has been over a week since I sent a mail to    
> > > overse...@gcc.gnu.org   > > 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.
> 
> ok I would be resending the mail again.
> Also should I cc that mail to you also ( similar to how they expect
> us to cc the sponsor at the time of creation of a new account ) ?

Yes please; that's a good idea

Dave
> 

Re: Are DECL_UIDs for the same across partitions during LGEN?

[Richard Biener via Gcc]

On June 30, 2021 6:28:29 PM GMT+02:00, Erick Ochoa  wrote:
>On Wed, 30 Jun 2021 at 17:06, Richard Biener
> wrote:
>>
>> On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc
> wrote:
>> >Hi,
>> >
>> >I am still working on understanding the LTO framework and how the
>> >gimple representation works across multiple partitions. I found
>myself
>> >printing all global variables and printing their DECL_UID. I noticed
>> >that for some variables, their DECL_UIDs were different across
>> >different partitions. That is, a single global variable has
>different
>> >DECL_UIDs in different partitions. Is this the correct behaviour?
>>
>> Yes.
>>
>> My
>> >understanding of DECL_UID is that for every declaration there is a
>> >unique identifier, but is this not the case during LTO?
>>
>> It's also true for WPA and LTrans a variables UID is just not the
>same in all of them because there's no way to ensure that.
>>
>
>So how would I be able to say that two different declarations are the
>same variable?

By looking at the associated varpool node. 

Richard. 

Re: [RISCV] Call for topics: RISC-V GNU Toolchain Biweekly Sync-up call (July 1, 2021)

[吴伟]

Hi all,

I've just noticed that the meeting time conflicted with the monthly
meeting of the software standing committee of RISC-V International.
So I'd like to skip today's meeting. The next meeting time is July 15.

Sorry for the inconvenience.

On Wed, Jun 30, 2021 at 10:52 PM Wei Wu (吴伟)  wrote:
>
> Hi all,
>
> Agenda:
> 1. Relax the ISA string order checking for -march
>  - https://github.com/riscv/riscv-toolchain-conventions/pull/14Zfinx ABI
>  - https://github.com/riscv/riscv-elf-psabi-doc/pull/189Mapping symbol
>  - https://sourceware.org/pipermail/binutils/2021-May/116803.htmlRFC:
> New attribute for reserved register
>  - Initial demand comes from overlay ABI, but it seems could be
> generalized for more general purpose.
> 2. Status update for Unratified Specs
> 3. Free Discussion.
>
> Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting.
>
> Topic: RISC-V GNU Toolchian Biweekly Sync-up
> Time: Jul 1, 2021 11:00 PM Singapore
>
> Please download and import the following iCalendar (.ics) files to
> your calendar system.
> Weekly: 
> https://zoom.com.cn/meeting/tZ0ufuqurjsjH9XTthkNg3MffX-QsRBuVBET/ics?icsToken=98tyKuGhrTIpHNSVuRyGRpx5A4r4b-7ziGJEgvplqAvtCA5UMS7wMNoPA6FNMs3m
>
> Join Zoom Meeting
> https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09
>
> Meeting ID: 893 9360 0951
> Passcode: 899662
>
>
> On Wed, Jun 30, 2021 at 8:48 PM Wei Wu (吴伟)  wrote:
> >
> > Hi all,
> >
> > We may skip tomorrow's RISC-V GNU Biweekly meeting, for not so many
> > topics were collected. Please reply this email if you have several
> > topics to discuss, otherwise I'd like to skip tomorrow's meeting.
> >
> > --
> > Best wishes,
> > Wei Wu (吴伟)
>
>
>
> --
> Best wishes,
> Wei Wu (吴伟)



-- 
Best wishes,
Wei Wu (吴伟)

Re: Update to GCC copyright assignment policy

[Bradley M. Kuhn]

As most of you are probably aware, glibc is also discussing whether or not
to remove the copyright assignment mandate to the FSF.  I have posted a
comment there regarding that, now available at:
   https://sourceware.org/pipermail/libc-alpha/2021-June/128303.html
… which is supplemented by a longer essay that I published here:
   https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/

I believe there are many complex issues related to the issue of where
copyrights for Free Software projects like GCC go, and while I've written
quite a lot of detail there, I think some of what I've written may be useful
as GCC considers how to build long-term robust plans to assure that the
copyleft of GCC is upheld for the long-term.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy

Become a Conservancy Supporter today: https://sfconservancy.org/supporter