Re: Question about git: merging to gccgo branch

[Ian Lance Taylor via Gcc]

On Mon, Mar 30, 2020 at 10:54 AM Joseph Myers  wrote:
>
> On Mon, 30 Mar 2020, Martin Liška wrote:
>
> > Can you please disable email sending for user branch? Or does it make any
> > sense?
>
> Email sending for user branches makes perfect sense, to make visible the
> development going on.  It's specifically email sending for merges of
> commits already present in the repository that doesn't seem useful, as
> discussed in .  (And the
> workaround for the limits, for now, is to merge not more than 1000 commits
> at a time.)

Hmmm, I have the same problem now with the gccgo branch.  I just set
up a merge, but it has 1304 commits.  Is there a simple way to merge
fewer changes?

Ian

Re: back to cvs, cool

[Ian Lance Taylor via Gcc]

On Wed, May 13, 2020 at 9:56 AM Mike Stump via Gcc  wrote:
>
> As seen in recent bug report:
>
>   CVS Commits 2020-05-12 20:40:40 UTC
>
> I guess that git thing was a bust and we're back to using cvs now.  At least 
> Ian did up the remote patches to make cvs work better.

In fairness, I worked on it but it was really Jim Kingdon who did the
bulk of the remote CVS support.

Ian

Re: ChangeLog files - server and client scripts

[Ian Lance Taylor via Gcc]

On Tue, May 19, 2020 at 2:26 AM Martin Liška  wrote:
>
> 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.

Hi, this unfortunately breaks gccgo development.  Significant parts of
the gccgo sources are simply copied from other repositories.  Those
other repositories do not use ChangeLog files.  The git commit hook
should not require ChangeLog files for those changes.  And, when the
time comes, no ChangeLog files should be created for changes in those
directories.

The directories in question are

gcc/go/gofrontend
libgo
gcc/testsuite/go.test/test

This is as documented in the README.gcc files in those directories.

How can I exempt those directories from the server hook?  Right now,
as far as I can tell, I cannot commit Go changes.  I get

remote: *** ChangeLog format failed:
remote: ERR: cannot find a ChangeLog location in message
remote:
remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
remote:
remote: error: hook declined to update refs/heads/master
To git+ssh://gcc.gnu.org/git/gcc
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc'

Thanks.

Ian

Re: ChangeLog files - server and client scripts

[Ian Lance Taylor via Gcc]

On Fri, May 22, 2020 at 4:11 AM Jakub Jelinek  wrote:
>
> On Fri, May 22, 2020 at 12:04:10PM +0100, Richard Earnshaw wrote:
> > >> The directories in question are
> > >>
> > >> gcc/go/gofrontend
> > >> libgo
> > >> gcc/testsuite/go.test/test
> > >
> > > The script has:
> > > ignored_prefixes = [
> > > 'gcc/d/dmd/',
> > > 'gcc/go/frontend/',
> >
> > The directory is gcc/go/gofrontend
> >
> > so it's missing 'go' from frontend.
>
> Thanks for spotting.  I believe Martin said he will be afk
> today, so I've fixed it for him and committed as obvious and
> am going to install into git-hooks now too.
>
> diff --git a/contrib/ChangeLog b/contrib/ChangeLog
> index 7b61bb8915b..64a0db18e58 100644
> --- a/contrib/ChangeLog
> +++ b/contrib/ChangeLog
> @@ -1,3 +1,9 @@
> +2020-05-22  Jakub Jelinek  
> +
> +   * gcc-changelog/git_commit.py: Add trailing / to
> +   gcc/testsuite/go.test/test and replace gcc/go/frontend/
> +   with gcc/go/gofrontend/ in ignored locations.
> +
>  2020-05-22  Martin Liska  
>
> * gcc-changelog/git_commit.py: Add gcc/testsuite/go.test/test
> diff --git a/contrib/gcc-changelog/git_commit.py 
> b/contrib/gcc-changelog/git_commit.py
> index ba9f5ce9650..8c5fa2c0fc9 100755
> --- a/contrib/gcc-changelog/git_commit.py
> +++ b/contrib/gcc-changelog/git_commit.py
> @@ -127,8 +127,8 @@ bug_components = set([
>
>  ignored_prefixes = [
>  'gcc/d/dmd/',
> -'gcc/go/frontend/',
> -'gcc/testsuite/go.test/test',
> +'gcc/go/gofrontend/',
> +'gcc/testsuite/go.test/test/',
>  'libgo/',
>  'libphobos/libdruntime',
>  'libphobos/src/',

Thanks for looking into this.

Unfortunately, my push is still failing.  I'm not sure why.

remote: *** ChangeLog format failed:
remote: ERR: cannot find a ChangeLog location in message
remote:
remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
remote:
remote: error: hook declined to update refs/heads/master
To git+ssh://gcc.gnu.org/git/gcc
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc'


I've attached the output of "git format-patch -k 1 --stdout", in case
that helps.

Ian
From 81994eab700da7fea6644541c163aa0f0f3b8cf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Tue, 19 May 2020 16:03:54 +0200
Subject: libgo: update x/sys/cpu after gccgo support added

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/234597
---
 gcc/go/gofrontend/MERGE   |  2 +-
 .../sys/cpu/{cpu_aix_ppc64.go => cpu_aix.go}  |  2 +-
 .../golang.org/x/sys/cpu/syscall_aix_gccgo.go | 27 +++
 3 files changed, 29 insertions(+), 2 deletions(-)
 rename libgo/go/golang.org/x/sys/cpu/{cpu_aix_ppc64.go => cpu_aix.go} (96%)
 create mode 100644 libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go

diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index bc9c1f07eda..284374820b0 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-bc27341f245a5cc54ac7530d037a609db72b677c
+ea58b8491064fbed18a220571a3043c38dccf7c7
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go 
b/libgo/go/golang.org/x/sys/cpu/cpu_aix.go
similarity index 96%
rename from libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go
rename to libgo/go/golang.org/x/sys/cpu/cpu_aix.go
index b0ede112d4e..02d03129e50 100644
--- a/libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go
+++ b/libgo/go/golang.org/x/sys/cpu/cpu_aix.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build aix,ppc64
+// +build aix
 
 package cpu
 
diff --git a/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go 
b/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go
new file mode 100644
index 000..2609cc49ae7
--- /dev/null
+++ b/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go
@@ -0,0 +1,27 @@
+// Copyright 2020 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// Recreate a getsystemcfg syscall handler instead of
+// using the one provided by x/sys/unix to avoid having
+// the dependency between them. (See golang.org/issue/32102)
+// Morover, this file will be used during the building of
+// gccgo's libgo and thus must not use a CGo method.
+
+// +build aix
+// +build gccgo
+
+package cpu
+
+import (
+   "syscall"
+)
+
+//extern getsystemcfg
+func gccgoGetsystemcfg(label uint32) (r uint64)
+
+func callgetsystemcfg(label int) (r1 uintptr, e1 syscall.Errno) {
+   r1 = uintptr(gccgoGetsystemcfg(uint32(label)))
+   e1 = syscall.GetErrno()
+   return
+}
-- 
2.27.0.rc0.183.gde8f92d652-goog

Re: ChangeLog files - server and client scripts

[Ian Lance Taylor via Gcc]

On Fri, May 22, 2020 at 12:48 PM Jakub Jelinek  wrote:
>
> On Fri, May 22, 2020 at 12:37:29PM -0700, Ian Lance Taylor wrote:
> > Thanks for looking into this.
> >
> > Unfortunately, my push is still failing.  I'm not sure why.
> >
> > remote: *** ChangeLog format failed:
> > remote: ERR: cannot find a ChangeLog location in message
> > remote:
> > remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
> > remote:
> > remote: error: hook declined to update refs/heads/master
> > To git+ssh://gcc.gnu.org/git/gcc
> >  ! [remote rejected] master -> master (hook declined)
> > error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc'
> >
> >
> > I've attached the output of "git format-patch -k 1 --stdout", in case
> > that helps.
>
> Bet the script first looks for the ChangeLog entry and only considers the
> ignored prefixes if it finds files in the patch that are not mentioned in
> the ChangeLog entry.  So, if you say modified gcc/go/whatever.cc and had
> ChangeLog entry for that and not for the files you've changed, it would be
> ok.
>
> So, I think before emitting the above message, it should look through the
> patch and if it finds all files in ignored prefixes, it should just not to
> do anything.
>
> We'll need it e.g. for the DATESTAMP bump job too which only modifies those
> files too and doesn't write ChangeLog entry for that.
>
> I'm sorry but I don't know the script well enough to fix it quickly, will
> defer to Martin as the author.
>
> Can you wait with the commit until Monday?  If not, I could just temporarily
> disable this for your commit.

Sure, I can wait.  Thanks for looking at it.

Ian

Re: ChangeLog files - server and client scripts

[Ian Lance Taylor via Gcc]

On Mon, May 25, 2020 at 12:48 AM Martin Liška  wrote:
>
> On 5/23/20 12:14 AM, Ian Lance Taylor wrote:
> > Sure, I can wait.  Thanks for looking at it.
>
> Hello.
>
> Thank you for patience. There's a patch that fixes that,
> I'm going to install it.

Thanks.  I was able to push my change to master.

Ian

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Mon, Mar 29, 2021 at 4:33 PM Christopher Dimech via Gcc
 wrote:
>
> Here is something close to the fundamental issue: Believing in private life,
> that people are entitled to their own associations and opinions (even bad 
> ones!),
> and entitled to make their own mistakes, too — and that, barring some direct
> connection to work life or extraordinary circumstance, that none of this is
> the concern of the little platoons of finks lurking in the community,
> particularly when driven by facebook lackeys muzzling everyday journalists
> who go against the grain.  We see this not only here but also to medical
> information dealing with coronavirus and vaccines.

Please work to avoid using terms like "finks" or "lackeys" when
describing members of the GCC community.  Please be respectful of
other people's opinions.  Thanks.

The question here is not whether RMS is permitted to contribute to
GCC.  I have not seen anybody arguing against that.  The question is
whether the GCC community should put him in a declared leadership
position.  For a leadership position, which serves as an example for
the community and to some extent demonstrates the values shared by the
community, I think it is reasonable that there is a decreased
expectation of privacy.

Ian

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

I encourage everyone to please try to keep this discussion focused on GCC.

If there is a message that is completely unrelated to GCC, I encourage
not responding, or responding off-list.

Thanks.

Ian

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Wed, Mar 31, 2021 at 5:28 AM Richard Biener via Gcc  wrote:
>
> And just to repeat - all the GCC governance structure (the "SC") represents
> all of the same non-openess as the FSF governance structure (because
> the "SC" is in fact appointed by the Chief GNUisance "or his delegates").

While that is true in a formal sense it's not true in a practical
sense.  In practice the steering committee appoints its own members.

That said I think it would be entirely reasonable to use a different
structure.  I just don't know what it would be.  The steering
committee doesn't really take very many actions, which is as it should
be.  The main and by and large only action is appointing, or perhaps a
better word would be anointing, maintainers: the people listed in the
MAINTAINERS file.

Thoughts on changing the steering committee system should probably be
on a separate thread from the RMS discussion.

Ian

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Wed, Mar 31, 2021 at 7:44 AM Joel Sherrill  wrote:
>
> On Wed, Mar 31, 2021 at 9:23 AM Paul Koning via Gcc  wrote:
>
> > I may have lost it in the enormous flood of text, but I want to ask these
> > general questions.
> >
> > 1. Is there a published code of conduct for GCC community members,
> > possibly different ones depending on which level of the organization you're
> > in?
> >
>
> As a GNU project, this should apply.:
>
> https://www.gnu.org/philosophy/kind-communication.en.html

Yes, although that is, by design, not a code of conduct as the term is
normally used.


> > 2. Is there a formal process for receiving claims of infraction of this
> > code, and for adjudicating such claims?
> >
>
> I admit to not looking for one but does any FLOSS organization have this?

Yes, many.  For example:

LLVM: https://llvm.org/docs/CodeOfConduct.html
Go: https://golang.org/conduct
Apache: https://www.apache.org/foundation/policies/conduct.html

and there are many more.

The GNU Cauldron also has a code of conduct:
https://gcc.gnu.org/wiki/cauldron2019#Code_of_Conduct

Ian

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell  wrote:
>
> You, the SC, have chosen to fix this as a clerical error.  The most
> do-nothing response, other than actually doing nothing.
>
> I am profoundly disappointed that you have not even acknowledged the
> harm RMS has caused.  Using passive voiced 'RMS was added' phrasing.
> You're not explicitly saying that was incorrect, and neither are you
> saying it was correct.   Your language attempts to distance you from
> your choices.
>
> 'we no longer feel the listing serves the best interest'.  'Therefore,
> we are removing him from the page FULLSTOP'. Well, at least that's not
> passive voice, but it is a milque-toast response.   You're not removing
> him from the SC, merely removing mention of him from the listing.
> You're not adding words to the website mentioning this historical
> ambiguity/error/misjudgement (you'd say if you were, right?).  You're
> not adding words acknowledging that RMS's involvement has been
> detrimental and repelled contributors.  Nor are you apologizing.  You're
> not owning your mistake.  You just hope the problem will silently go
> away.  The problem will not go away.
>
> /You/ involved RMS in SC discussions.  /You/ treated him as a member
> thereof.  /You/ gave him controlling rights.
>
> You have misled the majority of GCC developers, and the wider community
> by doing so.  If it looks like a duck, walks like a duck, and talks like
> a duck, it's a duck.  (As compiler developers for duck-typed languages,
> you should understand that.)
>
> You involved RMS prior to 2012, and continued to do so after.  Including
> after 2019 when he was no longer at the FSF.  Two instances I personally
> know of:
>
> 1) Sometime around 2005? maybe later, I lobbied to change gcc's
> implementation language to C++.  I failed because I'm lazy and learned I
> was arguing against an RMS effective veto.  (I learned this because Mark
> Mitchell informed me that some SC members were also pushing back against
> RMS's opposition to C++.  I was not privy to the actual SC discussion.)
>   If he was not an SC member, why was he even in that private
> conversation?  The public ML would have been more appropriate place for
> non-SC opinions to be voiced.  Just think, we could have transitioned to
> C++ earlier than we did, if it were not for the SC's inclusio of RMS.
>
> 2) Last year, I asked for libcody to be added as a subcomponent, with
> its Apachev2 license intact.  AFAICT RMS was involved in that licensing
> discussion, /for which I never received a response/.  He was not at the
> FSF then, so he could not render any FSF licensing opinion.  Why was he
> involved?  If he was not involved, how did he learn of it in order to
> ask me questions about C++ modules?  I only emailed the SC and the
> timing is too coincidental to draw a different conclusion.
>
> Interactions I've had with the SC, beyond maintainer appointment, seem
> to run into RMS.  (In the original email I mentioned a third interaction
> about RMS's position on the SC, which didn't do so, but also was
> decidedly one way.)
>
> You, the SC, do not state that you will not continue to involve RMS in
> discussions, just as you have done for the past 20 years.  You merely
> feel the listing is unfortunate.
>
> Your final paragraph is the corporate BS of hollow men.  Nice words, no
> specific actions.
>
> Richard Biener pointed out dysfunction in the SC.  The case of the
> missing question I asked in 2019 also points to that.  This response
> gives me no confidence that things will materially change.  I call for
> the dissolution of the SC, replacing it with a more open, functional and
> inclusive body (which includes, nothing).
>
> nathan
>
> FWIW, I am surprised that you, the SC, chose to respond only to the
> mailing list, and not CC me, the original complainant, of your decision.
>   Perhaps that seems petty, but it is personally insulting.


Nathan, you are clearly angry and frustrated.  I'm sorry about that.

I'm going to give some of my own personal opinions.  I'm not at all
speaking for the committee, and other committee members may disagree.

The steering committee is just a bunch of GCC hackers who originally
self-organized to manage the EGCS fork.  As it says at
https://gcc.gnu.org/steering.html, "committee members were chosen to
represent the interests of communities."  I was not on the steering
committee at the time, but I was somewhat involved with thinking about
who should be, and that statement accurately describes what we were
trying to do.  The intent was to ensure that when decisions were made
that covered the GCC project as a whole, all interested groups would
have a representative.

In practice the steering committee makes few decisions.  Naturally,
members of the committee work to improve GCC in various ways.  That
work almost never involves any sort of steering committee discussion.

I think you want the steering committee to issue a statement about
RMS's behavior.  I think

Re: RMS removed from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Fri, Apr 2, 2021 at 3:06 AM Giacomo Tesio  wrote:
>
> I'm sorry for this long mail that rivals with the original Nathan's
> request, but I wanted to back my request properly.

This is free software.  If you want to make it better, then make it
better.  The EGCS branch that displaced and became GCC came into
existence because the people involved felt that it would make GCC
better (I was a participant myself, though not a major one).  See
https://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork for a
few more details.

GCC is a successful free software project, but it is not perfect.  It
has many problems.  Lack of contributor diversity is one of them.  If
I knew how to fix that problem, I would work to fix it.  I personally
do not believe that the membership of the steering committee is a
significant cause of that problem.  But I could be mistaken.  So prove
me wrong.  Do the work.

Ian

Re: RMS removed from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Sat, Apr 3, 2021 at 10:31 AM Giacomo Tesio  wrote:
>
> I'm still just one Italian hacker: all the huge imbalances that the
> removal of the only FSF and GNU member of the Steering Committee
> uncovered, are still there!

As far as I can tell, the imbalances you refer to are the fact that
the GCC steering committee has mostly Americans and some Europeans.
And that is fair.

But you have singled out removing RMS (who as David noted was never
really a member of the committee anyhow) as a particular problem.
Let's not forget that RMS is an American.  So the imbalance you
mention was there already.


> > I personally do not believe that the membership of the steering
> > committee is a significant cause of that problem.
>
> I would be surprised if you did!

Fair point.

> I mean, you are a member of such committee since 2 decades.
> And you are from the US. And you work for the biggest threat to
> global democracies and to all people's autonomy and freedom!

Actually I joined the GCC steering committee in 2014.

And you are confusing my employer with my free software work.  In the
time I've been working on GCC I've worked for six different companies.
I don't get a job and then get told to work on free software.  I am a
free software programmer who only takes jobs where I will be working
on free software.


> But that's the fact with priviledge: if you have it, you can't see it.

I'm sure that's largely true.  And I'm well aware that I have enormous
amounts of privilege.

But you write that statement as though it contradicts something that I
said.  It doesn't.


> > But I could be mistaken.  So prove me wrong.
>
> Ok, let's try! ;-)
>
>
> > This is free software.  If you want to make it better, then make it
> > better. [...] So prove me wrong.  Do the work.
>
> This is plain old open source rhetoric.
> https://www.gnu.org/philosophy/open-source-misses-the-point.html

No, it really isn't.

The point of free software is to provide freedom.  In order to do
that, it has to work.  Free software is not just a group of people who
get together to discuss the benefits of free software.  It's a group
of people who build working software that gives freedom to other
people.  That is what we have been doing, in a small way, with GCC.  I
personally have been working on GCC for 30 years now, on and off.

If nobody worked on GCC, nobody would care about it.  People care
about GCC because it is free and because it works.  Both aspects are
critical.


> But you can see how flawed this argument is by comparing it with your
> own words: https://gcc.gnu.org/pipermail/gcc/2021-April/235269.html
>
> RMS was actively contributing to the Steering Committee without
> contributing a single line of code since years.
>
> So you proved that you (and open source rhetoric) are wrong.

I'm sorry, but that doesn't make any sense to me.  I think I was
pretty clear in that e-mail message that RMS was not actively
contributing to the steering committee.

And, even if he was, so what?  I agree that lots of work on GCC and
other free software projects has nothing to do with actual
programming.  When I spoke of doing the work, I didn't mean just
programming.  I meant the work of making GCC successful, which
includes much much more than just writing code.


> > If I knew how to fix that problem, I would work to fix it.
>
> Really?
>
> Well, let me do my job as a new member of the Steering Committee (:-D)
> and solve this problem for you and everybody else.
>
> In my original request[3], I proposed to solve it according to the
> recent precedent you established with the removal of Richard Stallman of
> Free Software Foundation [4][5], by simply removing enough employees of
> corporations ruled under the same legislation, until the global
> interests of the different economical regions and populations of the
> world are at least more balanced, if not more represented.
>
> But apparently you cannot decide which US-corporation should be thrown.
> (indeed US-corporations hold the vast majoirity of SC heads, right now).

I don't understand this argument.  If we remove everybody from the
committee, then it will be more balanced in some sense, but there
won't be anybody on it.  If you want a more balanced committee, then
at some point you have to talk about adding people.

And I do think it would make sense to add more people to the
committee.  Any suggestions?  They should of course be people
reasonably familiar with GCC and with free software, and with
compilers and software development tools.  (And for reasons discussed
elsewhere, RMS is not a good suggestion.)

Ian

Re: RMS removed from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Sun, Apr 4, 2021 at 6:11 AM Giacomo Tesio  wrote:
>
> with all respect with your personal history, your contributions and
> choices, I think you are still missing the point.

This conversation is going on circles.  You do not seem to hear what I
am saying, and you are telling me that I am not hearing what you are
saying.  There doesn't seem to be much point to continuing.

I'll just reply to one minor point.


> Thus, I'm not naive enough to ignore the thousands way your employee
> can get huge advantages by having you in the GCC's Steering Committee.

My employer truly doesn't care whether I am on the GCC steering
committee.  My employer no longer uses GCC.  It uses LLVM.

(Now you can spin that into a conspiracy theory that I am somehow
taking Google's direction to leverage my membership on the GCC
steering committee to slow down GCC development.)

Ian

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Tue, Apr 6, 2021 at 3:28 AM Richard Biener
 wrote:
>
> Seeing the word "dysfunction" I don't remember using I want to clarify
> the non-openess which I intended to criticize.  The SC is not "open" because:
> - it appoints itself (new members, that is) - in fact in theory it
> should be appointed
>   by the FSF because the SC is the GNU maintainer of GCC
> - all requests and discussions are _private_ - the SC does not report to the
>   GCC project (it might report to the FSF which it is formally a delegate of)
> - you can reach the SC only indirectly (unless you know the secret mailing 
> list
>   it operates on) - CC an SC member and hope a request is forwarded
>
> now I understand the SC sees itself as buffer between GCC and the FSF (RMS
> in particular) and it thinks we need to be protected from direct engagement.  
> I
> think this is wrong.  I can very well say NO to RMS myself.
>
> I'm actually curious how many of the 13 SC members actively contribute or
> whether the "SC show" is a one or two persons game and the "13" is just
> to make the SC appear as a big representative group of people.
>
> Thus I request an archive of the SC mailing list be made publically available
> and the SC discussion from now on take place in an open forum (you can
> choose to moderate everybody so the discussion while carried out in open
> is still amongst SC members only).

To a first approximation, the only thing that the SC does is approve
maintainers.  Questions like Nathan's example of libcody are rare.  To
be pedantically clear, by "maintainers" I mean the people listed in
the MAINTAINERS file who have the right to approve and commit changes
to various parts of the compiler.

While most discussion about approving maintainers is pro forma, there
are sometimes discussions as to whether a particular person has the
appropriate knowledge and sense of responsibility for the role.  I
don't think it would be appropriate to require that those discussions
be held publically.  In any case it wouldn't work; if they were
required to be public, SC members would resort to private e-mail for
anything they didn't want to be public.

So perhaps one thing we should be talking about is: can we develop a
mechanism for approving maintainers that does not involve the SC?

For example, I am also involved with the Go language project.  In that
project, any existing maintainer (that is, any person with the right
to commit changes to the repo) can approve any person to be a new
maintainer.  However, all changes require approval from at least two
maintainers, and, of course there are people who take at least a quick
look at every commit after it happens.  The two maintainer rule is
enforced by tooling, as all changes to Go must be made through Gerrit
(https://www.gerritcodereview.com/).  I'm not suggesting that we adopt
this for GCC, just mentioning as an example of a different approach
that does not require anything like the SC.

I'm sure other people on this list can give examples of other
approaches used by other free software projects.

Ian

Re: GCC association with the FSF

[Ian Lance Taylor via Gcc]

On Fri, Apr 9, 2021, 1:04 PM Giacomo Tesio  wrote:

> Hi John,
>
> On April 9, 2021 6:36:31 PM UTC, John Darrington <
> j...@darrington.wattle.id.au> wrote:
> > On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote:
> >
> >  Different opinions are fine.  Bringing national or international
> >  politics into the discussion (presumably meant to be as an insult) is
> >  not fine.  This is not a political discussion - please stop trying to
> >  make it one.
> >
> > For the record it was David who first brought up the political
>
> I think David was talking about me:
> https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html
>
> It was not meant to insult anybody, I was just asking to fix a serious
> problem in GCC.
>
> Since it's clear that the Steering Committee doesn't want to address it,
> I'm moving on.
>
>
> GCC is clearly an US-only project.
> A US-corporate one. Totally SFW (in the US).
>
> This is not intended as an insult.
> It's just a fact.
>

Just for the record, for other readers, this is not even remotely true.

Ian

Re: GCC association with the FSF

[Ian Lance Taylor via Gcc]

On Sat, Apr 10, 2021 at 4:36 AM Pankaj Jangid  wrote:
>
> I think, it would be great help if someone can document what the SC
> does.

I don't know whether anybody actually tried to answer this.

The main job of the GCC steering committee is to confirm GCC
maintainers: the people who have the right to approve changes to
specific parts of GCC, and the people who have the right to make
changes to specific parts of GCC without requiring approval from
anybody else.  These people are listed in the MAINTAINERS file in the
gcc repository (currently
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS;h=db25583b37b917102b001c0025d90ee0bc12800f;hb=HEAD),
from the start of the file down to the list of "Write After Approval"
people.

A secondary job of the GCC steering committee is to approve new
additions to GCC that are not under the GPL for one reason or another.
This happens rarely.

A tertiary job of the GCC steering committee is to decide disputes
between maintainers that the maintainers are unable to resolve.  I
can't recall this ever happening.

The GCC steering committee is in principle a place to make decisions
that affect the entire project.  There are very few such decisions.
One was the decision to change the implementation language of GCC from
C to C++, a decision made in 2010.  Another was the decision to allow
GCC plugins.  As a counter-example, moving GCC from Subversion to git
was supported by the steering committee members, but there was no
formal decision by the steering committee to approve the move.

More generally, the GCC steering committee has historically served as
a point of contact between the FSF and the GCC developers.  In my
opinion this has not amounted to much over the years that I've been on
the committee (since 2014).

Ian

Re: GCC association with the FSF

[Ian Lance Taylor via Gcc]

On Sun, Apr 11, 2021 at 8:04 AM David Brown  wrote:
>
> On 11/04/2021 16:37, Richard Kenner via Gcc wrote:
> >> I guess my point is that the direction in which a project *does* go is not
> >> always the direction in which it *should* go.
> >
> > I agree.  And depending on people's "political" views, that can either be
> > an advantage or disadvantage of the free software development model.
> >
> >> To give just one small practical example, I'm told (by people who are more
> >> familiar with GCC internals than I) that it is not feasible with today's
> >> GCC to port to backends which have a small number of registers.
> >
> > [Finally, a technical discussion in this thread!]
> >
> > It never really has been.  Maybe it's not even possible now (I don't
> > know), but if you tried it in the past the results would never have
> > been very good.  Almost all multi-backend systems operate by having
> > very large numbers of expressions at all levels, which you gradually
> > lower to actual registers.  This works quite well if you have enough
> > registers to hold the high-usage expressions in them, but when you
> > have high register pressure, the model breaks down completely.
> > Although the situation may well have gotten worse in recent versions
> > that I'm not familiar with, I'd say that GCC was probably doing a
> > *better* job with a small number of registers in more recent versions
> > than in older ones: "reload" was particularly bad when there was high
> > register pressure.
> >
> > When your main constraint is register pressure, in order to get
> > high-quality results, I think you almost have to change the entire
> > philosophy of compilation, to the point I think where you have an
> > almost entirely different compilation chain for such machines.
> >
>
> Low register count cpu designs have been out of fashion for quite some
> time now (perhaps precisely because they are not a good fit for common
> compiler strategies).  They are mostly found in older families, such as
> the 8-bit CISC designs in older microcontrollers (8051, PIC, COP8, 6502,
> etc.).  And you are absolutely right that you need a different way of
> thinking in order to get the best out of such chips - low register count
> is only one aspect.  Other issues are few or no flexible pointer
> registers, no "SP + offset" addressing modes for efficient parameters or
> stack frames, banked ram and code blocks, and multiple separate address
> spaces.  Good toolchains for such devices need to work in a very
> different way, and typically encompass compilation, assembling and
> linking in one "omniscient" build so that variables, parameters, etc.,
> can be placed statically in ways that minimise banking and maximise
> reuse, based on lifetime analysis of the whole program.
>
> This would be a massively different way of working from how gcc does
> things now, and given that such devices are very much on the decline
> (when 32-bit ARM microcontrollers can be bought for 30 cents, smaller
> and cheaper cpu cores are rarely the right choice for a new design), it
> would not make sense to spend the effort supporting them in gcc.  There
> is, after all, quite a solid GPL'ed compiler toolchain for such devices
> at .

I think it depends on your goals.  In the past I've ported GCC to a
Harvard architecture system with six registers.  I agree that the code
quality was not the highest possible.  But the port worked fine, and
for this process performance was not an issue.  (As you suggest, I
tend to think that for most people who choose a processor with a small
number of registers, performance is not an issue.  Where performance
matters a lot, spend the money for a real processor, or at least use a
RISC/V.)

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc  wrote:
>
> once or twice when physical violence with threatened, but that's about
> it (aside from spammers).  I don't think we want to get too deep into
> moderation and the like -- IMHO it should be an extremely rare event.
> As much as I disagree with some of the comments that have been made I
> don't think they've risen to the level of wanting/needing to ban those
> individuals from posting.

I think it's useful to observe that there are a reasonable number of
people who will refuse to participate in a project in which the
mailing list has regular personal attacks and other kinds of abusive
behavior.  I know this because I've spoken with such people myself.
They simply say "that project is not for me" and move on.

So we don't get the choice between "everyone is welcome" and "some
people are kicked off the list."  We get the choice between "some
people decline to participate because it is unpleasant" and "some
people are kicked off the list."

Given the choice of which group of people are going to participate and
which group are not, which group do we want?

(I'm raising this as a kind of first principle.  If there is a system
for banning people from the list, there are various things to discuss
as to how that might work.  And I've seen it work effectively in other
communities.  But if we don't agree on that first principle, there is
no point to continuing.)

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Wed, Apr 14, 2021 at 1:49 PM Paul Koning  wrote:
>
> > On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc  
> > wrote:
> >
> > On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc  wrote:
> >>
> >> once or twice when physical violence with threatened, but that's about
> >> it (aside from spammers).  I don't think we want to get too deep into
> >> moderation and the like -- IMHO it should be an extremely rare event.
> >> As much as I disagree with some of the comments that have been made I
> >> don't think they've risen to the level of wanting/needing to ban those
> >> individuals from posting.
> >
> > I think it's useful to observe that there are a reasonable number of
> > people who will refuse to participate in a project in which the
> > mailing list has regular personal attacks and other kinds of abusive
> > behavior.  I know this because I've spoken with such people myself.
> > They simply say "that project is not for me" and move on.
> >
> > So we don't get the choice between "everyone is welcome" and "some
> > people are kicked off the list."  We get the choice between "some
> > people decline to participate because it is unpleasant" and "some
> > people are kicked off the list."
> >
> > Given the choice of which group of people are going to participate and
> > which group are not, which group do we want?
>
> My answer is "it depends".  More precisely, in the past I would have favored 
> those who decline because the environment is unpleasant -- with the implied 
> assumption being that their objections are reasonable.  Given the emergency 
> of cancel culture, that assumption is no longer automatically valid.
>
> This is why I asked the question "who decides?"  Given a disagreement in 
> which the proposed remedy is to ostracise a participant, it is necessary to 
> inquire for what reason this should be done (and, perhaps, who is pushing for 
> it to be done).  My suggestion is that this judgment can be made by the 
> community (via secret ballot), unless it is decided to delegate that power to 
> a smaller body, considered as trustees, or whatever you choose to call them.

Personally, I think that voting is unworkable in practice.  I think
decisions can be reasonably delegated to a small group of trusted
people.  A fairly common name for that group is "moderators".  It
might be appropriate to use voting of some sort when selecting
moderators.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Wed, Apr 14, 2021 at 2:24 PM Jeff Law  wrote:
>
> But yes, I understand your point and it's a good one and I think we can
> probably find some common ground there -- but even so I think banning
> should be a rare event and some official outreach to the offender should
> happen first.

Agreed (except for cases of obvious spam entirely unrelated to the project).

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Wed, Apr 14, 2021 at 3:41 PM Frosku  wrote:
>
> I think, in general, it's fine to leave this decision to moderators. It's
> just a little disconcerting when one of the people who would probably be
> moderating is saying that he could have shut down the discussion if he
> could only ban jerks, as if to imply that everyone who dares to disagree
> with his position is a jerk worthy of a ban.

I haven't seen anybody say that, so I'm not sure who you are talking
about.  In any case, what makes you say that that person, whoever they
are, would probably be a moderator?  And why do you infer that that
person believes that everybody who "dares to disagree with his
position" is a jerk?  Did they say so?  Or are you making the same
mistake that you are attributing to this person: equating disagreement
over ideas with disagreement about appropriate behavior?

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Wed, Apr 14, 2021 at 4:28 PM Frosku  wrote:
>
> On Thu Apr 15, 2021 at 12:19 AM BST, Ian Lance Taylor wrote:
> > On Wed, Apr 14, 2021 at 3:41 PM Frosku  wrote:
> > >
> > > I think, in general, it's fine to leave this decision to moderators. It's
> > > just a little disconcerting when one of the people who would probably be
> > > moderating is saying that he could have shut down the discussion if he
> > > could only ban jerks, as if to imply that everyone who dares to disagree
> > > with his position is a jerk worthy of a ban.
> >
> > I haven't seen anybody say that, so I'm not sure who you are talking
> > about. In any case, what makes you say that that person, whoever they
> > are, would probably be a moderator? And why do you infer that that
> > person believes that everybody who "dares to disagree with his
> > position" is a jerk? Did they say so? Or are you making the same
> > mistake that you are attributing to this person: equating disagreement
> > over ideas with disagreement about appropriate behavior?
> >
> > Ian
>
> This was the quote:
>
> > The choice to /not/ have a policy for ejecting jerks has serious costs.
> > One of those costs is the kind of rancorous dispute that has been
> > burning like a brushfire on this list the last few weeks.
>
> My read is that this is suggestions that if the 'jerks' were simply
> removed from the discussion, there would be no dispute. The only way this
> would be true is if all the jerks were on a single side of it, and I make
> the assumption that the individual I'm quoting wasn't suggesting that he
> himself be banned.
>
> Perhaps you can suggest a more charitable read. Ambiguity is the enemy of
> good discussion in text, after all.

You are assuming that all dispute is rancorous.  That is not the case.

(And I'm still not sure why you think he would "probably be moderating.")

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Wed, Apr 14, 2021 at 4:39 PM Frosku  wrote:
>
> On Thu Apr 15, 2021 at 12:36 AM BST, Ian Lance Taylor wrote:
> >
> > (And I'm still not sure why you think he would "probably be
> > moderating.")
> >
> > Ian
>
> In my experience, those people who seek code of conducts generally envision
> themselves as the enforcers, not the parties upon which they should be 
> enforced.
> If you're telling me that it's unlikely, that makes me feel better.

It seems unlikely to me.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Thu, Apr 15, 2021 at 10:31 AM David Malcolm via Gcc  wrote:
>
> I still admire much of what RMS has written, and have spent much of my
> career trying to implement part of a vision inspired by him.  I'm sad
> about the way things have turned out.  Twitter seems to turn everything
> into a pitched battle between two camps.  I hope there's room for a
> nuanced view of him - the good and the less good.  I don't know what
> role he should have, but I think it should not be a leadership one, and
> I think the FSF and GNU need to greatly change to stay relevant,
> including on governance and on succession plans.  None of us are
> getting any younger, and the vision of the FSF and GNU seems to me to
> be stuck in the 1990s (or earlier).

Thanks, that is well put.  That describes my own feelings as well.

To be very blunt, I don't know how to read
https://www.fsf.org/news/rms-addresses-the-free-software-community and
think "the person who wrote this should be in a leadership role."  I
don't think RMS is a bad person.  I think that RMS can still have a
great deal to contribute to free software as a programmer and as a
philosopher.  But those are not the words of a leader.  Leadership is
about people: understanding what people need, understanding how to
motivate them toward a shared goal.  What I see in that essay is
somebody who doesn't understand people very well, and is not all that
interested in learning.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Thu, Apr 15, 2021 at 12:45 PM Christopher Dimech via Gcc
 wrote:
>
> Proposing the guidelines essentially means that the community accepts the fact
> that many of us are incapable of navigate everyday problems and dilemmas by 
> making
> “right” decisions based on the use of good judgment and values rather than 
> sterile
> sets of rules and conventions that typically disregard the individual, the 
> particular,
> or the discrete.  Thusly, it is wrong to suggest that the problems are simply 
> associated with RMS, FSF and GNU.

I think you are conflating two different things.  Iain was describing
general guidelines for communication, not saying anything about RMS,
FSF, or GNU.

Personally I would say that the purpose of communication guidelines
for GCC mailing lists is not for existing members of the community.
As several people have said, the GCC mailing lists are normally civil.
It is to provide a mechanism for blocking people whose goal is, for
whatever reason, to disrupt the community.  Such a mechanism requires
a lot of sensitivity to context and care on the part of the
moderators.  But it still helps to have a set of guidelines to refer
to.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc  wrote:
>
> Every single proponent of this argument that I have seen so far is
> employed by one of the same 5 companies and "really isn't doing it on
> behalf of my company I swear".
>
> Why is it almost exclusively that specific crowd saying it here, then?

For better or for worse, since the early '90s the majority of people
who do serious work on GCC have been hired by companies that want to
do serious work on GCC.  After all, it's a win-win: the company gets
work done, the GCC programmer gets well paid.  The effect is that most
of the major GCC contributors work for a relatively small number of
companies.  There are of course many exceptions, but that is the
general rule.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Thu, Apr 15, 2021 at 4:29 PM Eric S. Raymond  wrote:
>
> *grumble* Get *over* yourselves.  You want to be "welcoming" to
> women?  Don't patronize or infantilize them - respect their ability to
> tell off RMS for themselves *and then keep working with him*!

Thank you for sharing your experiences.

I just want to note that I think this last paragraph misses the point.
Patronizing or infantilizing anybody doesn't come into this at all.

This is about work.  There are social aspects to free software, but
it's not fundamentally a social activity.  It's about getting
something done, and for many people it's their job.  For the sake of
argument, I'm going to temporarily set aside all consideration of how
people should behave in a professional setting, not because it doesn't
matter, but just to try to clarify matters.  Let's just think about
the project.

We want free software to succeed.  Free software is more likely to
succeed if more people work on it.  If you are a volunteer, as many
are, you can choose to spend your time on the project where you have
to short-stop unwelcome advances, where you are required to deal with
"men with poor social skills."  Or you can choose to spend your time
on the project where people treat you with respect.  Which one do you
choose?

Or perhaps you have a job that requires you to work on free software.
Now, if you work on a project where the people act like RMS, you are
being forced by your employer to work in a space where you face
unwelcome advances and men who have "trouble recognizing boundaries."
That's textbook hostile environment, and a set up for you to sue your
employer.  So your employer will never ask anyone to work on a project
where people act like that--at least, they won't do it more than once.

In other words, having people who act in the way that you describe RMS
as acting is actively harmful for a free software project, because it
will discourage people from working on it.

(Entirely separately, I don't get the slant of your whole e-mail.  You
can put up with RMS despite the boorish behavior you describe.  Great.
You're a saint.  Why do you expect everyone else to be a saint?  I
don't meet with people who act like that, not more than once.  Life is
too short.  I'll work with them if I must, but not if I don't have
to.)

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Thu, Apr 15, 2021 at 8:02 PM Frosku  wrote:
>
> > We want free software to succeed. Free software is more likely to
> > succeed if more people work on it. If you are a volunteer, as many
> > are, you can choose to spend your time on the project where you have
> > to short-stop unwelcome advances, where you are required to deal with
> > "men with poor social skills." Or you can choose to spend your time
> > on the project where people treat you with respect. Which one do you
> > choose?
>
> The one where technical excellence is prioritized over social skills,
> personally. If I have a choice between partaking in a project where I
> have to walk on eggshells for fear of people coming with torches and
> pitchforks to expel me because I was a bit too harsh in my critique or
> posted an opinion on my personal blog which wasn't something they
> agreed with, or a project where some of the other people are people I
> wouldn't share a beer with but the technical standard is high and free
> expression is generally valued, I would choose the latter.

Those are not the only two possible ways that a project can work.

Also, you seem to be making the implicit assumption that there is some
sort of trade off between technical excellence and social skills.
That is false.  They are independent axes.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Thu, Apr 15, 2021 at 9:09 PM Eric S. Raymond  wrote:
>
> Ian Lance Taylor :
> > Patronizing or infantilizing anybody doesn't come into this at all.
>
> I am not even *remotely* persuaded of this.  This whole attitude that if
> a woman is ever exposed to a man with less than perfect American
> upper-middle-class manners it's a calamity requiring intervention
> and mass shunning, that *reeks* of infantilizing women.

I just don't see it.  Maybe occasionally.  But in general you see
someone acting badly, and you think "I don't want to associate with
that person."  Preferring to work with people who treat others
decently is not about infantilizing others.


> > We want free software to succeed.  Free software is more likely to
> > succeed if more people work on it.  If you are a volunteer, as many
> > are, you can choose to spend your time on the project where you have
> > to short-stop unwelcome advances, where you are required to deal with
> > "men with poor social skills."  Or you can choose to spend your time
> > on the project where people treat you with respect.  Which one do you
> > choose?
>
> The one where your expected satisfaction is higher, with boorishness
> from autistic males factored in as one of the overheads.  Don't try to
> tell me that's a deal-killer, I've known too many women who would
> laugh at you for that assumption.

I'm not saying either option is a deal killer, I'm saying you have to
make a choice.  And more generally a project has to make a choice.


> > Or perhaps you have a job that requires you to work on free software.
> > Now, if you work on a project where the people act like RMS, you are
> > being forced by your employer to work in a space where you face
> > unwelcome advances and men who have "trouble recognizing boundaries."
> > That's textbook hostile environment, and a set up for you to sue your
> > employer.  So your employer will never ask anyone to work on a project
> > where people act like that--at least, they won't do it more than once.
>
> Here's what happens in the real world (and I'm not speculating, I was
> a BoD member of a tech startup at one time, stuff like this came up).
> You say "X is being a jerk - can I work on something else?"  Your
> employer, rightly terrified of the next step, is not going to "force"
> you to do a damn thing. He's going to bend over backwards to
> accommodate you.

Yes.


> What I am pushing for is for everyone to recognize that *women are
> adults* - they have their own agency and are in general perfectly
> capable of treating an RMS-class jerk as at worst a minor annoyance.

OK, you got it.  Not sure it's relevant to what I'm saying, though.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Thu, Apr 15, 2021 at 9:08 PM Frosku  wrote:
>
> On the other hand, I also think that a project which goes too far in
> policing speech, especially speech unrelated to the project, will drive away
> talented people who are more than willing to comply with the project's norms
> within the project's spaces. Trying to enforce the 'California cultural
> standard' on not only someone's interactions with the project but their
> entire life (which may be lived in a very different cultural setting) seems
> very invasive and culturally exclusionary.

I do live in California, but I don't know what the "California
cultural standard" is.  It's a big place, and it's full of people who
behave in all kinds of different ways.  Harvey Weinstein and
brogrammer culture are California cultures.  You presumably have
something in mind, but I'm not sure it's a real thing.


> I'd be interested to know where you draw the line as to what behavior is
> related to the project, or if you don't draw a line, why volunteers in China,
> Russia, Poland etc should be expected to accept an entire political doctrine
> over their life to contribute to a compiler toolchain.

How did we get to accepting an entire political doctrine?

What I have in mind is treating people with respect.  For example, I'm
involved with the Go programming language.  The Go community has a
code of conduct: https://golang.org/conduct.  The key elements are:

- Be friendly and welcoming
- Be patient
  Remember that people have varying communication styles and that not
everyone is using their native language. (Meaning and tone can be lost
in translation.)
- Be thoughtful
  Productive communication requires effort. Think about how your words
will be interpreted.
  Remember that sometimes it is best to refrain entirely from commenting.
- Be respectful
  In particular, respect differences of opinion.
- Be charitable
  Interpret the arguments of others in good faith, do not seek to disagree.
  When we do disagree, try to understand why.

  Avoid destructive behavior:

  Derailing: stay on topic; if you want to talk about something else,
start a new conversation.
  Unconstructive criticism: don't merely decry the current state of
affairs; offer—or at least solicit—suggestions as to how things may be
improved.
  Snarking (pithy, unproductive, sniping comments)
  Discussing potentially offensive or sensitive issues; this all too
often leads to unnecessary conflict.
  Microaggressions: brief and commonplace verbal, behavioral and
environmental indignities that communicate hostile, derogatory or
negative slights and insults to a person or group.


That is what I would aim for.  And in general that is how the GCC
community behaves.  I don't know whether that is "California culture"
or not.


And I have to note that I have seen very few people here saying "RMS
must never participate in GCC in any way."  What I see most people
saying is "RMS should not be in a position of leading the GCC project
and telling people what to do."

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Fri, Apr 16, 2021 at 4:16 PM Frosku  wrote:
>
> When I refer to a 'California cultural standard', that's not prescriptive. 
> It's
> just a reference to the fact that a *lot* of the SC live in California, and 
> any
> culture prescribed by the steering committee will be overly influenced by that
> commonality.

To the best of my knowledge, 2 of the 13 members of the GCC steering
committee live in California.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

This conversation has moved well off-topic for the GCC mailing lists.

Some of the posts here do not follow the GNU Kind Communication
Guidelines (https://www.gnu.org/philosophy/kind-communication.en.html).

I suggest that people who want to continue this thread take it off the
GCC mailing list.

Thanks.

Ian

Re: removing toxic emailers

[Ian Lance Taylor via Gcc]

On Tue, Apr 20, 2021, 12:54 AM Jonathan Wakely via Gcc 
wrote:

>
> Check the git logs, Google employees are minor contributors these
> days. The GPLv3 scared Google away from GCC years ago.
>

Just for the record, Google has no problem with the GPLv3.  Google stopped
working on GCC because they made a company decision to use clang instead.
That decision was made for technical reasons, not licensing reasons.

Ian

>

Re: GCC 1.40.

[Ian Lance Taylor via gcc]

On Fri, Sep 14, 2018 at 3:40 AM, ?yvind Hagen via gcc  wrote:
>
> Hi to you in GCC Development department.
> Do you still have manual Version 1.40 so I can decode if that code in Linux 
> 0.01 is correctly set up 100% and just that.
> And, I am wondering if that is easy to decode MS-DOS 5.0 to run in Linux 0.01?
>
> A long, long ago, I have been sent to you an e-mail something about 
> compiling, which I forgetting through time, set up but you developers in your 
> organization never replied so I ran away disappointed.

It would be better to use the mailing list gcc-h...@gcc.gnu.org for
questions like this.  The mailing list gcc@gcc.gnu.org is mostly for
the development of GCC itself.  See https://gcc.gnu.org/lists.html.
Thanks.

You can get a copy of gcc-1.40 from
ftp://gcc.gnu.org/pub/gcc/old-releases/gcc-1 .  But I have to warn you
that it may not be possible to build it with a current version of GCC.
I haven't tried.

Ian

Re: Is GIMPLE stable?

[Ian Lance Taylor via gcc]

On Mon, Sep 9, 2019 at 8:09 PM Mateus Carmo Martins de Freitas Barbosa
 wrote:
>
> There's an ongoing discussion on the rustc forum
> ()
> on implementing a GCC front-end for the Rust compiler, and the issue
> of whether GIMPLE is stable was brought up. Namely, if a compiler
> front-end were to output GIMPLE directly, how often (if at all) would
> its codebase have to be changed to due to breaking changes from GCC?
>
> I did find this reply
>  which says:
>
> >> ?^ It looks like GIMPLE is expected to change per version of gcc. Is there 
> >> a time in >> the future when GIMPLE will be pretty stable?
> >
> > "Pretty stable" won't be enough, and I don't see us arriving there at
> > the moment.
>
> But this is fairly old (2011) so it seemed reasonable to ask if this
> is still the case.

GIMPLE is fairly stable but not 100% stable.  The way the Go frontend
handles this is that the file that converts between the Go frontend IR
and GIMPLE is part of the GCC tree (gcc/go/go-gcc.cc).  This file is
then routinely updated whenever three is a tree-wide GIMPLE change.
With that approach I very rarely have to change the GIMPLE generation
code myself.

Ian

Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
I'm seeing the following.  Is anybody else seeing this crash?  Thanks.

Ian

/tmp/go-build-release/gccgo-objdir/ppc/./gcc/xgcc
-B/tmp/go-build-release/gccgo-objdir/ppc/./gcc/
-B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/bin/
-B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/lib/
-isystem 
/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/include
-isystem 
/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/sys-include
--sysroot=/google/src/files/285475989/depot/google3/third_party/grte/v5_ppc/release/usr/grte/v5
  -g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
-Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I.
-I. -I../.././gcc -I/tmp/go-build-release/gccgo-srcdir/libgcc
-I/tmp/go-build-release/gccgo-srcdir/libgcc/.
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../gcc
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../include
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/dpd
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber
-DHAVE_CC_TLS  -o decNumber.o -MT decNumber.o -MD -MP -MF
decNumber.dep -c
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:
In function 'decToString':
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
error: unrecognizable insn:
 3760 |   } /* decToString */
  |   ^
(insn/f 1592 1591 1593 145 (set (reg:CC 104 4)
(unspec:CC [
(reg:SI 12 12)
(const_int 8 [0x8])
] UNSPEC_MOVESI_TO_CR))
"/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c":3760:3
-1
 (expr_list:REG_DEAD (reg:SI 12 12)
(expr_list:REG_CFA_RESTORE (reg:SI 104 4)
(nil
during RTL pass: cprop_hardreg
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
internal compiler error: in extract_insn, at recog.c:2294
0xb95832 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:108
0xb9585b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:116
0xb63ec2 extract_insn(rtx_insn*)
/tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2294
0xb67995 extract_constrain_insn(rtx_insn*)
/tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2193
0xb6a552 copyprop_hardreg_forward_1(basic_block_def*, value_data*)
/tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:802
0xb6e207 (anonymous namespace)::pass_cprop_hardreg::execute(function*)
/tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:1367
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [Makefile:645: decNumber.o] Error 1

Re: Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

On Sat, Dec 14, 2019 at 10:51 AM Ian Lance Taylor  wrote:
>
> I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
>
> Ian
>
> /tmp/go-build-release/gccgo-objdir/ppc/./gcc/xgcc
> -B/tmp/go-build-release/gccgo-objdir/ppc/./gcc/
> -B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/bin/
> -B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/lib/
> -isystem 
> /tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/include
> -isystem 
> /tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/sys-include
> --sysroot=/google/src/files/285475989/depot/google3/third_party/grte/v5_ppc/release/usr/grte/v5
>   -g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
> -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
> -Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
> -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
> -fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I.
> -I. -I../.././gcc -I/tmp/go-build-release/gccgo-srcdir/libgcc
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/.
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../gcc
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../include
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/dpd
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber
> -DHAVE_CC_TLS  -o decNumber.o -MT decNumber.o -MD -MP -MF
> decNumber.dep -c
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:
> In function 'decToString':
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
> error: unrecognizable insn:
>  3760 |   } /* decToString */
>   |   ^
> (insn/f 1592 1591 1593 145 (set (reg:CC 104 4)
> (unspec:CC [
> (reg:SI 12 12)
> (const_int 8 [0x8])
> ] UNSPEC_MOVESI_TO_CR))
> "/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c":3760:3
> -1
>  (expr_list:REG_DEAD (reg:SI 12 12)
> (expr_list:REG_CFA_RESTORE (reg:SI 104 4)
> (nil
> during RTL pass: cprop_hardreg
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
> internal compiler error: in extract_insn, at recog.c:2294
> 0xb95832 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
> const*)
> /tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:108
> 0xb9585b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> /tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:116
> 0xb63ec2 extract_insn(rtx_insn*)
> /tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2294
> 0xb67995 extract_constrain_insn(rtx_insn*)
> /tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2193
> 0xb6a552 copyprop_hardreg_forward_1(basic_block_def*, value_data*)
> /tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:802
> 0xb6e207 (anonymous namespace)::pass_cprop_hardreg::execute(function*)
> /tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:1367
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make: *** [Makefile:645: decNumber.o] Error 1


Sorry, I think I see the problem.  I forgot to mention that for
complicated reasons I am building this cross-compiler starting with
clang.  In rs6000.md we see

(define_expand "movsi_to_cr_one"
  [(set (match_operand:CC 0 "cc_reg_operand")
(unspec:CC [(match_operand:SI 1 "gpc_reg_operand")
(match_dup 2)] UNSPEC_MOVESI_TO_CR))]
  ""
  "operands[2] = GEN_INT (1 << (75 - REGNO (operands[0])));")

This code has been around for quite a while, and when it was written
the maximum value of a register matching cc_reg_operand was in fact
75.  But now it is 107.  I'm testing changing this 75, and the
corresponding one a few lines down, to MAX_CR_REGNO.

A PowerPC maintainer may want to take this from here.

Ian

Re: Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
 wrote:
>
> On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> > I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
>
> No, and that makes me wonder what is going on.  The error is simple enough
> of course, as you note in a later message; but why do we not see it on
> every other build?

I think it's because clang treats a left shift by a negative number as
undefined behavior but GCC does not.  So GCC is consistently producing
some number, and clang is producing different numbers.

I should note that I don't really understand what purpose that
constant is serving anyhow.

Ian

Re: Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
 wrote:
>
> On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> >  wrote:
> > >
> > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > > > cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> > > > I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
> > >
> > > No, and that makes me wonder what is going on.  The error is simple enough
> > > of course, as you note in a later message; but why do we not see it on
> > > every other build?
> >
> > I think it's because clang treats a left shift by a negative number as
> > undefined behavior but GCC does not.  So GCC is consistently producing
> > some number, and clang is producing different numbers.
> >
> > I should note that I don't really understand what purpose that
> > constant is serving anyhow.
>
> It's the (old, changed months ago!) register number for CR7.  This code
> creates the bitfield that says which CR fields to save or restore.

That much I got, but the bitfield doesn't seem to actually be used for
anything.  It seems to be created and matched but not used.  Unless I
missed something.  The constant doesn't seem to add anything we don't
already know from the register number.

> Anyway, should be fixed now.  If you can confirm, please do :-)

Confirmed.  Thanks.

Ian

Re: Proposal for the transition timetable for the move to GIT

[Ian Lance Taylor via gcc]

On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD
 wrote:
>
> Which brings me to something I find strange in your policy: to me,
> merges from trunk to branches should be rare if not nonexistent. And you
> are deciding to banish merges the other way around.

Out of curiosity, why do you say that merges from trunk to branches
should be rare?  It seems to me that any long-lived development branch
will require merges from trunk to the branch.  Are you saying that
those kinds of branches are rare?

In GCC we have historically had a pattern in which people use
long-lived parallel branches that maintain specific patches on top of
GCC trunk.  These branches provide a simple way to get a variant of
GCC with specific patches of interest to some people.  These branches
too require regular merges from trunk.

Ian

Re: GPLv3 clarification - what constitutes IR

[Ian Lance Taylor via gcc]

On Mon, Mar 6, 2017 at 9:12 AM,   wrote:
>
> I'm looking into the possibility of adding a SPIR-V
> (https://www.khronos.org/registry/spir-v) backend to GCC or as a
> plug-in. The output of which would be binary from the compiler, not
> binutils, with an option to extract a textual representation using an -f
> flag. The positive of this would be that any language that GCC supports
> could be used for GPGPU and graphics shading.
>
> But would the GCC IR exception (mentioned in
> https://www.gnu.org/licenses/gcc-exception-3.1-faq.html) cause any
> SPIR-V output from GCC become GPLv3 licenced?
>
> I have also posted this to the GCC ML for discussion as I don't think
> it's clear whether or not something like SPIR-V would fall under Target
> Code or IR.

I am not a lawyer and this is not legal advice.

Generating SPIR-V output would not cause that output to become GPLv3
licensed.  However, linking the result against the GCC support
libraries, as is normally required for any program generated by GCC,
and then distributing the resulting executable to other people, would
require you to use an eligible compilation process (as defined by the
GCC Runtime Library Exception license that you cite).  What this means
in practice is that you can not take SPIR-V, do further processing it
using a proprietary compiler, link the result with the GCC runtime
libraries, and then distribute the resulting program to anybody else.

I don't think it is necessary to determine whether SPIR-V is "target
code" or "intermediate representation" to draw that conclusion.

Ian

Re: GNU Toolchain Fund established at the Free Software Foundation

[Ian Lance Taylor via gcc]

On Thu, Mar 9, 2017 at 11:49 AM, David Edelsohn  wrote:
> A fund to benefit the components of the GNU Toolchain (GCC, GDB,
> GLIBC, Binutils, Sourceware) has been established at the Free Software
> Foundation.
>
> Personal and corporate donations are welcome!
>
> http://www.fsf.org/news/gnu-toolchain-now-accepting-donations-with-the-support-of-the-free-software-foundation

That is great news.  Thanks.

Is the membership of the committee who will oversee the funds public?

Ian

Re: GCC Runtime Library Exception in gcc/config/* files?

[Ian Lance Taylor via gcc]

On Fri, Jul 21, 2017 at 2:24 AM, Sebastian Huber
 wrote:
>
> there are some files in gcc/config/* that contain the GCC Runtime Library
> Exception
>
> grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config |
> wc
> 186 1865361
>
> and some files that don't include it
>
> grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config -v
> | wc
> 753 753   20927
>
> Does it matter? What should be used for new files?

I think that in general we should probably use the Runtime Library
Exception for header files that might need to be included by a plugin,
which means anything that might be included by tm.h.  But I can't
think of any reason to use the Exception for .c files.

Ian

Re: GCC and Meltdown and Spectre vulnerabilities

[Ian Lance Taylor via gcc]

On Thu, Jan 4, 2018 at 7:14 PM, Zan Lynx  wrote:
>
> On January 4, 2018 8:10:14 PM MST, Eric Gallager  wrote:
>>Is there anything GCC could be doing at the compiler level to mitigate
>>the recently-announced Meltdown and Spectre vulnerabilities? From
>>reading about them, it seems like they involve speculative execution
>>and indirect branch prediction, and those are the domain of things the
>>compiler deals with, right? (For reference, Meltdown is CVE-2017-5754,
>>and Spectre is CVE-2017-5753 and CVE-2017-5715)
>>
>>Just wondering,
>>Eric
>
> If you're allowing people to run untrustworthy machine code on your hardware 
> there's nothing a compiler can do to help. You'd need to make them use your 
> compiler, and why would they?
>
> So anyone offering shell accounts or virtual machines is out of luck.

For the Spectre attack, a compiler can help by using it to compile
accessible programs in such a way that they are not vulnerable to the
attack.

Ian

Re: rust frontend and UTF-8/unicode processing/properties

[Ian Lance Taylor via Gcc]

On Sun, Jul 18, 2021 at 6:23 AM Mark Wielaard  wrote:
>
> For the gcc rust frontend I was thinking of importing a couple of
> gnulib modules to help with UTF-8 processing, conversion to/from
> unicode codepoints and determining various properties of those
> codepoints. But it seems gcc doesn't yet have any gnulib modules
> imported, and maybe other frontends already have helpers to this that
> the gcc rust frontend could reuse.
>
> Rust only accepts valid UTF-8 encoded source files, which may or may
> not start with UTF-8 BOM character. Whitespace is any codepoint with
> the Pattern_White_Space property. Identifiers can start with any
> codepoint with the XID_start property plus zero or one codepoints with
> XID_continue property. It isn't required, but highly desirable to
> detect confusable identifiers according to tr39/Confusable_Detection.
>
> Other names might be constraint to Alphabetic and/or Number categories
> (Nd, Nl, No), textual types can only contain Unicode Scalar Values
> (any Unicode codepoint except high-surrogate and low-surrogates),
> strings in source code can contain unicode escapes (24 bit, up to 6
> digits codepoints) but are internally stored as UTF-8 (and must not
> encode any surrogates).
>
> Do other gcc frontends handle any of the above already in a way that
> might be reusable for other frontends?

I don't know that this is particularly helpful, but the Go frontend
has this kind of code in gcc/go/gofrontend/lex.cc.  E.g.,
Lex::fetch_char, Lex::advance_one_utf8_char, unicode_space,
unicode_digits, unicode_letters, Lex::is_unicode_space, etc.  But you
probably won't be able to use the code directly, and the code in the
gofrontend directory is also shared with GoLLVM so it can't trivially
be moved.

Ian

Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc

[Ian Lance Taylor via Gcc]

On Wed, Aug 3, 2022 at 6:26 AM j  wrote:
>
> I've proposed a patch [1] for condition coverage profiling in gcc,
> implemented in the middle-end alongside the branch coverage. I've
> written most of the tests for C and a few for C++ and finally got around
> to try it with a toy example for D and go and noticed something odd
> about Go's CFG construction.
>
> abc.c:
>  int fn (int a, int b, int c) {
>  if (a && (b || c))
>  return a;
>  else
>  return b * c;
>  }
>
> abc.d:
>  int fn (int a, int b, int c) {
>  if (a && (b || c))
>  return a;
>  else
>  return b * c;
>  }
>
> abc.go:
>  func fn (a int, b int, c int) int {
>  a_ := a != 0;
>  b_ := b != 0;
>  c_ := c != 0;
>
>  if a_ && (b_ || c_) {
>  return 1;
>  } else {
>  return 0;
>  }
>  }
>
> All were built with gcc --coverage -fprofile-conditions (my patch, but
> it does not affect this) and no optimization. The C and D programs
> behaved as expected:
>
> gcov --conditions abc.d:
>
>  3:3:int fn (int a, int b, int c) {
> 3*:4:if (a && (b || c))
> conditions outcomes covered 3/6
> condition  1 not covered (false)
> condition  2 not covered (true)
> condition  2 not covered (false)
>  1:5:return a;
>  -:6:else
>  2:7:return b * c;
>
>
> gcov --conditions abc.go:
>  3:5:func fn (a int, b int, c int) int {
>  3:6:a_ := a != 0;
>  3:7:b_ := b != 0;
>  3:8:c_ := c != 0;
>  -:9:
> 3*:   10:if a_ && (b_ || c_) {
> condition outcomes covered 2/2
> condition outcomes covered 1/2
> condition  0 not covered (true)
> condition outcomes covered 2/2
>  1:   11:return 1;
>  -:   12:} else {
>  2:   13:return 0;
>  -:   14:}
>  -:   15:}
>
> So I dumped the gimple gcc -fdump-tree-gimple abc.go:
>
> int main.fn (int a, int b, int c)
> {
>int D.2725;
>int $ret0;
>
>$ret0 = 0;
>{
>  bool a_;
>  bool b_;
>  bool c_;
>
>  a_ = a != 0;
>  b_ = b != 0;
>  c_ = c != 0;
>  {
>{
>  GOTMP.0 = a_;
>  if (GOTMP.0 != 0) goto ; else goto ;
>  :
>  {
>{
>  GOTMP.1 = b_;
>  _1 = ~GOTMP.1;
>  if (_1 != 0) goto ; else goto ;
>  :
>  {
>GOTMP.1 = c_;
>  }
>  :
>}
>GOTMP.2 = GOTMP.1;
>GOTMP.0 = GOTMP.2;
>  }
>  :
>}
>if (GOTMP.0 != 0) goto ; else goto ;
>:
>
>
>
>{
>  {
>$ret0 = 1;
>D.2725 = $ret0;
>// predicted unlikely by early return (on trees) predictor.
>return D.2725;
>  }
>}
>:
>{
>  {
>$ret0 = 0;
>D.2725 = $ret0;
>// predicted unlikely by early return (on trees) predictor.
>return D.2725;
>  }
>}
>  }
>}
> }
>
> Where as D (and C) is more-or-less as you would expect:
>
> int fn (int a, int b, int c)
>
>
>
> {
>int D.7895;
>
>if (a != 0) goto ; else goto ;
>:
>if (b != 0) goto ; else goto ;
>:
>if (c != 0) goto ; else goto ;
>:
>D.7895 = a;
>// predicted unlikely by early return (on trees) predictor.
>return D.7895;
>:
>D.7895 = b * c;
>// predicted unlikely by early return (on trees) predictor.
>return D.7895;
> }
>
> Clearly the decision inference algorithm is unable to properly
> instrument to Go program for condition coverage because of the use of
> temporaries in the emitted GIMPLE. The question is: is this intentional
> and/or required from Go's semantics or could it be considered a defect?
> Is emitting the GIMPLE without the use of temporaries feasible at all?

The Go frontend converts && and || expressions into code that uses
explicit if statements.  This is done largely as an internal
simplification.  Go has rules about the order in which function calls
and certain other kinds of expressions must be evaluated.  Separating
out the order of evaluation imposed by && and || simplifies the
implementation of the other order of evaluation rules.

Ian

Re: [PATCH 1/4] libbacktrace: change all pc related variables to uintptr_t

[Ian Lance Taylor via Gcc]

On Fri, Jan 20, 2023 at 2:54 AM Björn Schäpers  wrote:
>
> From: Björn Schäpers 
>
> It's the right thing to do, since the PC shouldn't go out of the
> uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t.
> This is a preparation for a following patch.
>
> Tested on x86_64-linux and i686-w64-mingw32.

Thanks.  Committed like so, with some additional tweaks.

For future reference, when pinging a patch, please reply to the
original patch to maintain the thread.  Or at least mention the
original patch.  It was still on my list, I just hadn't gotten to it.
Thanks.

Ian

Change variables holding PC values from uint64_t to uintptr_t.
Patch by Björn Schäpers.
* dwarf.c (struct function_addrs): Change low and high fields to
uintptr_t.
(struct unit_addrs): Likewise.
(resolve_addr_index): Change address parameter to uintptr_t*.
(add_unit_addr): Change lowpc and highpc parameters to uintptr_t.
(add_function_range): Likewise.
(struct pcrange): Change lowpc and highpc fields to uintptr_t.
(add_low_high_range): Change add_range lowpc and highpc parameters
to uintptr_t.
(add_ranges_from_ranges): Likewise.
(add_ranges_from_rnglists): Likewise.
(add_low_high_range): Chnage lowpc and highpc variables to
uintpr_t.
(add_ranges_from_rnglists): Change some local variables to
uintptr_t.
(add_ranges_from_ranges): Change base parameter to uintptr_t.
(add_ranges_from_rnglists): Likewise.
(read_function_entry): Likewise.
(resolve_addr_index): Add explicit casts to uintptr_t.
(update_pcrange): Likewise.
(add_ranges_from_ranges): Likewise.
(add_ranges_from_rnglists): Likewise.
(read_function_entry): Likewise.
0c193cabe1d8f209359f3ccb8e74cf87b38fc4bc
diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index 2d41f3b0397..8ff1fb3ce3d 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -136,7 +136,7 @@ enum attr_val_encoding
   /* An address.  */
   ATTR_VAL_ADDRESS,
   /* An index into the .debug_addr section, whose value is relative to
-   * the DW_AT_addr_base attribute of the compilation unit.  */
+ the DW_AT_addr_base attribute of the compilation unit.  */
   ATTR_VAL_ADDRESS_INDEX,
   /* A unsigned integer.  */
   ATTR_VAL_UINT,
@@ -274,8 +274,8 @@ struct function
 struct function_addrs
 {
   /* Range is LOW <= PC < HIGH.  */
-  uint64_t low;
-  uint64_t high;
+  uintptr_t low;
+  uintptr_t high;
   /* Function for this address range.  */
   struct function *function;
 };
@@ -356,8 +356,8 @@ struct unit
 struct unit_addrs
 {
   /* Range is LOW <= PC < HIGH.  */
-  uint64_t low;
-  uint64_t high;
+  uintptr_t low;
+  uintptr_t high;
   /* Compilation unit for this address range.  */
   struct unit *u;
 };
@@ -1094,7 +1094,7 @@ resolve_addr_index (const struct dwarf_sections 
*dwarf_sections,
uint64_t addr_base, int addrsize, int is_bigendian,
uint64_t addr_index,
backtrace_error_callback error_callback, void *data,
-   uint64_t *address)
+   uintptr_t *address)
 {
   uint64_t offset;
   struct dwarf_buf addr_buf;
@@ -1115,7 +1115,7 @@ resolve_addr_index (const struct dwarf_sections 
*dwarf_sections,
   addr_buf.data = data;
   addr_buf.reported_underflow = 0;
 
-  *address = read_address (&addr_buf, addrsize);
+  *address = (uintptr_t) read_address (&addr_buf, addrsize);
   return 1;
 }
 
@@ -1194,7 +1194,7 @@ function_addrs_search (const void *vkey, const void 
*ventry)
 
 static int
 add_unit_addr (struct backtrace_state *state, void *rdata,
-  uint64_t lowpc, uint64_t highpc,
+  uintptr_t lowpc, uintptr_t highpc,
   backtrace_error_callback error_callback, void *data,
   void *pvec)
 {
@@ -1530,10 +1530,10 @@ lookup_abbrev (struct abbrevs *abbrevs, uint64_t code,
lowpc/highpc is set or ranges is set.  */
 
 struct pcrange {
-  uint64_t lowpc;  /* The low PC value.  */
+  uintptr_t lowpc; /* The low PC value.  */
   int have_lowpc;  /* Whether a low PC value was found.  */
   int lowpc_is_addr_index; /* Whether lowpc is in .debug_addr.  */
-  uint64_t highpc; /* The high PC value.  */
+  uintptr_t highpc;/* The high PC value.  */
   int have_highpc; /* Whether a high PC value was found.  */
   int highpc_is_relative;  /* Whether highpc is relative to lowpc.  */
   int highpc_is_addr_index;/* Whether highpc is in .debug_addr.  */
@@ -1553,12 +1553,12 @@ update_pcrange (const struct attr* attr, const struct 
attr_val* val,
 case DW_AT_low_pc:
   if (val->encoding == ATTR_VAL_ADDRESS)
{
- pcrange->lowpc = val->u.uint;
+ pcrange->lowpc = (uintptr_t) val->u.uint;
  pcrange->have_lowpc = 1;
}
   else if (val->encoding == ATTR_VAL_ADDRESS_INDEX)
{
- pcrange->lowpc = val->u.uint;
+ pcrange->lowpc = (uintptr_t) val->u.uint;
  pcrange->have_lowpc = 1;
  pcrange->lowpc_is_addr_index = 1;
}
@

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc]

On Fri, Jan 20, 2023 at 2:56 AM Björn Schäpers  wrote:
>
> From: Björn Schäpers 
>
> This is actually needed so that libstdc++'s  implementation
> to be able to work on windows.
>
> Tested on x86_64-linux and i686-w64-mingw32.
>
> -- >8 --
>
> * configure.ac: Add a check for windows.h.
> * configure, config.h.in: Regenerate.
> * fileline.c: Add windows_get_executable_path.
> * fileline.c (fileline_initialiez): Add a pass using
> windows_get_executable_path.
>
> +#ifdef HAVE_WINDOWS_H
> +
> +static char *
> +windows_get_executable_path (char *buf, backtrace_error_callback 
> error_callback,
> +void *data)
> +{
> +  if (GetModuleFileNameA (NULL, buf, MAX_PATH - 1) == 0)
> +{
> +  error_callback (data,
> + "could not get the filename of the current executable",
> + (int) GetLastError ());
> +  return NULL;
> +}
> +  return buf;
> +}

Thanks, but this seems incomplete.  The docs for GetModuleFileNameA
say that if the pathname is too long to fit into the buffer it returns
the size of the buffer and sets the error to
ERROR_INSUFFICIENT_BUFFER.  It seems to me that in that case we should
allocate a larger buffer and try again.  And, in general, it will be
simpler if we always allocate the buffer, as macho_get_executable_path
does.  Unfortunately it appears that Windows does not provide a way to
ask for the required length.  On Windows it seems that MAX_PATH is not
a true limit, as an extended length path may be up to 32767 bytes.

So probably something like (untested)

static char *
windows_get_executable_path (struct backtrace_state *state,
 backtrace_error_callback error_callback,
 void *data)
{
  uint32_t len;
  char *buf;

  len = MAX_PATH;
  while (1)
{
  uint32_t got;

  name = (char *) backtrace_alloc (state, len, error_callback, data);
  if (name == NULL)
return NULL;
  got = GetModuleFileNameA (NULL, name, len);
  if (got < len - 1) /* -1 because NULB is not counted */
return name;
  backtrace_free (state, name, len, error_callback, data);
  if (GetLastError () != ERROR_INSUFFICIENT_BUFFER)
return NULL;
  len *= 2;
}
}

Ian

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc]

On Tue, Jan 24, 2023 at 5:11 AM Eli Zaretskii via Gcc-patches
 wrote:
>
> > Date: Mon, 23 Jan 2023 15:00:56 -0800
> > Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> > From: Ian Lance Taylor via Gcc 
> >
> > > +#ifdef HAVE_WINDOWS_H
> > > +
> > > +static char *
> > > +windows_get_executable_path (char *buf, backtrace_error_callback 
> > > error_callback,
> > > +void *data)
> > > +{
> > > +  if (GetModuleFileNameA (NULL, buf, MAX_PATH - 1) == 0)
> > > +{
> > > +  error_callback (data,
> > > + "could not get the filename of the current 
> > > executable",
> > > + (int) GetLastError ());
> > > +  return NULL;
> > > +}
> > > +  return buf;
> > > +}
> >
> > Thanks, but this seems incomplete.  The docs for GetModuleFileNameA
> > say that if the pathname is too long to fit into the buffer it returns
> > the size of the buffer and sets the error to
> > ERROR_INSUFFICIENT_BUFFER.  It seems to me that in that case we should
> > allocate a larger buffer and try again.
>
> This is correct in general, but not in this particular case.
>
> > On Windows it seems that MAX_PATH is not
> > a true limit, as an extended length path may be up to 32767 bytes.
>
> The limit of 32767 characters (not bytes, AFAIK) is only applicable
> when using the Unicode (a.k.a. "wide") versions of the Windows Win32
> APIs, see
>
>   
> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
>
> Since the above code uses GetModuleFileNameA, which is an "ANSI"
> single-byte API, it is still subject to the MAX_PATH limitation, and
> MAX_PATH is defined as 260 on Windows headers.

Thanks.  Should this code be using GetModuleFileNameW?  Or would that
mean that the later call to open will fail?

260 bytes does not seem like very much for a path name these days.

Ian

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc]

On Tue, Jan 24, 2023 at 8:53 AM Eli Zaretskii via Gcc-patches
 wrote:
>
> > From: Ian Lance Taylor 
> > Date: Tue, 24 Jan 2023 06:35:21 -0800
> > Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> >
> > > > On Windows it seems that MAX_PATH is not
> > > > a true limit, as an extended length path may be up to 32767 bytes.
> > >
> > > The limit of 32767 characters (not bytes, AFAIK) is only applicable
> > > when using the Unicode (a.k.a. "wide") versions of the Windows Win32
> > > APIs, see
> > >
> > >   
> > > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
> > >
> > > Since the above code uses GetModuleFileNameA, which is an "ANSI"
> > > single-byte API, it is still subject to the MAX_PATH limitation, and
> > > MAX_PATH is defined as 260 on Windows headers.
> >
> > Thanks.  Should this code be using GetModuleFileNameW?  Or would that
> > mean that the later call to open will fail?
>
> We'd need to use _wopen or somesuch, and the file name will have to be
> a wchar_t array, not a char array, yes.  So this is not very practical
> when file names need to be passed between functions, unless they are
> converted to UTF-8 (and back again before using them in Windows APIs).
>
> And note that even then, the 260-byte limit could be lifted only if
> the user has a new enough Windows version _and_ has opted in to the
> long-name feature by turning it on in the Registry.  Otherwise, file
> names used in "wide" APIs can only break the 260-byte limit if they
> use the special format "\\?\D:\foo\bar", which means file names
> specified by user outside of the program or file names that come from
> other programs will need to be reformatted to this special format.
>
> > 260 bytes does not seem like very much for a path name these days.
>
> That's true.  But complications with using longer file names are still
> a PITA on Windows, even though they are a step closer to practically
> possible.


OK, thanks.

I'd rather that the patch look like the appended.  Can someone with a
Windows system test to see what that builds and passes the tests?
Thanks.

Ian

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc]

On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
 wrote:
>
> > From: Ian Lance Taylor 
> > Date: Tue, 24 Jan 2023 09:58:10 -0800
> > Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> >
> > I'd rather that the patch look like the appended.  Can someone with a
> > Windows system test to see what that builds and passes the tests?
>
> ENOPATCH

Gah.

Ian
diff --git a/libbacktrace/config.h.in b/libbacktrace/config.h.in
index 94621c2e385..29d1ad3911a 100644
--- a/libbacktrace/config.h.in
+++ b/libbacktrace/config.h.in
@@ -100,6 +100,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UNISTD_H
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_WINDOWS_H
+
 /* Define if -lz is available. */
 #undef HAVE_ZLIB
 
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 6af2c04c81a..0a27cfb7799 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -13409,6 +13409,19 @@ $as_echo "#define HAVE_LOADQUERY 1" >>confdefs.h
 
 fi
 
+for ac_header in windows.h
+do :
+  ac_fn_c_check_header_mongrel "$LINENO" "windows.h" "ac_cv_header_windows_h" 
"$ac_includes_default"
+if test "x$ac_cv_header_windows_h" = xyes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_WINDOWS_H 1
+_ACEOF
+
+fi
+
+done
+
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 39e6bf41e35..e3e10abd7b5 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -377,6 +377,8 @@ if test "$have_loadquery" = "yes"; then
   AC_DEFINE(HAVE_LOADQUERY, 1, [Define if AIX loadquery is available.])
 fi
 
+AC_CHECK_HEADERS(windows.h)
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index 674bf33cdcf..e110b54ee24 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -47,6 +47,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #endif
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 #include "backtrace.h"
 #include "internal.h"
 
@@ -155,6 +167,27 @@ macho_get_executable_path (struct backtrace_state *state,
 
 #endif /* !defined (HAVE_MACH_O_DYLD_H) */
 
+#ifdef HAVE_WINDOWS_H
+
+static char *
+windows_get_executable_path (char *buf, backtrace_error_callback 
error_callback,
+void *data)
+{
+  size_t got;
+
+  got = GetModuleFileNameA (NULL, buf, MAX_PATH - 1);
+  if (got == 0
+  || (got == MAX_PATH - 1 && GetLastError () == ERROR_INSUFFICIENT_BUFFER))
+return NULL;
+  return buf;
+}
+
+#else /* !defined (HAVE_WINDOWS_H) */
+
+#define windows_get_executable_path(buf, error_callback, data) NULL
+
+#endif /* !defined (HAVE_WINDOWS_H) */
+
 /* Initialize the fileline information from the executable.  Returns 1
on success, 0 on failure.  */
 
@@ -168,7 +201,11 @@ fileline_initialize (struct backtrace_state *state,
   int called_error_callback;
   int descriptor;
   const char *filename;
+#ifdef HAVE_WINDOWS_H
+  char buf[MAX_PATH];
+#else
   char buf[64];
+#endif
 
   if (!state->threaded)
 failed = state->fileline_initialization_failed;
@@ -192,7 +229,7 @@ fileline_initialize (struct backtrace_state *state,
 
   descriptor = -1;
   called_error_callback = 0;
-  for (pass = 0; pass < 8; ++pass)
+  for (pass = 0; pass < 9; ++pass)
 {
   int does_not_exist;
 
@@ -224,6 +261,9 @@ fileline_initialize (struct backtrace_state *state,
case 7:
  filename = macho_get_executable_path (state, error_callback, data);
  break;
+   case 8:
+ filename = windows_get_executable_path (buf, error_callback, data);
+ break;
default:
  abort ();
}

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc]

On Sun, Feb 5, 2023 at 1:21 AM Björn Schäpers  wrote:
>
> Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:
> > On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
> >  wrote:
> >>
> >>> From: Ian Lance Taylor 
> >>> Date: Tue, 24 Jan 2023 09:58:10 -0800
> >>> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> >>>
> >>> I'd rather that the patch look like the appended.  Can someone with a
> >>> Windows system test to see what that builds and passes the tests?
> >>
> >> ENOPATCH
> >
> > Gah.
> >
> > Ian
> >
> That seems to be my original patch, right? That one I have tested (and
> am actually using) on x86 and x64 windows.

It's very similar but I changed the windows_get_executable_path function.

Ian

Re: More C type errors by default for GCC 14

[Ian Lance Taylor via Gcc]

On Tue, May 9, 2023 at 9:45 AM Florian Weimer via Gcc  wrote:
>
> The part David quoted above is about this:
>
> $ gcc -fno-gnu89-inline -std=gnu89 t.c
> cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode
>
> And some packages need -fno-gnu89-inline, but also rely on implicit ints
> and implicit function declarations heavily.  With a purely C89-based
> opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
> compile these self-contradictory programs.  Hence the idea of
> -fpermissive, in addition to the -std=gnu89 escape hatch.
>
> But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
> remaining reason for -fpermissive would be a flag that is accepted by
> both gcc and g++, in case a package build system passes CFLAGS to g++ as
> well, which sometimes happens.  And -fno-gnu89-inline is currently not
> accepted by g++.  But in the Fedora package set, this (some C++ and a
> C89 requirement) must be exceedingly rare because it's a subset of the
> already tiny set of -fno-gnu89-inline -std=gnu89 packages.

I think I wrote that error, back in 2007, because I thought it was odd
to rely on the C99 semantics for inline functions when not using C99.
And to encourage people to move to C99.  But I wouldn't be surprised
if the compiler just works without the error.  It would just require
adding a few test cases similar to gcc.dg/inline-18.c through
inline-21.c (well, inline-21.c would have to be removed or rewritten).

Ian

Re: When do I need -fnon-call-exceptions?

[Ian Lance Taylor via Gcc]

On Wed, Jun 7, 2023 at 10:09 AM Helmut Zeisel via Gcc  wrote:
>
> I wrote some simple program that set a signal handler for SIGFPE, throws a 
> C++ exception in the signal handler
> and catches the exception.
> I compiled with and without -fnon-call-exceptions (on x64 Linux).
> In both cases, the result was the same: the exception was caught and the 
> destructors were called as expected.
> I also tried "-fno-non-call-exceptions -fexceptions" and got the same result.
>
> My question: when do I really need -fnon-call-exceptions?
> Is there some simple program where I can see the difference whether it is on 
> or off??

On x864 Linux -fasynchronous-unwind-tables is the default.  That is
probably sufficient to make your test case work.

Ian

Re: New version of gnu assembler

[Ian Lance Taylor via Gcc]

On Sun, Jul 2, 2023 at 9:50 AM Dave Blanchard  wrote:
>
> On Sat, 01 Jul 2023 13:33:07 +0100
> Sam James via Gcc  wrote:
>
> > If you've taken files from Binutils BFD, please make sure you preserve
> > the copyright headers too.
>
> Why? How is that important? That's all you have to say about this?
>
> Copyright is an abomination, and especially so the GPL; particularly the 
> GPLv3. I hope he deleted the copyright notice.
>
> OP: Good work and nice project. The GNU ecosystem is full of bloated shitware 
> and cruft, and it's nice to see people working to get rid of all the junk so 
> we can have software that is actually usable and maintainable.

Please be respectful.  Thanks.

Ian

Re: wishlist: support for shorter pointers

[Ian Lance Taylor via Gcc]

On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc  wrote:
>
> W dniu 28.06.2023 o 17:44, Richard Earnshaw (lists) pisze:
> [---]
> > I think I understand what you're asking for but:
> > 1) You'd need a new ABI specification to handle this, probably involving
> > register assignments (for the 'segment' addresses), the initialization
> > of those at startup, assembler and linker extensions to allow for
> > relocations describing the symbols, etc.
>
> I was thinking about that, and it doesn't look as requiring that deep
> rewrites. ABI spec, that  could accomodate the functionality could be as
> little as one additional attribute to linker segments.

If I understand correctly, you are looking for something like the x32
mode that was available for a while on x86_64 processors:
https://en.wikipedia.org/wiki/X32_ABI .  That was a substantial amount
of work including changes to the compiler, assembler, linker, standard
library, and kernel.  And at least to me it's never seemed
particularly popular.

Ian

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc]

On Mon, Nov 20, 2023 at 11:57 AM Björn Schäpers  wrote:
>
> this is what I'm using with GCC 12 and 13 on my windows machines, rebased onto
> the current HEAD.

Thanks.  Committed as follows.

Ian

* fileline.c: Include  if available.
(windows_get_executable_path): New static function.
(fileline_initialize): Call windows_get_executable_path.
* configure.ac: Checked for windows.h
* configure: Regenerate.
* config.h.in: Regenerate.
0ee01dfacbcc9bc05d11433a69c0a0ac13afa42f
diff --git a/libbacktrace/config.h.in b/libbacktrace/config.h.in
index a4f5bf6..ee2616335c7 100644
--- a/libbacktrace/config.h.in
+++ b/libbacktrace/config.h.in
@@ -104,6 +104,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UNISTD_H
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_WINDOWS_H
+
 /* Define if -lz is available. */
 #undef HAVE_ZLIB
 
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 0ccc060901d..7ade966b54d 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -13509,6 +13509,19 @@ $as_echo "#define HAVE_LOADQUERY 1" >>confdefs.h
 
 fi
 
+for ac_header in windows.h
+do :
+  ac_fn_c_check_header_mongrel "$LINENO" "windows.h" "ac_cv_header_windows_h" 
"$ac_includes_default"
+if test "x$ac_cv_header_windows_h" = xyes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_WINDOWS_H 1
+_ACEOF
+
+fi
+
+done
+
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 71cd50f8cdf..00acb42eb6d 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -379,6 +379,8 @@ if test "$have_loadquery" = "yes"; then
   AC_DEFINE(HAVE_LOADQUERY, 1, [Define if AIX loadquery is available.])
 fi
 
+AC_CHECK_HEADERS(windows.h)
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index 0e560b44e7a..773f3a92969 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -47,6 +47,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #endif
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 #include "backtrace.h"
 #include "internal.h"
 
@@ -165,6 +177,37 @@ macho_get_executable_path (struct backtrace_state *state,
 
 #endif /* !HAVE_DECL__PGMPTR */
 
+#ifdef HAVE_WINDOWS_H
+
+#define FILENAME_BUF_SIZE (MAX_PATH)
+
+static char *
+windows_get_executable_path (char *buf, backtrace_error_callback 
error_callback,
+void *data)
+{
+  size_t got;
+  int error;
+
+  got = GetModuleFileNameA (NULL, buf, FILENAME_BUF_SIZE - 1);
+  error = GetLastError ();
+  if (got == 0
+  || (got == FILENAME_BUF_SIZE - 1 && error == ERROR_INSUFFICIENT_BUFFER))
+{
+  error_callback (data,
+ "could not get the filename of the current executable",
+ error);
+  return NULL;
+}
+  return buf;
+}
+
+#else /* !defined (HAVE_WINDOWS_H) */
+
+#define windows_get_executable_path(buf, error_callback, data) NULL
+#define FILENAME_BUF_SIZE 64
+
+#endif /* !defined (HAVE_WINDOWS_H) */
+
 /* Initialize the fileline information from the executable.  Returns 1
on success, 0 on failure.  */
 
@@ -178,7 +221,7 @@ fileline_initialize (struct backtrace_state *state,
   int called_error_callback;
   int descriptor;
   const char *filename;
-  char buf[64];
+  char buf[FILENAME_BUF_SIZE];
 
   if (!state->threaded)
 failed = state->fileline_initialization_failed;
@@ -202,7 +245,7 @@ fileline_initialize (struct backtrace_state *state,
 
   descriptor = -1;
   called_error_callback = 0;
-  for (pass = 0; pass < 9; ++pass)
+  for (pass = 0; pass < 10; ++pass)
 {
   int does_not_exist;
 
@@ -239,6 +282,9 @@ fileline_initialize (struct backtrace_state *state,
case 8:
  filename = macho_get_executable_path (state, error_callback, data);
  break;
+   case 9:
+ filename = windows_get_executable_path (buf, error_callback, data);
+ break;
default:
  abort ();
}

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

[Ian Lance Taylor via Gcc]

On Mon, Nov 20, 2023 at 11:58 AM Björn Schäpers  wrote:
>
> An updated version, using neither A or W, but just the macro.

Thanks.  Committed as follows.

Ian
1017495bc91d40570f58c37e88ca013164782129
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 56af4828e27..f976a963bf3 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -39,6 +39,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include "backtrace.h"
 #include "internal.h"
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 /* Coff file header.  */
 
 typedef struct {
@@ -610,6 +622,7 @@ coff_add (struct backtrace_state *state, int descriptor,
   int debug_view_valid;
   int is_64;
   uintptr_t image_base;
+  uintptr_t base_address = 0;
   struct dwarf_sections dwarf_sections;
 
   *found_sym = 0;
@@ -856,7 +869,16 @@ coff_add (struct backtrace_state *state, int descriptor,
  + (sections[i].offset - min_offset));
 }
 
-  if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_sections,
+#ifdef HAVE_WINDOWS_H
+  {
+uintptr_t module_handle;
+
+module_handle = (uintptr_t) GetModuleHandle (NULL);
+base_address = module_handle - image_base;
+  }
+#endif
+
+  if (!backtrace_dwarf_add (state, base_address, &dwarf_sections,
0, /* FIXME: is_bigendian */
NULL, /* altlink */
error_callback, data, fileline_fn,

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

[Ian Lance Taylor via Gcc]

On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers  wrote:
>
> From: Björn Schäpers 
>
> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
> that libraries loaded after the backtrace_initialize are not handled.
> But as far as I can see that's the same for elf.

Thanks, but I don't want a patch that loops using goto statements.
Please rewrite to avoid that.  It may be simpler to call a function.

Also starting with a module count of 1000 seems like a lot.  Do
typical Windows programs load that many modules?

Ian




> Tested on x86_64-linux and i686-w64-mingw32.
>
> -- >8 --
>
> * pecoff.c (coff_add): New argument for the module handle of the
> file, to get the base address.
> * pecoff.c (backtrace_initialize): Iterate over loaded libraries
> and call coff_add.
>
> Signed-off-by: Björn Schäpers 
> ---
>  libbacktrace/pecoff.c | 76 ---
>  1 file changed, 72 insertions(+), 4 deletions(-)
>
> diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
> index 296f1357b5f..40395109e51 100644
> --- a/libbacktrace/pecoff.c
> +++ b/libbacktrace/pecoff.c
> @@ -49,6 +49,7 @@ POSSIBILITY OF SUCH DAMAGE.  */
>  #endif
>
>  #include 
> +#include 
>  #endif
>
>  /* Coff file header.  */
> @@ -592,7 +593,8 @@ coff_syminfo (struct backtrace_state *state, uintptr_t 
> addr,
>  static int
>  coff_add (struct backtrace_state *state, int descriptor,
>   backtrace_error_callback error_callback, void *data,
> - fileline *fileline_fn, int *found_sym, int *found_dwarf)
> + fileline *fileline_fn, int *found_sym, int *found_dwarf,
> + uintptr_t module_handle ATTRIBUTE_UNUSED)
>  {
>struct backtrace_view fhdr_view;
>off_t fhdr_off;
> @@ -623,7 +625,6 @@ coff_add (struct backtrace_state *state, int descriptor,
>int is_64;
>uintptr_t image_base;
>uintptr_t base_address = 0;
> -  uintptr_t module_handle;
>struct dwarf_sections dwarf_sections;
>
>*found_sym = 0;
> @@ -871,7 +872,6 @@ coff_add (struct backtrace_state *state, int descriptor,
>  }
>
>  #ifdef HAVE_WINDOWS_H
> -module_handle = (uintptr_t) GetModuleHandleW (NULL);
>  base_address = module_handle - image_base;
>  #endif
>
> @@ -914,12 +914,80 @@ backtrace_initialize (struct backtrace_state *state,
>int found_sym;
>int found_dwarf;
>fileline coff_fileline_fn;
> +  uintptr_t module_handle = 0;
> +
> +#ifdef HAVE_WINDOWS_H
> +  DWORD i;
> +  DWORD module_count;
> +  DWORD bytes_needed_for_modules;
> +  HMODULE *modules;
> +  char module_name[MAX_PATH];
> +  int module_found_sym;
> +  fileline module_fileline_fn;
> +
> +  module_handle = (uintptr_t) GetModuleHandleW (NULL);
> +#endif
>
>ret = coff_add (state, descriptor, error_callback, data,
> - &coff_fileline_fn, &found_sym, &found_dwarf);
> + &coff_fileline_fn, &found_sym, &found_dwarf, module_handle);
>if (!ret)
>  return 0;
>
> +#ifdef HAVE_WINDOWS_H
> +  module_count = 1000;
> + alloc_modules:
> +  modules = backtrace_alloc (state, module_count * sizeof(HMODULE),
> +error_callback, data);
> +  if (modules == NULL)
> +goto skip_modules;
> +  if (!EnumProcessModules (GetCurrentProcess (), modules, module_count,
> +  &bytes_needed_for_modules))
> +{
> +  error_callback(data, "Could not enumerate process modules",
> +(int) GetLastError ());
> +  goto free_modules;
> +}
> +  if (bytes_needed_for_modules > module_count * sizeof(HMODULE))
> +{
> +  backtrace_free (state, modules, module_count * sizeof(HMODULE),
> + error_callback, data);
> +  // Add an extra of 2, if some module is loaded in another thread.
> +  module_count = bytes_needed_for_modules / sizeof(HMODULE) + 2;
> +  modules = NULL;
> +  goto alloc_modules;
> +}
> +
> +  for (i = 0; i < bytes_needed_for_modules / sizeof(HMODULE); ++i)
> +{
> +  if (GetModuleFileNameA (modules[i], module_name, MAX_PATH - 1))
> +   {
> + if (strcmp (filename, module_name) == 0)
> +   continue;
> +
> + module_handle = (uintptr_t) GetModuleHandleA (module_name);
> + if (module_handle == 0)
> +   continue;
> +
> + descriptor = backtrace_open (module_name, error_callback, data, 
> NULL);
> + if (descriptor < 0)
> +   continue;
> +
> + coff_add (state, descriptor, error_callback, data,
> +   &module_fileline_fn, &module_found_sym, &found_dwarf,
> +   module_handle);
> + if (module_found_sym)
> +   found_sym = 1;
> +   }
> +}
> +
> + free_modules:
> +  if (modules)
> +backtrace_free(state, modules, module_count * sizeof(HMODULE),
> +  error_callback, data);
> +  modules = NULL;
> + skip_modules:
> +#endif
> +
>if (!state->threaded)
>  {
>if (found_sym)
> --
> 2.38.1
>

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

[Ian Lance Taylor via Gcc]

On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers  wrote:
>
> Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
> > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
> >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers  wrote:
> >>>
> >>> From: Björn Schäpers 
> >>>
> >>> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
> >>> that libraries loaded after the backtrace_initialize are not handled.
> >>> But as far as I can see that's the same for elf.
> >>
> >> Thanks, but I don't want a patch that loops using goto statements.
> >> Please rewrite to avoid that.  It may be simpler to call a function.
> >>
> >> Also starting with a module count of 1000 seems like a lot.  Do
> >> typical Windows programs load that many modules?
> >>
> >> Ian
> >>
> >>
> >
> > Rewritten using a function.
> >
> > If that is commited, could you attribute that commit to me (--author="Björn
> > Schäpers ")?
> >
> > Thanks and kind regards,
> > Björn.
>
> I noticed that under 64 bit libraries loaded with LoadLibrary were missing.
> EnumProcessModules stated the correct number of modules, but did not fill the
> the HMODULEs, but set them to 0. While trying to investigate I noticed if I do
> the very same thing from main (in C++) I even got fewer module HMODULEs.
>
> So I went a different way. This detects all libraries correctly, in 32 and 64
> bit. The question is, if it should be a patch on top of the previous, or 
> should
> they be merged, or even only this solution and drop the EnumProcessModules 
> variant?

Is there any reason to use both patches?  Seems simpler to just use
this one if it works.  Thanks.

Ian

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

[Ian Lance Taylor via Gcc]

On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers  wrote:
>
> Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
> > On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers  wrote:
> >>
> >> Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
> >>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
>  On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers  wrote:
> >
> > From: Björn Schäpers 
> >
> > Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
> > that libraries loaded after the backtrace_initialize are not handled.
> > But as far as I can see that's the same for elf.
> 
>  Thanks, but I don't want a patch that loops using goto statements.
>  Please rewrite to avoid that.  It may be simpler to call a function.
> 
>  Also starting with a module count of 1000 seems like a lot.  Do
>  typical Windows programs load that many modules?
> 
>  Ian
> 
> 
> >>>
> >>> Rewritten using a function.
> >>>
> >>> If that is commited, could you attribute that commit to me 
> >>> (--author="Björn
> >>> Schäpers ")?
> >>>
> >>> Thanks and kind regards,
> >>> Björn.
> >>
> >> I noticed that under 64 bit libraries loaded with LoadLibrary were missing.
> >> EnumProcessModules stated the correct number of modules, but did not fill 
> >> the
> >> the HMODULEs, but set them to 0. While trying to investigate I noticed if 
> >> I do
> >> the very same thing from main (in C++) I even got fewer module HMODULEs.
> >>
> >> So I went a different way. This detects all libraries correctly, in 32 and 
> >> 64
> >> bit. The question is, if it should be a patch on top of the previous, or 
> >> should
> >> they be merged, or even only this solution and drop the EnumProcessModules 
> >> variant?
> >
> > Is there any reason to use both patches?  Seems simpler to just use
> > this one if it works.  Thanks.
> >
> > Ian
>
> This one needs the tlhelp32 header and its functions, which are (accoridng to
> the microsoft documentation) are only available since Windows XP rsp. Windows
> Server 2003.
>
> If that's no problem, and in my opinion it shouldn't be, then I can basically
> drop patch 4 and rebase this one.

I don't see that as a problem.  It seems like the patch will fall back
cleanly on ancient Windows and simply fail to pick up other loaded
DLLs.  I think that is fine.  I'll look for an updated patch.  Thanks.

Ian

Re: Sourceware mitigating and preventing the next xz-backdoor

[Ian Lance Taylor via Gcc]

On Tue, Apr 2, 2024 at 1:21 PM Paul Koning via Gcc  wrote:
>
> Would it help to require (rather than just recommend) "don't use root except 
> for the actual 'install' step" ?

Seems reasonable, but note that it wouldn't make any difference to
this attack.  The liblzma library was modified to corrupt the sshd
binary, when sshd was linked against liblzma.  The actual attack
occurred via a connection to a corrupt sshd.  If sshd was running as
root, as is normal, the attacker had root access to the machine.  None
of the attacking steps had anything to do with having root access
while building or installing the program.

Ian

Re: Sourceware mitigating and preventing the next xz-backdoor

[Ian Lance Taylor via Gcc]

On Wed, Apr 3, 2024 at 11:05 AM Toon Moene  wrote:
>
> Two questions arise (as far as I am concerned):
>
> 1. Do daemons like sshd *have* to be linked with shared libraries ?
> Or could it be left to the security minded of the downstream
> (binary) distributions to link it statically with known & proven
> correct libraries ?

I like static linking personally, but it seems like glibc has made a
decision that shared linking is much preferred over static.  That said
my guess is that this kind of attack would have been effective on any
executable built as PIE.  It relied on using an IFUNC hook to adjust
the PLT entry for a different function.  And, of course, most
executables are built as PIE these days, because that is more secure
against different kinds of attacks.

> 2. Is it a limitation of the Unix / Linux daemon concept that, once
> such a process needs root access, it has to have root access
> *always* - even when performing trivial tasks like compressing
> data ?
>
> I recall quite well (vis-a-vis question 2) that the VMS equivalent would
> drop all privileges at the start of the code, and request only those
> relevant when actually needed (e.g., to open a file for reading that was
> owned by [the equivalent on VMS] of root - or perform other functions
> that only root could do), and then drop them immediately afterwards again.

Note that the attack really didn't have anything to do with
compressing data.  The library used an IFUNC to change the PLT of a
different function, so it effectively took control of the code that
verified the cryptographic key.  The only part of the attack that
involved compression was the fact that it happened to live in a
compression library.  And it wouldn't matter whether the code that
verified the cryptographic key was run as root either; the effect of
the attack was to say that the key was OK, and that sshd should
execute the command, and of course that execution must be done on
behalf of the requesting user, which (as I understand it) could be
root.

Ian

Re: Updated Sourceware infrastructure plans

[Ian Lance Taylor via Gcc]

On Tue, Apr 23, 2024 at 2:32 AM Richard Earnshaw (lists) via Gcc
 wrote:
>
> I've been forced to use gerrit occasionally.  I hate it.  No, I LOATHE it.  
> The UI is anything but intuitive with features hidden behind unobvious 
> selections.  IMO It's not a tool for a casual developer, which makes it a bad 
> introduction to developing software.

I would be shocked if GCC ever adopted Gerrit.  But I don't understand
this objection.  Yes, Gerrit is not a tool for a casual developer.
But so what?  Casual developers don't have to use it, except that they
have to run a particular git command to submit a patch.  It's the GCC
maintainers who have to use Gerrit.

Ian

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

[Ian Lance Taylor via Gcc]

On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers  wrote:
>
> > Attached is the combined version of the two patches, only implementing the
> > variant with the tlhelp32 API.
> >
> > Tested on x86 and x86_64 windows.
> >
> > Kind regards,
> > Björn.
>
> A friendly ping.

Thanks.  Committed as follows.

Which of your other patches are still relevant?  Thanks.

Ian
942a9cf2a958113d2ab46f5b015c36e569abedcf
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 3e0075a2b79..59e9c415db8 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -380,6 +380,10 @@ if test "$have_loadquery" = "yes"; then
 fi
 
 AC_CHECK_HEADERS(windows.h)
+AC_CHECK_HEADERS(tlhelp32.h, [], [],
+[#ifdef HAVE_WINDOWS_H
+#  include 
+#endif])
 
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 9e437d810c7..4f267841178 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -49,6 +49,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #endif
 
 #include 
+
+#ifdef HAVE_TLHELP32_H
+#include 
+
+#ifdef UNICODE
+/* If UNICODE is defined, all the symbols are replaced by a macro to use the
+   wide variant. But we need the ansi variant, so undef the macros. */
+#undef MODULEENTRY32
+#undef Module32First
+#undef Module32Next
+#endif
+#endif
 #endif
 
 /* Coff file header.  */
@@ -592,7 +604,8 @@ coff_syminfo (struct backtrace_state *state, uintptr_t addr,
 static int
 coff_add (struct backtrace_state *state, int descriptor,
  backtrace_error_callback error_callback, void *data,
- fileline *fileline_fn, int *found_sym, int *found_dwarf)
+ fileline *fileline_fn, int *found_sym, int *found_dwarf,
+ uintptr_t module_handle ATTRIBUTE_UNUSED)
 {
   struct backtrace_view fhdr_view;
   off_t fhdr_off;
@@ -870,12 +883,7 @@ coff_add (struct backtrace_state *state, int descriptor,
 }
 
 #ifdef HAVE_WINDOWS_H
-  {
-uintptr_t module_handle;
-
-module_handle = (uintptr_t) GetModuleHandle (NULL);
-base_address = module_handle - image_base;
-  }
+  base_address = module_handle - image_base;
 #endif
 
   if (!backtrace_dwarf_add (state, base_address, &dwarf_sections,
@@ -917,12 +925,61 @@ backtrace_initialize (struct backtrace_state *state,
   int found_sym;
   int found_dwarf;
   fileline coff_fileline_fn;
+  uintptr_t module_handle = 0;
+#ifdef HAVE_TLHELP32_H
+  fileline module_fileline_fn;
+  int module_found_sym;
+  HANDLE snapshot;
+#endif
+
+#ifdef HAVE_WINDOWS_H
+  module_handle = (uintptr_t) GetModuleHandle (NULL);
+#endif
 
   ret = coff_add (state, descriptor, error_callback, data,
- &coff_fileline_fn, &found_sym, &found_dwarf);
+ &coff_fileline_fn, &found_sym, &found_dwarf, module_handle);
   if (!ret)
 return 0;
 
+#ifdef HAVE_TLHELP32_H
+  do
+{
+  snapshot = CreateToolhelp32Snapshot (TH32CS_SNAPMODULE, 0);
+}
+  while (snapshot == INVALID_HANDLE_VALUE
+&& GetLastError () == ERROR_BAD_LENGTH);
+
+  if (snapshot != INVALID_HANDLE_VALUE)
+{
+  MODULEENTRY32 entry;
+  BOOL ok;
+  entry.dwSize = sizeof (MODULEENTRY32);
+
+  for (ok = Module32First (snapshot, &entry); ok; ok = Module32Next 
(snapshot, &entry))
+   {
+ if (strcmp (filename, entry.szExePath) == 0)
+   continue;
+
+ module_handle = (uintptr_t) entry.hModule;
+ if (module_handle == 0)
+   continue;
+
+ descriptor = backtrace_open (entry.szExePath, error_callback, data,
+  NULL);
+ if (descriptor < 0)
+   continue;
+
+ coff_add (state, descriptor, error_callback, data,
+   &module_fileline_fn, &module_found_sym, &found_dwarf,
+   module_handle);
+ if (module_found_sym)
+   found_sym = 1;
+   }
+
+  CloseHandle (snapshot);
+}
+#endif
+
   if (!state->threaded)
 {
   if (found_sym)

Re: Updated Sourceware infrastructure plans

[Ian Lance Taylor via Gcc]

On Wed, May 1, 2024 at 11:48 PM Richard Biener
 wrote:
>
> We'd only know for sure if we try.  But then I'm almost 100% sure that
> having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA
> I am using for "quick" patch review.  It might be comparable to the
> review parts I do in the gmail UI or when I have to download attachments
> and cut&paste parts into the reply.  It might be also more convenient
> for "queued" for review patches which just end up in New state in either
> inbox.

Gerritt does not require clicking in a GUI, though that is of course
the more widely used option.  Patches can be approved from the command
line.


> But then would using gitlab or any similar service enforce the use of
> pull requests / forks for each change done or can I just continue to
> post patches and push them from the command-line for changes I
> can approve myself?

Gerritt permits submitting patches from the command line for people
who can self-approve.


> Btw, for any forge like tool I'd even consider there'd be the requirement
> that _all_ functionality is also accessible via a documented (stable) API,
> aka there's command-line tooling available or at least possible to write.

True of Gerritt.

Ian

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

[Ian Lance Taylor via Gcc]

On Thu, May 2, 2024 at 12:23 PM Björn Schäpers  wrote:
>
> Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor:
> >
> > Which of your other patches are still relevant?  Thanks.
> >
> only this one.

Thanks.  Committed.

Ian

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

[Ian Lance Taylor via Gcc]

On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers  wrote:
>
> Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> >> Cc: i...@google.com, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> >> From: Björn Schäpers 
> >>
> >> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
> >>> In that case, you an call either GetModuleHandeExA or
> >>> GetModuleHandeExW, the difference is minor.
> >>
> >> Here an updated version without relying on TEXT or TCHAR, directly calling
> >> GetModuleHandleExW.
> >
> > Thanks, this LGTM (but I couldn't test it, I just looked at the
> > sour ce code).
>
> Here an updated version. It is rebased on the combined approach of getting the
> loaded DLLs and two minor changes to suppress warnings.

This bug report was filed about this patch:

https://github.com/ianlancetaylor/libbacktrace/issues/131

> src\pecoff.c(86): error C2059: syntax error: '('
> src\pecoff.c(89): error C2059: syntax error: '('
>
> It works fine if deleting CALLBACK and NTAPI.

Any ideas?

Thanks.

Ian

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

[Ian Lance Taylor via Gcc]

On Mon, Jul 29, 2024 at 12:41 PM Björn Schäpers  wrote:
>
> > Instead of deleting those, move them inside the parentheses:
> >
> > typedef VOID (CALLBACK *LDR_DLL_NOTIFICATION)(ULONG,
> > struct dll_notification_data*,
> > PVOID);
> > typedef NTSTATUS (NTAPI *LDR_REGISTER_FUNCTION)(ULONG,
> >   LDR_DLL_NOTIFICATION, PVOID,
> >   PVOID*);
> >
> > and also I think you need to include , for the definition
> > of the NTSTATUS type.
> >
> > Caveat: I don't have MSVC, so I couldn't verify that these measures
> > fix the problem, sorry.
>
> Moving into the parentheses does fix the issue: 
> https://godbolt.org/z/Pe558ofYz
>
> NTSTATUS is typedefed directly before, so that no additional include is 
> needed.

Thanks.  I committed this patch.

Ian

* pecoff.c (LDR_DLL_NOTIFICATION): Put function modifier
inside parentheses.
(LDR_REGISTER_FUNCTION): Likewise.
338a93ce71ccfd435c0f392af483cc946b2c26fc
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 636e1b11296..ccd5ccbce2c 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -83,10 +83,10 @@ struct dll_notification_data
 #define LDR_DLL_NOTIFICATION_REASON_LOADED 1
 
 typedef LONG NTSTATUS;
-typedef VOID CALLBACK (*LDR_DLL_NOTIFICATION)(ULONG,
+typedef VOID (CALLBACK *LDR_DLL_NOTIFICATION)(ULONG,
  struct dll_notification_data*,
  PVOID);
-typedef NTSTATUS NTAPI (*LDR_REGISTER_FUNCTION)(ULONG,
+typedef NTSTATUS (NTAPI *LDR_REGISTER_FUNCTION)(ULONG,
LDR_DLL_NOTIFICATION, PVOID,
PVOID*);
 #endif

Re: ELF2.0: Linkable struct

[Ian Lance Taylor via Gcc]

On Fri, Jan 31, 2025 at 7:37 AM The Cuthour via Gcc  wrote:
>
> I understand the concerns about the C++ standard requiring constant
> expressions to be known during compilation. However, my proposal for
> link-time evaluation offers significant flexibility and efficiency
> improvements that could address current limitations in compile-time
> constant expressions.

>From what you are saying, you are looking for a C++ interpreter. That
is not what GCC is. GCC is a C++ compiler.

There have been C++ interpreters in the past, such as one by Saber.
Using an interpreter would give you the flexibility that you are
looking for. You are not going to get it from a compiler. The models
are just too different.

Ian