Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Thu, 10 Jun 2021 at 18:06, Martin Sebor  wrote:
>
> On 6/10/21 9:56 AM, Jonathan Wakely wrote:
> > On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote:
> >>
> >> On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote:
> >>> On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek  wrote:
> 
>  On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote:
> > On 10/06/21 10:44 +0100, Jonathan Wakely wrote:
> >>> Quite interesting idea! Are you willing to prepare a patch for it?
> >>
> >> This works.
> >
> > And this works better, because it checks the PR in the title matches
> > one in the changelog.
> >
> > I'll get something added to the tests and prep this for commit.
> 
>  Note, some commits fix more than one PR.  Sometimes the subject lists
>  just one of them and the ChangeLog several, at other times people mention
>  [PRnn, PRnn] etc. in the subject.
>  I think checking that at least one changeLog PR line matches at least 
>  one PR
>  in the subject would be good enough.
> 
>  Your regex will not match [PR123456, PR123457] in subject, perhaps ok
> >>>
> >>> Yeah, that wouldn't get matched, so no checks would be done for the
> >>> changelog body. Not ideal, but better than what we have no where
> >>> nothing is checked at all.
> >>>
>  initially, and if I read it will will be happy if at least one line 
>  matches
>  it.
> >>>
> >>> Yes, if the summary line has a single PR number, it must be present in
> >>> the changelog body. Other PR numbers can also be in the body, and they
> >>> aren't checked.
> >>>
> >>> But I've hit an issue trying to test it, because the testcases in
> >>> contrib/gcc-changelog/test_patches.txt are in the form of emails, and
> >>> the Subject: line from the emails is not passed to the GitInfo
> >>> constructor, so isn't part of the message that gets checked.
> >>>
> >>> Martin, Shouldn't the GitEmail class extract the Subject: from the
> >>> email header and use that as the first line passed to the GitInfo
> >>> object?
> >>>
> >>
> >> I'm a little lost as to what's being changed,
> >
> > Nothing is being changed.
>
> The script is being changed and Tobias' proposal that I understand
> is being discussed is:
>
>  >> One options would be to require a 'PR /' line if there is
>  >> 'PRn+' in the commit title, rejecting the commit otherwise.
>
> That sounds like a new requirement.  I want to understand what that
> will mean for me.

It's what the policies already recommend. It would mean you cannot say
"[PR1234]" in the first line of your git commit if you don't list a PR
in the changelog. Why would that affect you? Why would you be doing
that anyway? It was always wrong.

> >
> > If your patch is related to a bug, you're supposed to say so:
> > https://gcc.gnu.org/codingconventions.html#ChangeLogs
> >
> > And you're also supposed to put a [PR] tag in the email subject
> > line (which best practices say should also be the Subject: of the
> > email you send to gcc-patches):
> > https://gcc.gnu.org/contribute.html#patches
> >
> > The patches being proposed verify that if you put [PR] at the end
> > of the subject line, that you also put "PR component/" in the
> > changelog part. Because if you didn't, something is wrong and you're
> > failing to follow the existing policy (why would you put a [PR]
> > tag in the subject if it's not related to that PR, and if it is
> > related, why are you not putting it in the changelog part?)
>
> By "the subject line" are you referring to what the ChangeLog calls
> $git_description, and, AFAICS, consists of multiple lines?  (Based
> on the Example patch on the conventions page.  In that example,
> the PR87763 reference is in the middle of line 3.)


No, I mean the first line of the $git_description, which would also be

Please read https://chris.beams.io/posts/git-commit/ for git log best
practices. If you follow that, your git description has a single line
summary (the subject), followed by a blank line, followed by zero or
more lines of text.

The subject is the first line. Which also makes an excellent email
Subject: when you send the patch.

>
> I find this confusing.  Either we're talking about the Subject line
> of the email I send to gcc-patches with the patch or we're talking
> about the Git description ($git_description).  If they're supposed
> to be the same the ChangeLog convention should say so, and
> the Example patch should be changed to show that.

Yes, which is what I'm planning to do to the contribute.html and
codingconventions.html docs. You are complaining about exactly the
problems I'm pointing out and planning to fix.

We currently describe a useful and rich format for patch emails, but
allow any old garbage in the actual commit message. This is stupid. We
should describe and strongly recommend a useful and rich format for
the commit message itself. Then turning that into a useful email is
utterly trivial (you just

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Thu, 10 Jun 2021 at 22:16, Martin Sebor wrote:
> I don't see why the script users should be subjected to this tedium
> when it can be done in the script itself with (presumably) only
> a little more effort.  The proposed change is, IMO, a step in
> the wrong direction.

I don't see why "improve the mklog.py script to automatically follow
the policy" is in conflict with "enforce the policy".

If the script can be improved to do the right thing automatically when
you commit (it's not clear if it can be improved that way, but let's
say it can) then what's the problem with enforcing it when you push
the commit to the server? What are you being "subjected to"? If it's
automated, what is "this tedium"? You've already followed the policy,
why do you care if there are checks to make sure that everybody
follows the policy, including the people not using the script and
writing the entire commit msg by hand?

I'm not saying we are going to enforce every part of the policy
(because the policy isn't even clear right now), but if we wanted to
do it later, I don't understand your objection.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Fri, 11 Jun 2021 at 10:08, Jonathan Wakely wrote:
>
> On Thu, 10 Jun 2021 at 18:06, Martin Sebor  wrote:
> > By "the subject line" are you referring to what the ChangeLog calls
> > $git_description, and, AFAICS, consists of multiple lines?  (Based
> > on the Example patch on the conventions page.  In that example,
> > the PR87763 reference is in the middle of line 3.)
>
>
> No, I mean the first line of the $git_description, which would also be

Sorry, the end of that sentence got lost on my clipboard.

The first line of the $git_description would also be the Subject of
your email, if you follow established Git best practices (e.g. in the
kernel, GitHub and elsewhere). For further reading:

https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_commit_template
https://chris.beams.io/posts/git-commit/
https://reflectoring.io/meaningful-commit-messages/#formatting

This one suggests a lot more structure, which is partially in conflict
with GCC's own guidelines, but it agrees that the commit msg should
start with a single-line description:
https://www.conventionalcommits.org/en/v1.0.0/

If you're not already doing a brief "subject" line in your git
commits, you're Doing It Wrong!

This is why I want the docs to go into more detail on the content of
the $git_description part of the git commit msg, because then reusing
that subject as your email Subject: is a no-brainer. So if you're
confused whether I mean the (first line of the) $git_description or
the email Subject: you should ask yourself why you think there is any
distinction between the two :-)

And for the avoidance of doubt ...

> > Again, I'm not sure what exactly you mean by "the changelog" here.
> > Are you referring to the whole commit message or just to what
> > the conventions refer to as the ChangeLog entry?
>
> The latter.

When I say changelog, I mean the changelog, and when I say commit
message, I mean the whole git commit message. I don't say "changelog"
to mean the whole git commit message. I'm using the terminology of the
codingconventions.html page:
"ChangeLog entries are part of git commit messages and are
automatically put into a corresponding ChangeLog file."

Using "changelog" to mean the whole commit message would be confusing
and/or ambiguous.

Re: Lack of latest binutils in gcc 11 docker image

[Jonathan Wakely via Gcc]

> I was wondering where can we send a patch to add binutils (latest )
> to that docker hub image

Those images are maintained by Docker Inc. and nothing to do with the
GCC project:

https://docs.docker.com/docker-hub/official_images/

"All Official Images contain a User Feedback section in their
documentation which covers the details for that specific repository.
In most cases, the GitHub repository which contains the Dockerfiles
for an Official Repository also has an active issue tracker. General
feedback and support questions should be directed to #docker-library
on Freenode IRC."

Late SIMPLE_IPA_PASS, DECL_INITIAL and error mark nodes

[Erick Ochoa via Gcc]

Hi,

I am looking for a small clarification. I understand that during late
SIMPLE_IPA_PASSes some statically initialized global variables might
have error_mark_node trees in their DECL_INITIAL field.

I believe that I read something similar in the past about how to get
the tree expressions in these situations, and I believe it said one
had to stream in those symbols from the .gnu.lto_.decl section.

However, on the GCC Internals there is also the following mention: "If
the DECL_INITIAL is the error_mark_node, there is an initializer, but
it is given by an explicit statement later in the code; no bitwise
copy is required. " [0]

What (if any) is the correct way to get these expressions?

As a note, when running this pass as an IPA_PASS I am able to see the
DECL_INITIAL node of the variable of interest during LGEN.

Thanks!

[0] https://gcc.gnu.org/onlinedocs/gccint/Working-with-declarations.html

Re: Late SIMPLE_IPA_PASS, DECL_INITIAL and error mark nodes

[Richard Biener via Gcc]

On Fri, Jun 11, 2021 at 12:07 PM Erick Ochoa via Gcc  wrote:
>
> Hi,
>
> I am looking for a small clarification. I understand that during late
> SIMPLE_IPA_PASSes some statically initialized global variables might
> have error_mark_node trees in their DECL_INITIAL field.
>
> I believe that I read something similar in the past about how to get
> the tree expressions in these situations, and I believe it said one
> had to stream in those symbols from the .gnu.lto_.decl section.
>
> However, on the GCC Internals there is also the following mention: "If
> the DECL_INITIAL is the error_mark_node, there is an initializer, but
> it is given by an explicit statement later in the code; no bitwise
> copy is required. " [0]
>
> What (if any) is the correct way to get these expressions?

Use ctor_for_folding (decl) to access a known initializer.  error_mark_node
is returned when there is no known constant initializer, NULL for
zero-init and an actual value otherwise.

> As a note, when running this pass as an IPA_PASS I am able to see the
> DECL_INITIAL node of the variable of interest during LGEN.
>
> Thanks!
>
> [0] https://gcc.gnu.org/onlinedocs/gccint/Working-with-declarations.html

docs: Unification of "enabled by default at -O{,1}

[Martin Liška]

Hello.

First, note that -O is equal to -O1 :) I noticed we don't use it consistently
in documentation:

$ git grep 'at.*-O1}' | cat

gcc/ada/gnat_ugn.texi:pick it based on the optimization level: 1 for 
@code{-O1}, @code{-O2} or

gcc/ada/gnat_ugn.texi:The optimization level is at least @code{-O1}.

gcc/ada/gnat_ugn.texi:The optimization level is at least @code{-O1}.

gcc/doc/invoke.texi:Enabled at levels @option{-O1}, @option{-O2}, @option{-O3} 
and @option{-Os},

gcc/doc/invoke.texi:The default is @option{-fbranch-count-reg} at @option{-O1} 
and higher,

gcc/doc/invoke.texi:Enabled by default at @option{-O1} and higher.

gcc/doc/invoke.texi:at @option{-O1} and higher, except for @option{-Og}.

gcc/doc/invoke.texi:code.  This pass is enabled by default at @option{-O1} and 
higher,

gcc/doc/invoke.texi:enabled by default at @option{-O1} and higher, except for 
@option{-Og}.

gcc/doc/invoke.texi:early.  This flag is enabled by default at @option{-O1} and 
higher,

gcc/doc/invoke.texi:@option{-ftoplevel-reorder} is the default at @option{-O1} 
and higher, and

gcc/doc/invoke.texi:at level @option{-O1} and higher, except for @option{-Og}.


$ git grep 'at.*-O}' | cat

gcc/ada/gnat_ugn.texi:No optimization, the default setting if no @code{-O} 
appears

gcc/ada/gnat_ugn.texi:Normal optimization, the default if you specify @code{-O} 
without an

gcc/config/pa/pa-hpux.h:  "%{!mpa-risc-1-0:%{!march=1.0:%{static:-L/lib/pa1.1 
-L/usr/lib/pa1.1 }}}%{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{g*:-a 
archive} %{shared:-b}"

gcc/config/pa/pa64-hpux.h:   %{mhp-ld:+Accept TypeMismatch -z} 
%{mlinker-opt:-O}\

gcc/config/pa/pa64-hpux.h:   %{!mgnu-ld:+Accept TypeMismatch -z} 
%{mlinker-opt:-O}\

gcc/doc/invoke.texi:compiling with optimization (@option{-Os}, @option{-O}, 
@option{-O2},

gcc/doc/invoke.texi:set of optimizations may be enabled at each @option{-O} 
level than

gcc/doc/invoke.texi:@option{-O2} turns on all optimization flags specified by 
@option{-O}.  It

gcc/doc/invoke.texi:activated by @option{-O} options or are related to ones 
that are.  You

gcc/doc/invoke.texi:This option is enabled by default at optimization levels 
@option{-O},

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, 
@option{-Os}.

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3},

gcc/doc/invoke.texi:instructions to support this.  Enabled by default at 
@option{-O} and

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, 
@option{-Os}, but

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, 
@option{-Os}, but

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, 
@option{-Os},

gcc/doc/invoke.texi:at @option{-O} and higher.

gcc/doc/invoke.texi:at @option{-O} and higher.

gcc/doc/invoke.texi:This flag is enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:pass is enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:copy operations.  This flag is enabled by default at 
@option{-O} and

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:at @option{-O} and higher.

gcc/doc/invoke.texi:enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:default at @option{-O} and higher.

gcc/doc/invoke.texi:enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:flag is enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:is enabled by default at @option{-O} and higher.  It is not 
enabled

gcc/doc/invoke.texi:at @option{-O} and higher.

gcc/doc/invoke.texi:Enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:enabled by default at @option{-O} and higher.

gcc/doc/invoke.texi:calculations when possible.  This is enabled by default at 
@option{-O} and

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, 
@option{-Os}.

gcc/doc/invoke.texi:The default is @samp{simple} at levels @option{-O}, 
@option{-Os}, and

gcc/doc/invoke.texi:If you do not specify an optimization level option 
@option{-O} at

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, 
@option{-Os}.

gcc/doc/invoke.texi:Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, 
@option{-Os}.


Is the later (and more common variant) preferred?

Thanks,
Martin

Re: GCC documentation: porting to Sphinx

[Martin Liška]

On 6/10/21 6:49 PM, Joseph Myers wrote:

On Thu, 10 Jun 2021, Martin Liška wrote:


1) Can we organize the new documentation in $gccroot/doc folder
similarly to what I have in texi2rst-generated repo? Would be beneficial
as we can have a single Makefile and shared content will be in a same
depth to the individual manuals.


Where languages have their own manuals, I think it's more appropriate for
those to go under the language-specific directories.


So it will require the following folder structure:

$gccroot/gcc/doc/gcc - for GCC documentation
$gccroot/gcc/doc/gccint - for GCC internal documentation
$gccroot/gcc/doc/gfortran - for Fortran documentation
$gccroot/gcc/doc/gccgo - for GO documentation
...
$gccroot/doc/share - shared components
$gccroot/libgomp/doc - for libgomp documentation
...

Are you fine with that?



That doesn't stop the use of shared makefile code.  Make-lang.in is a
fragment included from gcc/Makefile.in ("-include $(LANG_MAKEFRAGS)").  I
certainly expect it should be possible to write GNU make code in
gcc/Makefile.in for building and installing manuals, such that
subdirectories only need to define a few variables describing what manuals
they have and everything else is handled by common code.



The Sphinx Makefile will be capable of e.g.
make html -C $gccroot/gcc/doc/gcc BUILDDIR=`pwd/put_it_somewhere`

and the only configure dependency will VERSION_PACKAGE and BUGURL which will
be provided in env:
https://github.com/marxin/texi2rst-generated/blob/6cfcb7b8ae6497d49ea23a38262dfa26854bdb40/sphinx/baseconf.py#L38-L39

Martin

Re: GCC documentation: porting to Sphinx

[Martin Liška]

On 6/11/21 1:48 AM, Martin Sebor wrote:

On 6/10/21 7:18 AM, Martin Liška wrote:

On 6/10/21 11:07 AM, Martin Liška wrote:

Doing that, one has 2 unique links, that would be needed for get_option_url 
function.
Plus, both :option:`-Wfoo` and :option:`-Wno-foo` references are going to work.


And I've actually did the transformation and one can see it e.g. here:
https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/options-to-request-or-suppress-warnings.html#cmdoption-Wprio-ctor-dtor 


I find the style you have below right now clearer than keeping both
options in the same heading and adding a Note explaining the default
etc.  I.e., this

   _
   -Wchar-subscripts

     Warn if an array subscript has type char. This is a common cause
     of error, as programmers often forget that this type is signed on
     some machines. This warning is enabled by -Wall.

   
   -Wno-char-subscripts

    Default option value for -Wchar-subscripts.


Yes, fully agree with you!

Thanks,
Martin



on this page right now:
https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/options-to-request-or-suppress-warnings.html#cmdoption-Wchar-subscripts

seems better than this:

   _
   -Wno-shift-overflow, -Wshift-overflow=n, -Wshift-overflow

     +--+
     | (!) Note |
     +---
     | Default value is -Wno-shift-overflow, -Wshift-overflow is    |
     | enabled by -Wall.    |
     +--+

     These options control warnings about left shift overflows.

and also better than the alternative with (non-default) after the option
in the heading.

https://splichal.eu/scripts/sphinx/demo/_build/html/#cmdoption-Wno-shift-overflow3

Martin




Martin

Question about PIC code and GOT

[vincent Dupaquis]

    Hello,

    I am doing PIC (Position Independant Code) code using the ARM 
compiler, and effectively try to avoid the creation of the GOT (Global 
Offset Table).


    I've got the feeling the GOT is not convinient and goes in opposite 
direction than the one we try to achieve with having PIC, at least this 
is the reason why I'm trying to avoid it.


    Any clue on the reason why it has been implemented that way ?

    I have got the feeling that its avoidable in all cases, even 
without going deep at assembly level.


    Regards,
        Vincent.

--

*Vincent Dupaquis*
Software security & Cryptography expert
06 24 58 17 05
/Europarc de Pichaury Bâtiment B8 1330 rue Guillibert Gautier de la 
Lauzière 13290 Aix-en-Provence/


www.trusted-objects.com 



OpenPGP_signature
Description: OpenPGP digital signature

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Joseph Myers]

On Fri, 11 Jun 2021, Jonathan Wakely via Gcc wrote:

> If you're not already doing a brief "subject" line in your git
> commits, you're Doing It Wrong!

If you don't have a subject line which is more than one word, and does not 
look like a ChangeLog header line, and which is followed by a blank line, 
the commit hooks will reject the commit when you try to push it to the GCC 
repository.  (The check for a blank line after the subject is a generic 
feature of the hooks, the checks for single-word subjects and those that 
look like ChangeLog headers are part of the local commit_checker hook.)

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

Re: GCC documentation: porting to Sphinx

[Joseph Myers]

On Fri, 11 Jun 2021, Martin Liška wrote:

> > Where languages have their own manuals, I think it's more appropriate for
> > those to go under the language-specific directories.
> 
> So it will require the following folder structure:
> 
> $gccroot/gcc/doc/gcc - for GCC documentation
> $gccroot/gcc/doc/gccint - for GCC internal documentation
> $gccroot/gcc/doc/gfortran - for Fortran documentation
> $gccroot/gcc/doc/gccgo - for GO documentation

I'm thinking of

$gccroot/gcc/fortran/doc
$gccroot/gcc/go/doc

(or subdirectories thereof if desired) for the Fortran and Go manuals, so 
they go alongside the front end sources.

> The Sphinx Makefile will be capable of e.g.

My concern with makefiles is what the main GCC build system does, with 
"make" run at the top level of the build tree and with the targets defined 
by the GNU Coding Standards, not with what happens if someone manually 
does make in a subdirectory of the source or build tree.

"make" at top level should build all the info manuals and man pages, as at 
present (if a suitable Sphinx version is installed), and "make install" 
should install them, in the same directories as at present.

"make html" at top level should build all the HTML manuals, and "make 
install-html" should install them.

"make pdf" and "make install-pdf" at top level should work likewise.

"make install-html" and "make install-pdf" should put things under 
$(DESTDIR)$(htmldir) and $(DESTDIR)$(pdfdir) as at present.

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

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Fri, 11 Jun 2021 at 16:45, Joseph Myers  wrote:
>
> On Fri, 11 Jun 2021, Jonathan Wakely via Gcc wrote:
>
> > If you're not already doing a brief "subject" line in your git
> > commits, you're Doing It Wrong!
>
> If you don't have a subject line which is more than one word, and does not
> look like a ChangeLog header line, and which is followed by a blank line,
> the commit hooks will reject the commit when you try to push it to the GCC
> repository.  (The check for a blank line after the subject is a generic
> feature of the hooks, the checks for single-word subjects and those that
> look like ChangeLog headers are part of the local commit_checker hook.)

Oh good! All the more reason to document that format in
codingconventions.html then.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/11/21 3:13 AM, Jonathan Wakely wrote:

On Thu, 10 Jun 2021 at 22:16, Martin Sebor wrote:

I don't see why the script users should be subjected to this tedium
when it can be done in the script itself with (presumably) only
a little more effort.  The proposed change is, IMO, a step in
the wrong direction.


I don't see why "improve the mklog.py script to automatically follow
the policy" is in conflict with "enforce the policy".

If the script can be improved to do the right thing automatically when
you commit (it's not clear if it can be improved that way, but let's
say it can) then what's the problem with enforcing it when you push
the commit to the server? What are you being "subjected to"? If it's
automated, what is "this tedium"? You've already followed the policy,
why do you care if there are checks to make sure that everybody
follows the policy, including the people not using the script and
writing the entire commit msg by hand?

I'm not saying we are going to enforce every part of the policy
(because the policy isn't even clear right now), but if we wanted to
do it later, I don't understand your objection.


My objection is to making our policies and tools more restrictive
than they need to be.  We shouldn't expect everyone to study whole
manuals just to figure out how to successfully commit a change (or
learn how to format it just the right way).  It should be easy.

Setting this discussion aside for a moment and using a different
example, the commit hook rejects commit messages that don't start
ChangeLog entries with tabs.  It also rejects commit messages that
don't list all the same test files as those changed by the commit
(and probably some others as well).  That's in my view unnecessary
when the hook could just replace the leading spaces with tabs and
automatically mention all the tests.

I see this proposal as heading in the same direction.  Rather than
making the script fix things up if we get them wrong it would reject
the commit, requiring the user to massage the ChangeLog by hand into
an unnecessarily rigid format.

Martin

PS I think I referred to mklog.py when I meant gcc-commit-mklog,
confusing the discussion and probably even myself.  Sorry about
that.  The mklog.py script is great.  It helps us avoid some of
these mistakes.  But the script isn't perfect and commit messages
for some more involved changes still need to be hand-edited.
That's when the mistakes usually creep back in.  But the fact
that we need a script to preformat a commit message for us in
the stringent format that makes the commit hook happy seems like
a pretty good indication that our policies and requirements are
too onerous for most of us to get all the details right.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jakub Jelinek via Gcc]

On Fri, Jun 11, 2021 at 11:02:52AM -0600, Martin Sebor wrote:
> My objection is to making our policies and tools more restrictive
> than they need to be.  We shouldn't expect everyone to study whole
> manuals just to figure out how to successfully commit a change (or
> learn how to format it just the right way).  It should be easy.

Following the policies isn't that hard, and the scripts when they
reject a commit also explain why it was rejected, so it is trivial
to
git commit --amend
it and git push again.

Jakub

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
> My objection is to making our policies and tools more restrictive
> than they need to be.  We shouldn't expect everyone to study whole
> manuals just to figure out how to successfully commit a change (or
> learn how to format it just the right way).  It should be easy.

I agree, to some extent. But consistency is also good. The conventions
for GNU ChangeLog formatting exist for a reason, and so do the
conventions for good Git commit messages.

> Setting this discussion aside for a moment and using a different
> example, the commit hook rejects commit messages that don't start
> ChangeLog entries with tabs.  It also rejects commit messages that
> don't list all the same test files as those changed by the commit
> (and probably some others as well).  That's in my view unnecessary
> when the hook could just replace the leading spaces with tabs and
> automatically mention all the tests.
>
> I see this proposal as heading in the same direction.  Rather than
> making the script fix things up if we get them wrong it would reject
> the commit, requiring the user to massage the ChangeLog by hand into
> an unnecessarily rigid format.

You cannot "fix things up" in a server-side receive hook, because
changing the commit message would alter the commit hash, which would
require the committer to do a rebase to proceed. That breaks the
expected behaviour and workflow of a git repo.

You can use the scripts on the client side to verify your commit
message before pushing, so you don't have to be surprised when the
server rejects it.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/11/21 11:32 AM, Jonathan Wakely wrote:

On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:

My objection is to making our policies and tools more restrictive
than they need to be.  We shouldn't expect everyone to study whole
manuals just to figure out how to successfully commit a change (or
learn how to format it just the right way).  It should be easy.


I agree, to some extent. But consistency is also good. The conventions
for GNU ChangeLog formatting exist for a reason, and so do the
conventions for good Git commit messages.


Setting this discussion aside for a moment and using a different
example, the commit hook rejects commit messages that don't start
ChangeLog entries with tabs.  It also rejects commit messages that
don't list all the same test files as those changed by the commit
(and probably some others as well).  That's in my view unnecessary
when the hook could just replace the leading spaces with tabs and
automatically mention all the tests.

I see this proposal as heading in the same direction.  Rather than
making the script fix things up if we get them wrong it would reject
the commit, requiring the user to massage the ChangeLog by hand into
an unnecessarily rigid format.


You cannot "fix things up" in a server-side receive hook, because
changing the commit message would alter the commit hash, which would
require the committer to do a rebase to proceed. That breaks the
expected behaviour and workflow of a git repo.

You can use the scripts on the client side to verify your commit
message before pushing, so you don't have to be surprised when the
server rejects it.


That sounds like a killer argument.  Do we have shared client-side
scripts that could fix things up for us, or are we each on our own
to write them?

Martin

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Fri, 11 Jun 2021 at 19:01, Martin Sebor wrote:
>
> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
> >> My objection is to making our policies and tools more restrictive
> >> than they need to be.  We shouldn't expect everyone to study whole
> >> manuals just to figure out how to successfully commit a change (or
> >> learn how to format it just the right way).  It should be easy.
> >
> > I agree, to some extent. But consistency is also good. The conventions
> > for GNU ChangeLog formatting exist for a reason, and so do the
> > conventions for good Git commit messages.
> >
> >> Setting this discussion aside for a moment and using a different
> >> example, the commit hook rejects commit messages that don't start
> >> ChangeLog entries with tabs.  It also rejects commit messages that
> >> don't list all the same test files as those changed by the commit
> >> (and probably some others as well).  That's in my view unnecessary
> >> when the hook could just replace the leading spaces with tabs and
> >> automatically mention all the tests.
> >>
> >> I see this proposal as heading in the same direction.  Rather than
> >> making the script fix things up if we get them wrong it would reject
> >> the commit, requiring the user to massage the ChangeLog by hand into
> >> an unnecessarily rigid format.
> >
> > You cannot "fix things up" in a server-side receive hook, because
> > changing the commit message would alter the commit hash, which would
> > require the committer to do a rebase to proceed. That breaks the
> > expected behaviour and workflow of a git repo.
> >
> > You can use the scripts on the client side to verify your commit
> > message before pushing, so you don't have to be surprised when the
> > server rejects it.
>
> That sounds like a killer argument.  Do we have shared client-side
> scripts that could fix things up for us, or are we each on our own
> to write them?

The scripts used in the server-side hooks are all based on what's
under contrib/gcc-changelog, e.g. the
contrib/gcc-changelog/git_check_com
mit.py script can be used in a client-side hook to run the same checks
as the server-side hook does when it receives a push.

If you want to write utilities to automate things on the client-side,
that's where they should go.

That's also where the implementations live for the gcc-verify and
gcc-commit-mklog aliases created by the
contrib/gcc-git-customization.sh script.

Re: GCC documentation: porting to Sphinx

[Koning, Paul via Gcc]

> On Jun 11, 2021, at 11:50 AM, Joseph Myers  wrote:
> 
> ...
> 
> "make" at top level should build all the info manuals and man pages, as at 
> present (if a suitable Sphinx version is installed), and "make install" 
> should install them, in the same directories as at present.
> 
> "make html" at top level should build all the HTML manuals, and "make 
> install-html" should install them.
> 
> "make pdf" and "make install-pdf" at top level should work likewise.
> 
> "make install-html" and "make install-pdf" should put things under 
> $(DESTDIR)$(htmldir) and $(DESTDIR)$(pdfdir) as at present.

And in addition, it would be nice to have additional make  and make 
install- targets for other output formats that Sphinx can generate for us, 
at least some of them.  "epub" comes to mind as an example I would like to have.

paul

GCC/clang warning incompatibility with unused private member variables

[Markus Faehling]

Hello,

I'm currently facing a problem where I cannot get both gcc and clang 
warning-free simultaneously in my project. My code looks somewhat like this:


class Test {
    int a_;
    void b() {};
};

This code gives me the(usually very useful) "-Wunused-private-field" 
warning on clang. But because I have the unused member on purpose, I 
would like to add the [[maybe_unused]] attribute to it:


class Test {
    [[maybe_unused]] int a_;
    void b() {};
};

While this version is warning-free in clang, gcc has a "-Wattributes" 
warning because it ignores the [[maybe_unused]] warning. But I do not 
want to disable either of these warnings because they are still very 
useful in other situations.


Would it be possible to ignore the "-Wattributes" warning for 
[[maybe_unused]] in places where other compilers might use the attribute?


Demonstration on godbolt.org: https://godbolt.org/z/8oT4Kr5eM

Regards,

Markus Faehling

Re: GCC/clang warning incompatibility with unused private member variables

[Gabriel Ravier via Gcc]

On 6/11/21 9:37 PM, Markus Faehling wrote:

Hello,

I'm currently facing a problem where I cannot get both gcc and clang 
warning-free simultaneously in my project. My code looks somewhat like 
this:


class Test {
    int a_;
    void b() {};
};

This code gives me the(usually very useful) "-Wunused-private-field" 
warning on clang. But because I have the unused member on purpose, I 
would like to add the [[maybe_unused]] attribute to it:


class Test {
    [[maybe_unused]] int a_;
    void b() {};
};

While this version is warning-free in clang, gcc has a "-Wattributes" 
warning because it ignores the [[maybe_unused]] warning. But I do not 
want to disable either of these warnings because they are still very 
useful in other situations.


Would it be possible to ignore the "-Wattributes" warning for 
[[maybe_unused]] in places where other compilers might use the attribute?


Demonstration on godbolt.org: https://godbolt.org/z/8oT4Kr5eM

Regards,

Markus Faehling

It should be easy to solve this with some application of `#pragma GCC 
diagnostic` pragmas to temporarily disable `-Wattributes` on that 
specific line. I suppose it may look ugly, but it works.

Re: GCC/clang warning incompatibility with unused private member variables

[Jason Merrill via Gcc]

On 6/11/21 3:37 PM, Markus Faehling wrote:

Hello,

I'm currently facing a problem where I cannot get both gcc and clang 
warning-free simultaneously in my project. My code looks somewhat like 
this:


class Test {
     int a_;
     void b() {};
};

This code gives me the(usually very useful) "-Wunused-private-field" 
warning on clang. But because I have the unused member on purpose, I 
would like to add the [[maybe_unused]] attribute to it:


class Test {
     [[maybe_unused]] int a_;
     void b() {};
};

While this version is warning-free in clang, gcc has a "-Wattributes" 
warning because it ignores the [[maybe_unused]] warning. But I do not 
want to disable either of these warnings because they are still very 
useful in other situations.


Would it be possible to ignore the "-Wattributes" warning for 
[[maybe_unused]] in places where other compilers might use the attribute?


Demonstration on godbolt.org: https://godbolt.org/z/8oT4Kr5eM


You can use #pragma to disable a warning for a particular section of code:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wattributes"
class Test {
 [[maybe_unused]] int a_;
 void b() {};
};
#pragma GCC diagnostic pop

But I also agree that GCC shouldn't warn here.

Jason

Re: GCC/clang warning incompatibility with unused private member variables

[Jakub Jelinek via Gcc]

On Fri, Jun 11, 2021 at 04:03:34PM -0400, Jason Merrill via Gcc wrote:
> You can use #pragma to disable a warning for a particular section of code:
> 
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wattributes"
> class Test {
>  [[maybe_unused]] int a_;
>  void b() {};
> };
> #pragma GCC diagnostic pop
> 
> But I also agree that GCC shouldn't warn here.

We could do that by using a wrapper around handle_unused_attribute
for the maybe_unused attribute, that way warn on unused attribute on
FIELD_DECLs, but not for maybe_unused (until we actually implement some
warning that uses it).

Jakub

Re: GCC/clang warning incompatibility with unused private member variables

[Jonathan Wakely via Gcc]

Here's another #pragma solution to your problem:

class Test {
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wpragmas" // so GCC ignores next line
# pragma GCC diagnostic ignored "-Wunused-private-field"
 int a_;
# pragma GCC diagnostic pop
 void b() {};
};

First tell GCC not to warn about the warning option that it doesn't
recognize, then use that option to tell clang to not warn about the
unused member.

gcc-10-20210611 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20210611 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20210611/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision ecbe8af2c38e22d3db99a57e21531fd523700492

You'll find:

 gcc-10-20210611.tar.xz   Complete GCC

  SHA256=8d1d696bb128ab74c58dd148b07d852859d82adfc91048781ac3f6d94a899bb8
  SHA1=c8e1be174b99c3c44eae257259c838041c8097c9

Diffs from 10-20210604 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Making *-netbsd-* to mean ELF not a.out for all CPUs

[John Ericson]

Hello Binutils and GCC lists[1],

I would like to propose that GNU tools consistently interpret configs with 
"netbsd" as meaning ELF as opposed to a.out. Currently, newer CPUs do that, but 
older ones have "netbsd" mean a.out for historical reasons, and "netbsdelf" is 
used instead. This inconsistency is a bit of a nuisance to my distro / package 
set[2] which aims to support cross compilation to/from arbitrary platforms 
without special cases. Other platforms that formerly used a.out (like Linux) 
have long since changed the default to be ELF, so I don't know why NetBSD 
shouldn't too.

I first reached out to the NetBSD toolchain developers[3]. They convinced me 
some alternate disambiguater (my first suggestion) wasn't worth it, with a.out 
being so old. But they did offer some tentative support for my second 
suggestion of changing the meaning of bare "netbsd" --- "netbsdaout" would 
still be available to unambiguously request a.out for anyone that wants it. I 
come now to just ask about that second suggestion.

I have prepared a first draft of patches for Binutils and GCC, but before 
polishing them off to submit, I figured I should ask about the openness to such 
a change.

Thanks,

John

[1]: I hope it's OK to email both lists at once like this; this is a question 
about a change that I think only makes sense if both projects approve.

[2] Nixpkgs, https://github.com/nixos/nixpkgs/

[3]: https://mail-index.netbsd.org/tech-toolchain/2021/06/10/msg003976.html 
this post goes more into more why I am interested in this change for anyone 
that's curious. Apologies for the duplicate emails; I thought the list was 
rejecting emails with HTML but it was something else.

RE: [EXTERNAL] Re: State of AutoFDO in GCC

[Eugene Rozenfeld via Gcc]

It appears that create_gcov doesn't support binaries with dwarf version 5 
(which is the current default). 
I tried a trivial example and got reasonable gcov files for binaries with dwarf 
v2, v3, and v4 but the same example with dwarf v5 produced 
"File './sort' has mangled .debug_info section."
and a gcov file with 0 functions.

Does create_llvm_prof has the same limitation?

Eugene

-Original Message-
From: Wei Mi  
Sent: Wednesday, May 26, 2021 7:52 PM
To: Eugene Rozenfeld 
Cc: Andi Kleen ; Hongtao Yu ; Xinliang David 
Li ; Jan Hubicka ; gcc@gcc.gnu.org; Wenlei 
He 
Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC

Thanks. Good to know the build works with newer protobuf.

Wei.

On Wed, May 26, 2021 at 4:40 PM Eugene Rozenfeld 
 wrote:
>
> 3.0.0 is the latest supported version on Ubuntu 18.04. I verified that the 
> build works on Ubuntu 20.04 with  protobuf-compiler and libprotobuf-dev 
> version 3.6.1.3.
>
> Eugene
>
> -Original Message-
> From: Wei Mi 
> Sent: Tuesday, May 25, 2021 8:07 PM
> To: Eugene Rozenfeld 
> Cc: Andi Kleen ; Hongtao Yu ; Xinliang 
> David Li ; Jan Hubicka ; 
> gcc@gcc.gnu.org; Wenlei He 
> Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
>
> I checked the source of protobuf 3.0.0 and it didn't contain the operator[] 
> in RepeatedField. Need to install a newer version of protobuf.
>
> Thanks,
> Wei.
>
> On Tue, May 25, 2021 at 1:49 PM Eugene Rozenfeld 
>  wrote:
> >
> > Both are 3.0.0-9.1ubuntu1:
> >
> > eugene@eugene-Virtual-Machine:~/autofdo1/build$ apt list 
> > protobuf-compiler Listing... Done protobuf-compiler/bionic,now
> > 3.0.0-9.1ubuntu1 amd64 [installed]
> > eugene@eugene-Virtual-Machine:~/autofdo1/build$ apt list 
> > libprotobuf-dev Listing... Done libprotobuf-dev/bionic,now
> > 3.0.0-9.1ubuntu1 amd64 [installed]
> >
> > -Original Message-
> > From: Wei Mi 
> > Sent: Tuesday, May 25, 2021 9:17 AM
> > To: Eugene Rozenfeld 
> > Cc: Andi Kleen ; Hongtao Yu ; 
> > Xinliang David Li ; Jan Hubicka 
> > ; gcc@gcc.gnu.org; Wenlei He 
> > Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
> >
> > It looks like some version problem about protobuf-compiler and 
> > libprotobuf-dev. Could you check what is the installed version on your end 
> > for those two packages and see if they are consistent?
> >
> > On my platform, they are both 3.12.4.
> >
> > On Tue, May 25, 2021 at 12:01 AM Eugene Rozenfeld 
> >  wrote:
> > >
> > > That eliminates the previous error but there is a new one:
> > >
> > > eugene@eugene-Virtual-Machine:~/autofdo1/build$ ninja [3/199] 
> > > Building CXX object 
> > > CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/qu
> > > ip
> > > pe
> > > r/perf_reader.cc.o
> > > FAILED: 
> > > CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o
> > > /usr/bin/c++   -I../third_party/perf_data_converter/src 
> > > -I../third_party/perf_data_converter/src/quipper -I../ 
> > > -I../third_party/glog/src -I../third_party/abseil -I../util -I. 
> > > -Ithird_party/glog -std=gnu++1z -MD -MT 
> > > CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o
> > >  -MF 
> > > CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o.d
> > >  -o 
> > > CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/perf_reader.cc.o
> > >  -c ../third_party/perf_data_converter/src/quipper/perf_reader.cc
> > > ../third_party/perf_data_converter/src/quipper/perf_reader.cc: In member 
> > > function 'bool 
> > > quipper::PerfReader::ReadCPUTopologyMetadata(quipper::DataReader*, 
> > > size_t)':
> > > ../third_party/perf_data_converter/src/quipper/perf_reader.cc:1518:46: 
> > > error: no match for 'operator[]' (operand types are 'const 
> > > google::protobuf::RepeatedField' and 'int')
> > >  nrcpus = proto_uint32_metadata.data()[0];
> > >
> > > -Original Message-
> > > From: Wei Mi 
> > > Sent: Monday, May 24, 2021 8:54 PM
> > > To: Eugene Rozenfeld 
> > > Cc: Andi Kleen ; Hongtao Yu ; 
> > > Xinliang David Li ; Jan Hubicka 
> > > ; gcc@gcc.gnu.org; Wenlei He 
> > > Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
> > >
> > > It isn't exposed on my platform either. Looks like a bug in 
> > > perf_data_converter (i.e., quipper). Could you try adding #include 
> > >  in 
> > > third_party/perf_data_converter/src/quipper/huge_page_deducer.cc and see 
> > > if it fixes the problem? If it works, I will need to file a bug against 
> > > perf_data_converter.
> > >
> > > Thanks,
> > > Wei.
> > >
> > > On Mon, May 24, 2021 at 8:33 PM Eugene Rozenfeld 
> > >  wrote:
> > > >
> > > > That fixed the error I saw before but the build still fails. The 
> > > > errors start with
> > > >
> > > >
> > > >
> > > > eugene@eugene-Virtual-Machine:~/autofdo1/build$ ninja
> > > >
> > > > [2/217] Building CXX object
> > > > CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/
> > > > qu
> > > > ip
> > > > pe
> > > > r/huge_page_d

Re: Mailing list reconfiguration: VERP Sender: header affected

[Gerald Pfeifer]

On Thu, 3 Jun 2021, Martin Liška via Overseers wrote:
> On 6/2/21 4:52 PM, Frank Ch. Eigler via Gcc wrote:
>> If you use Sender:-based filtering for sorting your incoming email
>> stream, I suggest switching to observing List-Id: instead, or else
>> using a regexp/substring style of Sender: matching.
> Which we recommend in the ection Filtering here:
> https://gcc.gnu.org/lists.html

Now we do. ;-)  We did recommend Sender: until

  commit 8beab8102fd97e0bc745a285e619c08c52d74b6f
  Author: Segher Boessenkool 
  Date:   Tue Jun 1 15:50:57 2021 +

lists: Correct procmail recipe

Thanks for the note, Frank!
Gerald