GCC 13.0.0 Status Report (2022-10-20), Stage 1 ends Nov 13th

[Richard Biener via Gcc]

Status
==

The GCC development branch which will become GCC 13 is open for
general development (Stage 1).  Stage 1 will end at the end of
November 13th after which we will accept no new features that
have not yet been submitted.  Starting with Novemer 14th we
are in a two month general bugfixing period (Stage 3).

I have gone over the set of unpriorized regression bugs that are in
confirmed state, please help updating regressions that are still
UNCONFIRMED and consider fixing bugs that are in your area of
interest.  Please make sure to finish and submit features you
want to see included into GCC 13 timely and actively look for
reviewers.


Quality Data


Priority  #   Change from last report
---   ---
P1  33+  33
P2  473   + 102
P3  84+   7
P4  247   -   6
P5  25-   1
---   ---
Total P1-P3 590   + 142
Total   862   + 135


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2022-April/238619.html

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/19/22 18:42, Joseph Myers wrote:
> On Wed, 19 Oct 2022, Martin Liška wrote:
> 
>>> Currently, there is a tarball with texinfo sources for all the manuals
>>> for each version.
>>
>> Well, then equivalent would be packaging all .rst files together with the 
>> corresponding
>> conf.py, logo.* and other files. But I don't see it much useful.
> 
> I think we should have such a source tarball when the sources are .rst, as 
> the successor to the Texinfo source tarball.

All right, putting that on my TODO list after the conversion happens. Won't be 
difficult
to achieve.

Cheers,
Martin

> 
> (Unfortunately when I added that source tarball - 
> https://gcc.gnu.org/legacy-ml/gcc-patches/2004-01/msg00140.html - I didn't 
> give specific references to any of the individual requests that resulted 
> in adding it.)

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/19/22 18:30, Sandra Loosemore wrote:
> On 10/19/22 05:09, Martin Liška wrote:
>> On 10/18/22 00:26, Sandra Loosemore wrote:
>>> On 10/17/22 07:28, Martin Liška wrote:
 Hello.

 Based on the very positive feedback I was given at the Cauldron Sphinx 
 Documentation BoF,
 I'm planning migrating the documentation on 9th November. There are still 
 some minor comments
 from Sandra when it comes to the PDF output, but we can address that once 
 the conversion is done.
>>>
>>> My main complaint about the PDF is that the blue color used for link text 
>>> is so light it interferes with readability.  Few people are going to print 
>>> the document on paper any more, but I did try printing a sample page on a 
>>> grayscale printer and the blue link text came out so faint that it was 
>>> barely visible at all.
>>
>> Sure, I've just added support for monochromatic PDF output where one needs 
>> to use
>> MONOCHROMATIC=1 make latexpdf ...
>>
>> and I linked the file here:
>> https://splichal.eu/scripts/sphinx/gcc/_build/latexmonochromatic/gcc.pdf
>>
>> right now I build only one PDF in this mode and it's mentioned here:
>> https://splichal.eu/scripts/sphinx/
>>
>> What do you think about it now?
> 
> Hmmm, removing *all* visual cues that something is a link does not seem so 
> great either, especially since the new format has changed the link text for 
> @xref to remove the page and section information.  E.g. we used to get "See 
> Section 3.4 [Options Controlling C Dialect], page 44." and now it just reads 
> "See Options Controlling C Dialect."
> 

Hey.

> I realize there is a can of worms here involving philosophical issues about 
> whether the PDF manual is intended to be formatted for reading as a book or 
> is just a handy way to repackage the hyperlinked web presentation for offline 
> reference.  Also there is another can of worms involving making the 
> documentation accessible to people who have visual disabilities, specifically 
> color blindness issues.  Just speaking for myself, I'd be happy if the PDF 
> just used a darker blue color for links that is both distinguishing and 
> higher contrast with the background than the current light blue, but I think 
> it is one of the principles of accessible design that color really shouldn't 
> be the *only* indication of something that initiates an action.  Maybe 
> underlining, or a little link glyph, or restoring the section/page info to 
> the link text?

I've just tweaked the monochrom. PDF where dark blue color is used for links. 
About the links, there are multiple PDF viewers (like Evince) which can do a 
preview if you hover
over a link. Plus a page number is showed in a toolbar.

What it comes to the philosophical issues of the monochrom. PDF, well, I would 
recommend discussing that with Sphinx upstream project. I bet
they must have other projects who's readers might request similar needs. 
Intention of my monochrom. PDF was to show that Sphinx PDF output
can be quite easily adjusted.

> 
>>
>>>    An E-ink reader device would probably have similar problems.
>>
>> There ePUB would be likely better output format. What do you think?
> 
> Ooof, a lot of problems there.  I looked at your new generated .epub in both 
> the "ebook-viewer" utility on my laptop and on my Kobo Forma.  The Kobo uses 
> the default proportionally-spaced font for everything; even the code examples 
> fail to come out in a fixed-width font.  ebook-viewer shows fixed-width fonts 
> for code examples and inline references to e.g. command line options, but the 
> names of options in the option tables sections are in the proportional body 
> font.  Also in both viewers I see hyperlinks to https://splicha.eu/...  in 
> place of internal links in some references to command-line options and the 
> like, and the formatting of the option summary tables really sucks, with 
> lines breaking at hyphens in the middle of option names.

Sure, let's leave it for now and keep it as a might-have thing for the future!

Appreciate the feedback,
Cheers,
Martin

> 
> I suggest we try to focus our efforts on the currently-supported formats 
> before adding EPUB as a new format.
> 
> -Sandra

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/20/22 04:26, Xi Ruoyao wrote:
> On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote:
>> Hello.
>>
>> Based on the very positive feedback I was given at the Cauldron Sphinx 
>> Documentation BoF,
>> I'm planning migrating the documentation on 9th November. There are still 
>> some minor comments
>> from Sandra when it comes to the PDF output, but we can address that once 
>> the conversion is done.
>>
>> The reason I'm sending the email now is that I was waiting for latest Sphinx 
>> release (5.3.0) that
>> simplifies reference format for options and results in much simpler Option 
>> summary section ([1])
>>
>> The current GCC master (using Sphinx 5.3.0) converted docs can be seen here:
>> https://splichal.eu/scripts/sphinx/
>>
>> If you see any issues with the converted documentation, or have a feedback 
>> about it,
>> please reply to this email.
> 
> Ouch.  This will be very painful for Linux From Scratch.  We'll need to
> add 23 Python modules to build the documentation, while we only have 88
> packages in total currently...  And we don't want to omit GCC
> documentation in our system.

Various other distros will have to face it too. The proper solution is a 
multi-build
package (gcc:doc) which can be built later in the dependency chain. Btw. do you 
also
provide PDF documentation in your system?

> 
> Could generated man and info pages be provided as a tarball on
> gcc.gnu.org or ftp.gnu.org?

Not planning doing that.

Cheers,
Martin

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Xi Ruoyao via Gcc]

(CC our team members.)

On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote:
> > Ouch.  This will be very painful for Linux From Scratch.  We'll need to
> > add 23 Python modules to build the documentation, while we only have 88
> > packages in total currently...  And we don't want to omit GCC
> > documentation in our system.
> 
> Various other distros will have to face it too. The proper solution is a 
> multi-build
> package (gcc:doc) which can be built later in the dependency chain. Btw. do 
> you also
> provide PDF documentation in your system?

No (texlive is much heavier than Sphinx).  But generally we expect man
pages and info pages.

We can separate man and info into the second-time build in BLFS (we're
already doing this now for Go, Objective C, etc.), but I don't really
like to omit the man and info pages...

> > Could generated man and info pages be provided as a tarball on
> > gcc.gnu.org or ftp.gnu.org?
> 
> Not planning doing that.

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/20/22 13:49, Xi Ruoyao wrote:
> (CC our team members.)
> 
> On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote:
>>> Ouch.  This will be very painful for Linux From Scratch.  We'll need to
>>> add 23 Python modules to build the documentation, while we only have 88
>>> packages in total currently...  And we don't want to omit GCC
>>> documentation in our system.
>>
>> Various other distros will have to face it too. The proper solution is a 
>> multi-build
>> package (gcc:doc) which can be built later in the dependency chain. Btw. do 
>> you also
>> provide PDF documentation in your system?
> 
> No (texlive is much heavier than Sphinx).  But generally we expect man
> pages and info pages.
> 
> We can separate man and info into the second-time build in BLFS (we're
> already doing this now for Go, Objective C, etc.),

Do the same for GCC.

> but I don't really
> like to omit the man and info pages..

What should I do about it? We want to switch to a more modern documentation tool
called Sphinx and yes, it will make packaging of the GCC more complicated.

Martin

> 
>>> Could generated man and info pages be provided as a tarball on
>>> gcc.gnu.org or ftp.gnu.org?
>>
>> Not planning doing that.

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Xi Ruoyao via Gcc]

On Thu, 2022-10-20 at 13:53 +0200, Martin Liška wrote:
> On 10/20/22 13:49, Xi Ruoyao wrote:
> > (CC our team members.)
> > 
> > On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote:
> > > > Ouch.  This will be very painful for Linux From Scratch.  We'll need to
> > > > add 23 Python modules to build the documentation, while we only have 88
> > > > packages in total currently...  And we don't want to omit GCC
> > > > documentation in our system.
> > > 
> > > Various other distros will have to face it too. The proper solution is a 
> > > multi-build
> > > package (gcc:doc) which can be built later in the dependency chain. Btw. 
> > > do you also
> > > provide PDF documentation in your system?
> > 
> > No (texlive is much heavier than Sphinx).  But generally we expect man
> > pages and info pages.
> > 
> > We can separate man and info into the second-time build in BLFS (we're
> > already doing this now for Go, Objective C, etc.),
> 
> Do the same for GCC.
> 
> > but I don't really
> > like to omit the man and info pages..
> 
> What should I do about it? We want to switch to a more modern documentation 
> tool
> called Sphinx and yes, it will make packaging of the GCC more complicated.

Nothing, I guess.  We'll handle it on our side (if we finally decide to
ship the man/info tarballs we can generate them by ourselves).

I was just trying to find a simpler solution before beginning all the
work :).

Thanks!

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/20/22 13:55, Xi Ruoyao wrote:
> On Thu, 2022-10-20 at 13:53 +0200, Martin Liška wrote:
>> On 10/20/22 13:49, Xi Ruoyao wrote:
>>> (CC our team members.)
>>>
>>> On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote:
> Ouch.  This will be very painful for Linux From Scratch.  We'll need to
> add 23 Python modules to build the documentation, while we only have 88
> packages in total currently...  And we don't want to omit GCC
> documentation in our system.

 Various other distros will have to face it too. The proper solution is a 
 multi-build
 package (gcc:doc) which can be built later in the dependency chain. Btw. 
 do you also
 provide PDF documentation in your system?
>>>
>>> No (texlive is much heavier than Sphinx).  But generally we expect man
>>> pages and info pages.
>>>
>>> We can separate man and info into the second-time build in BLFS (we're
>>> already doing this now for Go, Objective C, etc.),
>>
>> Do the same for GCC.
>>
>>> but I don't really
>>> like to omit the man and info pages..
>>
>> What should I do about it? We want to switch to a more modern documentation 
>> tool
>> called Sphinx and yes, it will make packaging of the GCC more complicated.
> 
> Nothing, I guess.  We'll handle it on our side (if we finally decide to
> ship the man/info tarballs we can generate them by ourselves).

Good!

> 
> I was just trying to find a simpler solution before beginning all the
> work :).

Sure, makes sense.

Martin

> 
> Thanks!
> 

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Joseph Myers]

On Thu, 20 Oct 2022, Martin Liška wrote:

> > Could generated man and info pages be provided as a tarball on
> > gcc.gnu.org or ftp.gnu.org?
> 
> Not planning doing that.

Release tarballs (but not snapshots) currently include the info files and 
man pages, via gcc_release running a build with 
--enable-generated-files-in-srcdir before building the tarball.

I think they should continue to do so.  This means:

(a) --enable-generated-files-in-srcdir needs to cause those files to be 
generated in the source directory, as it does at present.

(b) gcc_release, for building a release but not a snapshot, needs to give 
an error if Sphinx is missing or too old and so those files weren't built 
properly (and thus people running gcc_release to build a release tarball 
will need new-enough Sphinx).

(c) It needs to be verified that building and installing from such a 
release tarball works even if Sphinx is missing or too old - that is, that 
it installs the prebuilt info / man files rather than giving an error or 
failing to install them.

Also, but not strictly part of the release issue:

(d) Builds with missing or old Sphinx should work regardless of whether 
such files are in the source directory - but if they aren't in the source 
directory, the effect of missing or old Sphinx (detected at configure 
time) should be to disable building and installing documentation.

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

Re: [PATCH RESEND 1/1] p1689r5: initial support

[Jason Merrill via Gcc]

On 10/18/22 08:18, Ben Boeckel wrote:

On Tue, Oct 11, 2022 at 07:42:43 -0400, Ben Boeckel wrote:

On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:

Can we share utf8 parsing code with decode_utf8_char in pretty-print.cc?


I can look at factoring that out. I'll have to decode its logic to see
how much overlap there is.


There is some mismatch. First, that is in `gcc` and this is in `libcpp`.


Oops, I was thinking this was in gcc as well.  In libcpp there's 
_cpp_valid_utf8 (which calls one_utf8_to_cppchar).


Jason

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/20/22 17:35, Joseph Myers wrote:
> On Thu, 20 Oct 2022, Martin Liška wrote:
> 
>>> Could generated man and info pages be provided as a tarball on
>>> gcc.gnu.org or ftp.gnu.org?
>>
>> Not planning doing that.
> 
> Release tarballs (but not snapshots) currently include the info files and 
> man pages, via gcc_release running a build with 
> --enable-generated-files-in-srcdir before building the tarball.
> 
> I think they should continue to do so.  This means:
> 
> (a) --enable-generated-files-in-srcdir needs to cause those files to be 
> generated in the source directory, as it does at present.
> 
> (b) gcc_release, for building a release but not a snapshot, needs to give 
> an error if Sphinx is missing or too old and so those files weren't built 
> properly (and thus people running gcc_release to build a release tarball 
> will need new-enough Sphinx).
> 
> (c) It needs to be verified that building and installing from such a 
> release tarball works even if Sphinx is missing or too old - that is, that 
> it installs the prebuilt info / man files rather than giving an error or 
> failing to install them.
> 
> Also, but not strictly part of the release issue:
> 
> (d) Builds with missing or old Sphinx should work regardless of whether 
> such files are in the source directory - but if they aren't in the source 
> directory, the effect of missing or old Sphinx (detected at configure 
> time) should be to disable building and installing documentation.

All right Joseph, is it something you're willing to help me once we start
using Sphinx? Apparently, there will be many consequent steps after we switch.

Cheers,
Martin

Re: No-named-argument variadic functions

[Joseph Myers]

On Thu, 20 Oct 2022, Richard Biener via Gcc wrote:

> > 1. How should (...) be represented differently from unprototyped functions
> > so that stdarg_p and prototype_p handle it properly?  Should I add a new
> > language-independent type flag (there are plenty spare) to use for this?
> 
> I'd say unprototyped should stay with a NULL TYPE_ARG_TYPES but
> a varargs function might change to have a TREE_LIST with a NULL type
> as the trailing element?  Not sure if we want to change this also for
> varargs functions with actual arguments.
> 
> If we want to go down the route with a flag on the function type then
> I'd rather flag the unprototyped case and leave varargs without any
> actual arguments as NULL TYPE_ARG_TYPES?

The issue with both of those options is that they don't seem very safe for 
code that accesses TYPE_ARG_TYPES directly, of which I think we have a 
lot.  Such code is quite likely to fall over on a TREE_LIST with a NULL 
type entry, and having code that encounters a (...) prototype treat it 
like an unprototyped function seems safer than having code that encounters 
an unprototyped function treat it like a (...) prototype because the code 
that created the function type failed to set a flag to say it's 
unprototyped.

(In principle TYPE_ARG_TYPES could change to have static type other than 
tree, with explicit flags both for stdarg_p and for prototype_p, which 
would provide GCC-build-time assurance that there's no non-updated code 
left that expects an old representation.  But that would be a very large 
change.)

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

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Joseph Myers]

On Thu, 20 Oct 2022, Martin Liška wrote:

> > Also, but not strictly part of the release issue:
> > 
> > (d) Builds with missing or old Sphinx should work regardless of whether 
> > such files are in the source directory - but if they aren't in the source 
> > directory, the effect of missing or old Sphinx (detected at configure 
> > time) should be to disable building and installing documentation.
> 
> All right Joseph, is it something you're willing to help me once we start
> using Sphinx? Apparently, there will be many consequent steps after we switch.

Sure, but most of the conditionals are *already* present, just need 
updating as part of the Sphinx transition.  E.g. gcc/Makefile.in has 
BUILD_INFO and GENERATED_MANPAGES conditionals based on configure tests 
for whether relevant tools are present and new enough; the rules for 
$(DESTDIR)$(infodir)/%.info quietly allow the info files not to be 
present, so installing also works without the info files or tools to build 
them, and the rules for installing man pages similarly ignore errors; and 
there are srcinfo and srcman rules, enabled based on @GENINSRC@, to copy 
those built files to the source directory, which are what's used when 
--enable-generated-files-in-srcdir is used as part of building a release 
tarball.

The main thing I've suggested that I think may actually be new is an error 
for trying to build a release tarball without new-enough Sphinx (I think 
the current rules would quietly not copy info / man pages to the source 
directory if build tools were missing - but having those tools missing 
when building a release tarball is much less likely than not having 
new-enough Sphinx).

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

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Jakub Jelinek via Gcc]

On Thu, Oct 20, 2022 at 04:43:06PM +, Joseph Myers wrote:
> On Thu, 20 Oct 2022, Martin Liška wrote:
> 
> > > Also, but not strictly part of the release issue:
> > > 
> > > (d) Builds with missing or old Sphinx should work regardless of whether 
> > > such files are in the source directory - but if they aren't in the source 
> > > directory, the effect of missing or old Sphinx (detected at configure 
> > > time) should be to disable building and installing documentation.
> > 
> > All right Joseph, is it something you're willing to help me once we start
> > using Sphinx? Apparently, there will be many consequent steps after we 
> > switch.
> 
> Sure, but most of the conditionals are *already* present, just need 
> updating as part of the Sphinx transition.  E.g. gcc/Makefile.in has 
> BUILD_INFO and GENERATED_MANPAGES conditionals based on configure tests 
> for whether relevant tools are present and new enough; the rules for 
> $(DESTDIR)$(infodir)/%.info quietly allow the info files not to be 
> present, so installing also works without the info files or tools to build 
> them, and the rules for installing man pages similarly ignore errors; and 
> there are srcinfo and srcman rules, enabled based on @GENINSRC@, to copy 
> those built files to the source directory, which are what's used when 
> --enable-generated-files-in-srcdir is used as part of building a release 
> tarball.
> 
> The main thing I've suggested that I think may actually be new is an error 
> for trying to build a release tarball without new-enough Sphinx (I think 
> the current rules would quietly not copy info / man pages to the source 
> directory if build tools were missing - but having those tools missing 
> when building a release tarball is much less likely than not having 
> new-enough Sphinx).

But perhaps that test should go to maintainer-scripts/gcc_release.
Can be either of the form of checking if Sphinx is new enough, or checking
of make actually built the documentation before creating the tarballs.

Jakub

C2x features status

[Joseph Myers]

I'm working on adding various C2x features to the C front end (and 
elsewhere in GCC as applicable).

I suspect I won't get all the C2x features done for GCC 13.  If anyone 
else is interested in adding C2x features, I'd encourage looking at some 
of the following, which I may well not get to for GCC 13 (and posting here 
to avoid duplication of effort if working on such a feature):

* Bit-precise integer types (_BitInt) (see bug 102989) (integrated version 
based on N2763, plus literal suffixes from N2775 and bit-fields from 
N2969).  Would require working with back-end maintainers and upstream ABI 
groups, where available, to get ABIs defined for as many architectures as 
possible, as well as some default ABI choice in GCC for architectures that 
haven't defined the ABI for these types.

* [[unsequenced]] and [[reproducible]] attributes for function types.  See 
N2956.  These are supposed to be similar to const and pure attributes, at 
least in the absence of pointer and array function parameters (but note 
they never affect type compatibility).

* Tag compatibility (N3037, alternative wording).  Martin Uecker might 
have patches for a draft version of this?

* Preprocessor #embed (N3017) (see bug 105863).

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

Re: [PATCH RESEND 1/1] p1689r5: initial support

[Ben Boeckel via Gcc]

On Thu, Oct 20, 2022 at 11:39:25 -0400, Jason Merrill wrote:
> Oops, I was thinking this was in gcc as well.  In libcpp there's 
> _cpp_valid_utf8 (which calls one_utf8_to_cppchar).

This routine has a lot more logic (including UCN decoding) and the
`one_utf8_to_cppchar` also supports out-of-bounds codepoints above
`0x10`.

--Ben

Re: [PATCH RESEND 1/1] p1689r5: initial support

[Jason Merrill via Gcc]

On 10/20/22 13:31, Ben Boeckel wrote:

On Thu, Oct 20, 2022 at 11:39:25 -0400, Jason Merrill wrote:

Oops, I was thinking this was in gcc as well.  In libcpp there's
_cpp_valid_utf8 (which calls one_utf8_to_cppchar).


This routine has a lot more logic (including UCN decoding) and the
`one_utf8_to_cppchar` also supports out-of-bounds codepoints above
`0x10`.


The latter seems like a bug to be fixed; presumably it hasn't been 
updated since the range of codepoints was restricted.  This sort of 
thing is why I'd like to minimize the number of separate implementations 
of UTF-8 parsing.


Jason

GTI project presentation and public discussion

[David Edelsohn via Gcc]

The FSF will host a public conversation and Q&A about the GTI project on:

October 24, 10am Eastern Time.

You can read the full details here:
https://www.fsf.org/events/the-gti-project-a-conversation-and-community-q-a

Everyone is welcome to submit questions, attend the event, and engage.

Thank you!
Carlos & David

gcc-10-20221020 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-10-20221020.tar.xz   Complete GCC

  SHA256=eb5acfbd75d0766d88b465dbe0efc64bc2372be3b02ec0132266cbecd14f13d0
  SHA1=bbb6f69fa8b5229a31ca65aa8f1d1b26d238896d

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

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

Re: Toolchain Infrastructure project statement of support

[Alexandre Oliva via Gcc]

On Oct 18, 2022, Siddhesh Poyarekar  wrote:

> The rest, AFAICT, are either fear of some kind of corporate takeover,
> discussions about current sourceware infrastructure, or just rhetoric,
> none of which I'm interested in engaging with.

So in which category do you place my question about the viability of
using the funds raised through the LF to pay for IT services provided by
third parties rather than by the LF?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about