Re: Compiling GCC using an older sysroot

[Jonathan Wakely via Gcc]

On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> The tricky bit is that although both the host and target are always
> x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
> much older systems than the one I build it on.
>
> I have a sysroot I've created (downloading RPMs from older systems and
> unpacking them) which is sufficient to build GCC (and binutils etc.)  I
> need the GCC binaries I create to be compiled using this sysroot so
> that they can run on older systems.

I suggest using containers for this. Once you've got a working
Dockerfile it makes life much easier in my experience.

The podman and buildah utilities are great alternatives to docker itself.

By building in a container using something like "FROM centos:6" you
know you're using those packages, not trying to convince GCC to use a
cobbled-together sysroot based on old RPMs.

Re: Compiling GCC using an older sysroot

[Jonathan Wakely via Gcc]

On Wed, 11 Mar 2020 at 16:46, Paul Smith  wrote:
>
> On Wed, 2020-03-11 at 14:17 +, Jonathan Wakely wrote:
> > On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> > > The tricky bit is that although both the host and target are always
> > > x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
> > > much older systems than the one I build it on.
> >
> > I suggest using containers for this. Once you've got a working
> > Dockerfile it makes life much easier in my experience.
> >
> > The podman and buildah utilities are great alternatives to docker itself.
> >
> > By building in a container using something like "FROM centos:6" you
> > know you're using those packages, not trying to convince GCC to use a
> > cobbled-together sysroot based on old RPMs.
>
> That's a good idea, certainly for building the compiler: it would save me
> having to build the initial compiler ("step 1" in Joseph's email): I can
> skip that step and just build the target compiler in a container.
>
> Unfortunately currently I target RHEL/CentOS 6.5 and there's no official
> docker image for that, but that's not a major problem.
>
> However I don't think, at least for now, I can switch to having developers
> build in a docker container.  Getting that integrated with all the
> tooling/IDE environments everyone uses, etc. will be a lot of change.
> Since I want to use a much newer version of GCC than was provided in these
> older releases, a docker image won't save me having to build the compiler
> anyway; it would only change the way the compiler is distributed and used
> (inside a docker image/container vs. stand-alone with a sysroot).

My thinking was to build GCC inside the container, then package up the
results and install that on your dev machines (outside a container).
But actually that won't work because you'd also need to package the
glibc from the container, and at that point you're basically back to
using a sysroot.

Re: Not usable email content encoding

[Jonathan Wakely via Gcc]

On Mon, 16 Mar 2020 at 14:13, Martin Liška wrote:
>
> On 3/16/20 2:54 PM, Alexander Monakov wrote:
> > Are you trying to copy from the raw message representation?
>
> Exactly.

That's never been reliable.

Re: Integrating GCC with oss-fuzz

[Jonathan Wakely via Gcc]

On Mon, 16 Mar 2020 at 21:15, David Korczynski wrote:
>
> Hi!
>
> My name is David Korczynski and I have been doing some work on
> integrating fuzzing by way of OSS-Fuzz into the gcc project. This came
> out of fuzzing libiberty within the binutils project where we found
> several bugs within libiberty. However, the binutils owners are not
> working on libiberty so we dont get much results from reporting to them.

N.B. fuzzing the demangler is not really considered useful by some of
us. Actually helping to fix bugs would be more helpful than just
reporting yet another issue in the demangler code. There are more
useful things that could be fuzzed, but so far everybody fuzzing seems
to go for the easy target that gets them lots of "successes".

We talked about using oss-fuzz for the std::regex code. There are
probably other places in the C++ standard library that would benefit.

> I was wondering if we could set up a similar project, namely by
> integrating gcc to the OSS-Fuzz project and the errors found will then
> automatically be sent to gcc-b...@gcc.gnu.org?

Sending email to that list doesn't achieve anything. Bugs need to be
reported to Bugzilla.

> We can either add the
> fuzzers upstream to gcc or do as binutils and adding them to OSS-Fuzz. I
> have already done the work so we should be good to go with continuous
> fuzzing if you are interested!
>
> You can see the current binutils project here:
> https://github.com/google/oss-fuzz/tree/master/projects/binutils

I'm glad to see there's more being fuzzed than just the demangler.

> Here the binutils owners outline their interest in the project:
> https://github.com/google/oss-fuzz/pull/2617

Re: Not usable email content encoding

[Jonathan Wakely via Gcc]

On Wed, 18 Mar 2020 at 21:54, Jim Wilson wrote:
>
> I'm one of the old timers that likes our current work flow, but even I
> think that we are risking our future by staying with antiquated tools.
> One of the first things I need to teach new people is now to use email
> "properly".  It is a barrier to entry for new contributors, since our
> requirements aren't how the rest of the world uses email anymore.
> LLVM has phabricator.

Which is horrible.

> Some git based projects are using gerrit.

Which I looked into previously and decided I didn't like it. If I
recall correctly, gerrit has to "own" the repo, and so it's only
possible to commit to the repo by pushing to gerrit first, then
getting the patch approved. That is fine for write-after-approval, but
adds a step for maintainers who can approve their own changes.

I think it also only very recently gained the ability to group a
series of patches together, as it wants a single commit per review.


> Github and gitlab are useful services.  We need to think about setting
> up easier ways for people to submit patches, rather than trying to fix
> all of the MUAs and MTAs in the world.

There's also https://pagure.io/pagure which is Free Software.

I think it would be great if one of those forge services could be set
up to run *in parallel* to our existing workflow, so that we can
accept pull requests there without forcing all work to go through it
(like gerrit). New contributors who are used to the GitHub model could
submit pull requests there, and maintainers could merge them into the
repo with the click of a button. For significant changes it's more
likely maintainers would pull the branch into their local repo, test
it, and then push manually. But if we had a CI service testing pull
requests (like Travis CI does for GitHub) and a pull request was shown
to introduce no regressions then it could be merged with a single
click.

Re: Not usable email content encoding

[Jonathan Wakely via Gcc]

N.B. the CC list has got too big and is causing posts to this thread
to be held for moderator approval.

Re: Not usable email content encoding

[Jonathan Wakely via Gcc]

On Wed, 18 Mar 2020 at 22:45, Joseph Myers wrote:
>
> On Wed, 18 Mar 2020, Jonathan Wakely via Gcc wrote:
>
> > > Some git based projects are using gerrit.
> >
> > Which I looked into previously and decided I didn't like it. If I
> > recall correctly, gerrit has to "own" the repo, and so it's only
>
> The glibc experiment with gerrit worked without it owning the repo.

Ah, good to know, thanks.

Re: printf-like function.

[Jonathan Wakely via Gcc]

On Fri, 20 Mar 2020 at 07:16, jf wrote:
>
> Hi all,
>
> I'm a printf-like function lover. I always found that better than doing
> something like out << "blabla : " << var1 << ", blabla" << etc.
>
> Now, I use a lot of different platforms and to be portable, I'm supposed
> to use PRIxxx constants for portability. For me that half-breaks the
> readability of printf format.
>
> What about a new set of functions that'll be specified slightly
> differently :
>
> What if we can write %d for ANY number ?

You should look at https://en.cppreference.com/w/cpp/utility/format
and the reference implementation https://fmt.dev/

There's no need for compiler magic.

Re: Want to contribute in open source project

[Jonathan Wakely via Gcc]

On Sat, 21 Mar 2020 at 15:24, PRIYANSHU ARYA via Gcc  wrote:
>
> Dear Sir/ma'am:
>
> I'm a new learner wanted to contribute in your open source project so i
> want to know how to start contributing in your open source projects and
> want to know all the requirements for contributing in your organization.

See https://gcc.gnu.org/wiki/GettingStarted

Re: Can we please have the old mailing list back

[Jonathan Wakely via Gcc]

On Wed, 25 Mar 2020 at 04:48, Bernd Edlinger wrote:
>
> Hi,
>
> I do not want to start a flame war.
>
> I just am curious what was the reason why
> the old system cannot be used any more?

The software it ran on hasn't been maintained for years.

> Would there be a possibility to get the old look-and-feel back?

There are at least two existing threads on this topic.

Re: Changes dueto server migration

[Jonathan Wakely via Gcc]

On Wed, 25 Mar 2020 at 05:51, Fangrui Song wrote:
> It is really difficult for a non-subscriber to comment now.
> There are no To: or Cc: fields on Pipermail.

Yes, that's a pain. You can click on the sender's address at the top
of the archived mail (or use
https://gitlab.com/miscripts/miscripts/-/blob/master/gcc/get_gcc_mail
to do so in mutt) but it only replies to the sender. The list isn't
CC'd and neither are any other people CC'd on the original mail (which
might include people who aren't subscribed to the list, and now won't
receive your reply).

Re: Can we please have the old mailing list back

[Jonathan Wakely via Gcc]

On Wed, 25 Mar 2020 at 20:29, Bernd Edlinger wrote:
>
> -On 3/25/20 7:55 PM, Christopher Faylor wrote:
> > On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
> >> I believe the canonical place for the "Linux suff" mailing lists these 
> >> days is
> >> lore.kernel.org, powered by public-inbox[1]. ISTM that software can 
> >> address most
> >> if not all needs of those involved in GCC development and even has NNTP 
> >> support,
> >> though I've no idea whether it could be an acceptable solution from the
> >> overseers' perspective.
> >>
> >> [1] https://public-inbox.org/public-inbox.git
> >
> > The overseers are trying hard to use only software that can be installed
> > via the RHEL packaging system so as not to duplicate the mistake that
> > kept us dependent on poorly supported mail software.  Is there a
> > public-inbox rpm package for RHEL or CentOS?
> >
> > FWIW, this particular overseer is is also pretty exhausted from the
> > effort of moving sourceware to a new system + new software and would not
> > relish the effort involved in getting all of this moved to new software.
> >
>
> Honestly this is not about blaming you at all.
>
> I do not quite understand what is the exact software which
> was used previously?

See the link at the bottom of every page in the old archive:
http://www.mhonarc.org/

> what is the exact problem that prevents it from being used any longer?

It's not packaged for RHEL 8.

> Which software is being used now?

See the text at the bottom of every page in the new archive:
Pipermail 0.09 (Mailman edition).

Re: OpenACC

[Jonathan Wakely via Gcc]

Please don't cross-post to both the gcc and gcc-help mailing lists.
Either your question is about GCC development, or it's about help
using GCC, not both. Pick one list.

On Thu, 26 Mar 2020 at 08:44, MAHDI LOTFI via Gcc  wrote:
>
> Hello
> I am a researcher from Jam Petrochemical company I want to use OpenACC with
> GCC compiler. I have a question about your compiler.
> Does your compiler support OpenACC in windows OS or not?
>
> Thanks very much
> --
> Mahdi Lotfi
> Student at Sharif University of Technology

Re: GSoC Static Analysis

[Jonathan Wakely via Gcc]

On Wed, 25 Mar 2020 at 22:38, Andrew Briand wrote:
>
> Hello,
>
> I am an undergrad interested in extending GCC’s static analysis pass for GSoC 
> 2020. In particular, I’m interested in adding C++ support.
>
> The selected project ideas list mentions adding new/delete checking and 
> exception checking. The features that immediately come to my mind would be 
> checking for undeleted allocations, mixing delete and delete[], double 
> deletion (it seems the current static analyzer already checks for double 
> free), and uncaught exceptions.

I'm not sure reporting about uncaught exceptions is useful, except in
the (unlikely) case where the entire program is visible to the
compiler, or maybe as an extension of the -Wterminate warning.
Exceptions are *supposed* to be uncaught in most code, so they
propagate to a layer that can actually do something about the error.

Some other ideas for C++ code could be:

- Locking a mutex twice, or locking it and not unlocking it in the same scope.

- Locking and unlocking a mutex around a region with no side effects
(i.e. no I/O, no volatile read/writes, no atomic operations on
non-local variables).

- Using a shared_ptr where there's only a single owner so unique_ptr would work.

- Returning a reference/pointer to a local variable through another
function (which the current -Wreturn-local-addr warning can't
diagnose) e.g.
int& f(int& i) { return i; }
int& g() { int i = 0; return f(i); }

Re: Can we please have the old mailing list back

[Jonathan Wakely via Gcc]

On Wed, 1 Apr 2020 at 21:30, Bernd Edlinger  wrote:
> @overseeers: PLEASE STOP IMMEDIATELY THAT SCRUBBING

You're emailing the gcc list about the gdb-patches mailing list, and
haven't CC'd the overseers list or the gdb list.

> can you act now, or do you need a CVE number first ?

That doesn't seem like it would be helpful.

Re: Can we please have the old mailing list back

[Jonathan Wakely via Gcc]

On Wed, 1 Apr 2020 at 23:54, Joseph Myers wrote:
>
> On Wed, 1 Apr 2020, Bernd Edlinger wrote:
>
> > PS: I have a discovered a very serious problem with the mailing lists
> > that must be fixed by our overseers.
> >
> > That is the scubbed attachments.
> >
> > As an example please look at this one:
> > https://marc.info/?l=gdb-patches&m=158571308379946&w=2
>
> The copy of that message I received from gdb-patches by email appears to
> have the attachment intact.  I don't know where marc.info got the message
> from, but it doesn't seem to be by email from the list.

The sourceware.org archive also has an HTTP (not HTTPS) link for that
attachment:

https://sourceware.org/pipermail/gdb-patches/2020-March/166601.html

Re: Can we please have the old mailing list back

[Jonathan Wakely via Gcc]

On Thu, 2 Apr 2020 at 04:35, Bernd Edlinger wrote:
> Regarding the overseers, they repeatedly spoke up on this list,
> but all the time they use an e-mail that bounces.

No. ONE of the overseers replies from a personal email address that
bounces, because as the address clearly says, you should contact him
via the list, not his personal address. And the relevant list is the
overseers one, not this one.

> I'd call that impolite.

No, it's impolite to ignore his request and try to reach him
personally, rather than via the list. It's perfectly reasonable to say
"please use the mailing list instead of emailing me personally". I do
that all the time when people reply to me off-list after looking for
help on gcc-help.

Re: Question about the testresults mailing list

[Jonathan Wakely via Gcc]

On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
>
> Hi,
>
> I have a question about the gcc-testresults mailing list,
> that is I see everyone using:
>
> [releases/gcc-9 revision 
> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839]
>
> or
>
> [master revision 
> 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e
>
> what is the first 2 hashes, I cant make sens out of it?

See contrib/gcc_update, which sets that string:

revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H`

Re: Question about the testresults mailing list

[Jonathan Wakely via Gcc]

On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger  wrote:
>
>
>
> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
> >>
> >> Hi,
> >>
> >> I have a question about the gcc-testresults mailing list,
> >> that is I see everyone using:
> >>
> >> [releases/gcc-9 revision 
> >> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839]
> >>
> >> or
> >>
> >> [master revision 
> >> 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e
> >>
> >> what is the first 2 hashes, I cant make sens out of it?
> >
> > See contrib/gcc_update, which sets that string:
> >
> > revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H`
> >
>
> and for dummies like me,
>
> what is %p %t and %H ?

git help log

Re: Question about the testresults mailing list

[Jonathan Wakely via Gcc]

On Fri, 3 Apr 2020 at 18:54, Bernd Edlinger  wrote:
>
> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
> >>
> >> Hi,
> >>
> >> I have a question about the gcc-testresults mailing list,
> >> that is I see everyone using:
> >>
> >> [releases/gcc-9 revision 
> >> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839]
> >>
> >> or
> >>
> >> [master revision 
> >> 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e
> >>
> >> what is the first 2 hashes, I cant make sens out of it?
> >
> > See contrib/gcc_update, which sets that string:
> >
> > revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H`
> >
>
> ah, you mean my workflow was wrong,
> git pull
> configure
> make
> test
> gcc_testresults?
>
> what is your workflow?

Using contrib/gcc_update isn't required.

Re: Question about the testresults mailing list

[Jonathan Wakely via Gcc]

On Fri, 3 Apr 2020 at 19:40, Bernd Edlinger  wrote:
>
>
>
> On 4/3/20 7:56 PM, Jonathan Wakely wrote:
> > On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger  
> > wrote:
> >>
> >>
> >>
> >> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> >>> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
> 
>  Hi,
> 
>  I have a question about the gcc-testresults mailing list,
>  that is I see everyone using:
> 
>  [releases/gcc-9 revision 
>  02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839]
> 
>  or
> 
>  [master revision 
>  63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e
> 
>  what is the first 2 hashes, I cant make sens out of it?
> >>>
> >>> See contrib/gcc_update, which sets that string:
> >>>
> >>> revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H`
> >>>
> >>
> >> and for dummies like me,
> >>
> >> what is %p %t and %H ?
> >
> > git help log
> >
>
> done.
> But why do we use parent hash and tree hash, that does just
> look confusing?

I don't think they're very useful in this context.

Re: Not usable email content encoding

[Jonathan Wakely via Gcc]

On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc  wrote:
>  And can certainly score a positive though not a definite rating in spam
> qualification.  I don't think we ought to encourage bad IT management
> practices by trying to adapt to them too hard and hurting ourselves (our
> workflow) in the process.

What you call "bad IT management practices" includes how Gmail works,
which a HUGE number of people use.

A number of lists I'm on switched to our current style of minging a
year or two ago, because gmail users were not receiving mail, because
gmail was rejecting the mail.

Re: G++ 10

[Jonathan Wakely via Gcc]

On Thu, 16 Apr 2020 at 21:02, Baumanns via Gcc  wrote:
>
> Hello gcc Team,
>
> currently I work on some very modern c++ projects based on c++20. For my
> tests I would like to compile my code with all three major compilers: g++,
> msvc and llvm/clang to test the latest features (like co_yield).
> Furthermore I have problems with unicode header names.
>
> Unfortunately I am not able to get the prereleased Version of g++ 10
> running on my node (can be Linux or Windows). Could you explain me, how can
> install / build g++-10?


This is the wrong mailing list, please use gcc-help for questions like
this, as documented at https://gcc.gnu.org/lists.html

See https://gcc.gnu.org/wiki/InstallingGCC for the simplest
instructions for installing and building GCC.

You might find https://jwakely.github.io/pkg-gcc-latest/ useful.

Re: Not usable email content encoding

[Jonathan Wakely via Gcc]

On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote:
>
> * Tamar Christina:
>
> > A bit late to the party, but this really doesn't work that well
> > because until recent version of gitlab there was no fairness
> > guarantee.  another patch could be approved after mine (with hours
> > in between because of CI) and yet still get merged first causing my
> > own patch to no longer apply, you'd rebase and roll the dice again.
> > To fix this they added merge trains
> > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/
> >
> > but trains for GCC Will likely be very short because of Changelog
> > conflicts.  So I don't think an automated merge workflow would work
> > for projects where every single commit changes the same files.
>
> I had not thought about that.
>
> Does Gitlab support pluggable merge helpers?  The gnulib changelog
> auto-merger did a great job when we were still writing changelogs for
> glibc.

I've been having problems with it recently, e.g.
https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog,
because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog
entry in the wrong place in gcc/testsuite/Changelog, as a result of a
rebase using merge-changelog.

Maybe we should follow glibc and get rid of ChangeLog files before
trying to use automated CI and Git workflows.

Re: Not usable email content encoding

[Jonathan Wakely via Gcc]

On Thu, 23 Apr 2020 at 12:47, Segher Boessenkool
 wrote:
>
> Hi!
>
> On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > but trains for GCC Will likely be very short because of Changelog conflicts.
>
> Why that?  Your patches should *not* touch changelog files, ever.
>
> For CI it is probably easiest if the CI never gets to see the changelog
> at all, and that isn't hard to do ;-)

For the actual CI testing, yes. But if you want an automated "merge
after CI testing passes" then what you merge needs to add a ChangeLog
entry. So either we auto-generate the entry when doing the auto-merge,
or the ChangeLog entry is already there.

Re: blacklisted after announce on GNU cauldron ?

[Jonathan Wakely via Gcc]

On Thu, 23 Apr 2020 at 16:46, Christopher Faylor via Gcc
 wrote:
>
> On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote:
> >Hi Frank,
> >
> >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler  wrote:
> >>
> >> Hi -
> >>
>  A re-subscription attempt to the gcc mailing list just
>  failed, expectedly I guess.
> >>
> >> I see no sign in the logs of Olivier being banned in any form.  Please
> >> resubscribe online and forward complete failure symptoms if you
> >> believe this is still happening.
> >
> >Thanks for your feedback!
> >
> >I managed to subscribe again by going through the gcc
> >list specific info page :-)
> >
> >My previous attempts were issued from
> >
> >  https://gcc.gnu.org/lists.html#subscribe
> >
> >Subscribing from there doesn't work and leads
> >to a page which provides instructions which don't work
> >either.
> >
> >From there I thought the coincidence was troubling.
> >
> >There is actually a FAQ link on the instructions page,
> >which I just checked, and ... it directs to a 404 page:
> >
> >  https://sourceware.org/pipermail/index.html#faqs
> >
> >I'll try to re-subscribe to gcc-patches now.
>
> All of the above is handled by whomever is responsible for the
> gcc web pages.  It would be nice if someone fixed those links.

Yes, removing the broken subcription form on gcc.gnu.org/lists.html is
on my TODO list, but gcc-10 work is higher priority.

Re: blacklisted after announce on GNU cauldron ?

[Jonathan Wakely via Gcc]

On Thu, 23 Apr 2020 at 18:02, Jonathan Wakely  wrote:
>
> On Thu, 23 Apr 2020 at 16:46, Christopher Faylor via Gcc
>  wrote:
> >
> > On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote:
> > >Hi Frank,
> > >
> > >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler  wrote:
> > >>
> > >> Hi -
> > >>
> >  A re-subscription attempt to the gcc mailing list just
> >  failed, expectedly I guess.
> > >>
> > >> I see no sign in the logs of Olivier being banned in any form.  Please
> > >> resubscribe online and forward complete failure symptoms if you
> > >> believe this is still happening.
> > >
> > >Thanks for your feedback!
> > >
> > >I managed to subscribe again by going through the gcc
> > >list specific info page :-)
> > >
> > >My previous attempts were issued from
> > >
> > >  https://gcc.gnu.org/lists.html#subscribe
> > >
> > >Subscribing from there doesn't work and leads
> > >to a page which provides instructions which don't work
> > >either.
> > >
> > >From there I thought the coincidence was troubling.
> > >
> > >There is actually a FAQ link on the instructions page,
> > >which I just checked, and ... it directs to a 404 page:
> > >
> > >  https://sourceware.org/pipermail/index.html#faqs
> > >
> > >I'll try to re-subscribe to gcc-patches now.
> >
> > All of the above is handled by whomever is responsible for the
> > gcc web pages.  It would be nice if someone fixed those links.
>
> Yes, removing the broken subcription form on gcc.gnu.org/lists.html is
> on my TODO list, but gcc-10 work is higher priority.

Patch submitted for approval now:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html

Re: Unrolling for constexpr

[Jonathan Wakely via Gcc]

On Mon, 27 Apr 2020 at 04:54, Laleh Aghababaie via Gcc  wrote:
>
> Hi all,

N.B. this is the wrong mailing list for such a question, you should
have used the gcc-help list instead.

> I have a question about the constexpr variable specifications and how the 
> compiler handles them. The constexpr specifier declares that it is possible 
> to evaluate the value of the function or variable “at compile time”. If we 
> look at the bellow simplified example:
>
> int func(){
> int sum = 0;
> for (int i = 0; i < 3; i++){
> constexpr int j = i;
> sum +=j;
> }
> return sum;
> }
>
> The compiler will throw an error as:
>
> “The value of ‘i' is not usable in a constant expression.”
> However the value of ‘i’ is known during the compile time, and if I unroll 
> this computation myself it works perfect, so why the compiler is not able to 
> do that?

The compiler *could* do it, but the rules of the C++ standard do not
allow a constexpr variable to have an initializer that is nto a
constant expression. The loop variable i is not a constant expression,
obviously, because its value changes.

> The main reason I am asking this is because I want to call a constexpr 
> function for a few iteration which is known at compile time (instead of that 
> “sum” in the for loop) , but using the iteration number in the call is 
> prohibited, even though the number of iterations and iteration number  is 
> known during the compile time to do the sum. When unrolling it by hand works, 
> why the compiler refuses to handle this situation?

Because it's not valid C++.

If you want to process a sequence of integer constants there are
various metaprogramming techniques you can use e.g create
std::integer_sequence and pass it to a function
template that accepts an int... pack, and expands it in a fold
expression.

Re: segment fault

[Jonathan Wakely via Gcc]

On Tue, 28 Apr 2020 at 02:26, luo alvin via Gcc  wrote:
>
> Dear gnu:
>Here is code:

Please do not report bugs to this mailing list. Bug reports belong in
our Bugzilla database, see https://gcc.gnu.org/bugs/

But this is not a bug anyway, your code has undefined behaviour. You
cannot use memset on non-trivial objects. Using memset like that
overwrites the contents of the std::string with invalid data.

Re: segment fault

[Jonathan Wakely via Gcc]

Please move this discussion to the gcc-help mailing list where it
belongs. I'll reply on that list instead.

On Tue, 28 Apr 2020 at 07:07, luo alvin  wrote:
>
> Thank you very much for replying me. I also think it not bug,because I test 
> this code in the lower version(lower than 8.3.1-3) of gcc,all cause segment 
> fault. The funny thing is that if you run this code higher than gcc 
> version(8.3.1-4)(actually I only test code in the version 8.3.1-4),the result 
> is fine(doesn’t lead to segment fault).furthermore, I found that the value of 
> sizeof(std::string) is different between gcc versions. Value in version 
> 8.3.1-3 is 8 ,and 32 in version 8.3.1-4.
>
> 发送自 Windows 10 版邮件应用
>
>
>
> 发件人: Jonathan Wakely
> 发送时间: 2020年4月28日 13:56
> 收件人: luo alvin
> 抄送: gcc@gcc.gnu.org
> 主题: Re: segment fault
>
>
>
> On Tue, 28 Apr 2020 at 02:26, luo alvin via Gcc  wrote:
> >
> > Dear gnu:
> >Here is code:
>
> Please do not report bugs to this mailing list. Bug reports belong in
> our Bugzilla database, see https://gcc.gnu.org/bugs/
>
> But this is not a bug anyway, your code has undefined behaviour. You
> cannot use memset on non-trivial objects. Using memset like that
> overwrites the contents of the std::string with invalid data.
>
>

Re: GCC 10.0.1 Status Report (2019-04-30)

[Jonathan Wakely via Gcc]

On Thu, 30 Apr 2020 at 19:20, Jakub Jelinek via Gcc  wrote:
>
> Status
> ==
>
> We have reached zero P1 regressions today and releases/gcc-10 branch has
> been created;  GCC 10.1-rc1 will be built and announced later tonight
> or tomorrow.
> The branch is now frozen for blocking regressions and documentation
> fixes only, all changes to the branch require a RM approval now.

I'd like to backport this fix for a broken link in the libstdc++ FAQ:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545098.html
The only non-whitespace change is to replace a URL. It's already on
master, gcc-9 and gcc-8 branches.

Re: GCC 10.1 Release Candidate available from gcc.gnu.org

[Jonathan Wakely via Gcc]

On Tue, 5 May 2020 at 15:42, Victor Rodriguez via Gcc  wrote:
> Has someone found issues on common packages that require patches for GCC 10?

Yes, several. See https://gcc.gnu.org/gcc-10/porting_to.html for the
known issues (the first one being a problem with "common" packages!)

Re: Multilibs in stage-1

[Jonathan Wakely via Gcc]

On Thu, 7 May 2020 at 07:28, Uros Bizjak via Gcc  wrote:
>
> On Thu, May 7, 2020 at 8:16 AM Richard Biener
>  wrote:
> >
> > On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc  
> > wrote:
> > >Hello!
> > >
> > >I wonder, if the build process really needs to build all multilibs in
> > >stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build
> > >stage-1 gcc, so there is no need for multilibs, apart from library
> > >that will be used by stage-1 gcc during compilation of stage-2
> > >compiler.
> >
> > Correct. Only stage3 needs those. But IIRC we already avoid building them? 
> > Likewise we avoid building libsanitizer and friends in stage 1/2 unless 
> > ubsan bootstrap is enabled.
>
> Looking at:
>
> [gcc-build]$ ls stage1-x86_64-pc-linux-gnu/32/
> libgcc  libgomp  libstdc++-v3
>
> it seems that 32bit multilibs are built anyway, also in stage2:
>
> [gcc-build]$ ls prev-x86_64-pc-linux-gnu/32/
> libgcc  libgomp  libstdc++-v3

Debian have a local patch to skip those:
https://gcc.gnu.org/legacy-ml/libstdc++/2015-11/msg00164.html

The libstdc++-v3/acinclude.m4 part was committed as
https://gcc.gnu.org/g:86f73527aa3556b7d5ead9b03d8a5c91d351a409 but not
the top-level part for multilibs.

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

[Jonathan Wakely via Gcc]

On Sat, 9 May 2020 at 08:15, John Paul Adrian Glaubitz
 wrote:
>
> Hi!
>
> On 5/9/20 12:15 AM, Segher Boessenkool wrote:
> > I can do both, if you want, or just the first group?  Your choice.
> >
> > But let's hear other opinions first.
>
> These bugs document the current issues with the backend as it existed
> in gcc-8 (or was it -9)? The bugs are still in the removed code, so
> I don't really understand what you gain by closing bugs?

If the code has been removed, the bug no longer exists.

What do you gain by keeping them open forever?

> Is it important
> to keep the number of open issues low?

If you mean for PR reasons or good apeparances, no. But it's wrong to
have bugs left open that only refer to unsupported versions of GCC. If
none of the supported releases has the bug (either because it's been
fixed, or the relevant code has been removed) then the bug should be
closed.

If the bug is still present in supported versions (like gcc-8 or
gcc-9) but will never be fixed (like SPE ones) they might as well be
closed now as WONTFIX. Suggesting anything else will happen to them is
misleading.


> I don't consider bug reports a bad thing, they document the code quality
> and are a useful resource to anyone working on the code or using these
> versions.

A closed bug report doesn't disappear from the database. It just
documents that the bug report has (probably) reached a terminal state
and no work will be done on it.

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

[Jonathan Wakely via Gcc]

On Sat, 9 May 2020 at 19:56, John Paul Adrian Glaubitz
 wrote:
>
> On 5/9/20 12:31 PM, Arseny Solokha wrote:
> > I'd also like to nominate the following two:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
> >
> > which I also cannot close myself. There won't be any further revisions of 
> > this
> > list by me.
>
> They affect given older versions, so if you just close them, that would imply
> that the bug in question in gcc-4.5.3 has been dealt with  - which I assume
> is not the case.

Did you bother to read my reply? Closing a bug means no more work will
be done, not that work has already been done.

> So, again, I'm not sure what you gain by closing these bugs. Having them 
> marked
> as open means that someone has observed the issue with a certain gcc version
> and target.

Please read my first email to you.

> Moving it to "closed" just expresses that some people don't care about this
> bug anymore. But it doesn't change the fact that the bug still exists.

Please read my first email to you.

> The only thing you gain by closing such bugs is that you are reducing the
> number of open bug reports and you can somehow claim you fixed a bug.

No, it doesn't claim anything was fixed, please read my first email to you.

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

[Jonathan Wakely via Gcc]

On Sat, 9 May 2020 at 09:56, John Paul Adrian Glaubitz
 wrote:
>
> On 5/9/20 10:31 AM, Jonathan Wakely wrote:
> > If you mean for PR reasons or good apeparances, no. But it's wrong to
> > have bugs left open that only refer to unsupported versions of GCC. If
> > none of the supported releases has the bug (either because it's been
> > fixed, or the relevant code has been removed) then the bug should be
> > closed.
> >
> > If the bug is still present in supported versions (like gcc-8 or
> > gcc-9) but will never be fixed (like SPE ones) they might as well be
> > closed now as WONTFIX. Suggesting anything else will happen to them is
> > misleading.
>
> If you don't accept my opinion, why did you ask for it in the first place.

Eh? This is the first time I've said anything on the subject, I didn't
ask for anything, and I didn't say that I don't accept your opinion,
and I certainly didn't say the rets of the GCC project doesn't accept
your opinion.

You asked questions about closing bugs, and I answered them. If you
don't accept straightforward answers, why did you ask questions in the
first place?

> Please do whatever you want. I will still continue to contribute to GCC
> and start BountySource campaigns to support, despite my opinion not being
> of any relevance.

That seems a rather silly overreaction to somebody replying to you,
answering your questions.

Re: size of exception handling (Was: performance of exception handling)

[Jonathan Wakely via Gcc]

On Tue, 12 May 2020 at 09:17, Freddie Chopin wrote:
> The problem with C++ exceptions is that even in the most
> trivial of the programs and even if you don't explicitly
> use/catch/throw them, they instantly eat around 60 kB of ROM and quite
> a lot of RAM. With some hacking you can get down to about 20 kB of ROM
> (by overriding a lot of string formatting code and overriding
> std::terminate()),

You're talking about C++ exceptions in general, but the problems you
mention seems to be issues with specific implementation properties.

If the comments above are referring to the libstdc++ verbose terminate
handler, that's configurable. Configuring GCC with
--disable-libstdcxx-verbose will disable that, and so will building
libstdc++ with -fno-exceptions. That was fixed years ago.

If there are remaining problems where I/O and string routines get
dragged in without exceptions and the verbose terminate handler,
please report bugs against libstdc++. I would expect heroics to be
needed for a tiny footprint, but it should be possible to get a small
footprint just by rebuilding with the right options and flags.

Re: size of exception handling

[Jonathan Wakely via Gcc]

On Tue, 12 May 2020 at 11:48, Freddie Chopin wrote:
> To summarize. Current C++ exceptions have very huge, mostly "one-time"
> kind, cost on the size, even if not used at all by the user, mosly due
> to std::terminate() and all the string handling code inside it, as well
> as the unwind tables.

There is no string handling code in std::terminate:

namespace std
{
  typedef void (*terminate_handler) ();
  void terminate() _GLIBCXX_USE_NOEXCEPT __attribute__ ((__noreturn__));
}

void
__cxxabiv1::__terminate (std::terminate_handler handler) throw ()
{
  __try
{
  handler ();
  std::abort ();
}
  __catch(...)
{ std::abort (); }
}

void
std::terminate () throw()
{
  __terminate (get_terminate ());
}

Please clarify what you're talking about.

Re: size of exception handling (Was: performance of exception handling)

[Jonathan Wakely via Gcc]

On Tue, 12 May 2020, 21:57 Freddie Chopin,  wrote:
>
> On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote:
> > You're talking about C++ exceptions in general, but the problems you
> > mention seems to be issues with specific implementation properties.
>
> Possibly true, but this argument - that all the problems are related to
> specific implementation and thus can be easily fixed


I didn't say anything about it being easy to fix.

I'm just trying to stop misinformation about std::terminate requiring
string handling or I/O, which isn't true for C++ in general, and isn't
even true for libstdc++ because it's configurable. If you want a
smaller EH runtime, that's already possible with libstdc++. Could it
be even smaller? Yes, probably, but we need bug reports or concrete
suggestions, not outdated or misleading claims about optional
properties of the libstdc++ runtime.


> - is the same for
> years and yet the problem is still there (; I guess that if this could
> be easily fixed, then it would be done years ago. Along with the
> performance and non-deterministic execution issues...

Nobody said it can easily be fixed though.

> > If the comments above are referring to the libstdc++ verbose
> > terminate
> > handler, that's configurable. Configuring GCC with
> > --disable-libstdcxx-verbose will disable that, and so will building
> > libstdc++ with -fno-exceptions. That was fixed years ago.
>
> True, sorry for the confusion, indeed I was talking about verbose
> terminate handler. I check the state of C++ exceptions for MCUs only
> once every few years, so that's why I got that mixed with
> std::terminate(). I use my custom compilation with disabled exceptions
> (toolchain & libstdc++ built with -fno-exceptions -fno-rtti) and this
> works perfectly fine.

It's been a few years since we changed anything, because disabling the
verbose handler solved one of the biggest issues.

> Anyway... If you have to recompile the toolchain, the problem is still
> there. Most of the people (like 99,666%) will not do that for various
> reasons. Some don't know how, some use only Windows, some don't have
> time to deal with the compilation (the whole toolchain takes around an
> hour here, but this excludes the time to prepare the script that builds
> it), some other consider the toolchain provided by MCU vendor (or by
> ARM) as "tested to work correctly" so they don't want to replace that
> with their custom built solution, and so on, and so on...

There is no one-size-fits-all solution that gives everybody their
ideal set of defaults, so we provide configuration options to tune
things for your needs. Complaining that you have to rebuild things to
get different defaults seems silly. Would you prefer we don't offer
the options at all?

If you have concrete suggestions for improvements or can identify
places we can improve, I'd like to hear them. If you just want to
complain about C++ exceptions, that's not very helpful.

Re: size of exception handling (Was: performance of exception handling)

[Jonathan Wakely via Gcc]

On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote:
> On Tue, 12 May 2020, 21:57 Freddie Chopin,  wrote:
> > Anyway... If you have to recompile the toolchain, the problem is still
> > there. Most of the people (like 99,666%) will not do that for various
> > reasons. Some don't know how, some use only Windows, some don't have
> > time to deal with the compilation (the whole toolchain takes around an
> > hour here, but this excludes the time to prepare the script that builds
> > it), some other consider the toolchain provided by MCU vendor (or by
> > ARM) as "tested to work correctly" so they don't want to replace that
> > with their custom built solution, and so on, and so on...
>
> There is no one-size-fits-all solution that gives everybody their
> ideal set of defaults, so we provide configuration options to tune
> things for your needs. Complaining that you have to rebuild things to
> get different defaults seems silly. Would you prefer we don't offer
> the options at all?

And I also never said that every user should rebuild the toolchain.
The options can be used by vendors providing a toolchain for their
hardware, if the verbose handler (or exceptions in general!) are not
appropriate for their users. Just because something isn't the default,
doesn't mean every user needs to change it themselves.

And if writing a script and waiting an hour is too much effort to
reduce unwanted overhead, then I guess that overhead isn't such a big
deal anyway.

Re: size of exception handling (Was: performance of exception handling)

[Jonathan Wakely via Gcc]

On Tue, 12 May 2020, 10:15 Oleg Endo,  wrote:
>
> On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote:
> >
> > I actually have to build my own toolchain instead of the one provided
> > by ARM, because to really NOT use C++ exceptions, you have to recompile
> > the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they
> > provide the "nano" libraries, but I the options they used for newlib
> > don't suit my needs - this is "too minimized"). If you pass these two
> > flags during compilation and linking of your own application, this
> > disables these features only in your code. As libstdc++ is compiled
> > with exceptions and RTTI enabled, ...
>
> IMHO this is a conceptual fail of the whole concept of using pre-
> compiled pre-installed libraries somewhere in the toolchain, in
> particular for this kind of cross-compilation scenario.


The concept works well in other scenarios though. Not everybody has
the same use case or the same needs.


>   Like you say,
> when we set "exceptions off" it usually means for the whole embedded
> app, and the whole embedded app usually means all the OS and runtime
> libraries and everything, not just the user code.
>
> One option is to not use the pre-compiled toolchain libstc++ but build
> it from source (or use another c++ std lib of your choice), as part of
> the whole project, with the desired project settings.


Yes, IMO that's probably the right option if there is no pre-compiled
toolchain that matches your desired configuration.

If there are properties of libstdc++ that make it more difficult than
necessary, we want to know about them.


>
> BTW, just to throw in my 2-cents into the "I'm using MCU" pool of
> pain/joy ... in one of my projects I'm using STM32F051K6U6, 32 KB
> flash, 8 KB RAM, running all C++ code with shared C++ RPC libraries to
> communicate with other (bigger) devices.  Exceptions, RTTI, threads
> have to be turned off and only the header-only things from the stdlib
> can be used and no heap allocations.


Are you using headers that are not part of the freestanding subset? Which ones?

A future version of the C++ standard is probably going to expand the
headers that should be part of freestanding (or replace the concept of
freestanding with something more useful) so it would be good to know
what parts of the standard library people are actually using on
devices like that.


> Otherwise the thing doesn't fit.
> Don't feel like rewriting the whole thing either.  There are some
> annoyances when turning off exceptions and RTTI which results in
> increased code maintenance.


Such as?


> I'd definitely be good and highly
> appreciated if there were any improvements in the area of exception
> handling.
>
> Cheers,
> Oleg
>

Re: dejagnu version update?

[Jonathan Wakely via Gcc]

On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc  wrote:
>
> I've changed the subject to match the 2015, 2017 and 2018 email threads.
>
> On May 13, 2020, at 3:26 AM, Thomas Schwinge  wrote:
> >
> > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > vs. "new") that ought to return identical results, I found that they
> > didn't:
>
> > I have not found any evidence in DejaGnu master branch that this not
> > working would've been a "recent" DejaGnu regression (and then fixed for
> > DejaGnu 1.6) -- so do we have to assume that this never worked as
> > intended back then?
>
> Likely not.
>
> > Per our "Prerequisites for GCC" installation documentation, we currently
> > require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> > question, given that it has "just" been released (four years ago).
>
> :-)  A user that wants full coverage should use 1.6, apparently.

As documented at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
anything older than 1.5.3 causes problems for libstdc++ (and probably
the rest of GCC) because the options in --target_board get placed
after the options in dg-options. If the test depends on the options in
dg-options to work properly it might fail. For example, a test that
has { dg-options "-O2" } and fails without optimisation would FAIL if
you use --target_board=unix/-O0 with dejagnu 1.5.


> > As the failure mode with old DejaGnu is "benign" (only causes missing
> > execution testing), we could simply move on, and accept non-reproducible
> > results between different DejaGnu versions?  Kind of lame...  ;-|
>
> An ugly wart to be sure.
>
> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 6, 
> and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone want 
> to not update dejagnu to require 1.6?

There are still lots of older systems in use for GCC dev, like all the
POWER servers in the compile farm (but I've put a recent dejagnu in
/opt/cfarm on some of them).

> I had previously approved the update to 1.5.3, but no one really wanted it as 
> no one updated the requirement.  Let's have the 1.6 discussion.  I'm not only 
> inclined to up to 1.6, but to actually edit it in this time.

Would the tests actually refuse to run with an older version?

> Anyone strongly against?  Why?

I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.

Re: dejagnu version update?

[Jonathan Wakely via Gcc]

On Thu, 14 May 2020 at 07:45, Christophe Lyon wrote:
>
> On Wed, 13 May 2020 at 19:44, Jonathan Wakely via Gcc  wrote:
> >
> > On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc  wrote:
> > >
> > > I've changed the subject to match the 2015, 2017 and 2018 email threads.
> > >
> > > On May 13, 2020, at 3:26 AM, Thomas Schwinge  
> > > wrote:
> > > >
> > > > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > > > vs. "new") that ought to return identical results, I found that they
> > > > didn't:
> > >
> > > > I have not found any evidence in DejaGnu master branch that this not
> > > > working would've been a "recent" DejaGnu regression (and then fixed for
> > > > DejaGnu 1.6) -- so do we have to assume that this never worked as
> > > > intended back then?
> > >
> > > Likely not.
> > >
> > > > Per our "Prerequisites for GCC" installation documentation, we currently
> > > > require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> > > > question, given that it has "just" been released (four years ago).
> > >
> > > :-)  A user that wants full coverage should use 1.6, apparently.
> >
> > As documented at
> > https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
> > anything older than 1.5.3 causes problems for libstdc++ (and probably
> > the rest of GCC) because the options in --target_board get placed
> > after the options in dg-options. If the test depends on the options in
> > dg-options to work properly it might fail. For example, a test that
> > has { dg-options "-O2" } and fails without optimisation would FAIL if
> > you use --target_board=unix/-O0 with dejagnu 1.5.
> >
> I think that was commit:
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commitdiff;h=5256bd82343000c76bc0e48139003f90b6184347
> which for sure was a major change (though I don't see it documented in
> dejagnu/NEWS file)


Yes, that's the one.

Re: The gcc version used for compiling qt4.

[Jonathan Wakely via Gcc]

On Mon, 18 May 2020 at 13:34, Hongyi Zhao via Gcc  wrote:
>
> Hi,
>
> I want to compile qt4 on Ubuntu 20.04 which shipped with the following
> gcc version:
>
> $ gcc --version
> gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
>
> But I'm not sure whether this gcc version is suitable for qt4.  Any
> hints for this problem?

Check the Qt4 docs, or just try it and see if it works.

Re: 0800-GIT-HELP: Doing a simple backport

[Jonathan Wakely via Gcc]

On Tue, 19 May 2020 at 17:19, Gerald Pfeifer  wrote:
>
> I hope the offer by some of you to support people like me who Git
> appears to hate with a fervor still stands? ;-)
>
> And I volunteer to enhance our documentation if it appears useful.
>
>
> Usecase: I've got a patch approved and pushed to HEAD, and approved
> for active release branches - 13a46321516e2efd3bbb1f1899c539c6724240a9 .
>
> Now I want to backport from HEAD to the GCC 10 tree, so checked out a
> copy, found git cherry-pick, and gave it a try:
>
>   git cherry-pick 13a46321516e2efd3bbb1f1899c539c6724240a9
>   Auto-merging gcc/ChangeLog
>   CONFLICT (content): Merge conflict in gcc/ChangeLog
>   error: could not apply 13a46321516... i386: Define __ILP32__ and _ILP32 for 
> all 32-bit targets
>   hint: after resolving the conflicts, mark the corrected paths
>   hint: with 'git add ' or 'git rm '
>   hint: and commit the result with 'git commit'
>
> What now?  I can manually fix up gcc/ChangeLog, but `git diff` then
> shows a fairly big diff (essentially all changes since the one I am
> trying to cherry pick)?

Then you fixed it up wrong, or didn't 'git add' after fixing it.

'git cherry-pick --abort' will bail out and undo the mess.



>
> So ... is git cherry-pick even the right tool?

Yes.


>
> And if so, how do I best go about conflicts happening as part of
> that, ChangeLog or otherwise?

Follow the instructions at https://gcc.gnu.org/gitwrite.html#changelog

Re: 0800-GIT-HELP: Doing a simple backport

[Jonathan Wakely via Gcc]

On Tue, 19 May 2020 at 17:36, Jonathan Wakely  wrote:
>
> On Tue, 19 May 2020 at 17:19, Gerald Pfeifer  wrote:
> >
> > I hope the offer by some of you to support people like me who Git
> > appears to hate with a fervor still stands? ;-)
> >
> > And I volunteer to enhance our documentation if it appears useful.
> >
> >
> > Usecase: I've got a patch approved and pushed to HEAD, and approved
> > for active release branches - 13a46321516e2efd3bbb1f1899c539c6724240a9 .
> >
> > Now I want to backport from HEAD to the GCC 10 tree, so checked out a
> > copy, found git cherry-pick, and gave it a try:
> >
> >   git cherry-pick 13a46321516e2efd3bbb1f1899c539c6724240a9
> >   Auto-merging gcc/ChangeLog
> >   CONFLICT (content): Merge conflict in gcc/ChangeLog
> >   error: could not apply 13a46321516... i386: Define __ILP32__ and _ILP32 
> > for all 32-bit targets
> >   hint: after resolving the conflicts, mark the corrected paths
> >   hint: with 'git add ' or 'git rm '
> >   hint: and commit the result with 'git commit'
> >
> > What now?  I can manually fix up gcc/ChangeLog, but `git diff` then
> > shows a fairly big diff (essentially all changes since the one I am
> > trying to cherry pick)?
>
> Then you fixed it up wrong, or didn't 'git add' after fixing it.

N.B. the git error above does tell you to do 'git add ' on the
files with conflicts, after resolving the conflicts (which is done the
same way as for svn conflicts).

When git gives you hints about what to do they're often right.

>
> 'git cherry-pick --abort' will bail out and undo the mess.
>
>
>
> >
> > So ... is git cherry-pick even the right tool?
>
> Yes.
>
>
> >
> > And if so, how do I best go about conflicts happening as part of
> > that, ChangeLog or otherwise?
>
> Follow the instructions at https://gcc.gnu.org/gitwrite.html#changelog

Re: New mklog script

[Jonathan Wakely via Gcc]

On Tue, 19 May 2020 at 17:13, Joseph Myers wrote:
>
> On Tue, 19 May 2020, Martin Liška wrote:
>
> > On 5/19/20 10:11 AM, Martin Liška wrote:
> > > Can you please share how do you do it? It would be easy to add it.
> >
> > I added the feature via --fill-up-bug-titles option. It uses common
> > request and beatifulsoup packages.
>
> The REST interface is much better to use for extracting bug data than
> screen scraping of HTML output.  Fetch e.g.
> https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=12345&include_fields=summary
> to get JSON bug data (change or omit include_fields if you want more than
> just the summary).

REST+JSON is probably better for the mklog.py script, but in case this
is useful to anybody else, I get bugzilla info by fetching the XML for
a bug using the URL
https://gcc.gnu.org/bugzilla/show_bug.cgi?ctype=xml&id= and
applying this stylesheet:


http://www.w3.org/1999/XSL/Transform";
version="1.0">


  
   
  
   
  
  

Re: New mklog script

[Jonathan Wakely via Gcc]

On Tue, 19 May 2020 at 09:26, Jakub Jelinek via Gcc  wrote:
>
> On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
> > > I find this format more helpful for the reasons below so unless your
> > > script can be tweaked to do something similar I'd like to be able to
> > > continue to use mine going forward with the new infrastructure.
> >
> > Let's extend the contrib script.
>
> BTW, concerning mklog, the very common problem is that it doesn't do the
> right thing because the patch doesn't contain enough context to figure out
> what exactly has changed.  If the script would be used together with git
> rather than just on a patch file, perhaps it could handle more, like
> ask git for a patch with unlimited context (like -U1 on patch does).
> The common problems I remember is that e.g. when changing a function comment
> above some function, it is attributed to the previous function rather than
> following, labels in function confusing it:
>  void
>  foo ()
>  {
>...
>  label:
>...
> -  ...
> +  ...
>  }
> will result in (label), GTY markers confusing it
>  struct GTY foobar {
>...
> -  ...
> +  ...
>  };
> resulting in (struct GTY) or so, another common problem is too large
> function names (or more often *.md define_* names); here I'm afraid
> diff doesn't have an argument to not truncate it, or sometimes e.g. changes
> to #define being attributed to something else.
> I know some of the issues can be pretty hard to deal with.

This isn't a complaint, because I don't expect them to work, but
mklog.py (and diff --show-c-function) are useless for libstdc++ code,
they can't handle namespaces and result in nonsense like:

--- a/libstdc++-v3/src/c++11/random.cc
+++ b/libstdc++-v3/src/c++11/random.cc
@@ -97,7 +97,7 @@ namespace std _GLIBCXX_VISIBILITY(default)

and

libstdc++-v3/ChangeLog:

* src/c++11/random.cc (_GLIBCXX_VISIBILITY):
* testsuite/26_numerics/random/random_device/94087.cc: New test.

Re: ChangeLog files - server and client scripts

[Jonathan Wakely via Gcc]

On Tue, 19 May 2020 at 11:44, Martin Liška  wrote:
>
> Hello.
>
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison of auto-generated CangeLog entries.
>
> The format is documented here:
> https://gcc.gnu.org/codingconventions.html#ChangeLogs
>
> And I would recommend to install the new 'git gcc-verify' hook from:
> contrib/gcc-git-customization.sh
>
> Feel free to contact me about future troubles you'll see.

The --allow-non-strict-mode option seems unnecessarily verbose. It's
not allowing non-strict mode, it's enabling it. Would --non-strict or
--relaxed be better?

And I don't understand the help text for it. 'Use non-strict mode
(change in both ChangeLog and other files.' It seems that non-strict
mode allows changes to certain "project files" that are not supposed
to be manually edited, but I can't correlate that to "change in both
ChangeLog and other files". It's also missing the closing parenthesis.

Would this patch make sense?
diff --git a/contrib/gcc-changelog/git_check_commit.py 
b/contrib/gcc-changelog/git_check_commit.py
index 8553c90a96f..d504be9dbde 100755
--- a/contrib/gcc-changelog/git_check_commit.py
+++ b/contrib/gcc-changelog/git_check_commit.py
@@ -28,9 +28,9 @@ parser.add_argument('-g', '--git-path', default='.',
 help='Path to git repository')
 parser.add_argument('-p', '--print-changelog', action='store_true',
 help='Print final changelog entires')
-parser.add_argument('-n', '--allow-non-strict-mode', action='store_true',
-help='Allow non-strict mode (change in both ChangeLog and '
-'other files.')
+parser.add_argument('-n', '--non-strict-mode', action='store_true',
+help='Use non-strict mode (allow changes in ChangeLog and '
+'other automatically updated files.')
 args = parser.parse_args()
 
 retval = 0

Re: ChangeLog files - server and client scripts

[Jonathan Wakely via Gcc]

On Tue, 19 May 2020 at 23:19, Jonathan Wakely  wrote:
>
> On Tue, 19 May 2020 at 11:44, Martin Liška  wrote:
> >
> > Hello.
> >
> > We've just installed server git hooks that verify git messages
> > for a correct ChangeLog format. For a limited time period, please
> > still apply ChangeLog changes to the corresponding ChangeLog files.
> > We'll use it for comparison of auto-generated CangeLog entries.
> >
> > The format is documented here:
> > https://gcc.gnu.org/codingconventions.html#ChangeLogs
> >
> > And I would recommend to install the new 'git gcc-verify' hook from:
> > contrib/gcc-git-customization.sh
> >
> > Feel free to contact me about future troubles you'll see.
>
> The --allow-non-strict-mode option seems unnecessarily verbose. It's
> not allowing non-strict mode, it's enabling it. Would --non-strict or
> --relaxed be better?
>
> And I don't understand the help text for it. 'Use non-strict mode
> (change in both ChangeLog and other files.' It seems that non-strict
> mode allows changes to certain "project files" that are not supposed
> to be manually edited, but I can't correlate that to "change in both
> ChangeLog and other files". It's also missing the closing parenthesis.
>
> Would this patch make sense?

Or this one that actually adds the closing parenthesis :-)
diff --git a/contrib/gcc-changelog/git_check_commit.py 
b/contrib/gcc-changelog/git_check_commit.py
index 8553c90a96f..4fa2bb0b4a2 100755
--- a/contrib/gcc-changelog/git_check_commit.py
+++ b/contrib/gcc-changelog/git_check_commit.py
@@ -28,9 +28,9 @@ parser.add_argument('-g', '--git-path', default='.',
 help='Path to git repository')
 parser.add_argument('-p', '--print-changelog', action='store_true',
 help='Print final changelog entires')
-parser.add_argument('-n', '--allow-non-strict-mode', action='store_true',
-help='Allow non-strict mode (change in both ChangeLog and '
-'other files.')
+parser.add_argument('-n', '--non-strict-mode', action='store_true',
+help='Use non-strict mode (allow changes in ChangeLog and '
+'other automatically updated files).')
 args = parser.parse_args()
 
 retval = 0

Re: condition variables on vxworks

[Jonathan Wakely via Gcc]

On Wed, 20 May 2020 at 09:44, Rasmus Villemoes  wrote:
>
> Hi
>
> The condition variable implementation added in commit 806dd0472f56fd
> seems to fall into the trap(s) pointed out in the paper
>
>   http://birrell.org/andrew/papers/ImplementingCVs.pdf
>
> in particular, the "if no thread is currently waiting, signal should not
> leave a full semaphore so a following _wait will just fall through".
>
> Now, libgcc/gthr.h doesn't really spell out whether __gthread condition
> variables are supposed to behave as POSIX condition variables, so I
> don't know if it's a problem in practice.

The libstdc++ std::condition_variable assumes POSIX-ish semantics for
__gthread_cond_t. It certainly assumes that a signal/broadcast will
only wake threads that are currently waiting, not affect waits that
haven't started yet. So it seems gthr-vxworks.h should not set
__GTHREADS_CXX0X, or libstdc++ needs a different condition_variable
implementation for VxWorks.

Libstdc++ also assumes this requirement of pthread_cond_destroy is met:
"It shall be safe to destroy an initialized condition variable upon
which no threads are currently blocked."
This means it's OK for another thread to destroy the CV after the
semTake (*cond, WAIT_FOREVER) statement in __ghtread_cond_wait, even
if the semTake (*mutex, WAIT_FOREVER) statement hasn't happened. The
code looks OK as far as that requirement goes.

I'm not sure how many other implicit assumptions libstdc++ makes about
POSIX-ish semantics.

As an aside, it looks like there are enough libgcc/config/*vx* files
to justify creating a libgcc/config/vxworks sub-directory.

Re: dialect option change affect on existing code

[Jonathan Wakely via Gcc]

N.B. I've redirected this to gcc-help where it's on-topic. Please
answer there instead.

On Wed, 20 May 2020 at 22:35, Ted Toth via Gcc  wrote:
>
> I work on a project with a large code base some of which is pretty old. We
> are discussing adding -std=gnu++11 to our g++ compiles to be able to use
> newer classes/features but there are concerns that there could be
> unintended consequences. For existing code that doesn't use any new
> features/classes  can it be expected that its function will not be altered
> by use of this flag? Will we have to regression all of our c++ code?
>
> Ted

Re: How to deal with the different result when executing UB programs?

[Jonathan Wakely via Gcc]

On Fri, 22 May 2020 at 06:54, Haoxin Tu via Gcc  wrote:
>
> Hi, there!
>
> I am new for using GCC mail list, please forgive me if something is wrong.

You're using the wrong mailing list, see
https://gcc.gnu.org/lists.html which says this question should be on
the gcc-help list. Please send any replies there instead.

> I have some issues about how GCC deal with the different optimizations in a
> UB program.

It's undefined. Anything can happen. We're not going to define the
behaviour of undefined behaviour, because it's undefined.

https://en.wikipedia.org/wiki/Undefined_behavior
https://en.cppreference.com/w/cpp/language/ub

Re: New mklog script

[Jonathan Wakely via Gcc]

On Fri, 22 May 2020 at 19:15, Thomas Koenig via Gcc  wrote:
>
> Hi,
>
> what's currently in trunk (as of a few hours ago) fails for me with
>
>File "contrib/mklog.py", line 36, in 
>  from unidiff import PatchSet
> ModuleNotFoundError: No module named 'unidiff'
>
> I think this is an error which would have to be taken into account
> one way or another - maybe include it in download_prerequisites ?

No, most people do not want download_prerequisites to start installing
python packages, they should use their system's package manager.


>
> Regards
>
> Thomas

Re: g++ compiler produces an error on Redhat Linux # 4.8.5-39

[Jonathan Wakely via Gcc]

Your question is inappropriate on this mailing list, and I already
answered it on the gcc-help list anyway.


On Thu, 28 May 2020 at 18:22, kiran kumar vangara via Gcc
 wrote:
>
> Team,
>
> We have been compiling cpp files with g++ compiler on Redhat Linux OS
> machine and as part of this -mt option was given for g++ and it produced
> required binary in case # 1 but produced an error in case#2 , I'm sharing
> g++ version and the Redhat Linux OS version being used to compile the cpp
> code details  below .. Can you please let us know what is the meaning of
> flag -mt and why it works in case#1 but not in case#2
>
> Case#1
> --
> g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
>
> Case# 2
> 
> g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
>
> In this case the error produced by compiler is
>
> g++: error: unrecognized command line option -mt
>
> your help will be greatly appreciated .
>
> Thanks,
> Kiran

Re: [1-800-GIT-HELP] Backporting a series of commits into a combined commit?

[Jonathan Wakely via Gcc]

On Sat, 30 May 2020 at 21:09, Harald Anlauf  wrote:
>
> Dear experts,
>
> let's assume I need to backport a series of commits on master to a release 
> branch.
> In the release branch, this series of commits should become a single commit.
>
> With bare git, there is "cherry-pick -n" that seems to be applicable.
>
> What is the right way to do it for gcc?

I do it with cherry-pick -n.

Or you can cherry-pick each one, then do git rebase --interactive to
squash them all into one.

Re: [1-800-GIT-HELP] Backporting a series of commits into a combined commit?

[Jonathan Wakely via Gcc]

On Mon, 1 Jun 2020 at 12:56, Thomas Koenig  wrote:
>
> Hi Martin,
>
> > For now, I would recommend doing 1:1 backports. Otherwise, you'll need
> > to merge
> > all ChangeLog entries in a format the server hook accepts. That can
> > require some
> > work.
>
> If the first commit caused a regression, which the second one fixed,
> this would keep the first regression, right?  Is that what we want?

It will only "keep" it for a matter of seconds, between that
backported commit and the backported fix. And unless you push the
first commit before pushing the fix, nobody will ever see the
regression without also seeing the fix (unless they specifically check
out the branch at the point of the first commit).

Re: [1-800-GIT-HELP] Backporting a series of commits into a combined commit?

[Jonathan Wakely via Gcc]

On Mon, 1 Jun 2020 at 13:25, Thomas Koenig  wrote:
>
> Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
> > It will only "keep" it for a matter of seconds, between that
> > backported commit and the backported fix. And unless you push the
> > first commit before pushing the fix, nobody will ever see the
> > regression without also seeing the fix (unless they specifically check
> > out the branch at the point of the first commit).
>
> Or they do a regression hunt.

Which would specifically check out the branch at the point of the first commit.

> I thought it was policy not to have broken revisions on gcc.
> Am I wrong?

We all commit broken revisions. And then fix them.

If you're concerned, squash them into a single commit. It's probably
not hard to alter the commit log to be a single entry that describes
the original change and the fix. You can always be more descriptive
(and even give the IDs of the original commits on master) in the
freeform text paragraphs before the ChangeLog entry.

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Mon, 25 May 2020 at 23:50, Jakub Jelinek via Gcc  wrote:
>
> Hi!
>
> I've turned the strict mode of Martin Liška's hook changes,
> which means that from now on no commits to the trunk or release branches
> should be changing any ChangeLog files together with the other files,
> ChangeLog entry should be solely in the commit message.
> The DATESTAMP bumping script will be updating the ChangeLog files for you.
> If somebody makes a mistake in that, please wait 24 hours (at least until
> after 00:16 UTC after your commit) so that the script will create the
> ChangeLog entries, and afterwards it can be fixed by adjusting the ChangeLog
> files.  But you can only touch the ChangeLog files in that case (and
> shouldn't write a ChangeLog entry for that in the commit message).
>
> If anything goes wrong, please let me, other RMs and Martin Liška know.

The libstdc++ manual is written in Docbook XML, but we commit both the
XML and generated HTML pages to Git. Sometimes a small XML file can
result in dozens of mechanical changes to the generated HTML files,
which we record in the ChangeLog as:

* doc/html/*: Regenerated.

With the new checks we need to name every generated file individually.

If we add that directory to the ignored_prefixes list, we won't need
to name them. But then the doc/html/* entry will give an error, and
changes to the HTML files can be committed without any ChangeLog
entry. Should we just stop mentioning the HTML in the ChangeLog?

We could do something like the attached patch, but it seems overkill
for this one special case.
diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 4f82b58f64b..add0defaeed 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -501,6 +501,7 @@ class GitCommit:
 assert folder_count == len(self.changelog_entries)
 
 mentioned_files = set()
+libstdcxx_html_regenerated = False
 for entry in self.changelog_entries:
 if not entry.files:
 msg = 'ChangeLog must contain a file entry'
@@ -508,16 +509,33 @@ class GitCommit:
 assert not entry.folder.endswith('/')
 for file in entry.files:
 if not self.is_changelog_filename(file):
-mentioned_files.add(os.path.join(entry.folder, file))
+file = os.path.join(entry.folder, file)
+if file == 'libstdc++-v3/doc/html/*':
+libstdcxx_html_regenerated = True
+else:
+mentioned_files.add(file)
 
 cand = [x[0] for x in self.modified_files
 if not self.is_changelog_filename(x[0])]
 changed_files = set(cand)
+if libstdcxx_html_regenerated:
+libstdcxx_html_regenerated = False
+for c in changed_files:
+if c.startswith('libstdc++-v3/doc/html/'):
+libstdcxx_html_regenerated = True
+break
+if not libstdcxx_html_regenerated:
+self.errors.append(Error('No libstdc++ HTML changes found'))
+
 for file in sorted(mentioned_files - changed_files):
 self.errors.append(Error('file not changed in a patch', file))
 for file in sorted(changed_files - mentioned_files):
 if not self.in_ignored_location(file):
-if file in self.new_files:
+if file.startswith('libstdc++-v3/doc/html/'):
+if not libstdcxx_html_regenerated:
+msg = 'libstdc++ HTML changes not in ChangeLog'
+self.errors.append(Error(msg, file))
+elif file in self.new_files:
 changelog_location = self.get_changelog_by_path(file)
 # Python2: we cannot use next(filter(...))
 entries = filter(lambda x: x.folder == changelog_location,

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Jonathan Wakely via Gcc]

On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc  wrote:
>
> Hi -
>
> > git pull from the GCC and Glibc repos is failing for me with the error
> > below.  It worked fine last week and I haven't made any changes to my
> > ssh keys.
>
> And are you logging in from the same workstation with access to the same
> set of ssh private keys?
>
> > Is this a transient glitch or has something changed recently that I
> > need to make some adjustments for?
>
> I know of nothing relevant that has changed on the sourceware side.
>
> > sign_and_send_pubkey: signing failed: agent refused operation
> > mse...@gcc.gnu.org: Permission denied (publickey).
> > fatal: Could not read from remote repository.
>
> The usual advice is to run   % ssh -vv gcc.gnu.org alive
> and report the ssh level error.
>
> "agent refused operation" sounds like a problem on the client end.

Yes, it is. "agent" refers to the ssh-agent program.

Martin, what does 'ssh-add -l' show?

Is there only one ssh-agent process shown by 'ps -ef | fgrep
[s]sh-agent'? Does its PID match $SSH_AGENT_PID?

Another possible cause is that the file permissions are not strict
enough on the private key, or on the ~/.ssh directory that contains
it. Key files should be 600 and ~/.ssh should be 700.

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Jonathan Wakely via Gcc]

On Mon, 1 Jun 2020 at 20:16, Martin Sebor via Gcc  wrote:
>
> On 6/1/20 12:10 PM, Frank Ch. Eigler wrote:
> > Hi -
> >
> >> git pull from the GCC and Glibc repos is failing for me with the error
> >> below.  It worked fine last week and I haven't made any changes to my
> >> ssh keys.
> >
> > And are you logging in from the same workstation with access to the same
> > set of ssh private keys?
>
> Yes.
>
> >
> >> Is this a transient glitch or has something changed recently that I
> >> need to make some adjustments for?
> >
> > I know of nothing relevant that has changed on the sourceware side.
> >
> >> sign_and_send_pubkey: signing failed: agent refused operation
> >> mse...@gcc.gnu.org: Permission denied (publickey).
> >> fatal: Could not read from remote repository.
> >
> > The usual advice is to run   % ssh -vv gcc.gnu.org alive
> > and report the ssh level error.
> >
> > "agent refused operation" sounds like a problem on the client end.
>
> Until last week, when I ran git pull from the GCC or Glibc repo
> I'd get prompted for my password.  I'd either type it in or hit
> ctrl-C, enter ssh-add, and start over.
>
> After deleting ~/.ssh/known_hosts to resolve the problem I asked
> about last week (Re: ssh key conflicts), I'm no longer prompted
> for my password.  Instead, I get the error above.

Is ~/.ssh/known_hosts no longer present? Is ~/.ssh writable by your
user? The ssh client (or the agent) will try to create
~/.ssh/known_hosts if it doesn't exist, to add the host key. If ~/.ssh
is not writable that will fail.

> Both of this is new (I think since the recent server changes).  Now

The host key did change after the server upgrade, that's expected. The
other problem is not caused by the server.

> that I've seen it and know what to expect I can adjust to it but it
> seems like things have gotten worse.  Certainly the errors I got
> in both instances (i.e., last week as well as today) are not helpful.

SSH errors usually aren't.

> I captured the ssh -vv gcc.gnu.org output below for a successful
> invocation and a failed one if that sheds more light on why it's
> failing in (to me) a mysterious way.

The failed attempt shows that your public key is offered to the
server, and the server says it will accept it (meaning it matches a
~/.ssh/authorized_keys entry on the server) but then your client
refuses to use that key.

Check your ~/.ssh and ~/.ssh/id_rsa* permissions.

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Jonathan Wakely via Gcc]

On Mon, 1 Jun 2020 at 20:46, Martin Sebor  wrote:
>
> On 6/1/20 1:25 PM, Jonathan Wakely wrote:
> > On Mon, 1 Jun 2020 at 20:16, Martin Sebor via Gcc  wrote:
> >>
> >> On 6/1/20 12:10 PM, Frank Ch. Eigler wrote:
> >>> Hi -
> >>>
>  git pull from the GCC and Glibc repos is failing for me with the error
>  below.  It worked fine last week and I haven't made any changes to my
>  ssh keys.
> >>>
> >>> And are you logging in from the same workstation with access to the same
> >>> set of ssh private keys?
> >>
> >> Yes.
> >>
> >>>
>  Is this a transient glitch or has something changed recently that I
>  need to make some adjustments for?
> >>>
> >>> I know of nothing relevant that has changed on the sourceware side.
> >>>
>  sign_and_send_pubkey: signing failed: agent refused operation
>  mse...@gcc.gnu.org: Permission denied (publickey).
>  fatal: Could not read from remote repository.
> >>>
> >>> The usual advice is to run   % ssh -vv gcc.gnu.org alive
> >>> and report the ssh level error.
> >>>
> >>> "agent refused operation" sounds like a problem on the client end.
> >>
> >> Until last week, when I ran git pull from the GCC or Glibc repo
> >> I'd get prompted for my password.  I'd either type it in or hit
> >> ctrl-C, enter ssh-add, and start over.
> >>
> >> After deleting ~/.ssh/known_hosts to resolve the problem I asked
> >> about last week (Re: ssh key conflicts), I'm no longer prompted
> >> for my password.  Instead, I get the error above.
> >
> > Is ~/.ssh/known_hosts no longer present? Is ~/.ssh writable by your
> > user? The ssh client (or the agent) will try to create
> > ~/.ssh/known_hosts if it doesn't exist, to add the host key. If ~/.ssh
> > is not writable that will fail.
>
> ~/.ssh/known_hosts exists and ~/.ssh is rwx only by the owner.
> Everything works fine if I add my key by running ssh-add.  What's
> not so great is the errors I get when I forget to do that: "agent
> refused operation?"

Is $SSH_ASKPASS set in your environment? Does running the command it's
set to work?

Are you using the openssh agent, or something else like gpg-agent or
GNOME keyring?

It's not a server-side error though. The server can't prevent your
agent from prompting you for your key's passphrase.

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer  wrote:
>
> On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> > The libstdc++ manual is written in Docbook XML, but we commit both the
> > XML and generated HTML pages to Git. Sometimes a small XML file can
> > result in dozens of mechanical changes to the generated HTML files,
> > which we record in the ChangeLog as:
> >
> > * doc/html/*: Regenerated.
> >
> > With the new checks we need to name every generated file individually.
> >
> > If we add that directory to the ignored_prefixes list, we won't need
> > to name them. But then the doc/html/* entry will give an error, and
> > changes to the HTML files can be committed without any ChangeLog
> > entry. Should we just stop mentioning the HTML in the ChangeLog?
> >
> > We could do something like the attached patch, but it seems overkill
> > for this one special case.
>
> The change makes sense, but indeed it feels like a very specialized
> case in a general script.

Yes, that was my thought too.

> Thinking out of the box (and admittedly with a dose of igorance, which
> means I am likely missing something): Is not keeping the libstdc++/doc
> HTML in Git a viable option?  Only creating that HTML as part of releases
> and maybe snapshots?

It gets sync'd to https://gcc.gnu.org/onlinedocs/libstdc++ nightly. We
could generate it nightly, but we'd need all the docbook stylesheets
etc. on sourceware. Or we could just generate it for snapshots (which
would still need the docbook stuff on the server) and only sync the
onlinedocs weekly from the snapshot.

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 07:44, Martin Liška  wrote:
>
> On 6/1/20 7:24 PM, Jonathan Wakely wrote:
> > On Mon, 25 May 2020 at 23:50, Jakub Jelinek via Gcc  wrote:
> >>
> >> Hi!
> >>
> >> I've turned the strict mode of Martin Liška's hook changes,
> >> which means that from now on no commits to the trunk or release branches
> >> should be changing any ChangeLog files together with the other files,
> >> ChangeLog entry should be solely in the commit message.
> >> The DATESTAMP bumping script will be updating the ChangeLog files for you.
> >> If somebody makes a mistake in that, please wait 24 hours (at least until
> >> after 00:16 UTC after your commit) so that the script will create the
> >> ChangeLog entries, and afterwards it can be fixed by adjusting the 
> >> ChangeLog
> >> files.  But you can only touch the ChangeLog files in that case (and
> >> shouldn't write a ChangeLog entry for that in the commit message).
> >>
> >> If anything goes wrong, please let me, other RMs and Martin Liška know.
> >
> > The libstdc++ manual is written in Docbook XML, but we commit both the
> > XML and generated HTML pages to Git. Sometimes a small XML file can
> > result in dozens of mechanical changes to the generated HTML files,
> > which we record in the ChangeLog as:
> >
> >  * doc/html/*: Regenerated.
> >
> > With the new checks we need to name every generated file individually.
> >
> > If we add that directory to the ignored_prefixes list, we won't need
> > to name them. But then the doc/html/* entry will give an error, and
> > changes to the HTML files can be committed without any ChangeLog
> > entry. Should we just stop mentioning the HTML in the ChangeLog?
> >
> > We could do something like the attached patch, but it seems overkill
> > for this one special case.
> >
>
> The patch is fine to me.
> Can you please a pytest for the situation: 
> contrib/gcc-changelog/test_email.py ?

Tests now added (and passing) for the positive case and both negative cases.
commit 21f171e1f8af7e222a87523d7957174f985a1dd5
Author: Jonathan Wakely 
Date:   Mon Jun 1 18:33:48 2020 +0100

gcc-changelog: Allow "doc/html/*" in libstdc++ changelog

contrib/ChangeLog:

* gcc-changelog/git_commit.py (check_mentioned_files): Allow
wildcard path for generated files in libstdc++-v3/doc/html.
* gcc-changelog/test_email.py (test_libstdcxx_html_regenerated):
New test.
* gcc-changelog/test_patches.txt: Add patches.

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index b8c7f718c50..d723d890f31 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -501,6 +501,7 @@ class GitCommit:
 assert folder_count == len(self.changelog_entries)
 
 mentioned_files = set()
+libstdcxx_html_regenerated = False
 for entry in self.changelog_entries:
 if not entry.files:
 msg = 'ChangeLog must contain at least one file entry'
@@ -508,16 +509,33 @@ class GitCommit:
 assert not entry.folder.endswith('/')
 for file in entry.files:
 if not self.is_changelog_filename(file):
-mentioned_files.add(os.path.join(entry.folder, file))
+file = os.path.join(entry.folder, file)
+if file == 'libstdc++-v3/doc/html/*':
+libstdcxx_html_regenerated = True
+else:
+mentioned_files.add(file)
 
 cand = [x[0] for x in self.modified_files
 if not self.is_changelog_filename(x[0])]
 changed_files = set(cand)
+if libstdcxx_html_regenerated:
+libstdcxx_html_regenerated = False
+for c in changed_files:
+if c.startswith('libstdc++-v3/doc/html/'):
+libstdcxx_html_regenerated = True
+break
+if not libstdcxx_html_regenerated:
+self.errors.append(Error('No libstdc++ HTML changes found'))
+
 for file in sorted(mentioned_files - changed_files):
 self.errors.append(Error('file not changed in a patch', file))
 for file in sorted(changed_files - mentioned_files):
 if not self.in_ignored_location(file):
-if file in self.new_files:
+if file.startswith('libstdc++-v3/doc/html/'):
+if not libstdcxx_html_regenerated:
+msg = 'libstdc++ HTML changes not in ChangeLog'
+self.errors.append(Error(msg, file))
+elif file in self.new_files:
 changelog_location = self.get_changelog_by_path(file)
 # Python2: we cannot use next(filter(...))
 entries = filter(lambda x: x.folder == changelog_location,
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index 2

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 12:05, Jonathan Wakely  wrote:
>
> On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer  wrote:
> >
> > On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> > > The libstdc++ manual is written in Docbook XML, but we commit both the
> > > XML and generated HTML pages to Git. Sometimes a small XML file can
> > > result in dozens of mechanical changes to the generated HTML files,
> > > which we record in the ChangeLog as:
> > >
> > > * doc/html/*: Regenerated.
> > >
> > > With the new checks we need to name every generated file individually.
> > >
> > > If we add that directory to the ignored_prefixes list, we won't need
> > > to name them. But then the doc/html/* entry will give an error, and
> > > changes to the HTML files can be committed without any ChangeLog
> > > entry. Should we just stop mentioning the HTML in the ChangeLog?
> > >
> > > We could do something like the attached patch, but it seems overkill
> > > for this one special case.
> >
> > The change makes sense, but indeed it feels like a very specialized
> > case in a general script.
>
> Yes, that was my thought too.

On the other hand, the script is just meant to enforce our policies,
not dictate them. But on the gripping hand, if the policy can't be
checked simply, maybe it's a bad policy.

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 12:09, Jonathan Wakely  wrote:
>
> On Tue, 2 Jun 2020 at 12:05, Jonathan Wakely  wrote:
> >
> > On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer  wrote:
> > >
> > > On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> > > > The libstdc++ manual is written in Docbook XML, but we commit both the
> > > > XML and generated HTML pages to Git. Sometimes a small XML file can
> > > > result in dozens of mechanical changes to the generated HTML files,
> > > > which we record in the ChangeLog as:
> > > >
> > > > * doc/html/*: Regenerated.
> > > >
> > > > With the new checks we need to name every generated file individually.
> > > >
> > > > If we add that directory to the ignored_prefixes list, we won't need
> > > > to name them. But then the doc/html/* entry will give an error, and
> > > > changes to the HTML files can be committed without any ChangeLog
> > > > entry. Should we just stop mentioning the HTML in the ChangeLog?
> > > >
> > > > We could do something like the attached patch, but it seems overkill
> > > > for this one special case.
> > >
> > > The change makes sense, but indeed it feels like a very specialized
> > > case in a general script.
> >
> > Yes, that was my thought too.
>
> On the other hand, the script is just meant to enforce our policies,
> not dictate them. But on the gripping hand, if the policy can't be
> checked simply, maybe it's a bad policy.

Similar to "doc/html/*" I've sometimes used "testsuite/*" for changes
that affect huge numbers of files in the libstdc++ testsuite, e.g.
commit r7-2817-52066eae5d3dd6b7c0a1b843469582dbdbb941eb did:

 2911 files changed, 3072 insertions(+), 4512 deletions(-)

I don't want to list thousands of files at once. So maybe a general
approach for allowing wildcards in specific directories makes sense.

What will we do on January 1 2021 when Jakub updates the copyright
years in every file in the tree, turn off the hook temporarily?

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 14:16, Martin Liška  wrote:
>
> On 6/2/20 1:48 PM, Martin Liška wrote:
> > I tend to this approach. Let me prepare a patch candidate for it.
>
> There's a patch for it. Can you please Jonathan take a look?

Looks great, thanks!

+if name not in wildcard_prefixes:
+msg = 'unsupported wilcard prefix'

Typo "wilcard"

+if pattern not in used_patterns:
+self.errors.append(Error('a file pattern not used in a patch',
+ pattern))

If the script printed this error I don't think I'd know what it was
complaining about. How about "pattern doesn't match any changed files"
?

I find the existing error 'file not changed in a patch' to be
suboptimal too. We're checking revisions (or commits), not patches.

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely  wrote:
>
> On Tue, 2 Jun 2020 at 14:16, Martin Liška  wrote:
> >
> > On 6/2/20 1:48 PM, Martin Liška wrote:
> > > I tend to this approach. Let me prepare a patch candidate for it.
> >
> > There's a patch for it. Can you please Jonathan take a look?
>
> Looks great, thanks!
>
> +if name not in wildcard_prefixes:
> +msg = 'unsupported wilcard prefix'
>
> Typo "wilcard"
>
> +if pattern not in used_patterns:
> +self.errors.append(Error('a file pattern not used in a 
> patch',
> + pattern))
>
> If the script printed this error I don't think I'd know what it was
> complaining about. How about "pattern doesn't match any changed files"
> ?
>
> I find the existing error 'file not changed in a patch' to be
> suboptimal too. We're checking revisions (or commits), not patches.

Along those lines, here's an incomplete patch (tests aren't updated
yet, no commit log, your latest change isn't merged ) to revise the
error messages. I've tried to make them more consistent (e.g change
'file not changed in a patch' to 'unchanged file mentioned in a
ChangeLog' which mirrors the error for the opposite condition,
'changed file not mentioned in a ChangeLog').

I've also moved line numbers to the start of the line (like GCC's own
diagnostics) and not used the "line" argument of the Error constructor
for things that aren't line numbers. I've aimed to be consistent, so
that line numbers come at the start, pathnames and patterns come at
the end (and there's a space before them).

I also suggest changing 'additional author must prepend with tab and 4
spaces' to 'additional author must be indented with one tab and four
spaces'.

The intent is to improve the user experience, since for many people
who are new to git *any* error can cause confusion, so extra,
gcc-specific errors that we issue should aim to be easy to understand.

Do you like the direction?
diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 069900d7cbf..453f0f61803 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -173,10 +173,9 @@ class Error:
 self.line = line
 
 def __repr__(self):
-s = self.message
 if self.line:
-s += ':"%s"' % self.line
-return s
+return '%d: %s' % (self.line, self.message)
+return self.message
 
 
 class ChangeLogEntry:
@@ -376,8 +375,8 @@ class GitCommit:
 elif additional_author_regex.match(line):
 m = additional_author_regex.match(line)
 if len(m.group('spaces')) != 4:
-msg = 'additional author must prepend with tab ' \
-  'and 4 spaces'
+msg = 'additional author must be indented with '\
+  ' one tab and four spaces'
 self.errors.append(Error(msg, line))
 else:
 author_tuple = (m.group('name'), None)
@@ -437,15 +436,14 @@ class GitCommit:
 m = star_prefix_regex.match(line)
 if m:
 if len(m.group('spaces')) != 1:
-err = Error('one space should follow asterisk',
-line)
-self.errors.append(err)
+msg = 'one space should follow asterisk'
+self.errors.append(Error(msg, line))
 else:
 last_entry.lines.append(line)
 else:
 if last_entry.is_empty:
 msg = 'first line should start with a tab, ' \
-  'asterisk and space'
+  'an asterisk and a space'
 self.errors.append(Error(msg, line))
 else:
 last_entry.lines.append(line)
@@ -526,8 +524,8 @@ class GitCommit:
 used_patterns = set()
 for entry in self.changelog_entries:
 if not entry.files:
-msg = 'ChangeLog must contain at least one file entry'
-self.errors.append(Error(msg, entry.folder))
+msg = 'no files mentioned for ChangeLog in directory: "%s"'
+self.errors.append(Error(msg % entry.folder))
 assert not entry.folder.endswith('/')
 for file in entry.files:
 if not self.is_changelog_filename(file):
@@ -539,7 +537,8 @@ class GitCommit:
 if not self.is_changelog_filename(x[0])]
 changed_files = set(cand)
 for file in sorted(mentioned_files - changed_files):
-self.errors.append(Error('file not changed in a patch', file))
+msg =

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 21:26, Martin Sebor  wrote:
>
> On 6/1/20 1:12 PM, Jonathan Wakely via Overseers wrote:
> > On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc  
> > wrote:
> >>
> >> Hi -
> >>
> >>> git pull from the GCC and Glibc repos is failing for me with the error
> >>> below.  It worked fine last week and I haven't made any changes to my
> >>> ssh keys.
> >>
> >> And are you logging in from the same workstation with access to the same
> >> set of ssh private keys?
> >>
> >>> Is this a transient glitch or has something changed recently that I
> >>> need to make some adjustments for?
> >>
> >> I know of nothing relevant that has changed on the sourceware side.
> >>
> >>> sign_and_send_pubkey: signing failed: agent refused operation
> >>> mse...@gcc.gnu.org: Permission denied (publickey).
> >>> fatal: Could not read from remote repository.
> >>
> >> The usual advice is to run   % ssh -vv gcc.gnu.org alive
> >> and report the ssh level error.
> >>
> >> "agent refused operation" sounds like a problem on the client end.
> >
> > Yes, it is. "agent" refers to the ssh-agent program.
> >
> > Martin, what does 'ssh-add -l' show?
> >
> > Is there only one ssh-agent process shown by 'ps -ef | fgrep
> > [s]sh-agent'? Does its PID match $SSH_AGENT_PID?
> >
> > Another possible cause is that the file permissions are not strict
> > enough on the private key, or on the ~/.ssh directory that contains
> > it. Key files should be 600 and ~/.ssh should be 700.
>
> We solved the problem over IRC last night so just to close the loop
> on it here: it turned out to be caused by Gnome keyring setting
> SSH_AUTH_SOCK=/run/user/1000/keyring/ssh.  With the environment
> variable undefined I get prompted for the password as expected.

But that just means you're not using an agent, right?

Do you really want to enter a passphrase every time you connect to gcc.gnu.org?

Solving it by the GNOME keyring would match Jim's suggestion that the
GNOME keyring won't use your key.

You could generate a new 4K key that GNOME keyring will accept, upload
the public key to gcc.gnu.org, and use that instead. Then you could
use the keyring as your agent.

Re: help with uninstalling gcc

[Jonathan Wakely via Gcc]

On Fri, 5 Jun 2020 at 10:12, Diego Pardo via Gcc  wrote:
>
> Hi,I've installed gcc 8, how can I uninstall it?

That depends how you installed it, and you've told us nothing useful
that would allow us to help you.

But in any case, please direct this question to the
gcc-h...@gcc.gnu.org list where it is appropriate. This list is for
discussing development of GCC itself, not for help using or installing
it, or uninstalling it.

Re: gcc math functions for OpenMP vectoization

[Jonathan Wakely via Gcc]

On Fri, 5 Jun 2020 at 18:59, Toon Moene  wrote:
>
> On 6/5/20 6:10 PM, Tobias Burnus wrote:
>
> > On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote:
>
> >> It is glibc that provides them, not GCC.
> >> See
> >> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD
> >>
> >
> > Minor addition: That header file is included in math.h, i.e.
> > automatically available.
> > For Fortran/gfortran there is math-vector-fortran.h (also provided by
> > glibc)
> > which has the same functions and a similar effect.
>
> I wonder if there are Linux distributions where this actually effected
> already.
>
> I know for sure that it is not in Debian Testing (as of two weeks ago)
> and Red Hat Fedora 30 (similarly).

Fedora 30 is EOL.

> Do you know of any ?

Fedora 31 and 32.

Re: [IMPORTANT] ChangeLog related changes

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 15:25, Martin Liška  wrote:
>
> On 6/2/20 4:14 PM, Jonathan Wakely wrote:
> > On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely  wrote:
> >>
> >> On Tue, 2 Jun 2020 at 14:16, Martin Liška  wrote:
> >>>
> >>> On 6/2/20 1:48 PM, Martin Liška wrote:
>  I tend to this approach. Let me prepare a patch candidate for it.
> >>>
> >>> There's a patch for it. Can you please Jonathan take a look?
> >>
> >> Looks great, thanks!
> >>
> >> +if name not in wildcard_prefixes:
> >> +msg = 'unsupported wilcard prefix'
> >>
> >> Typo "wilcard"
> >>
> >> +if pattern not in used_patterns:
> >> +self.errors.append(Error('a file pattern not used in a 
> >> patch',
> >> + pattern))
> >>
> >> If the script printed this error I don't think I'd know what it was
> >> complaining about. How about "pattern doesn't match any changed files"
> >> ?
> >>
> >> I find the existing error 'file not changed in a patch' to be
> >> suboptimal too. We're checking revisions (or commits), not patches.
> >
> > Along those lines, here's an incomplete patch (tests aren't updated
> > yet, no commit log, your latest change isn't merged ) to revise the
> > error messages. I've tried to make them more consistent (e.g change
> > 'file not changed in a patch' to 'unchanged file mentioned in a
> > ChangeLog' which mirrors the error for the opposite condition,
> > 'changed file not mentioned in a ChangeLog').
>
> I welcome this.
>
> >
> > I've also moved line numbers to the start of the line (like GCC's own
> > diagnostics) and not used the "line" argument of the Error constructor
> > for things that aren't line numbers. I've aimed to be consistent, so
> > that line numbers come at the start, pathnames and patterns come at
> > the end (and there's a space before them).
>
> Well, the Error ctor argument 'line' is bit misleading. It's a string and
> not an integer:
>
>File "/home/marxin/Programming/gcc/contrib/gcc-changelog/git_commit.py", 
> line 177, in __repr__
>  return '%d: %s' % (self.line, self.message)
> TypeError: %d format: a number is required, not str
>
> and it represents a line from a git commit message. I use it in order to 
> provide
> line which is affected by an error.
>
> >
> > I also suggest changing 'additional author must prepend with tab and 4
> > spaces' to 'additional author must be indented with one tab and four
> > spaces'.>
> > The intent is to improve the user experience, since for many people
> > who are new to git *any* error can cause confusion, so extra,
> > gcc-specific errors that we issue should aim to be easy to understand.
>
> I like your wordings.

OK, here's a proper patch for the changes you liked, dropping the
changes to the Error exception type.

pytest contrib/gcc-changelog/test_email.py passes.

OK for master?
commit 49652b7f5b57b88c1e0e27cf8ac488cbc85f1c7d
Author: Jonathan Wakely 
Date:   Tue Jun 9 21:25:50 2020 +0100

gcc-changelog: Improve git_commit.py diagnostics

This changes some error messages to be more self-consistent and to fix
some grammar.

contrib/ChangeLog:

* gcc-changelog/git_commit.py (GitCommit.parse_changelog):
Improve error strings.
* gcc-changelog/test_email.py: Update expected errors.

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index f85d4c83c63..0b350ba7fda 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -377,8 +377,8 @@ class GitCommit:
 elif additional_author_regex.match(line):
 m = additional_author_regex.match(line)
 if len(m.group('spaces')) != 4:
-msg = 'additional author must prepend with tab ' \
-  'and 4 spaces'
+msg = 'additional author must be indented with '\
+  'one tab and four spaces'
 self.errors.append(Error(msg, line))
 else:
 author_tuple = (m.group('name'), None)
@@ -438,15 +438,14 @@ class GitCommit:
 m = star_prefix_regex.match(line)
 if m:
 if len(m.group('spaces')) != 1:
-err = Error('one space should follow asterisk',
-line)
-self.errors.append(err)
+msg = 'one space should follow asterisk'
+self.errors.append(Error(msg, line))
 else:
 last_entry.lines.append(line)
 else:
 if last_entry.is_empty:
 msg = 'first line should start with a tab, ' \
-  'asterisk and space'
+   

Re: GCC 10.1.0 HELP

[Jonathan Wakely via Gcc]

On Thu, 11 Jun 2020 at 08:43, MAHDI LOTFI via Gcc  wrote:
>
> Hello
> I am a researcher from Jam Petrochemical company. I want to use OpenACC
> with GCC compiler(FORTRAN language). I read from your documentation that
> GCC 10.1.0 supports carrizo, fiji and vega (third and fifth generation) AMD
> GPU for OpenACC  parallelization.
> I am using following AMD GPU:
>
> [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445]
> [1002:6900] (rev 81)
>
> I think my GPU is older than fiji and Vega AMDs.
> Can GCC 10 support my GPU Model?

Your question is off-topic on this mailing list. For help using GCC
please use the gcc-help mailing list (the clue is in the name).

Re: Is it very hard to implement Zero-overhead deterministic exceptions: Throwing values??

[Jonathan Wakely via Gcc]

On Sun, 14 Jun 2020 at 22:34, Andrew Pinski via Gcc  wrote:
>
> On Sun, Jun 14, 2020 at 2:27 PM Andi Kleen via Gcc  wrote:
> >
> > sotrdg sotrdg via Gcc  writes:
> >
> > > http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0709r0.pdf
> > >
> > > I really want this feature. How, it looks like this requires changes
> > > on RTL, gimple and C++ front-end. Is that very hard to implement it?
> >
> > If you're asking about setjmp/longjmp exceptions, you can already
> > configure with --enable-sjlj-exceptions and then use -fsjlj-exceptions
> > to enable them.
> >
> > It would be a new ABI and likely break some existing libraries.
>
> NOTE Setjmp/longjump is much much slower if exceptions are not used at
> all.  Because there will be many many setjump locations.

This is nothing to do with SJLJ exceptions anyway.

Re: Push to my private branches is disallowed

[Jonathan Wakely via Gcc]

On Tue, 16 Jun 2020 at 10:11, Martin Jambor  wrote:
>
> Hi,
>
> On Mon, Jun 15 2020, Segher Boessenkool wrote:
> > Hi!
> >
> [...]
> > What.
> >
> > Of course it is not a fast-forward.  I rebase the branches I publish,
> > what is the point of publishing them otherwise?  This is so that people
> > can see the stuff that will make its way into master *later*.
> >
> > The number of new commits is nonsense (it is just 13), and the number of
> > emails that triggers should be 0.
> >
> > Please fix?  Or, what else is wrong?
>
> while I tend to agree that sending emails about commits to user branches
> is not a good idea, I also believe that you should (almost?) never
> rebase a public branch.  Certainly not if you expect anyone else to
> fetch it or - god forbid - base some of their commits on it, as opposed
> to just reading it through the web interface.  I'd suggest appending a
> date to the namer of the branch and thus always publish a new branch,
> making it clear that its history is different.

I see no harm in rebasing public branches as long as nobody expects
otherwise. A public branch on gcc.gnu.org under refs/heads that is
being pulled by unknown persons and used in unknown forks for unknown
purposes shouldn't be rebased, because you don't know who you're
causing problems for by doing so. But a personal branch like Segher's
could disappear at any time. If we're going to discourage rebasing, we
should also discourage deleting personal branches. But I don't see any
benefit to that.

If I create a branch refs/users/redi/work-in-progress for somebody
else to look at and then delete it, do I have to remember never to
create another branch using that name in future, in case somebody
pulled the old branch before I deleted it?

Randos on the internet aren't going to be basing work on those
branches accidentally, they're not fetched by default so you have to
make some non-trivial effort to even fetch them. If you do that, you
should know you're not using an official GCC branch, but one that
Segher can rebase or completely delete at any time.

I think only the owner of a personal branch should decide what
workflow and rebasing policies apply to that branch.

Re: Please put vim swap files into gitignore

[Jonathan Wakely via Gcc]

On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc  wrote:
>
> Hi,
>
> I just found a few unversioned files called .intrinsic.c.swp and
> similar in my "git status" output.
>
> Could somebody please put .*.swp into .gitignore?  I'm sure this
> would save at least 10 reverts :-)

You can just add it to .git/info/exclude in your own clone.

Re: Please put vim swap files into gitignore

[Jonathan Wakely via Gcc]

On Thu, 18 Jun 2020 at 20:34, Thomas Koenig  wrote:
>
> Am 18.06.20 um 20:34 schrieb Jonathan Wakely via Gcc:
> > On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc  wrote:
> >>
> >> Hi,
> >>
> >> I just found a few unversioned files called .intrinsic.c.swp and
> >> similar in my "git status" output.
> >>
> >> Could somebody please put .*.swp into .gitignore?  I'm sure this
> >> would save at least 10 reverts :-)
> >
> > You can just add it to .git/info/exclude in your own clone.
>
> The same argument goes for the emacs files, do you suggest we
> remove them from .gitignore? :-)
>
> Seriously, while a personal solution will work for me personally,
> I don't suppose that I am the only person ever to visit a file
> in the Gcc source tree with vim.

You could propose a patch for .gitignore on the gcc-patches list, like
any other change to the source tree.

Re: a small typo in the documentation, FYI

[Jonathan Wakely via Gcc]

On Tue, 7 Jul 2020 at 15:41, Nino Pereira via Gcc  wrote:
>
> The top line in
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gfortran/BOZ-literal-constants.html
>
> says " The syntax is: `prefix quote digits quote', were the prefix is
> either b, o or z,"
>
> Here, 'were' must be 'where'

Thanks. That page is the documentation from the GCC 4.6.3 release,
which is old, and has already been released, so its documentation
can't be changed now.

But the typo is still present in the currently supported branches.
I've CC'd the fortran mailing list, so our Fortran devs can fix it.

Re: Effect of nested unions and structures in GCC?

[Jonathan Wakely via Gcc]

On Fri, 10 Jul 2020 at 09:25, Unidef Defshrizzle  wrote:
>
> What would happen?

This doesn't seem like a question about GCC development, so is
off-topic on this mailing list.

The C language says what should happen, GCC follows that.

Re: t/47153851 GCC 10.2 Released

[Jonathan Wakely via Gcc]

Could somebody at Google please turn this crap off.

It might be confused by the change in the List-Id headers a few months
ago, but whatever the reason, please stop it.

On Thu, 23 Jul 2020 at 08:56, Google Ticket System via Gcc
 wrote:
>
> You have been CC'd on a Google Ticket   The GNU Compiler 
> Collection version 10.2 has been released.
>
> GCC 10.2 is a bug-fix release from the GCC 10 branch
> containing important fixes for regressions and serious bugs in
> GCC 10.1 with more than 94 bugs fixed since the previous release.
>
> This release is available from the FTP servers listed at:
>
> http://www.gnu.org/order/ftp.html
>
> Please do not contact me directly regarding questions or comments
> about this release.  Instead, use the resources available from
> http://gcc.gnu.org.
>
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
>   Reply to this email to update this ticket.

Re: GCC 10.2 Released

[Jonathan Wakely via Gcc]

On Thu, 23 Jul 2020 at 09:34, ireng ajah via Gcc  wrote:
>
> Hi..
>
> Can you remove my email from your list?

No, you have to do it yourself. See
https://gcc.gnu.org/lists.html#subscribe for instructions.

Re: GCC 10.2 Released

[Jonathan Wakely via Gcc]

On Thu, 23 Jul 2020 at 12:19, Jonathan Wakely  wrote:
>
> On Thu, 23 Jul 2020 at 09:34, ireng ajah via Gcc  wrote:
> >
> > Hi..
> >
> > Can you remove my email from your list?
>
> No, you have to do it yourself. See
> https://gcc.gnu.org/lists.html#subscribe for instructions.

I followed those simple instructions and sent an unsubscribe request
for you. Just click on the link in the email.

Re: Tar version being used

[Jonathan Wakely via Gcc]

On Mon, 27 Jul 2020 at 11:59, CHIGOT, CLEMENT via Gcc  wrote:
>
> Hi everyone,
>
> I'm wondering if someone knows which tar version / configuration was being 
> used when creating gcc-10.2.0 tarballs ?

GNU tar 1.30, I think.

>
> I'm getting some directory checksum errors while trying to unpack it with the 
> AIX tar (which can be a bit old). But they are disappearing when I'm building 
> these tarballs on Ubuntu-18.04, even with the last tar version 1.32.

https://gcc.gnu.org/install/prerequisites.html says:

"GNU tar version 1.14 (or later)
Necessary (only on some platforms) to untar the source code. Many
systems’ tar programs will also work, only try GNU tar if you have
problems."


> Note that gcc-10.1.0 doesn't have these problems, so maybe something have 
> changed since.

I think it's the same version of GNU tar on the same system.

Re: Tar version being used

[Jonathan Wakely via Gcc]

On Mon, 27 Jul 2020 at 12:34, Jonathan Wakely  wrote:
>
> On Mon, 27 Jul 2020 at 11:59, CHIGOT, CLEMENT via Gcc  wrote:
> >
> > Hi everyone,
> >
> > I'm wondering if someone knows which tar version / configuration was being 
> > used when creating gcc-10.2.0 tarballs ?
>
> GNU tar 1.30, I think.

I've been informed that the tarball isn't necessarily created on the
gcc.gnu.org server, and so it could be using a different version of
tar. The 1.30 version was indeed used for GCC 10.1.0 though/

The advice about using GNU tar still holds though ...

>
> >
> > I'm getting some directory checksum errors while trying to unpack it with 
> > the AIX tar (which can be a bit old). But they are disappearing when I'm 
> > building these tarballs on Ubuntu-18.04, even with the last tar version 
> > 1.32.
>
> https://gcc.gnu.org/install/prerequisites.html says:
>
> "GNU tar version 1.14 (or later)
> Necessary (only on some platforms) to untar the source code. Many
> systems’ tar programs will also work, only try GNU tar if you have
> problems."
>
>
> > Note that gcc-10.1.0 doesn't have these problems, so maybe something have 
> > changed since.
>
> I think it's the same version of GNU tar on the same system.

Re: Contributor forms related to adding p1004 for C++20 -- constexpr std::vector

[Jonathan Wakely via Gcc]

On Tue, 28 Jul 2020 at 18:58, Josh Marshall via Gcc  wrote:
>
> Hello,
>
> What are the forms and related legal stuff I need to fill out for 
> contributions?

I'll send you these off-list.

Re: Ellipsis in varadic macro definitions

[Jonathan Wakely via Gcc]

On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc  wrote:
>
> Hi *GCC*:
>
> On page:
>
> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros
>
> you say:
>
> #define eprintf(args…) fprintf (stderr, args)
>
> but do you in fact mean:
>
> #define eprintf(args...) fprintf (stderr, args)
>
> The first variant produces:
>
> error: expected ',' or ')', found "…"
>
>  the second variant works well using GCC10.2 on Kubuntu 18.04.

Yes, the texinfo source uses @dots which gets turned into … in
the HTML, which isn't necessarily displayed as three separate dots in
the browser. I don't know why @dots is used rather than ...

Re: FWIW

[Jonathan Wakely via Gcc]

CC The gfortran list.

On Sat, 1 Aug 2020 at 23:38, Nino Pereira via Gcc  wrote:
>
> https://gcc.gnu.org/onlinedocs/gfortran/INT.html#INT
>
> has two occurrences of 'or' next to each other.
>
> Arguments:
> A   Shall be of type INTEGER, REAL, or COMPLEX or or a 
> boz-literal-constant.
>
> HTH,
>
> Nino

Re: Ellipsis in varadic macro definitions

[Jonathan Wakely via Gcc]

On Mon, 3 Aug 2020 at 11:28, Florian Weimer wrote:
>
> * Jonathan Wakely via Gcc:
>
> > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc  
> > wrote:
> >>
> >> Hi *GCC*:
> >>
> >> On page:
> >>
> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros
> >>
> >> you say:
> >>
> >> #define eprintf(args…) fprintf (stderr, args)
> >>
> >> but do you in fact mean:
> >>
> >> #define eprintf(args...) fprintf (stderr, args)
> >>
> >> The first variant produces:
> >>
> >> error: expected ',' or ')', found "…"
> >>
> >>  the second variant works well using GCC10.2 on Kubuntu 18.04.
> >
> > Yes, the texinfo source uses @dots which gets turned into … in
> > the HTML, which isn't necessarily displayed as three separate dots in
> > the browser. I don't know why @dots is used rather than ...
>
> It was introduced with:
>
> commit 1c5dd43ff7c78bbdba5e89a6cb16a3e50e1abff9
> Author: Zack Weinberg 
> Date:   Fri Jun 15 17:57:48 2001 +
>
> cpp.texi: Formatting corrections.
>
> * doc/cpp.texi: Formatting corrections.
> Correct buggy example of use of __GNUC__ etc.
> Clarify $ in identifiers.
> * doc/cpp.1: Regenerate.
>
> From-SVN: r43404
>
> Some of these changes were clearly correct, but the ... C token should
> have not been changed.  Looks like a simple oversight to me.

Thanks for the archaeology, Florian.

Here's a patch to replace those inappropriate @dots macros with the
literal ... token.

Tested by building the docs and inspecting the .info and .html output.

OK for trunk?
commit 81034f739112019f29c62a704d0920e9894add6f
Author: Jonathan Wakely 
Date:   Mon Aug 3 12:47:58 2020

cpp: Do not use @dots for ... tokens in code examples

This prevents a ... token in code examples from being turned into a
single HORIZONTAL ELLIPSIS glyph (e.g. via the HTML … entity).

gcc/ChangeLog:

* doc/cpp.texi (Variadic Macros): Use the exact ... token in
code examples.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 8c3dfcc708a..33f876ab706 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1631,7 +1631,7 @@ a function can.  The syntax for defining the macro is 
similar to that of
 a function.  Here is an example:
 
 @smallexample
-#define eprintf(@dots{}) fprintf (stderr, __VA_ARGS__)
+#define eprintf(...) fprintf (stderr, __VA_ARGS__)
 @end smallexample
 
 This kind of macro is called @dfn{variadic}.  When the macro is invoked,
@@ -1655,11 +1655,11 @@ below for an important special case for @samp{##}.)
 If your macro is complicated, you may want a more descriptive name for
 the variable argument than @code{@w{__VA_ARGS__}}.  CPP permits
 this, as an extension.  You may write an argument name immediately
-before the @samp{@dots{}}; that name is used for the variable argument.
+before the @samp{...}; that name is used for the variable argument.
 The @code{eprintf} macro above could be written
 
 @smallexample
-#define eprintf(args@dots{}) fprintf (stderr, args)
+#define eprintf(args...) fprintf (stderr, args)
 @end smallexample
 
 @noindent
@@ -1670,7 +1670,7 @@ You can have named arguments as well as variable 
arguments in a variadic
 macro.  We could define @code{eprintf} like this, instead:
 
 @smallexample
-#define eprintf(format, @dots{}) fprintf (stderr, format, __VA_ARGS__)
+#define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
 @end smallexample
 
 @noindent
@@ -1709,7 +1709,7 @@ invocation expands to its argument; but if the variable 
argument does
 not have any tokens, the @code{@w{__VA_OPT__}} expands to nothing:
 
 @smallexample
-#define eprintf(format, @dots{}) \
+#define eprintf(format, ...) \
   fprintf (stderr, format __VA_OPT__(,) __VA_ARGS__)
 @end smallexample
 
@@ -1722,7 +1722,7 @@ the introduction of @code{@w{__VA_OPT__}}, this extension 
remains
 supported in GNU CPP, for backward compatibility.  If you write
 
 @smallexample
-#define eprintf(format, @dots{}) fprintf (stderr, format, ##__VA_ARGS__)
+#define eprintf(format, ...) fprintf (stderr, format, ##__VA_ARGS__)
 @end smallexample
 
 @noindent
@@ -1758,7 +1758,7 @@ replacement list of a variadic macro.
 Variadic macros became a standard part of the C language with C99.  
 GNU CPP previously supported them
 with a named variable argument
-(@samp{args@dots{}}, not @samp{@dots{}} and @code{@w{__VA_ARGS__}}), which
+(@samp{args...}, not @samp{...} and @code{@w{__VA_ARGS__}}), which
 is still supported for backward compatibility.
 
 @node Predefined Macros

Re: Ellipsis in varadic macro definitions

[Jonathan Wakely via Gcc]

On Mon, 3 Aug 2020 at 14:53, Richard Sandiford
 wrote:
>
> Jonathan Wakely via Gcc  writes:
> > On Mon, 3 Aug 2020 at 11:28, Florian Weimer wrote:
> >>
> >> * Jonathan Wakely via Gcc:
> >>
> >> > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc  
> >> > wrote:
> >> >>
> >> >> Hi *GCC*:
> >> >>
> >> >> On page:
> >> >>
> >> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros
> >> >>
> >> >> you say:
> >> >>
> >> >> #define eprintf(args…) fprintf (stderr, args)
> >> >>
> >> >> but do you in fact mean:
> >> >>
> >> >> #define eprintf(args...) fprintf (stderr, args)
> >> >>
> >> >> The first variant produces:
> >> >>
> >> >> error: expected ',' or ')', found "…"
> >> >>
> >> >>  the second variant works well using GCC10.2 on Kubuntu 18.04.
> >> >
> >> > Yes, the texinfo source uses @dots which gets turned into … in
> >> > the HTML, which isn't necessarily displayed as three separate dots in
> >> > the browser. I don't know why @dots is used rather than ...
> >>
> >> It was introduced with:
> >>
> >> commit 1c5dd43ff7c78bbdba5e89a6cb16a3e50e1abff9
> >> Author: Zack Weinberg 
> >> Date:   Fri Jun 15 17:57:48 2001 +
> >>
> >> cpp.texi: Formatting corrections.
> >>
> >> * doc/cpp.texi: Formatting corrections.
> >> Correct buggy example of use of __GNUC__ etc.
> >> Clarify $ in identifiers.
> >> * doc/cpp.1: Regenerate.
> >>
> >> From-SVN: r43404
> >>
> >> Some of these changes were clearly correct, but the ... C token should
> >> have not been changed.  Looks like a simple oversight to me.
> >
> > Thanks for the archaeology, Florian.
> >
> > Here's a patch to replace those inappropriate @dots macros with the
> > literal ... token.
> >
> > Tested by building the docs and inspecting the .info and .html output.
> >
> > OK for trunk?
>
> OK, thanks.  (And for branches too.)

Pushed to all branches, thanks.

Re: Coding style for C++ constructs going forward

[Jonathan Wakely via Gcc]

On Fri, 7 Aug 2020 at 15:08, Luis Machado via Gcc  wrote:
>
> Hi,
>
> cc-ing the GCC mailing list, as we may want to use the same coding style
> for GDB and GCC.
>
> Yesterday I brought this topic up on IRC. I notice we started using more
> and more the "auto" keyword. In some cases, this is actually useful and
> makes the code a bit more compact. GDB has been using those more often,
> whereas GCC, for example, isn't using those too much.
>
> Looking at the coding standards for GCC
> (https://gcc.gnu.org/codingconventions.html), I don't see anything
> dictating best practices for "auto" use.
>
> I guess it is a consensus that "auto" is a good fit when dealing with
> iterators, lambda's and gnarly templates (but only when the type is
> already obvious from its use).

GCC only moved to C++11 very recently, so it's unsurprising.

> There are other situations where "auto" may make things a little more
> cryptic when one wants to figure out the types of the variables. One
> example of this is when you have a longer function, and you use "auto"
> in a variable that lives throughout the scope of the function. This
> means you'll need to go back to its declaration and try to figure out
> what type this particular variable has.
>
> Pedro has pointed out LLVM's coding standards for "auto", which we may
> or may not want to follow/adopt:
> https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
>
> It sounds like a reasonable idea to me. Thoughts?

It seems like common sense to me. "Almost always use auto" is a silly
guideline. I can't stand seeing nonsense like:

auto main() -> int
{ ... }

> Are there other C++ constructs people think would benefit from a more
> formal style guideline? As we move to newer C++ standards over time, it
> is more likely we will start using newer constructs, and some of those
> may make the code potentially less readable.

I'm also not a fan of "always use {} for init" rules. There are times
when using {} for initialization is necessary, or more convenient
(e.g. it avoids ambiguities in the grammar that would need clunky
workarounds to avoid otherwise) but that doesn't make it always
better.

On the other hand, I do like:

- nullptr instead of NULL

- constructors and assignment ops defined with = default

- default member initializers i.e.

struct X
{
  void* p = nullptr;
  size_t num = 0;
};

(especially useful in GCC code where leaving members uninitialized
seems to be the norm)

Re: 10-12% performance decrease in benchmark going from GCC8 to GCC9

[Jonathan Wakely via Gcc]

Hi Matt,

The best thing to do here is file a bug report with the code to reproduce it:
https://gcc.gnu.org/bugzill

Thanks

On Sat, 8 Aug 2020 at 23:01, Soul Studios  wrote:
>
> Hi all,
> recently have been working on a new version of the plf::colony container
> (plflib.org) and found GCC9 was giving 10-12% worse performance on a
> given benchmark than GCC8.
>
> Previous versions of the colony container did not experience this
> performance loss going from GCC8 to GCC9.
> However Clang 6 and MSVC2019 show no performance loss going from the old
> colony version to the new version.
>
> The effect is repeatable across architectures - I've tested on xubuntu,
> windows running nuwen mingw, and on Core2 and Haswell CPUs, with and
> without -march=native specified.
>
> Compiler flags are: -O2;-march=native;-std=c++17
>
> Code is attached with an absolute minimum use-case - other benchmarks
> have not shown such strong performance differences - including both
> simpler and more complex tests.
> So I cannot reduce further, please do not ask me to do so.
>
> The benchmark in question inserts into a container initially then
> iterates over container elements repeatedly, randomly erasing and/or
> inserting new elements.
>
>
> In addition I've attached the assembly output under both GCC8 and GCC9.
> In this case I have output from 8.2 and 9.2 respectively, but the same
> effects apply to 8.4 and 9.3. The output for 8 is a lot larger than 9,
> wondering if there's more unrolling occurring.
>
> Any questions let me know. I will help where I can, but my knowledge of
> assembly is limited. If supplying the older version of colony is useful
> I'm happy to do so.
>
> Nanotimer is a ~nanosecond-precision sub-timeslice cross-platform timer.
> Colony is a bucket-array-like unordered sequence container.
> Thanks,
> Matt
>
>

Re: Coding style for C++ constructs going forward

[Jonathan Wakely via Gcc]

On Tue, 11 Aug 2020 at 14:56, Nathan Sidwell  wrote:
>
> On 8/7/20 10:06 AM, Luis Machado via Gcc wrote:
> > Hi,
> >
> > cc-ing the GCC mailing list, as we may want to use the same coding style
> > for GDB and GCC.
> >
> > Yesterday I brought this topic up on IRC. I notice we started using more
> > and more the "auto" keyword. In some cases, this is actually useful and
> > makes the code a bit more compact. GDB has been using those more often,
> > whereas GCC, for example, isn't using those too much.
> >
> > Looking at the coding standards for GCC
> > (https://gcc.gnu.org/codingconventions.html), I don't see anything
> > dictating best practices for "auto" use.
> >
> > I guess it is a consensus that "auto" is a good fit when dealing with
> > iterators, lambda's and gnarly templates (but only when the type is
> > already obvious from its use).
> >
> > There are other situations where "auto" may make things a little more
> > cryptic when one wants to figure out the types of the variables. One
> > example of this is when you have a longer function, and you use "auto"
> > in a variable that lives throughout the scope of the function. This
> > means you'll need to go back to its declaration and try to figure out
> > what type this particular variable has.
> >
> > Pedro has pointed out LLVM's coding standards for "auto", which we may
> > or may not want to follow/adopt:
> > https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
> >
> >
> > It sounds like a reasonable idea to me. Thoughts?
>
> I agree, it's the way I use auto.  I particularly like the
> auto *foo = expr;
> idiom, when you're getting a pointer, but the type of the pointee is
> clear.  It informs how you use 'foo'.

Yes, great suggestion. I use that in libstdc++ too, e.g.

include/bits/shared_ptr.h:  if (auto* __p = dynamic_cast(__r.get()))

Re: Problem with 64-bit only compiler build

[Jonathan Wakely via Gcc]

On Wed, 12 Aug 2020 at 01:02, Paul Smith  wrote:
>
> This is a kind of esoteric problem, but all the more annoying for that.
>
> As usual I've built my own version of GCC, and then I check it into Git
> so that all builds can use this one canonical compiler regardless of
> operating system, etc.
>
> After being checked into Git, the compiler started failing to link with
> an error that it could not find libgcc_s.so, even though it exists in
> exactly the same place (relatively) as it was before.
>
> After some debugging and strace-ing, I discovered that in the failure
> mode the front-end didn't provide this flag to collect2, which is where
> libgcc_s.so lives:
>
> -L/.../cc/unknown/bin/../lib/gcc/x86_64-unknown-linux-gnu/10.2.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/.
>
> The problem is this: when I built this compiler I only built the 64bit
> version of it, not the 32bit version.  As a result, the lib/.
> directories are empty: only the lib64 directories have any content.
>
> When I check this into Git, of course all empty directories are
> ignored.  So while the /.../cc/unknown/x86_64-unknown-linux-gnu/lib64
> directory, where 64bit libgcc_s.so lives, does exist, the
> /.../cc/unknown/x86_64-unknown-linux-gnu/lib directory doesn't exist,
> which means the above path cannot be resolved.
>
> Of course, I can force the lib directory to exist by adding a dummy
> file there and I will do so.  However, it seems to me that it would be
> better if GCC would apply a simplifying function to pathnames to reduce
> all the "/.." elements, before it starts looking for directories, to
> avoid failing if some unnecessary element doesn't exist.  This
> shouldn't be too difficult since the path will be either the same
> length as, or shorter than, the original so there's no need to
> reallocate memory etc.: it can be updated in place.
>
> Oddly, I looked through the gnulib library and didn't find any
> appropriate module for this.  It seems like there should be one.

C++17 provides std::filesystem::weakly_canonical for that. It doesn't
help GCC or gnulib though.

POSIX realpath and GNU canonicalize_file_name do the canonicalization,
but require every path component to exist.

I think it's worth adding this to bugzilla. Depending on the existence
of empty directories seems less than ideal.

Re: Problem with 64-bit only compiler build

[Jonathan Wakely via Gcc]

On Wed, 12 Aug 2020 at 14:33, Paul Smith  wrote:
>
> I'm not talking about PREFIX/lib, though.
>
> As can be seen from my question I'm talking about
> PREFIX///lib.  This is where GCC keeps its own
> internal libraries,

Not by default, it isn't. I'm not sure what directory that is, but
none of my builds have it.

Is this a cross-compiler? Mine have PREFIX//lib instead, and
it's not empty (for a 64-bit --disable-multlib build)

Re: Problem with 64-bit only compiler build

[Jonathan Wakely via Gcc]

On Wed, 12 Aug 2020 at 17:43, Paul Smith wrote:
> However, the lib directory is empty in my build.  What lives in your
> version of lib?

All the runtime libs, but I think that's because mingw doesn't use the
lib/lib64 split.

$ ls -1  ~/gcc/mingw/x86_64-w64-mingw32/lib/
libatomic-1.dll
libatomic.a
libatomic.dll.a
libatomic.la
libgcc_s.a
libgcc_s_seh-1.dll
libgomp-1.dll
libgomp.a
libgomp.dll.a
libgomp.la
libgomp.spec
libquadmath-0.dll
libquadmath.a
libquadmath.dll.a
libquadmath.la
libssp-0.dll
libssp.a
libssp.dll.a
libssp.la
libssp_nonshared.a
libssp_nonshared.la
libstdc++-6.dll
libstdc++.a
libstdc++.dll.a
libstdc++.dll.a-gdb.py
libstdc++.la
libstdc++fs.a
libstdc++fs.la
libsupc++.a
libsupc++.la

Re: Coding style for C++ constructs going forward

[Jonathan Wakely via Gcc]

On Thu, 13 Aug 2020 at 07:46, Liu Hao via Gcc  wrote:
>
> 在 2020/8/13 上午2:40, David Blaikie 写道:
> >
> > Then use of `auto*` would make it easier for you to spot use of plain
> > pointers in your projects & scrutinize them further?
> >
>
> My point is that `auto*` conveys no more information than `auto`. The absence 
> of `*` does not imply the object (pointer)
> being declared can never be null (apologies for this triple negation), so it 
> complexifies coding rules and probably should
> not be used at all.

I am not aware of any significant downsides to it. You are of course
welcome to ban raw pointers from your own code, but that's not going
to happen for GCC any time soon, so maybe different rules should
apply.

Re: Coding style for C++ constructs going forward

[Jonathan Wakely via Gcc]

On Thu, 13 Aug 2020 at 08:52, Metzger, Markus T
 wrote:
>
> Hello,
>
> > It seems like common sense to me. "Almost always use auto" is a silly
> > guideline. I can't stand seeing nonsense like:
> >
> > auto main() -> int
> > { ... }
>
> I personally do not like auto for reasons like the above or
>
> auto foo = bar->foo ();
>
> I find this very hard to read and I also think that if types become too
> complicated or too long to type, something else is wrong.

That seems like a reasonable use of auto, and not comparable to the
'main' example I gave above (where it doesn't save you any typing, it
actually involves more keystrokes).

Re: C:\Program Files (x86)\Dev-Cpp\MinGW64\x86_64-w64-mingw32\lib32\libmingw32.a(lib32_libmingw32_a-crt0_c.o) In function `main': 18 C:\crossdev\src\mingw-w64-v3-git\mingw-w64-crt\crt\crt0_c.c undefin

[Jonathan Wakely via Gcc]

This is the wrong mailing list for your question, please read
https://gcc.gnu.org/lists.html (and don't put your entire email in the
Subject: line please).

The MinGW compiler can be used to create console applications or GUI
applications. The default is -mconsole, which means the linker looks
for a 'main' function. You have apparently used -mwindows which is
used to create GUI applications and means the linker looks for a
WinMain function. See
https://gcc.gnu.org/onlinedocs/gcc/x86-Windows-Options.html#x86-Windows-Options
or MinGW tutorials for more information.

If your intention is a GUI application, then you need to write
'WinMain' not 'main'. If your intention is a console application, then
you need to stop using the -mwindows option (or add the -mconsole
option).

Please send any replies to the gcc-h...@gcc.gnu.org mailing list, not this one.

Re: Request to join development team

[Jonathan Wakely via Gcc]

On Thu, 13 Aug 2020 at 14:57, Dnyaneshwar Gomsale via Gcc
 wrote:
>
> I am Dnyaneshwar Gomsale. I want to be the part of the your development
> team.

Great! We have a wiki page describing how to get started;
https://gcc.gnu.org/wiki/GettingStarted

Re: GCC / GFortran (9.3.0; Cygwin 64) Internal Compiler Error on NINT() Function

[Jonathan Wakely via Gcc]

On Wed, 19 Aug 2020 at 15:24, Bernd Eggen via Gcc  wrote:
>
> Hello,
>
> I've come across an internal compiler error (in GFortran), concerning the
> function NINT(),

Then you should be reporting it to Bugzilla, not to this mailing list.


> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

Just as it said in the compiler output.