Re: performance of exception handling

[David Edelsohn via Gcc]

On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc  wrote:

> My current preferred solution is something that moves the entire code
> that locates the relevant FDE table into glibc.  This is all the code in
> _Unwind_IteratePhdrCallback until the first read_encoded_value_with_base
> call.  And the callback mechanism would be gone, so _Unwind_Find_FDE
> would call __dl_ehframe_find (see below) and then the reamining
> processing in _Unwind_IteratePhdrCallback.

Not all GCC/G++ targets are GNU/Linux and use GLIBC.  A duplicate
implementation in GLIBC creates its own set of advantages and
disadvantages.

Thanks, David

Re: performance of exception handling

[David Edelsohn via Gcc]

On Mon, May 11, 2020 at 10:52 AM Florian Weimer  wrote:
>
> * David Edelsohn:
>
> > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc  
> > wrote:
> >
> >> My current preferred solution is something that moves the entire code
> >> that locates the relevant FDE table into glibc.  This is all the code in
> >> _Unwind_IteratePhdrCallback until the first read_encoded_value_with_base
> >> call.  And the callback mechanism would be gone, so _Unwind_Find_FDE
> >> would call __dl_ehframe_find (see below) and then the reamining
> >> processing in _Unwind_IteratePhdrCallback.
> >
> > Not all GCC/G++ targets are GNU/Linux and use GLIBC.  A duplicate
> > implementation in GLIBC creates its own set of advantages and
> > disadvantages.
>
> The new interface is no less generic than _dl_iterate_phdr, so other
> systems can easily implement it if they want (and reuse the libgcc code
> that uses it).

The mission of GCC explicitly states that it supports other platforms
and diverse environments.  Other targets may or may not be able to
modify their C Library.  GLIBC is free to implement a more optimal API
and coordinate with GCC, but GCC EH cannot rely on a new, optional, ad
hoc interface provided by GLIBC.

Thanks, David

Re: dejagnu version update?

[David Edelsohn via Gcc]

On Thu, May 14, 2020 at 12:00 PM Rob Savoye  wrote:
>
> On 5/14/20 8:08 AM, Rainer Orth wrote:
>
> >> stops responding for whatever reason.  I have come up with a solution
> >> (that I'd be happy to upstream, except that DejaGNU maintenance seems to
> >> have been dead for like a year now), which I have also confirmed to be
> >> required with current DejaGNU Git master so it must be a different one,
> >> and I would like to know how it might be related to the bug you mention.
>
>   I feel I need to bring up the issue that DejaGnu is 30 years old, and
> it's two maintainers are either trying to pay bills, or trying to
> retire, or both... This problem will effect more projects in the future,
> not just DejaGnu. I'd love to see if anyone would like to become a
> co-maintainer, who preferably will be actively working for a few decades
> still. I think most people on these lists make their income from working
> on the toolchain, but some of us are still volunteers... and getting
> older every day...
>
>   There is a patch backlog neither of us have even looked at, sorry. I'm
> willing to put some time into this, but I think you all realize the time
> involved to adequately test this. I'm not sure I have enough disk space. :-)
>
>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

I greatly appreciate all of the work that you have invested in the
infrastructure and your continued assistance.

Have you approached the Linux Foundation Core Infrastructure
Initiative for funding for both DejaGNU maintenance (patch backlog)
and refactoring DejaGNU in Python efforts?

Thanks, David

GCC multilib build machinery for AIX 64 bit configuration

[David Edelsohn via Gcc]

TL;DR: How to preserve multilibs directory hierarchy for GCC 64 bit
configuration on AIX when 32 bit multilib exists in the top-level
directory, no explicit MULTILIB_DIRNAME.

Currently the powerpc-ibm-aix* port supports a 64-bit explicit
multilib and a 32 bit implicit, default multilib in the top-level
directory.

MULTILIB_OPTIONS= pthread maix64
MULTILIB_DIRNAMES = pthread ppc64

There is no explicit "maix32" multilib with "ppc32" directory.

My colleagues and I are trying to add a compatible, 64 bit
configuration where the compiler itself is a 64 bit application.  If
GCC is a 64 bit application, the build process requires that it
generate 64 bit code by default. I thought that adding an explicit
"maix32" multilib option with "." directory

MULTILIB_OPTIONS= pthread maix64/maix32
MULTILIB_DIRNAMES = pthread ppc64 .

and

MULTILIB_DEFAULTS { "maix64" }

in 64 bit mode would maintain the existing directory hierarchy.  In 32
bit mode with

MULTILIB_DEFAULTS { "maix32" }

the above configuration functions.  In 64 bit mode, the build
machinery seems confused that "." is at the wrong level in the
hierarchy.

I see t-sol2 uses "." for MULTILIB_OSDIRNAMES but I do not see any
other target example that uses "." in MULTILIB_DIRNAMES.

Does anyone have a suggestion to achieve the same, compatible
hierarchy using the GCC build system for a 64 bit configuration on
AIX?

Thanks, David

GCC Testsuite patches break AIX

[David Edelsohn via Gcc]

Alexandre,

Your testsuite patches have completely broken the testsuite on AIX.
1000's of testsuite failures because the testsuite is inserting
unsupported options on AIX.

Complaints about -dA, -dD, -dumpbase, etc.

This patch was not properly tested on all targets.  Please fix or
revert this patch immediately.

Thanks, David

Re: GCC Testsuite patches break AIX

[David Edelsohn via Gcc]

On Wed, May 27, 2020 at 10:16 AM Alexandre Oliva  wrote:
>
> Hello, David,
>
> On May 26, 2020, David Edelsohn  wrote:
>
> > Complaints about -dA, -dD, -dumpbase, etc.
>
> This was the main symptom of the problem fixed in the follow-up commit
> r11-635-g6232d02b4fce4c67d39815aa8fb956e4b10a4e1b
>
> Could you please confirm that you did NOT have this commit in your
> failing build, and that the patch above fixes the problem for you as it
> did for others?

Hi, Alexandre

Thanks for diligently working on this issue.  I did not have the fix
mentioned above in the original test.  I am performing a new bootstrap
with the patch.  Hopefully it will address some or all of the issues.

DejaGNU and the GCC testsuite is what it is.  It is fragile.  One of
the strengths of GCC is the wide variety of targets supported, not
only GNU/Linux, but other Unixes, Windows, embedded.  Testsuite
infrastructure changes such as these need testing on a wide variety of
targets to find system dependencies.

Thanks, David

Re: Push to my private branches is disallowed

[David Edelsohn via Gcc]

On Mon, Jun 15, 2020 at 2:13 PM Segher Boessenkool
 wrote:
>
> On Mon, Jun 15, 2020 at 10:47:48AM -0700, H.J. Lu wrote:
> > These are all the reasons why I don't use GCC repo for my personal
> > branches.
>
> Yeah, but I thought a lot of different GCC people might be interested in
> my "nuke CC0" patches, so putting it in the official repo seemed like a
> good idea, for easy access to all interested parties.  Oh well, back to
> my more private repos.

There is a difference between providing a service for the use of a
wide variety of GCC Developers and providing a service that implements
a workflow and automation preferred / desired by a subset of the
community.  The currently implemented rules and automation are not
encouraging personal branches in the GCC repository.

- David

Re: Modula-2 into the GCC tree on master?

[David Edelsohn via Gcc]

Hi, Gaius

Thanks for your diligent effort to complete this port of Modula-2 and
prepare it for inclusion in GCC.  I have forwarded the proposal to the
GCC Steering Committee.

Thanks, David


On Wed, Jun 24, 2020 at 5:03 PM Gaius Mulley via Gcc  wrote:
>
>
> Hello GCC Steering Committee and fellow GCC developers,
>
> I was wondering whether now might be a sensible time to graft GNU
> Modula-2 into the GCC tree?  (on the master branch only).  At present
> gm2 fully implements PIM2, PIM3, PIM4 and ISO dialects of Modula-2.  All
> the ISO libraries are implemented - there are a number of PIM libraries
> as well.  There are also no extra failures on master branch for other
> languages when Modula-2 is introduced.
>
> Since last year all non GPL3 material has been purged, the Ulm libraries
> removed (which were GPL2) and libpth removed.  All dependent code
> (coroutines) replaced by functionally equivalent modules using
> libatomic.  Multilib libraries are built and gm2 works with lto.  All
> code is now GPL3 or GPL3.1 with GCC runtime exemption (libraries).  It
> comes with a testsuite using dejagnu.  gm2 builds and runs on i386,
> amd64, powerpc64le, aarch64 and thanks to Matthias Klose there are gm2
> Debian packages on https://packages.debian.org/bullseye/gm2 with a few
> more architectures.
>
> Currently gm2 is tracking the GCC development model, there are branches
> open for [gm2-4, gm2-6, gm2-8, gm2-9, gm2-10], and gm2-master.
> (Although the branches in [] < 10 are not all GPL3 compliant and/or
> require libpth).
>
> The gm2 front code is currently in git on Savannah:
>
>git clone https://git.savannah.nongnu.org/git/gm2.git
>
> and there is a nightly automatic rebase of gm2 onto GCC which is
> available from:
>
>git clone http://floppsie.comp.glam.ac.uk/gm2 gm2-floppsie
>
>[See http://www.nongnu.org/gm2/development.html].
>
> which contains the above branches and GCC.  The gm2-master branch (on
> the floppsie git repro) passes all regressions (on aarch64 and there is
> one failure on amd64 - which I will fix after sending this email).  It
> perhaps might be useful to have yet another language with a regression
> testsuite even if just as a canary in the coal mine for various
> architectures, maybe?
>
> There are a few patches required to non m2 directories.  A number of
> these have been posted before and reviewed twice by Richard Sandiford
> and Joseph Myers.  (For reference
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg225115.html).
> I've made the suggested changes and the latest patches to be applied can
> be found here:
>
>
> http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/m2/patches/gcc/trunk
>
> The git sources can be browsed at:
>
>http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno
>
> using the master branch.  When the patches are applied it would look
> like the gm2-master branch on floppsie.comp.glam.ac.uk.
>
> Anyway from my perspective I'd be very happy to see the master
> branch reside in GCC :-) and was wondering if this is a good time?
>
> regards,
> Gaius

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

[David Edelsohn via Gcc]

On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose  wrote:
>
> https://gcc.gnu.org/gcc-8/criteria.html lists the little endian platform first
> as a primary target, however it's not mentioned for GCC 9 and GCC 10. Just an
> omission?
>
> https://gcc.gnu.org/legacy-ml/gcc-patches/2018-07/msg00854.html suggests that
> the little endian platform should be mentioned, and maybe the big endian
> platform should be dropped?
>
> Jakub suggested to fix that for GCC 9 and GCC 10, and get a consensus for GCC 
> 11.

Why are you so insistent to drop big endian?  No.  Please leave this alone.

Thanks, David

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

[David Edelsohn via Gcc]

On Thu, Jul 9, 2020 at 9:07 AM Matthias Klose  wrote:
>
> On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote:
> > On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose  wrote:
> >>
> >> https://gcc.gnu.org/gcc-8/criteria.html lists the little endian platform 
> >> first
> >> as a primary target, however it's not mentioned for GCC 9 and GCC 10. Just 
> >> an
> >> omission?
> >>
> >> https://gcc.gnu.org/legacy-ml/gcc-patches/2018-07/msg00854.html suggests 
> >> that
> >> the little endian platform should be mentioned, and maybe the big endian
> >> platform should be dropped?
> >>
> >> Jakub suggested to fix that for GCC 9 and GCC 10, and get a consensus for 
> >> GCC 11.
> >
> > Why are you so insistent to drop big endian?  No.  Please leave this alone.
>
> No, I don't leave this alone.  The little endian target is dropped in GCC 9 
> and
> GCC 10.  Is this really what you intended to do?

No, it's not dropped.  Some people are being pedantic about the name,
which is why Bill added {,le}.  powerpc64-unknown-linux-gnu means
everything.  If you want to add {,le} back, that's fine.  But there
always is some variant omitted, and that doesn't mean it is ignored.
The more that one over-specifies and enumerates some variants, the
more that it implies the other variants intentionally are ignored.

I would appreciate that we would separate the discussion about
explicit reference to {,le} from the discussion about dropping the big
endian platform.

Thanks, David

Re: Crash at gimple_code(gimple* )

[David Edelsohn via Gcc]

On Wed, Jul 15, 2020 at 10:07 AM Shuai Wang via Gcc  wrote:
>
> Hello!
>
> Thank you very much. I use the following statement to check and I confirm
> that it's not SSA_NAME:
>
> if (TREE_CODE(operand) != SSA_NAME) return;
>
> But considering the following code snippet:
>
> _313 = _312 + 2147450880;
> _314 = (signed char *) _313;
> _315 = **_314*; // _314 is NOT a SSA_NAME
>
> I was using the SSA_NAME_DEF_STMT here and there but right now since it
> does not work, how can I backwardly track the dependency of the above code
> snippet? Basically given _314, I would like to backwardly collect _313,
> _312, ..., until constructing the entire data dependency of _314...? Thanks
> a lot!

GCC has a powerful data dependency infrastructure.  Why are you trying
to duplicate that / recreate that yourself?

If you want to learn how to inquire about the data dependency for the
statement, please ask that explicitly.

I think that maybe your real question is being lost because you are
asking details about the symptoms of the crash instead of asking how
to use the GCC internal APIs to obtain the real information that you
want.  If you want to know how to obtain the data dependency for a
statement, please ask that, not "why is this crashing".

Thanks David

Re: Tar version being used

[David Edelsohn via Gcc]

On Mon, Jul 27, 2020 at 7:58 AM Richard Biener via Gcc  wrote:
>
> On Mon, Jul 27, 2020 at 12:59 PM CHIGOT, CLEMENT via Gcc
>  wrote:
> >
> > Hi everyone,
> >
> > I'm wondering if someone knows which tar version / configuration was being 
> > used when creating gcc-10.2.0 tarballs ?
> >
> > I'm getting some directory checksum errors while trying to unpack it with 
> > the AIX tar (which can be a bit old). But they are disappearing when I'm 
> > building these tarballs on Ubuntu-18.04, even with the last tar version 
> > 1.32.
> >
> > Note that gcc-10.1.0 doesn't have these problems, so maybe something have 
> > changed since.
>
> I have used tar 1.30 as shipped by openSUSE Leap 15.1
> (tar-1.30-lp151.2.1.x86_64)

GNU tar is listed as a requirement to install GCC from source:

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

Thanks, David

Re: LTO Dead Field Elimination

[David Edelsohn via Gcc]

On Mon, Jul 27, 2020 at 9:03 AM Christoph Müllner
 wrote:
>
> Hi Richard,
>
> On 7/27/20 2:36 PM, Richard Biener wrote:
> > On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
> >  wrote:
> >>
> >> This patchset brings back struct reorg to GCC.
> >>
> >> We’ve been working on improving cache utilization recently and would
> >> like to share our current implementation to receive some feedback on it.
> >>
> >> Essentially, we’ve implemented the following components:
> >>
> >>  Type-based escape analysis to determine if we can reorganize a type
> >> at link-time
> >>
> >>  Dead-field elimination to remove unused fields of a struct at
> >> link-time
> >>
> >> The type-based escape analysis provides a list of types, that are not
> >> visible outside of the current linking unit (e.g. parameter types of
> >> external functions).
> >>
> >> The dead-field elimination pass analyses non-escaping structs for fields
> >> that are not used in the linking unit and thus can be removed. The
> >> resulting struct has a smaller memory footprint, which allows for a
> >> higher cache utilization.
> >>
> >> As a side-effect a couple of new infrastructure code has been written
> >> (e.g. a type walker, which we were really missing in GCC), which can be
> >> of course reused for other passes as well.
> >>
> >> We’ve prepared a patchset in the following branch:
> >>
> >>refs/vendors/ARM/heads/arm-struct-reorg-wip
> >
> > Just had some time to peek into this.  Ugh.  The code doesn't look like
> > GCC code looks :/  It doesn't help to have one set of files per C++ class 
> > (25!).
>
> Any suggestions how to best structure these?
> Are there some coding guidelines in the GCC project,
> which can help us to match the expectation?

Thanks for working on this feature in GCC.  The coding standards for
the GNU Project and for GCC are:

https://www.gnu.org/prep/standards/
https://gcc.gnu.org/codingconventions.html

As others have mentioned, the documentation should be in the source
code itself.  An external design document is nice, but the code should
seemlessly integrate with the rest of the GCC source code, not a
separate, self-contained set of files bolted onto the side.

Thanks, David

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

[David Edelsohn via Gcc]

On Wed, Aug 19, 2020 at 10:34 AM Bernd Eggen via Gcc  wrote:
>
> Hello,
>
> I realised when I created the small code snippet I accidentally put the
> variable "m" in the default integer declaration, I checked it and moving it
> (to kind=16) does not make a difference either.
>
> I also checked on Ubuntu-64, same GCC & GFortran version (9.3.0) and I get
> the same error message / behaviour.  I re-attach the corrected f90 file,
> which also as a slightly improved loop exit condition.

Please open a GCC Bugzilla issue, as requested.  Sending messages and
updates to the GCC Development mailing list will not resolve your
issue.

Thanks, David

Re: duplicate arm test results?

[David Edelsohn via Gcc]

On Wed, Sep 23, 2020 at 8:26 AM Christophe Lyon via Gcc  wrote:
>
> On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
>  wrote:
> >
> > On 23/09/2020 11:20, Jakub Jelinek via Gcc wrote:
> > > On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wrote:
> > >> So that would give:
> > >>
> > >>   Results for 8.4.1 20200918 [r8-10517] on arm-none-linux-gnueabihf
> > >>
> > >> and hopefully free up some space at the end for the kind of thing
> > >> you mention.
> > >
> > > Even that 8.4.1 20200918 is redundant, r8-10517 uniquely and shortly
> > > identifies both the branch and commit.
> > > So just
> > > Results for r8-10517 on ...
> > > and in ... also include something that uniquely identifies the
> > > configuration.
> > >
> > >   Jakub
> > >
> >
> > I was thinking similarly, but then realised anyone using snapshots
> > rather than git might not have that information.
> >
> > If that's not the case, however, then simplifying this would be a great
> > idea.
> >
> > On the other hand, I use subject filters in my mail to steer results to
> > a separate folder, so I do need some invariant key in the subject line
> > that is sufficient to match without (too many) false positives.
> >
>
> I always assumed there was a required format for the title/email
> contents, is that documented somewhere?
> There must be a smart filter to avoid spam, doesn't it require some
> "keywords" in the title for instance?
>
> Same question for the gcc-regression list: is there a mandatory format?

The format is generated by contrib/test_summary.

- David

GCC PowerPC bootstrap and irange

[David Edelsohn via Gcc]

The latest irange patch has broken bootstrap for PowerPC

In file included from /nasfarm/edelsohn/src/src/gcc/tree-ssa-propagate.h:25:0,
 from
/nasfarm/edelsohn/src/src/gcc/config/rs6000/rs6000-call.c:67:
/nasfarm/edelsohn/src/src/gcc/value-query.h:90:31: error: 'irange' has
not been  declared
   virtual bool range_of_expr (irange &r, tree name, gimple * = NULL) = 0;
   ^~
/nasfarm/edelsohn/src/src/gcc/value-query.h:91:31: error: 'irange' has not been
declared
   virtual bool range_on_edge (irange &r, edge, tree name);
   ^~
/nasfarm/edelsohn/src/src/gcc/value-query.h:92:31: error: 'irange' has not been
declared
   virtual bool range_of_stmt (irange &r, gimple *, tree name = NULL);
   ^~
make[3]: *** [/nasfarm/edelsohn/src/src/gcc/config/rs6000/t-rs6000:47:
rs6000-call.o] Error 1

tree-ssa-propagate.h was (incorrectly?) changed to include
value-query.h, which breaks the flat header model of GCC, but
value-query.h depends upon value-range.h.

rs6000.c includes tree-ssa-propagate.h, but not value-range.h.

GCC sources can't be half pregnant about this.  Either
tree-ssa-propagate.h includes all of the dependent headers or none.  I
thought that the GCC policy was C files including the headers that
they needed, not headers sneaking into other headers.

Thanks, David

Re: Multilib Hierarchy

[David Edelsohn via Gcc]

On Tue, Oct 13, 2020 at 4:09 AM CHIGOT, CLEMENT via Gcc  wrote:
>
> Hi everyone,
>
> Since no one answered, I assume that MULTILIB_REUSE was indeed not the 
> solution.
> Thus, I've implemented a solution using a new target macro MULTILIB_FALLBACK.
> It allows any target to return a new multilib suffix based on the current
> one being used by the algorithm. This solution is much simpler than
> adding a new Makefile option like MULTILIB_REUSE and it allows targets
> to fully control the new suffix, which can be an advantage.
>
> However, this solution is not perfect. Especially, MULTILIB_FALLBACK must take
> care of freeing "curr_multilib_dir" array, which might not be the best thing 
> to
> do. But letting "for_each_path" doing it is created a much more complex code,
> which isn't better in my opinion.
>
> Anyway, is a patch like the following one seems possible to be integrated or
> should I search for a better solution ?

Your assumption is completely wrong.  The lack of a response has no
bearing on the correctness of the solution.  The lack of response is
that this is local to AIX so no one bothers to investigate or respond.

Thanks, David

Re: Fortran Shared Coarrays for GCC 11

[David Edelsohn via Gcc]

On Fri, Oct 23, 2020 at 12:52 PM Nicolas König  wrote:
>
> Hello everyone,
>
> I'm hoping to get shared coarrays for fortran (the devel/coarray_native
> branch) merged for GCC 11 as an experimental feature, but, since the
> library uses a lot of low-level routines, I'm a bit scared of breaking
> bootstrap. It would be great if some people with more unusual setup-ups
> could try building with the branch (at the moment, I have tested it on
> Linux both on Power and x86_64). The focus at the moment is just on
> bootstrap.
>
> Thanks in advance!

The GNU Compile Farm has a wide variety of systems on which you can
test bootstrap.

I tested the branch on AIX and it broke because the new files are
violating a GCC coding style convention: the libgfortran.h header file
MUST be the first header file included.  Some of the new files in the
libgfortran/nca subdirectory include system header files first.  This
is verboten.

It also is incorrect to include libgfortran.h in the source code, and
again include it in the coarrays header files.  And some system header
files are included in source code and some in the coarrays header
files.  The header file inclusion style should be consistent.

But, most importantly, libgfortran.h MUST be included first in any
coarrays source code file.

Thanks, David

Claudiu Zissulescu appointed ARC Co-Maintainer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has
appointed Claudiu Zissulescu as ARC Co-Maintainer.

Please join me in congratulating Claudiu on his new role.
Claudiu, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: [EXTERNAL]Re: MIPS Maintainer

[David Edelsohn via Gcc]

On Tue, Dec 8, 2020 at 12:52 PM Chao-ying Fu  wrote:
>
> Hi Maciej,
>
> >  Great to hear from you again!
>
>   It's great to hear from you, too!
>
> > >   We just wonder if you can sponsor me to become a MIPS maintainer,
> > > because Wave Computing would like to continue supporting MIPS
> > > architecture in GCC, although there are very few patches for MIPS
> > > recently. Any feedback is welcome.
>
> >  Well, it's up to the GCC steering committee really to appoint maintainers
> > , however you can post patches and help
> > with getting reviews through right away.  There hasn't been much traffic
> > with the MIPS port recently, but there has been some and it always helps
> > to have someone provide input.
>
>   I got David Edelsohn's email and replied to him yesterday.
> We have some small tweaks in GCC and can send the patches.
> There is a big patch for nanoMIPS that stays as-is for long time.
> It will take time to get the patch working against the latest code base,
> if the community wants to include nanoMIPS in GCC.

You shouldn't ask to be a co-maintainer solely because you want to
contribute patches, or patches that are specific to your specific
implementation of Mips.  You already can contribute patches.
Maintainers / reviewers for a port review all patches relevant to the
port, their appointment is to the community role, not a role for their
specific vendor.

Thanks, David

Re: Copyright assignment for Rust-GCC

[David Edelsohn via Gcc]

On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc  wrote:
>
> Hi Folks!
> This mail is about the development of Rust frontend of GCC.
>
> To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> In 2013, Philip Herron had announced the project in GCC mailing-list:
> https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> In 2019, @SimplyTheOther had contributed the almost complete parser and
> AST.
> And I helped to do some trivial work to make it work with the latest GCC
> at that time.
> Of course there are more contributors that I can't mention one by one.
> At that time, a small community of Rust-GCC had formed. We're interested
> in continuing it till it can be merged into GCC.
> https://github.com/Rust-GCC/gccrs
> So this is the brief history.
>
> Now we have a question, when should we assign copyright paper for GNU?
> Last time I assigned the copyright paper, I noticed that the paper
> mentioned the project name. But Rust-GCC hasn't been recognized by GCC
> community yet, so I'm not sure if it's the correct time to consider this
> issue.
>
> Comments are welcome.

As Jeff wrote, the assignment is for the GNU Compiler Collection (GCC)
project, not for specific languages.  One does /not/ submit separate
assignments for GNU Fortran, GNU C++, GNU Go, GNU Ada, GNU Modula2,
etc.

Please have all of the developers start the FSF copyright assignment
process now.

Thanks, David

Re: Copyright assignment for Rust-GCC

[David Edelsohn via Gcc]

On Tue, Jan 5, 2021 at 10:48 AM Jeff Law  wrote:
>
> On 1/4/21 11:01 PM, Eric Gallager via Gcc wrote:
> > On Mon, Jan 4, 2021 at 11:13 AM David Edelsohn via Gcc 
> > wrote:
> >
> >> On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc 
> >> wrote:
> >>> Hi Folks!
> >>> This mail is about the development of Rust frontend of GCC.
> >>>
> >>> To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> >>> In 2013, Philip Herron had announced the project in GCC mailing-list:
> >>> https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> >>> In 2019, @SimplyTheOther had contributed the almost complete parser and
> >>> AST.
> >>> And I helped to do some trivial work to make it work with the latest GCC
> >>> at that time.
> >>> Of course there are more contributors that I can't mention one by one.
> >>> At that time, a small community of Rust-GCC had formed. We're interested
> >>> in continuing it till it can be merged into GCC.
> >>> https://github.com/Rust-GCC/gccrs
> >>> So this is the brief history.
> >>>
> >>> Now we have a question, when should we assign copyright paper for GNU?
> >>> Last time I assigned the copyright paper, I noticed that the paper
> >>> mentioned the project name. But Rust-GCC hasn't been recognized by GCC
> >>> community yet, so I'm not sure if it's the correct time to consider this
> >>> issue.
> >>>
> >>> Comments are welcome.
> >> As Jeff wrote, the assignment is for the GNU Compiler Collection (GCC)
> >> project, not for specific languages.  One does /not/ submit separate
> >> assignments for GNU Fortran, GNU C++, GNU Go, GNU Ada, GNU Modula2,
> >> etc.
> >>
> >>
> > Speaking of Modula2, has that frontend made it into mainline GCC yet? I see
> > there was a bugzilla component for it added, but I don't remember seeing
> > anything about it in the changes.html file for any existing releases...
> No.  I haven't seen anyone even trying in a while.

Maybe Jeff is not caught up with his email.

The GCC SC previously accepted Modula2 support. Richard Biener
approved the patch merge a few days ago and Gaius is planning to
proceed.

Thanks, David

Re: Copyright assignment for Rust-GCC

[David Edelsohn via Gcc]

First, please be more patient.  People only are now returning from the
end of year vacation.  And the FSF may not respond immediately in the
best of times.

Second, you must get the assignment document from the FSF.  They
create a custom, pre-generated assignment form.  It takes time for
them to transfer your information to the form and send it.  It isn't a
click-through CLA.

Thanks, David

On Tue, Jan 5, 2021 at 11:25 AM Nala Ginrut  wrote:
>
>
> Thanks for all the replies, I've contacted ass...@gnu.org but no reply
> for 2 days.
> Should I get the form from GCC folks?
>
> Best regards.
>
>
> Eric Gallager writes:
>
> > On Mon, Jan 4, 2021 at 11:13 AM David Edelsohn via Gcc 
> > wrote:
> >
> >> On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc 
> >> wrote:
> >> >
> >> > Hi Folks!
> >> > This mail is about the development of Rust frontend of GCC.
> >> >
> >> > To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> >> > In 2013, Philip Herron had announced the project in GCC mailing-list:
> >> > https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> >> > In 2019, @SimplyTheOther had contributed the almost complete parser and
> >> > AST.
> >> > And I helped to do some trivial work to make it work with the latest GCC
> >> > at that time.
> >> > Of course there are more contributors that I can't mention one by one.
> >> > At that time, a small community of Rust-GCC had formed. We're interested
> >> > in continuing it till it can be merged into GCC.
> >> > https://github.com/Rust-GCC/gccrs
> >> > So this is the brief history.
> >> >
> >> > Now we have a question, when should we assign copyright paper for GNU?
> >> > Last time I assigned the copyright paper, I noticed that the paper
> >> > mentioned the project name. But Rust-GCC hasn't been recognized by GCC
> >> > community yet, so I'm not sure if it's the correct time to consider this
> >> > issue.
> >> >
> >> > Comments are welcome.
> >>
> >> As Jeff wrote, the assignment is for the GNU Compiler Collection (GCC)
> >> project, not for specific languages.  One does /not/ submit separate
> >> assignments for GNU Fortran, GNU C++, GNU Go, GNU Ada, GNU Modula2,
> >> etc.
> >>
> >>
> > Speaking of Modula2, has that frontend made it into mainline GCC yet? I see
> > there was a bugzilla component for it added, but I don't remember seeing
> > anything about it in the changes.html file for any existing releases...
> >
> >
> >> Please have all of the developers start the FSF copyright assignment
> >> process now.
> >>
> >> Thanks, David
> >>
>
>
> --
> GNU Powered it
> GPL Protected it
> GOD Blessed it
> HFG - NalaGinrut
> Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058

Re: Google GSOC Idea

[David Edelsohn via Gcc]

Are you trying to propose a JavaScript / TypeScript front-end and
associated runtime for GCC?

I don't believe that anyone would object to that.  It probably is much
too ambitious for a GSoC project.  You could propose a subset as a
GSoC project.

It's unclear if you already have a preliminary implementation and want
to incrementally continue it, like a Hackathon, as part of GSoC.

Thanks, David

On Tue, Jan 5, 2021 at 2:34 PM Alper G. via Gcc  wrote:
>
> I wanted to talk about a gcc front-end with the syntax js / ts, which is
> ahead-of-time. The standard library will also contain basic functions that
> will enable the use of several basic frameworks that can be used in
> standard output. It was an e-mail that I could not fully explain because I
> tried to correct the text a few times, I'm sorry :) We are a group of
> several people who have already worked on compiler design and we thought of
> applying this idea under the name gcc.
>
> Martin Jambor , 4 Oca 2021 Pzt, 17:37 tarihinde şunu yazdı:
>
> > Hi,
> >
> > On Sun, Dec 27 2020, Alper G. via Gcc wrote:
> > > Hello, I am waiting for your suggestions and evaluations about an idea
> > that
> > > I am thinking about applying to this year's event of google gsoc. In
> > short,
> > > I can say about myself that I am an engineering student and worked on
> > > compilers as well as several different fields. Nowadays, we see that
> > > scripting languages such as javascript / typescript are more than just a
> > > client-side language in the browser. In order to develop applications on
> > > desktop and mobile devices, there are alternatives such as electron that
> > > contain chromium and nodejs, have multi-disk-size requirements and cannot
> > > be packaged statically before runtime, such as react-native. In order to
> > > overcome such problems, it is necessary to create the ahead-of-time
> > > compilation, which we are familiar with such as c / c ++, according to
> > this
> > > syntax and standards, and to call the graphics libraries and system calls
> > > directly from within js. Therefore, I want to create a subset of gcc that
> > > can be statically compiled and contains the ecmascript standards required
> > > to run common js frameworks native. What are your comments on this
> > > idea?
> >
> > I'm afraid I don't understand it at all.  Making GCC "run common js
> > frameworks" makes very little sense to me.  Are you proposing some kind
> > of JavaScript Front-end (which is not a JIT)?
> >
> > > What can we say about the acceptability for gsoc?
> >
> > Well, unfortunately I can say only that I do not understand it.  If it
> > is the JavaScript Front-end, the project would too big for a GSoC, by
> > orders of magnitude, even if severely reduced in scope.
> >
> > Martin
> >

Re: Copyright Forms Request

[David Edelsohn via Gcc]

Sent privately.

- David

On Thu, Jan 7, 2021 at 8:08 PM Anthony Sharp via Gcc  wrote:
>
> Hello,
>
> Hope all is well. Please could I have a copy of the form to assign
> copyright of all future changes.
>
> Kind regards,
> Anthony Sharp

Re: Copyright assignment paperwork request

[David Edelsohn via Gcc]

Sent off-list.

- David

On Wed, Jan 13, 2021 at 11:43 AM Harris Snyder  wrote:
>
> Hi,
>
> I would like to start contributing to GCC. As such, from my
> understanding, I need to file some paperwork related to copyright
> assignment. If there is a set of paperwork that would cover all future
> contributions by me, please send it to me at your convenience.
>
> Thank you!
> Harris Snyder

Re: Copyright Assignment Form

[David Edelsohn via Gcc]

Sent off list.

- David

On Wed, Feb 17, 2021 at 11:28 PM Akshat Agarwal via Gcc  wrote:
>
> Hey,
> I would like to contribute some patches to the gccrs project 
> (https://github.com/Rust-GCC/gccrs/) and I'd like to get a copyright 
> assignment form as per the guidelines outlined at 
> https://gcc.gnu.org/contribute.html.
> Do let me know if there are any more steps involved.
>
> Thanks,
> Akshat Agarwal

Re: Request for copyright assignment form

[David Edelsohn via Gcc]

See off list.

Thanks, David

On Tue, Feb 23, 2021 at 7:08 AM The Other via Gcc  wrote:
>
> Hi,
>
> I would like to get a copyright assignment form for GCC. I believe that 
> https://gcc.gnu.org/contribute.html states that the right place to get such a 
> form is here.
>
> Thanks,
> Theo

Re: What is pex_run

[David Edelsohn via Gcc]

On Thu, Feb 25, 2021 at 5:26 PM Gary Oblock via Gcc  wrote:
>
> I've got collect2 finding a linker error and I'm out of
> other options so I'm poking around in the collect2
> sources. I'm wondering what pex_run is (since it's
> getting handed the arguments this might mater?)
> I figure if I can get collect2 to spill its guts
> about what arguments are fed to "ld" I'll have
> at least a chance figuring out what in the bleep
> is going on... alternate debugging strategies
> are welcome.

collect2 will dump out a lot of extra information and save temporary
files if passed "-debug" option to collect2 (not to GCC).  In other
words

$ gcc -Wl,-debug -o foo foo.o

Thanks, David

Re: Request for Copyright Assignment Form

[David Edelsohn via Gcc]

Replied off-list.

Thanks, David

On Sat, Mar 13, 2021 at 11:16 AM Ansh Tyagi via Gcc  wrote:
>
> Hey,
> I would like to contribute in Rust-GCC/gccrs so I am requesting a Copyright
> Assignment Form. Let me know if there are any more steps to contribute.
>
> Thanks & Regards
> Ansh Tyagi

Re: Copyright assignment

[David Edelsohn via Gcc]

Replied off-list.

On Tue, Mar 30, 2021 at 9:49 AM George Liakopoulos via Gcc
 wrote:
>
> Dear GCC Community ,
>
> I am planning to contribute in Rust-GCC project (
> https://github.com/Rust-GCC) , so I think it will be good to have the
> copyright assignment from now on .
>
> Waiting for your reply ,
> George Liakopoulos

Re: Remove RMS from the GCC Steering Committee

[David Edelsohn via Gcc]

On Wed, Mar 31, 2021 at 8:28 AM Richard Biener via Gcc  wrote:
>
> On Wed, Mar 31, 2021 at 1:36 PM Mark Wielaard  wrote:
> >
> > You are referencing the recent open letter which isn't really what
> > people are discussing here. Although many probably sympathize with
> > calling for the removal of the entire Board of the Free Software
> > Foundation and calling for Richard M. Stallman to be removed from all
> > leadership positions, including the GNU Project
> >
> > You can disagree with the specific way that was worded and still come
> > to the same conclusion. See for example https://www.arp242.net/rms.html
>
> Ah, this one is _very_ well written and captures my thoughts when
> writing my response to Nathan (but not willing to spend so much time
> on this to coherently formulate what I was thinking).
>
> 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").

Richard historically has approved nominees to the GCC SC because the
GNU Project considers the SC the official "maintainers" of GCC, but he
has not nominated or suggested any of the members.  I don't remember
him rejecting a proposed nominee.  And many major contributors to GCC
have not wished to be members of the GCC SC whose major purpose is to
be a buffer between the GCC Community and the Free Software
Foundation.

Has the GCC SC micro-managed you or prevented you from doing anything
as Global Reviewer and Release Manager?  Not that I'm aware of.

Has the GCC SC blocked any new port or major feature?  Not that I'm aware of.

Has the GCC SC blocked any qualified maintainer nominations?  Not that
I'm aware of.

Has the GCC SC instructed GCC developers on which features to work?  No.

Has the GCC SC inserted itself or voted on any disagreements?  No.

The reality is that the governance of GCC is extremely open because
it's performed by the developers in the community, not the GCC SC.
And GCC is much less bureaucratic than other, large Open Source
projects.  It doesn't have multiple committees and SIGs.  Everything
is worked out among the developers.  Projects are started by
developers who take the initiative to start a project.

Be careful what you wish for because it may be much worse than the
freedom that you currently enjoy.

Thanks, David

Re: Remove RMS from the GCC Steering Committee

[David Edelsohn via Gcc]

On Wed, Mar 31, 2021 at 9:46 AM Florian Weimer  wrote:
>
> * David Edelsohn via Gcc:
>
> > Has the GCC SC blocked any new port or major feature?  Not that I'm aware 
> > of.
>
> What about the plugin framework?  The libgcc licensing change would
> not have happened naturally.  Someone had to step in and delay the
> plugin framework feature until the licensing changes were in place.

I wrote blocked, not delayed.  In order to continue the alignment of
GCC with the FSF, the GCC SC agreed to delay deployment of LTO and
Plugins until a license to allow such features could be implemented.
We didn't feel that a rupture with the FSF would be beneficial.

Because I foresaw the need for such features and the need for the
license to accommodate it, I had been designing and negotiating with
the FSF for an appropriate license exception for years before LTO and
Plugins were proposed.  Richard Stallman, Richard Fontana, Brad Kuhn
and I all worked to resolve the issue.

I and other members of the GCC SC have worked diligently behind the
scenes to ensure that GCC and GNU Toolchain development can proceed as
smoothly and unhindered as possible.  We have prevented or resolved
many conflicts and issues without disturbing the broader community and
allow the community to focus on its important tasks and great progress
for the toolchain itself. I, at least, view that as my role as a
member of the GCC SC.  It's like a good manager: regardless of the
openness, hopefully the GCC community feels that the GCC SC "has their
back", manages the politics, and removes real or potential roadblocks
so that the software engineer can focus on being productive.

Thanks, David

Re: Having trouble getting my school to sign the copyright disclaimer

[David Edelsohn via Gcc]

On Wed, Mar 31, 2021 at 11:28 AM PKU via Gcc  wrote:
>
> Hello,
>
> I’m trying to get my school to sign the copyright disclaimer. Unfortunately 
> the officials are reluctant to do that. Can anyone suggest what to do next?
>
> They claim that university owns copyright to my code if I wrote it for a 
> school-related research project. However, since I’m an undergraduate and thus 
> do not have an advisor, nobody in the campus knows me well enough to prove 
> that it’s not the case. They do promise(verbally) that they won’t interfere 
> if I’m working on my own.
>
> Is there a way to get around that? Any suggestion is appreciated.

Will the university sign a copyright assignment?

Also, you seem to be in China.  It's the people's code.  Ask the
university why they are claiming ownership to something that belongs
to the people.

Thanks, David

Re: Remove RMS from the GCC Steering Committee

[David Edelsohn via Gcc]

[I previously sent this from another email account, but it seems to be
lost.  I am sending this on behalf of the GCC Steering Committee.]

In 2012 RMS was added to the GCC Steering Committee web page
based on his role in the GNU Project, though his role as a member
of the Steering Committee has been ambiguous and he was not a member
of the Steering Committee when EGCS became GCC[1].  We no longer feel
that this listing serves the best interests of the GCC developer and
user community.  Therefore, we are removing him from the page.

GCC supports the principles of Free Software and has remained aligned
with the GNU Project since EGCS became GCC, but effectively has continued
to operate as an autonomous project.

The GCC Steering Committee is committed to providing a friendly, safe
and welcoming environment for all, regardless of gender identity and
expression, sexual orientation, disabilities, neurodiversity, physical
appearance, body size, ethnicity, nationality, race, age, religion, or
similar personal characteristics.

- The GCC Steering Committee

[1] https://static.lwn.net/1999/0429/a/gcc.html

Re: RMS removed from the GCC Steering Committee

[David Edelsohn via Gcc]

As we have expressed, the GCC Steering Committee doesn't micromanage
the development of GCC.  The technical decisions are made by the
Release Managers and the various maintainers.  But if you want to play
nationality bingo, let's play and see what we find, shall we?

The three GCC Release Managers are from Czechia, Germany and the UK.
GCC is proud to have an overabundance of world-class Czech developers
who make amazing contributions to the project and maintain various
critical components.

The four stewards (maintainers) of GDB are from Brazil, France, Israel
and the US.

The two stewards (maintainers) of Binutils are from Australia and the UK.

The GLIBC project stewards are from Brazil, Canada, Czechia, Germany,
Russia, the UK, and the US, with frequent release management by a
developer in India.

Also, all of the appointments of stewards, release managers, and
maintainers are personal appointments.  We don't represent our
nationalities. We don't represent our countries.  We don't represent
our continents. We don't represent our companies; these are not
positions allocated to particular companies.  We don't represent
constituencies, but we bring experience and perspective from various
constituencies as human beings with diverse backgrounds.

These projects have thrived for the past 20+ years under the guidance
of a diverse set of developers as a testament to the benefits of Free
Software.  There always are opportunities for improvement and we
welcome constructive suggestions.

Thanks, David


On Sat, Apr 3, 2021 at 1:33 PM Giacomo Tesio  wrote:
>
> Hi Ian, Gerald and GCC all
>
> On Fri, 2 Apr 2021 14:25:34 -0700 Ian Lance Taylor wrote:
>
> > 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. [...] So prove me wrong.  Do the work.
>
> Well Ian, I'm glad and honoured to be appointed as a new member of
> the GCC Steering Committee [0]!!! :-D
>
> But now what?
>
> 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!
>
>
> > 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.
>
> A very interesting read, thanks!
>
> I didn't know that the Steering Committee was subject to these sort of
> power imbalances since 1999! It has been more than twenty years! :-o
>
>
> > 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!
>
> 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!
>
>
> But that's the fact with priviledge: if you have it, you can't see it.
>
> Yet as a C++ programmer, you will have no difficulty to properly
> abstract what Peggy McIntosh described in 1989[1] beyond the cultural
> context you share: US-priviledge is to the rest of the world, what
> white-priviledge is in the United States. [2]
>
>
> > 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
>
> The GNU Compiler Collection is a GNU project and Free Software.
>
> I'm not suprised to see this sort of arguments from a FSF-less and
> GNU-less Steering Committee (nor from a Google employee[3]).
>
> Indeed it is what scares me so much, what makes me feel unsafe at
> contributing to GCC and it is exactly why I asked to fix the GCC
> Steering Committee after the removal of RMS.
>
>
> 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.
>
>
> > 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 

Re: Default debug format for AVR

[David Edelsohn via Gcc]

On Tue, Apr 6, 2021 at 6:34 AM Richard Biener via Gcc  wrote:
>
> On Mon, Apr 5, 2021 at 10:56 PM Simon Marchi via Gcc  wrote:
> >
> > On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at 6:24 PM 
> > Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>> wrote:
> > >
> > > The default debug format (when using only -g) for the AVR target is
> > > stabs.  Is there a reason for it not being DWARF, and would it be
> > > possible to maybe consider possibly thinking about making it default 
> > > to
> > > DWARF?  I am asking because the support for stabs in GDB is pretty 
> > > much
> > > untested and bit-rotting, so I think it would be more useful for
> > > everyone to use DWARF.
> > >
> > >
> > > I tried to deprecate the stabs support a little over 4 years ago.
> > > https://gcc.gnu.org/pipermail/gcc-patches/2017-December/489296.html 
> > > 
> > > There was a suggestion to change the error to a warning, but my startup 
> > > company job kept me so busy I never had a chance to follow up on this.
> > >
> > > I would like to see the stabs support deprecated and the later removed 
> > > from gcc.  No new features have been added in a long time, and it is only 
> > > being maintained in the sense that when it fails it is fixed to ignore 
> > > source code constructs that it doesn't support.  The longer it survives 
> > > in this state, the less useful it becomes.
> > >
> > > Jim
> >
> > You have 100% my suppose on this.  The longer stabs survives (especially
> > as the default for an arch), the longer some people who don't know the
> > intricacies of debug formats could use it without knowing, and that
> > does them a disservice.
>
> Patches to kill STABS (and related/derived formats) are pre-approved for 
> stage1.

AIX continues to use and support STABS, although it is transitioning
to DWARF.  If this is intended as a general statement about removal of
STABS support in GCC, it is premature.

Thanks, David

Re: Default debug format for AVR

[David Edelsohn via Gcc]

On Thu, Apr 8, 2021 at 2:03 AM Richard Biener
 wrote:
>
> On April 8, 2021 1:17:53 AM GMT+02:00, David Edelsohn  
> wrote:
> >On Tue, Apr 6, 2021 at 6:34 AM Richard Biener via Gcc 
> >wrote:
> >>
> >> On Mon, Apr 5, 2021 at 10:56 PM Simon Marchi via Gcc
> > wrote:
> >> >
> >> > On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at
> >6:24 PM Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>>
> >wrote:
> >> > >
> >> > > The default debug format (when using only -g) for the AVR
> >target is
> >> > > stabs.  Is there a reason for it not being DWARF, and would
> >it be
> >> > > possible to maybe consider possibly thinking about making it
> >default to
> >> > > DWARF?  I am asking because the support for stabs in GDB is
> >pretty much
> >> > > untested and bit-rotting, so I think it would be more useful
> >for
> >> > > everyone to use DWARF.
> >> > >
> >> > >
> >> > > I tried to deprecate the stabs support a little over 4 years ago.
> >> > >
> >https://gcc.gnu.org/pipermail/gcc-patches/2017-December/489296.html
> >
> >> > > There was a suggestion to change the error to a warning, but my
> >startup company job kept me so busy I never had a chance to follow up
> >on this.
> >> > >
> >> > > I would like to see the stabs support deprecated and the later
> >removed from gcc.  No new features have been added in a long time, and
> >it is only being maintained in the sense that when it fails it is fixed
> >to ignore source code constructs that it doesn't support.  The longer
> >it survives in this state, the less useful it becomes.
> >> > >
> >> > > Jim
> >> >
> >> > You have 100% my suppose on this.  The longer stabs survives
> >(especially
> >> > as the default for an arch), the longer some people who don't know
> >the
> >> > intricacies of debug formats could use it without knowing, and that
> >> > does them a disservice.
> >>
> >> Patches to kill STABS (and related/derived formats) are pre-approved
> >for stage1.
> >
> >AIX continues to use and support STABS, although it is transitioning
> >to DWARF.  If this is intended as a general statement about removal of
> >STABS support in GCC,
>
> Yes, it is.
>
> Richard.

Richard,

It is inappropriate to unilaterally make this decision without
discussion with all affected ports and maintainers, without warning,
and without deprecation.  I request that you rescind this decision.

It is somewhat ironic to act as a dictator when we are having a
discussion about dictatorial behavior in GCC leadership.

Thanks, David

Re: Default debug format for AVR

[David Edelsohn via Gcc]

On Thu, Apr 8, 2021 at 10:41 AM Jeff Law  wrote:
>
> On 4/8/2021 8:06 AM, Simon Marchi via Gcc wrote:
> > On 2021-04-08 9:11 a.m., David Edelsohn wrote:
>  AIX continues to use and support STABS, although it is transitioning
>  to DWARF.  If this is intended as a general statement about removal of
>  STABS support in GCC,
> >>> Yes, it is.
> >>>
> >>> Richard.
> >> Richard,
> >>
> >> It is inappropriate to unilaterally make this decision without
> >> discussion with all affected ports and maintainers, without warning,
> >> and without deprecation.  I request that you rescind this decision.
> >>
> >> It is somewhat ironic to act as a dictator when we are having a
> >> discussion about dictatorial behavior in GCC leadership.
> > I don't really want to start such a debate about GCC politics.  If stabs
> > is not ready to be deleted, that's fine.  But it would be good to go
> > through all targets for which it is the default (like avr), and see if
> > they are ready to be switched to DWARF.  That's a baby step towards
> > eventually deleting it.
>
> Agreed.  I'd bet AIX is the outlier here and that most, if not all,
> other ports that may currently be stabs-by-default can switch to
> dwarf-by-default with no significant fallout.  So we fix everything we
> can while we wait for AIX to move forward.

I am not requesting a continuation of support for STABS to be
obstinate.  AIX has some support for DWARF, but STABS continues to be
the primary debug format on AIX.  Binutils does not fully function on
AIX and the AIX native tools support for DWARF is incomplete.  Also,
AIX uses XCOFF file format, not ELF, so DWARF syntax needs to be
adapted and all of the tools need to agree on the way that AIX symbols
are represented in DWARF.

IBM is adding support for AIX to LLVM and LLVM does not support STABS
debugging, which has both exposed problems and is motivating work to
resolve the gaps, but the additional features and fixes require time
to implement and deploy.

I am eager to transition to DWARF on AIX, but I continue to ask that
the support not be removed until DWARF can be used as a complete
substitute on AIX.  I hope that full support for DWARF in AIX will be
completed in 2022 and removal of GCC support for STABS can be targeted
for GCC 13, not GCC 12.

Thanks, David

Re: Default debug format for AVR

[David Edelsohn via Gcc]

On Thu, Apr 8, 2021 at 12:09 PM David Edelsohn  wrote:
>
> On Thu, Apr 8, 2021 at 10:41 AM Jeff Law  wrote:
> >
> > On 4/8/2021 8:06 AM, Simon Marchi via Gcc wrote:
> > > On 2021-04-08 9:11 a.m., David Edelsohn wrote:
> >  AIX continues to use and support STABS, although it is transitioning
> >  to DWARF.  If this is intended as a general statement about removal of
> >  STABS support in GCC,
> > >>> Yes, it is.
> > >>>
> > >>> Richard.
> > >> Richard,
> > >>
> > >> It is inappropriate to unilaterally make this decision without
> > >> discussion with all affected ports and maintainers, without warning,
> > >> and without deprecation.  I request that you rescind this decision.
> > >>
> > >> It is somewhat ironic to act as a dictator when we are having a
> > >> discussion about dictatorial behavior in GCC leadership.
> > > I don't really want to start such a debate about GCC politics.  If stabs
> > > is not ready to be deleted, that's fine.  But it would be good to go
> > > through all targets for which it is the default (like avr), and see if
> > > they are ready to be switched to DWARF.  That's a baby step towards
> > > eventually deleting it.
> >
> > Agreed.  I'd bet AIX is the outlier here and that most, if not all,
> > other ports that may currently be stabs-by-default can switch to
> > dwarf-by-default with no significant fallout.  So we fix everything we
> > can while we wait for AIX to move forward.
>
> I am not requesting a continuation of support for STABS to be
> obstinate.  AIX has some support for DWARF, but STABS continues to be
> the primary debug format on AIX.  Binutils does not fully function on
> AIX and the AIX native tools support for DWARF is incomplete.  Also,
> AIX uses XCOFF file format, not ELF, so DWARF syntax needs to be
> adapted and all of the tools need to agree on the way that AIX symbols
> are represented in DWARF.
>
> IBM is adding support for AIX to LLVM and LLVM does not support STABS
> debugging, which has both exposed problems and is motivating work to
> resolve the gaps, but the additional features and fixes require time
> to implement and deploy.
>
> I am eager to transition to DWARF on AIX, but I continue to ask that
> the support not be removed until DWARF can be used as a complete
> substitute on AIX.  I hope that full support for DWARF in AIX will be
> completed in 2022 and removal of GCC support for STABS can be targeted
> for GCC 13, not GCC 12.
>

I have discussed the STABS debugging situation internally and the AIX
team has accepted that STABS support will be removed in GCC 12.  This
also will mean that I will remove the AIX 6.1 and AIX 7.1
configurations for GCC 12.

If you want to delete all STABS debugging support in Stage 1, go ahead.

Thanks, David

Re: Copyright Assignment Form

[David Edelsohn via Gcc]

Replied privately.

On Fri, Apr 9, 2021 at 8:37 AM Ruihan Li via Gcc  wrote:
>
> Hello, everyone.
>
>
>
>
> I'd like to contribute to the gccrs project 
> (https://github.com/Rust-GCC/gccrs) and they require contributions to have 
> copyright assignment in place. Could you please tell me what I should do and 
> send me the relevant forms?
>
> Thank you in advance.
>
> Ruihan Li

Re: GCC association with the FSF

[David Edelsohn via Gcc]

On Sun, Apr 11, 2021 at 8:40 PM Ian Lance Taylor via Gcc
 wrote:
>
> 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).

Also, because the FSF considers the GCC SC the "package maintainers"
of GCC, the Steering Committee also receives and answers questions and
requests from RMS and the FSF.

And, as I mentioned in another thread, I believe that the role of the
GCC SC is to perform some of the duties of a good technical manager:
remove real or potential roadblocks so that the developers can focus
on being productive.

Some of us have initiated other activities and alliances to support
and promote GCC and the GNU Toolchain, although it is not an official
responsibility of the GCC SC.

Thanks, David

Re: Gcc as callable libraries (was: removing toxic emailers)

[David Edelsohn via Gcc]

On Thu, Apr 15, 2021 at 5:04 PM Thomas Koenig via Gcc  wrote:
>
> David,
>
> for some reason or other, I did not get your mail, so I will
> just reply copying in from the archive.
>
> First, thanks for injecting some sanity into the discussion.
>
> I will not discuss RMS' personal shortcomings or the lack of them.
> In today's toxic political climate, such allegations are often
> made up and weaponized without an effective defense for the
> alleged wrongdoer.  I don't know the truth of the matter, and I make
> a point of not finding out.
>
>  > In many ways the last 8 years of my career have been
>  > an attempt to get gcc to respond to the appearance of LLVM/clang (I've
>  > added JIT-compilation, improved diagnostics, and I'm implementing a
>  > static analysis pass)
>
> And this is highly welcome, and has made gcc (including gfortran) a much
> better compiler.  I well remember how you implemented the much better
> colored error messages that gfortran has now.
>
>  > Perhaps a pronouncement like: "try to make everything be consumable as
>  > libraries with APIs, as well as as standalone binaries" might have
>  > helped (and still could; can we do that please?)
>
> That makes perfect sense, as LLVM shows, and is something that the
> steering committee could decide for the project (or rather, it could
> issue a pronouncement that this will not be opposed if some volunteer
> does it).
>
> I think this could be as close to an unanimous decision as there can
> be among such a diverse community as the gcc developers.  If the FSF
> takes umbrage at this, the ball is in their court.

Andrew Macleod led a BOF at GNU Cauldron 2013 that discussed
re-architecting and modularizing GCC along these same lines.  The
header flattening was one step.

Thanks, David

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

[David Edelsohn via Gcc]

On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc  wrote:
>
> The first release candidate for GCC 11.1 is available from
>
>  https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
>  ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors.  It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux.  Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.

As I have reported in Bugzilla, the last minute

libstdc++: Refactor/cleanup of C++20 atomic wait implementation

has severely regressed libstdc++ on AIX due to changes to
bits/semaphore_base.h header.

- David

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

[David Edelsohn via Gcc]

On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
 wrote:
>
> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc  
> wrote:
>
>
> The first release candidate for GCC 11.1 is available from
>
>  https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
>  ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors.  It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux.  Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
>
>
> I posted a patch to BZ that should disable  entirely for AIX (and 
> other targets where there's not a supported implementation strategy).
>
> This patch isn't the best way of addressing this for a variety of reasons, 
> but this support is intended as experimental for GCC11 anyway. Unfortunately 
> I can't test it on AIX because it would seem that my ssh keys never landed on 
> the AIX cfarm machines.

I am testing the patch on an AIX system inside IBM.

But it seems that you are disabling semaphore entirely on AIX, which
is an unnecessary regression.  AIX has POSIX semaphores.  libstdc++
configure defines

_GLIBCXX_HAVE_POSIX_SEMAPHORE

I don't understand your comments about disabling semaphore on AIX
while the comment about experimental for GCC11 implies that this is
some new, experimental feature.  I could understand disabling the
experimental feature, but not disabling all semaphore support.

Thanks, David

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

[David Edelsohn via Gcc]

On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers
 wrote:
>
> On 2021-04-20 17:09, David Edelsohn wrote:
>
> On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
>  wrote:
>
>
> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc  
> wrote:
>
>
> The first release candidate for GCC 11.1 is available from
>
>  https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
>  ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors.  It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux.  Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
>
>
> I posted a patch to BZ that should disable  entirely for AIX (and 
> other targets where there's not a supported implementation strategy).
>
> This patch isn't the best way of addressing this for a variety of reasons, 
> but this support is intended as experimental for GCC11 anyway. Unfortunately 
> I can't test it on AIX because it would seem that my ssh keys never landed on 
> the AIX cfarm machines.
>
>
> I am testing the patch on an AIX system inside IBM.
>
> But it seems that you are disabling semaphore entirely on AIX, which
> is an unnecessary regression.  AIX has POSIX semaphores.  libstdc++
> configure defines
>
> _GLIBCXX_HAVE_POSIX_SEMAPHORE
>
> I don't understand your comments about disabling semaphore on AIX
> while the comment about experimental for GCC11 implies that this is
> some new, experimental feature.  I could understand disabling the
> experimental feature, but not disabling all semaphore support.
>
> Thanks, David
>
>
> The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, 
> but it shows up in your error report.

You now have pinpointed the problem.

It's not that AIX doesn't have semaphore, but that the code previously
had a fallback that hid a bug in the macros:

#if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
  // Use futex if available and didn't force use of POSIX
  using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>;
#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
  using __fast_semaphore = __platform_semaphore;
#else
  using __fast_semaphore = __atomic_semaphore;
#endif

The problem is that libstdc++ configure defines
_GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h.  libstdc++ uses sed to
rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
contains

#define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1

And bits/semaphore_base.h is not testing that corrupted macro.  Either
semaphore_base.h needs to test for the corrupted macro, or libtsdc++
configure needs to define HAVE_POSIX_SEMAPHORE without itself
prepending _GLIBCXX_  so that the c++config.h rewriting works
correctly and defines the correct macro for semaphore_base.h.

Thanks, David

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

[David Edelsohn via Gcc]

On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn  wrote:
>
> On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers
>  wrote:
> >
> > On 2021-04-20 17:09, David Edelsohn wrote:
> >
> > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
> >  wrote:
> >
> >
> > On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
> >
> > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc  
> > wrote:
> >
> >
> > The first release candidate for GCC 11.1 is available from
> >
> >  https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> >  ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
> >
> > and shortly its mirrors.  It has been generated from git revision
> > r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
> >
> > I have so far bootstrapped and tested the release candidate on
> > x86_64-linux and i686-linux.  Please test it and report any issues to
> > bugzilla.
> >
> > If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
> >
> >
> > As I have reported in Bugzilla, the last minute
> >
> > libstdc++: Refactor/cleanup of C++20 atomic wait implementation
> >
> > has severely regressed libstdc++ on AIX due to changes to
> > bits/semaphore_base.h header.
> >
> > - David
> >
> >
> > I posted a patch to BZ that should disable  entirely for AIX 
> > (and other targets where there's not a supported implementation strategy).
> >
> > This patch isn't the best way of addressing this for a variety of reasons, 
> > but this support is intended as experimental for GCC11 anyway. 
> > Unfortunately I can't test it on AIX because it would seem that my ssh keys 
> > never landed on the AIX cfarm machines.
> >
> >
> > I am testing the patch on an AIX system inside IBM.
> >
> > But it seems that you are disabling semaphore entirely on AIX, which
> > is an unnecessary regression.  AIX has POSIX semaphores.  libstdc++
> > configure defines
> >
> > _GLIBCXX_HAVE_POSIX_SEMAPHORE
> >
> > I don't understand your comments about disabling semaphore on AIX
> > while the comment about experimental for GCC11 implies that this is
> > some new, experimental feature.  I could understand disabling the
> > experimental feature, but not disabling all semaphore support.
> >
> > Thanks, David
> >
> >
> > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, 
> > but it shows up in your error report.
>
> You now have pinpointed the problem.
>
> It's not that AIX doesn't have semaphore, but that the code previously
> had a fallback that hid a bug in the macros:
>
> #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
>   // Use futex if available and didn't force use of POSIX
>   using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>;
> #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
>   using __fast_semaphore = __platform_semaphore;
> #else
>   using __fast_semaphore = __atomic_semaphore;
> #endif
>
> The problem is that libstdc++ configure defines
> _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h.  libstdc++ uses sed to
> rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
> contains
>
> #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1
>
> And bits/semaphore_base.h is not testing that corrupted macro.  Either
> semaphore_base.h needs to test for the corrupted macro, or libtsdc++
> configure needs to define HAVE_POSIX_SEMAPHORE without itself
> prepending _GLIBCXX_  so that the c++config.h rewriting works
> correctly and defines the correct macro for semaphore_base.h.
>
> Thanks, David

By the way, you can see the bug in the macro name on any Linux system
and reproduce the failure on any Linux system if you force it to
fallback to POSIX semaphores instead of Linux Futex or atomic wait.

Thanks, David

Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)

[David Edelsohn via Gcc]

On Fri, May 21, 2021 at 5:25 AM Martin Liška  wrote:
>
> On 5/20/21 2:54 PM, Richard Biener wrote:
> > On Thu, May 20, 2021 at 2:34 PM Martin Liška  wrote:
> >>
> >> Hello.
> >>
> >> I've got a patch candidate that leverages partial linking for a couple of 
> >> selected object files.
> >>
> >> I'm sending make all-host- jX results for my machine:
> >>
> >> before: 3m18s (user 32m52s)
> >> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/1dd5eae5001295ba0230a689f7edc67284c9b742/gcc-all-host.svg
> >>
> >> after: 2m57m (user 35m)
> >> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/d659b2187cf622167841efbbe6bc93cb33855fa9/gcc-all-host-partial-lto.svg
> >>
> >> One can utilize it with:
> >> make -j16 all-host PARTIAL_LTO=1
> >>
> >> @Segher, Andrew: Can you please measure time improvement for your slow 
> >> bootstrap?
> >> One can also tweak --param=lto-partitions=16 param value.
> >>
> >> Thoughts?
> >
> > You're LTO linking multiple objects here - that's almost as if you
> > were doing this
> > for the whole of libbackend.a ... so $(OBJS)_CLFAGS += -flto and in the
> > libbackend.a rule do a similar partial link trick.
>
> Yeah, apart from that one can't likely do partial linking for an archive:
>
> $ g++ -no-pie -flto=auto --param=lto-partitions=16 -flinker-output=nolto-rel 
> -r libbackend.a
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault], 
> core dumped
> compilation terminated.
>
> while ld.bfd immediately finishes.
>
> >
> > That gets you half of a LTO bootstrap then.
> >
> > So why did you go from applying this per-file to multiple files?  Does 
> > $(LINKER)
> > have a proper rule to pick up a jobserver?
> >
> > When upstreaming in any form you probably have to gate it on bootstrap-lto
> > being not active.
>
> Sure, that's reasonable, we can likely detect a -flto option in $(COMPILE), 
> right?
>
> One more thing I face is broken dependency:
> $ make clean && make -j32 PARTIAL_LTO=1
>
> g++ -fcf-protection -fno-PIE -c   -g   -DIN_GCC -fPIC-fno-exceptions 
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
> -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute 
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. 
> -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. 
> -I/home/marxin/Programming/gcc/gcc/../include 
> -I/home/marxin/Programming/gcc/gcc/../libcpp/include 
> -I/home/marxin/Programming/gcc/gcc/../libcody  
> -I/home/marxin/Programming/gcc/gcc/../libdecnumber 
> -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber 
> -I/home/marxin/Programming/gcc/gcc/../libbacktrace   -o gimple-match-lto.o 
> -MT gimple-match-lto.o -MMD -MP -MF ./.deps/gimple-match-lto.TPo 
> gimple-match.c -flto
> g++ -fcf-protection -fno-PIE -c   -g   -DIN_GCC -fPIC-fno-exceptions 
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
> -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute 
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. 
> -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. 
> -I/home/marxin/Programming/gcc/gcc/../include 
> -I/home/marxin/Programming/gcc/gcc/../libcpp/include 
> -I/home/marxin/Programming/gcc/gcc/../libcody  
> -I/home/marxin/Programming/gcc/gcc/../libdecnumber 
> -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber 
> -I/home/marxin/Programming/gcc/gcc/../libbacktrace   -o generic-match-lto.o 
> -MT generic-match-lto.o -MMD -MP -MF ./.deps/generic-match-lto.TPo 
> generic-match.c -flto
>
> In file included from ./tm.h:26,
>   from /home/marxin/Programming/gcc/gcc/backend.h:28,
>   from 
> /home/marxin/Programming/gcc/gcc/generic-match-head.c:23,
>   from generic-match.c:4:
> /home/marxin/Programming/gcc/gcc/config/i386/i386.h:2286:10: fatal error: 
> insn-attr-common.h: No such file or directory
>   2286 | #include "insn-attr-common.h"
>|  ^~~~
> compilation terminated.
> make: *** [Makefile:2678: generic-match-lto.o] Error 1
> make: *** Waiting for unfinished jobs
>
> In file included from ./tm.h:26,
>   from /home/marxin/Programming/gcc/gcc/backend.h:28,
>   from 
> /home/marxin/Programming/gcc/gcc/gimple-match-head.c:23,
>   from gimple-match.c:4:
> /home/marxin/Programming/gcc/gcc/config/i386/i386.h:2286:10: fatal error: 
> insn-attr-common.h: No such file or directory
>   2286 | #include "insn-attr-common.h"
>|  ^~~~
>
> I explicitly added:
> gimple-match.o: gimple-match.c $(generated_files)
> generic-match.o: generic-match.c $(generated_files)
>
> But it's not obeyed.

Please remembe

Update to GCC copyright assignment policy

[David Edelsohn via Gcc]

GCC was created as part of the GNU Project but has grown to operate as
an autonomous project.

The GCC Steering Committee has decided to relax the requirement to
assign copyright for all changes to the Free Software Foundation.  GCC
will continue to be developed, distributed, and licensed under the GNU
General Public License v3.0. GCC will now accept contributions with or
without an FSF copyright assignment. This change is consistent with
the practices of many other major Free Software projects, such as the
Linux kernel.

Contributors who have an FSF Copyright Assignment don't need to
change anything.  Contributors who wish to utilize the Developer Certificate
of Origin[1] should add a Signed-off-by message to their commit messages.
Developers with commit access may add their name to the DCO list in the
MAINTAINERS file to certify the DCO for all future commits in lieu of individual
Signed-off-by messages for each commit.

The GCC Steering Committee continues to affirm the principles of Free
Software, and that will never change.

- The GCC Steering Committee

[1] https://developercertificate.org/

Re: Update to GCC copyright assignment policy

[David Edelsohn via Gcc]

On Tue, Jun 1, 2021 at 10:15 AM Jakub Jelinek  wrote:
>
> On Tue, Jun 01, 2021 at 10:00:06AM -0400, David Edelsohn via Gcc wrote:
> > GCC was created as part of the GNU Project but has grown to operate as
> > an autonomous project.
> >
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. This change is consistent with
> > the practices of many other major Free Software projects, such as the
> > Linux kernel.
> >
> > Contributors who have an FSF Copyright Assignment don't need to
> > change anything.  Contributors who wish to utilize the Developer Certificate
> > of Origin[1] should add a Signed-off-by message to their commit messages.
> > Developers with commit access may add their name to the DCO list in the
> > MAINTAINERS file to certify the DCO for all future commits in lieu of 
> > individual
> > Signed-off-by messages for each commit.
> >
> > The GCC Steering Committee continues to affirm the principles of Free
> > Software, and that will never change.
>
> What does this mean for the source file comments?
>
> Do we continue using contrib/update-copyright.py --this-year to update
> the FSF copyright notices?
>
> When a new source file (that has copyright boilerplate, not say some small
> testcase) is added by somebody submitting their work under FSF copyright
> assignment, shall the
>   Copyright (C) 2021 Free Software Foundation, Inc.
> be added?
>
> What about when such a new source file is added by somebody submitting their
> work under DCO?  Shall they list
>   Copyright (C) 2021 John Doe
> or something else (note, update-copyright.py would need all such copyright
> lines in it).  If yes and later on somebody with FSF copyright assignment
> modifies that, shall the
>   Copyright (C) 2021 Free Software Foundation, Inc.
> line be added?

The copyright author will be listed as "Free Software Foundation,
Inc." and/or "The GNU Toolchain Authors", as appropriate.

>
> Can contributors with FSF Copyright Assignment on file (or those working
> for companies with company wide ones) assign all their further work or
> just selected commits under DCO?

The update to the policy does not negate any existing or future FSF
copyright assignments -- it solely expands the options available.
Individuals may add a Signed-off-by line or add their name to the DCO
list in the MAINTAINERS file, but it doesn't change the legal
framework for a contribution by an individual or company with a
copyright assignment.  Individuals and companies can choose how to
proceed with their existing FSF copyright assignments.  Individuals
and companies may continue to establish new copyright assignments with
the FSF.

Thanks, David

Re: Update to GCC copyright assignment policy

[David Edelsohn via Gcc]

On Tue, Jun 1, 2021 at 11:14 AM Jose E. Marchesi
 wrote:
>
>
> > GCC was created as part of the GNU Project but has grown to operate as
> > an autonomous project.
> >
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. This change is consistent with
> > the practices of many other major Free Software projects, such as the
> > Linux kernel.
> >
> > Contributors who have an FSF Copyright Assignment don't need to
> > change anything.  Contributors who wish to utilize the Developer Certificate
> > of Origin[1] should add a Signed-off-by message to their commit messages.
> > Developers with commit access may add their name to the DCO list in the
> > MAINTAINERS file to certify the DCO for all future commits in lieu of 
> > individual
> > Signed-off-by messages for each commit.
> >
> > The GCC Steering Committee continues to affirm the principles of Free
> > Software, and that will never change.
> >
> > - The GCC Steering Committee
> >
> > [1] https://developercertificate.org/
>
> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only??

The current, active license in GPL v3.0.  This is not an announcement
of any change in license.

Quoting Jason Merrill:

"GCC's license is "GPL version 3 or later", so if there ever needed to be a
GPL v4, we could move to it without needing permission from anyone."

Thanks, David

Re: Update to GCC copyright assignment policy

[David Edelsohn via Gcc]

On Tue, Jun 1, 2021 at 10:40 AM Paul Koning  wrote:
>
> > On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc  wrote:
> >
> > The copyright author will be listed as "Free Software Foundation,
> > Inc." and/or "The GNU Toolchain Authors", as appropriate.
>
> What does that mean?  FSF is a well defined organization.  "The GNU Toolchain 
> Authors" sounds like one, but is it?  Or is it just a label for "the set of 
> contributors who have contributed without assigning to FSF"?  In other words, 
> who is the owner of such a work, the GTA, or the submitter?  I'm guessing the 
> latter.
>
> That seems to create a possible future complication.  Prior to this change, 
> the FSF (as owner of the copyright) could make changes such as replacing the 
> GPL 2 license by GPL 3.  With the policy change, that would no longer be 
> possible, unless you get the approval of all the copyright holders.  This may 
> not be considered a problem, but it does seem like a change.
>
> I looked at gcc.gnu.org to find the updated policy.  I don't think it's 
> there; the "contribute" page wording still feels like the old policy.  Given 
> the change, it would seem rather important to have the implications spelled 
> out in full, and the new rules clearly expressed.

The GNU Toolchain Authors are all of the authors, including those with
FSF Copyright.  All of the authors agree to the existing license,
which is "...either version 3, or (at your option) any later version."
 If the project chooses to adopt a future update to the GPL, all of
the authors have given permission through the existing copyright
assignment or through certification of the DCO to utilize the newer
license.

Thanks, David

Re: Update to GCC copyright assignment policy

[David Edelsohn via Gcc]

On Mon, Jun 7, 2021 at 6:11 AM Giacomo Tesio  wrote:
>
> Hi Richard,
>
> On June 7, 2021 7:35:01 AM UTC, Richard Biener  
> wrote:
> > On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc 
> > wrote:
> > >
> > > On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio 
> > wrote:
> > >
> > > >
> > > > I would have really appreciated if the GCC SC had announced such
> > change
> > > > for the upcoming GCC 12 while sticking to the old policy in GCC
> > 11.
> > > >
> > >
> > > That is how I was thinking of the change, but I agree that it needs
> > > clarification.
> >
> > I don't think this is very practical - we'd need to check each and
> > every commit before considering backporting fixes, no?
>
> I'm a bit surprised: aren't such commits reviewed anyway on backport?
>
> Even if they apply smoothly, they could introduce nasty bugs if applied 
> blindly.
>
> Also, are there many non-FSF-assigned contribution in the development
> branch already?
>
>
>
> > "tainted"
>
> Sad word choice, tbh.
>
> Given that such major development decision was not discussed here but
> Imposed unilateraly by the Steering Committee, a bit of forewarning would be
> much more professional.
>
> Not because the new version are somehow "tainted" but because the many 
> different
> users of GCC around the world deserve a bit more respect, imho.
>
>
> This is not a minor change and should not be introduced in minor versions.
>
> It's a breaking change, after all.

It's not a new or different license (unlike GPLv2->GPLv3).  It's not
reverting the existing copyrights and assignments. As Eben Moglen
stated in the ZDNet article: "the FSF will long remain the
preponderant copyright holder in GCC and related projects... No
downstream user, modifier or redistributor of GCC is facing any
changes whatsoever."

The break mostly is psychological, not technical or legal.

Thanks, David

Re: Some libgcc headers are missing the runtime exception

[David Edelsohn via Gcc]

On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc
 wrote:
>
> Hi,
>
> It was pointed out to me off-list that config/aarch64/value-unwind.h
> is missing the runtime exception.  It looks like a few other files
> are too; a fuller list is:
>
> libgcc/config/aarch64/value-unwind.h
> libgcc/config/frv/frv-abi.h
> libgcc/config/i386/value-unwind.h
> libgcc/config/pa/pa64-hpux-lib.h
>
> Certainly for the aarch64 file this was simply a mistake;
> it seems to have been copied from the i386 version, both of which
> reference the runtime exception but don't actually include it.
>
> What's the procedure for fixing this?  Can we treat it as a textual
> error or do the files need to be formally relicensed?

I'm unsure what you mean by "formally relicensed".  It generally is
considered a textual omission.  The runtime library components of GCC
are intended to be licensed under the runtime exception, which was
granted and approved at the time of introduction.

In addition, it would be good to start adding the correct SPDX License
Identifier to all of these files.

Thanks, David

Re: Some libgcc headers are missing the runtime exception

[David Edelsohn via Gcc]

On Fri, Jul 9, 2021 at 1:31 PM Richard Sandiford
 wrote:
>
> David Edelsohn  writes:
> > On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc
> >  wrote:
> >>
> >> Hi,
> >>
> >> It was pointed out to me off-list that config/aarch64/value-unwind.h
> >> is missing the runtime exception.  It looks like a few other files
> >> are too; a fuller list is:
> >>
> >> libgcc/config/aarch64/value-unwind.h
> >> libgcc/config/frv/frv-abi.h
> >> libgcc/config/i386/value-unwind.h
> >> libgcc/config/pa/pa64-hpux-lib.h
> >>
> >> Certainly for the aarch64 file this was simply a mistake;
> >> it seems to have been copied from the i386 version, both of which
> >> reference the runtime exception but don't actually include it.
> >>
> >> What's the procedure for fixing this?  Can we treat it as a textual
> >> error or do the files need to be formally relicensed?
> >
> > I'm unsure what you mean by "formally relicensed".
>
> It seemed like there were two possibilities: the licence of the files
> is actually GPL + exception despite what the text says (the textual
> error case), or the licence of the files is plain GPL because the text
> has said so since the introduction of the files.  In the latter case
> I'd have imagined that someone would need to relicense the code so
> that it is GPL + exception.
>
> > It generally is considered a textual omission.  The runtime library
> > components of GCC are intended to be licensed under the runtime
> > exception, which was granted and approved at the time of introduction.
>
> OK, thanks.  So would a patch to fix at least the i386 and aarch64 header
> files be acceptable?  (I'm happy to fix the other two as well if that's
> definitely the right thing to do.  It's just that there's more history
> involved there…)

Please correct the text in the files. The files in libgcc used in the
GCC runtime are intended to be licensed with the runtime exception and
GCC previously was granted approval for that licensing and purpose.

As you are asking the question, I sincerely doubt that ARM and Cavium
intended to apply a license without the exception to those files.  And
similarly for Intel and FRV.

The runtime exception explicitly was intended for this purpose and
usage at the time that GCC received approval to apply the exception.

Thanks, David

Re: Proper Place for builtin_define(__ELF__)

[David Edelsohn via Gcc]

On Wed, Jul 21, 2021 at 11:09 PM Jeff Law via Gcc  wrote:
>
>
>
> On 7/21/2021 6:31 PM, Michael Eager wrote:
> >
> >
> > On 7/21/21 5:22 PM, Joel Sherrill wrote:
> >>
> >>
> >> On Wed, Jul 21, 2021, 7:12 PM Michael Eager  >> > wrote:
> >>
> >> On 7/21/21 2:28 PM, Joel Sherrill wrote:
> >>  > Hi
> >>  >
> >>  > We are in the process of porting RTEMS to the Microblaze and
> >> gcc does
> >>  > not have __ELF__ as a predefine. In looking around at where to
> >> add it,
> >>  > it looks like there are multiple ways to do it. We see
> >> variations on
> >>  > the following patterns:
> >>  >
> >>  > + dbxelf.h
> >>  > + OS specific header in config/
> >>  > + Arch/OS specific header
> >>  >
> >>  > Integrating dbxelf.h into the microblaze seems risky for one
> >> simple
> >>  > builtin_define(). Adding it to config/microblaze/rtems.h won't
> >> address
> >>  > the microblaze-elf target.
> >>  >
> >>  > A suggestion on where to add the builtin_predefine is
> >> appreciated.
> >>
> >> There are very few defines for __ELF__ in the GCC target files.
> >>
> >>
> >> Many  targets include dbxelf.h from the config.gcc script. There are
> >> 130 references to that file there. That seems to be where most
> >> architectures get it.
> >
> > AFAIK, no one has ever tried to build microblaze to generate stabs,
> > and I can't see a good reason why anyone would.  Including dbxelf.h
> > seems wrong.  I don't have an answer why other arch's do that.
> Avoiding dbxelf would be advisable.  We're really only supporting stabs
> for for aix anymore.  We need to start excising dbxelf from all the
> places it's being used.

As requested by Richi, the GCC configuration for AIX on trunk no
longer enables stabs.  There still are some variables defined in
xcoffout.c that would need to move to rs6000.c.  GCC should be ready
for stabs support to be removed.

Thanks, David

Re: Expensive selftests (was: 'hash_map>')

[David Edelsohn via Gcc]

This causes a bootstrap failure for me.

PR/101959

On Tue, Aug 17, 2021 at 5:00 AM Richard Biener via Gcc  wrote:
>
> On Tue, Aug 17, 2021 at 8:40 AM Thomas Schwinge  
> wrote:
> >
> > Hi!
> >
> > On 2021-08-16T14:10:00-0600, Martin Sebor  wrote:
> > > On 8/16/21 6:44 AM, Thomas Schwinge wrote:
> > >> [...], to document the current behavior, I propose to
> > >> "Add more self-tests for 'hash_map' with Value type with non-trivial
> > >> constructor/destructor", see attached.  OK to push to master branch?
> > >> (Also cherry-pick into release branches, eventually?)
> >
> > (Attached again, for easy reference.)
> >
> > > Adding more tests sounds like an excellent idea.  I'm not sure about
> > > the idea of adding loopy selftests that iterate as many times as in
> > > the patch (looks like 1234 times two?)
> >
> > Correct, and I agree it's a sensible concern, generally.
> >
> > The current 1234 times two iterations is really arbitrary (should
> > document that in the test case), just so that we trigger a few hash table
> > expansions.
>
> You could lower N_init (the default init is just 13!),
> even with just 128 inserted elements you'll trigger
> expansions to 31, 61 and 127 elements.
>
> > For 'selftest-c', we've got originally:
> >
> > -fself-test: 74775 pass(es) in 0.309299 seconds
> > -fself-test: 74775 pass(es) in 0.366041 seconds
> > -fself-test: 74775 pass(es) in 0.356663 seconds
> > -fself-test: 74775 pass(es) in 0.355009 seconds
> > -fself-test: 74775 pass(es) in 0.367575 seconds
> > -fself-test: 74775 pass(es) in 0.320406 seconds
> >
> > ..., and with my changes we've got:
> >
> > -fself-test: 94519 pass(es) in 0.327755 seconds
> > -fself-test: 94519 pass(es) in 0.369522 seconds
> > -fself-test: 94519 pass(es) in 0.355531 seconds
> > -fself-test: 94519 pass(es) in 0.362179 seconds
> > -fself-test: 94519 pass(es) in 0.363176 seconds
> > -fself-test: 94519 pass(es) in 0.318930 seconds
> >
> > So it really seems to be all in the noise?
>
> Yes.  I think the test is OK but it's also reasonable to lower
> the '1234' times and add a comment as to the count should
> trigger hashtable expansions "a few times".
>
> Richard.
>
> > Yet:
> >
> > > Selftests run each time GCC
> > > builds (i.e., even during day to day development).  It seems to me
> > > that it might be better to run such selftests only as part of
> > > the bootstrap process.
> >
> > I'd rather have thought about a '--param self-test-expensive' (or
> > similar), and then invoke the selftests via a new
> > 'gcc/testsuite/selftests/expensive.exp' (or similar).
> >
> > Or, adapt 'gcc/testsuite/gcc.dg/plugin/expensive_selftests_plugin.c',
> > that is, invoke them via the GCC plugin mechanism, which also seems to be
> > easy enough?
> >
> > I don't have a strong opinion about where/when these tests get run, so
> > will happily take any suggestions.
> >
> >
> > Grüße
> >  Thomas
> >
> >
> > -
> > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 
> > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: 
> > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; 
> > Registergericht München, HRB 106955

Harald Anlauf appointed Fortran Reviewer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has
appointed Harald Anlauf as a Fortran Reviewer.

Please join me in congratulating Harald on his new role.
Harald, please update your listing in the MAINTAINERS file.

Happy hacking!
David

GCC Register Pressure BoF notes

[David Edelsohn via Gcc]

Richi and Aaron,

Thanks for the great conversation about register pressure at the GCC
BoF at LPC2021.  It was a very productive session with good ideas
about how to proceed.

Where do you suggest that I place the Register pressure BoF notes?
GCC Wiki?  Email it to the GCC mailing list?  Bugzilla?  I'm not
certain where and how we want the conversation to continue.

Thanks, David

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[David Edelsohn via Gcc]

On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
 wrote:
>
> On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > On 05.10.21 23:54, Segher Boessenkool wrote:
> > >>There is also the issue of binary data.  If some user has written
> > >>out data in double double and wants to read it in as IEEE quad,
> > >>the results are going to be garbage.  Another option for CONVERT
> > >>might be the solution to that, or, as you wrote, having a
> > >>REAL(KIND=15).  It should be inaccessible via SELECTED_REAL_KIND,
> > >>though.
> > >
> > >That means flipping the default on all PowerPC to no longer be double-
> > >double.  This means that you should have IEEE QP work everywhere, or the
> > >people who do need more than double precision will have no recourse.
> >
> > I think we can exclude big-endian POWER from this - they do not have
> > IEEE QP support, correct?  So, exclude that from the SONAME change.
>
> Not correct, no.  IEEE QP works fine in either endianness.

This needs to be described with more granularity.  IEEE QP
instructions work with either endianness.

IEEE QP is enabled and supported for PPC64 LE Linux on Power.  The
transition is under discussion.

PPC64 BE Linux on Power does not define IEEE QP.  The ABI could be
updated and IEEE QP could be enabled, but PPC64 BE is not planning
future releases from Linux distros.

IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD
community.

AIX on Power will continue to use double-double long double format.
GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement
and support the double-double format on AIX.

Thanks, David

P.S. This is my personal understanding and not an official statement
of support or product guidance from IBM.

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[David Edelsohn via Gcc]

On Wed, Oct 6, 2021 at 12:21 PM Segher Boessenkool
 wrote:
>
> On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> > On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> >  wrote:
> > >
> > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > > >>There is also the issue of binary data.  If some user has written
> > > > >>out data in double double and wants to read it in as IEEE quad,
> > > > >>the results are going to be garbage.  Another option for CONVERT
> > > > >>might be the solution to that, or, as you wrote, having a
> > > > >>REAL(KIND=15).  It should be inaccessible via SELECTED_REAL_KIND,
> > > > >>though.
> > > > >
> > > > >That means flipping the default on all PowerPC to no longer be double-
> > > > >double.  This means that you should have IEEE QP work everywhere, or 
> > > > >the
> > > > >people who do need more than double precision will have no recourse.
> > > >
> > > > I think we can exclude big-endian POWER from this - they do not have
> > > > IEEE QP support, correct?  So, exclude that from the SONAME change.
> > >
> > > Not correct, no.  IEEE QP works fine in either endianness.
> >
> > This needs to be described with more granularity.  IEEE QP
> > instructions work with either endianness.
> >
> > IEEE QP is enabled and supported for PPC64 LE Linux on Power.  The
> > transition is under discussion.
>
> IEEE QP insns are enabled for BE as well:
>
> powerpc64-linux-gcc -Wall -W -O2 -S qp.c -mcpu=power9
>
> === qp.c ===
> #define QP _Float128
> QP f(QP x) { return x*x; }
> ===
>
> results in
>
> .L.f:
> xsmulqp 2,2,2
> blr
>
> > PPC64 BE Linux on Power does not define IEEE QP.  The ABI could be
> > updated and IEEE QP could be enabled, but PPC64 BE is not planning
> > future releases from Linux distros.
>
> This is a different thing: on BE (and on LE by default as well) we use
> double-double for long double.
>
> > IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD
> > community.
>
> Yes.
>
> > AIX on Power will continue to use double-double long double format.
> > GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement
> > and support the double-double format on AIX.
>
> Yes.  But this wasn't about what to use for long double -- it was about
> Fortran even :-)
>
> The actual IEEE QP float types work fine on BE.  I suspect they do on
> AIX as well for that matter?
>
> Fwiw, with -mcpu=power8 we get
>
> .L.f:
> mflr 0
> xxlor 35,34,34
> std 0,16(1)
> stdu 1,-112(1)
> bl __mulkf3
> nop
> addi 1,1,112
> ld 0,16(1)
> mtlr 0
> blr

GCC can generate the IEEE QP instructions on AIX.  The AIX Assembler
is aware of the instructions.  libquadmath is neither built nor
installed on AIX.  The AIX C library and AIX Math library are not
aware of the IEEE QP type nor how to work with it, e.g., printf.

Thanks, David

Re: Broken links on website

[David Edelsohn via Gcc]

The Binaries information on the website is generated from the Binaries
information in the GCC Install docs.  I updated the links in the docs.
Thanks for alerting us to the broken links.

Thanks, David

On Tue, Oct 12, 2021 at 4:14 AM Ryan Plant  wrote:
>
> Just a quick heads-up , https://gcc.gnu.org/install/binaries.html currently
> has two broken links. "MinGW" leads to a dead site covered in
> domain-parking ads, and the "mingw-w64" one 404s. I believe the current
> links for those projects are https://osdn.net/projects/mingw/ and
> https://www.mingw-w64.org/ respectively.

Re: How to get started with contribution

[David Edelsohn via Gcc]

On Wed, Jan 5, 2022 at 3:27 PM Prakhar Khandelwal via Gcc
 wrote:
>
> Hey !!
> I, Prakhar Khandelwal, am currently in the 3rd year of my engineering and
> majoring in Computer Science. I always wanted to work at a low level in
> software. That's why  I want to contribute to your organization but
> wondering from where should I start, as I am new to this world of
> open-source. So, if you can guide me,  then it would be great.
> Waiting for your precious response.!!
> Regards.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

Re: How to get started with contribution

[David Edelsohn via Gcc]

On Sat, Jan 15, 2022 at 5:07 AM Purvak Baliyan via Gcc  wrote:
>
> Respected Sir/Madam
>
> I am Purvak Baliyan, an Information Technology undergrad, I have entered my
> third year at DR. Akhilesh Das Gupta Institute of Technology &
> Management(ADGITM). I am new to open source contributions but i am well
> aware of C/C++, Data Structure and Algorithms, and HTML & CSS. I would love
> to contribute to your organisation but could you please tell me how to get
> started?

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

Re: how to get started with contribution

[David Edelsohn via Gcc]

On Sat, Jan 29, 2022 at 10:37 AM VAISHNAVI DAYANAND via Gcc
 wrote:
>
> Respected sir/madam,
> I am Vaishnavi Andhalkar, a junior undergrad at IIT Roorkee. I have
> recently started contributing to open source, and I am new at it. But, I am
> well aware of C++, programming and algorithms, and javascript. I would like
> to contribute to your organization. Would you please tell me how to get
> started?
> Hoping to hear from you soon
> Thanks and Regards
> Vaishnavi

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

Re: How to get started with Contribution

[David Edelsohn via Gcc]

On Sat, Feb 19, 2022 at 2:45 AM Purvak Baliyan via Gcc  wrote:
>
> Respected Sir/Madam
>
> I am Purvak Baliyan, an Information Technology undergrad, I have entered my
> third year at DR. Akhilesh Das Gupta Institute of Technology &
> Management(ADGITM). I am new to open source contributions but i am well
> aware of C/C++, Data Structure and Algorithms, and HTML & CSS. I would love
> to contribute to your organisation but could you please tell me how to get
> started?
>
> Hoping to hear from you soon.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

Re: GSoC

[David Edelsohn via Gcc]

On Sat, Mar 12, 2022 at 10:40 AM Γιωργος Μελλιος via Gcc
 wrote:
>
> Greetings,
>
> I am sending this email in order to show my interest in your GSoC program
> for this summer.
> To begin with, I would like to learn some general information about your
> project in order to judge if I am capable of participating in it. I am
> currently studying Compilers and Programming Languages in my university
> (Computer Science Department, University of Crete) and I am very interested
> in it, so finding you as a GSoC organization made me extremely happy.
>
> Thanks in advance,
> Georgios Panagiotis Mellios

Hi, Georgios

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

The GSoC application process is not open yet, but you can look at
previous GSoC projects and project ideas on the GCC Wiki:

https://gcc.gnu.org/wiki/SummerOfCode

Thanks, David

Re: Contribution

[David Edelsohn via Gcc]

On Mon, Mar 14, 2022 at 4:37 AM farhad via Gcc  wrote:
>
> TO whom it may concern,
> I'm Farhad Sarvari and I have been working as a software engineer for more
> than 10 years and also have a strong background in c++ programming language.
> In addition I wrote a book about modern C++.
>   I want to contribute to GCC
> development. It would be great if you provide more detail about how i can
> contribute.
> Thanks in advance. I'm looking forward to hearing from you.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

>
> Best regards,
> Farhad
>
> --
> sent by Farhad
>
>
> --
> sent by Farhad

Re: Announcement: gcobol

[David Edelsohn via Gcc]

On Mon, Mar 14, 2022 at 4:35 PM James K. Lowden
 wrote:
>
> https://git.symas.net:443/cobolworx/gcc-cobol/
> https://github.com/Apress/beg-cobol-for-programmers
>
> Greetings, gcc!  We come bearing gifts!
>
> When you set your clock ahead an hour yesterday, you might not have
> realized you set your calendar back to 1985.  There's a new gcc COBOL
> compiler. We call it: gcobol.
>
> On the books, we have 1 man-year invested: two full-time
> programmers since October 2021.
>
> We have so far compiled just over 100 programs from the examples in
> "Beginning COBOL for Programmers", by Michael Coughlin. We are near the
> end of that phase of the project, and expect to have ISAM and
> Object-Oriented Cobol features implemented in the next few weeks.  We
> are working on compiling the NIST COBOL test suite, which we expect
> will take a few months to complete.  We have begun work on  gdb, too,
> and hope to have it working by year end.
>
> Our project should not be confused with GnuCOBOL
> (https://savannah.gnu.org/projects/gnucobol).  That project is a Cobol
> translator: it compiles Cobol to C, and invokes gcc to produce
> executable code.  Our gcobol compiler is (currently) a fork of gcc.  It
> implements a gcc frontend for Cobol and (obviously) invokes the gcc
> backend to produce executables.  (We have a friendly relationship with
> GnuCOBOL, and its maintainer supports our undertaking.)
>
> Ours should also not be confused with prior efforts to create a gcc
> Cobol compiler.  Others have tried and failed.  Failure wasn't an
> option for us.  I won't say it was easy, but here we are.
>
> Eventually, if the gcc maintainers are interested, we would like to
> pursue full integration with gcc.  For the moment, we have questions
> we're hoping can be answered here by those who ran the gauntlet
> before us.  Given the state of the internals documentation, that seems
> like our best option. We've been rummaging around in the odd sock
> drawer for too long.
>
> If you're like me (like I was), your visceral response to this
> announcement can be summed up in one word: Why?
>
> The answer is as easy as it is trite: the right tool for the job.
>
> I wouldn't write an operating system in Cobol.  But I wouldn't write
> one in Python or Java, either.  Cobol has a niche no other language
> occupies: a compiled language for record-oriented I/O.
>
> That might sound strangely specialized, but it's not.  Record-oriented
> I/O describes, I would argue, nearly *all* applications.  Yet, since the
> advent of C, nearly all applications have relegated I/O to an external
> library, and adopted the Unix byte-stream definition of a "file".
>
> If you've written a CGI web application, you know what I'm talking
> about.  Cobol eliminates a lot of gobbledygook by reducing free-form
> run-time variables to compile-time constants.
>
> That's the rationale, and it's not just a theory.  Cobol is alive and
> kicking.  Estimates vary, but they all say north of 100 billion lines
> of Cobol are still in use, with millions more written every year, even
> now, in the 21st century.  Odds are your last ATM transaction or credit
> card purchase went through a Cobol application.
>
> There's another answer to Why: because a free Cobol compiler is an
> essential component to any effort to migrate mainframe applications to
> what mainframe folks still call "distributed systems".  Our goal is a
> Cobol compiler that will compile mainframe applications on Linux.  Not
> a toy: a full-blooded replacement that solves problems.  One that runs
> fast and whose output runs fast, and has native gdb support.
>
> I am happy to debate the lunacy of this project and the viability of
> Cobol, either here or off-list.  Today, we want to make the project
> known to those in the technical community who might most want to know
> what we're up to, and explain why we'll be asking the questions we're
> asking.
>
> Also, if you want to give it a whirl, please don't hesitate.  We're
> happy to help, and expect to learn something in the process.
>
> Thank you for you kind attention.
>
> --jkl

Hi, James

Great work!  Looking forward to having the GCobol front-end contributed to GCC.

Thanks, David

Re: Query regarding GSoC

[David Edelsohn via Gcc]

On Thu, Mar 17, 2022 at 1:39 PM Riva Malthiyar via Gcc  wrote:
>
> Respected mentor,
> I am Riva Malthiyar from India. I am experienced in C/C++. I saw the list
> of projects in your GSoC project ideas and wish to work in one of them. In
> the "Before You Apply" Section there is something related to compiler, I
> did not understand that point. What kind of compiler is needed?

Hi, Riva

Thank you for your interest to apply to participate in GSoC for the GCC project.

GCC is a compiler.  GCC is the system compiler for many, major Linux
distributions and many other operating systems and embedded
environments.  It helps to be aware of compilers and GCC to
participate in the GSoC for the GCC project.

Thanks, David

Re: passing command-line arguments, still

[David Edelsohn via Gcc]

On Sat, Mar 19, 2022 at 1:11 PM James K. Lowden
 wrote:
>
> I'm collecting my remarks in one reply here, hopefully for easier
> reading.  I want to offer my thanks, and also my assessment of the
> situation as I understand it.  My critique is intended as purely
> constructive.
>
> I understand vaguely what's going on.  I'll use the -findicator-column=
> form because it works, and because that's today's convention.
>
> I assert:
>
> 1.  I did define my option to take an argument.
> 2.  The documentation is incomplete and incorrect.
> 3.  The naming convention is inconsistent.
>
> Joseph Myers answered my question directly:
>
> > The .opt files control how options are parsed, both in the driver and
> > in the compiler programs such as cc1.  Passing of options from the
> > driver to those compiler programs is based on specs in the driver; -f
> > options are passed down because of the use of %{f*} in cc1_options
> > (and the use of %(cc1_options) in the specs for most languages).
>
> IIUC, it's not lang.opt, but lang-specs.h:
>
> $ nl lang-specs.h
>  1  /* gcc-src/gcc/config/lang-specs.h */
>  2  {".cob", "@cobol", 0, 1, 0},
>  3  {".COB", "@cobol", 0, 1, 0},
>  4  {".cbl", "@cobol", 0, 1, 0},
>  5  {".CBL", "@cobol", 0, 1, 0},
>  6  {"@cobol", "cobol1 %i %(cc1_options) %{!fsyntax-only:%
> (invoke_as)}", 0, 1, 0},
>
> The contents of that file are unspecified.  gccint.info says only:
>
> > 'lang-specs.h'
> >  This file provides entries for 'default_compilers' in 'gcc.c'
> > which override the default of giving an error that a compiler for that
> >  language is not installed.
>
> I implemented the above by cargo-cult coding.   Until today I had no
> idea what line 6 does.  Now I have only some idea.
>
> I don't understand where the %{} syntax is processed.  I'm guessing
> autoconf, which on this project is above my pay grade.

The %{} syntax is the "Specs language" used for options processing by
GCC.  It is not related to autoconf.  The options processing is
handled in gcc.c.  Please see the comment in gcc/gcc.cc beginning with
"The Specs Language".

GCC definitely could benefit from better documentation and clearer
introductions for beginners.  You privately mentioned to me that
documentation is one of your passions.  Your assistance to improve the
documentation of GCC would be welcomed.

Thanks, David


>
> On Thu, 17 Mar 2022 17:39:00 +
> Jonathan Wakely  wrote:
>
> > You didn't define your option to take an argument in the
> > .opt file.
>
> Of course I did:
>
>   indicator-column
>   Cobol Joined Separate UInteger Var(indicator_column) Init(0)
>   IntegerRange(0, 8)
>   Column after which Region B begins
>
> That says it takes an argument -- either Joined or Separate -- as an
> unsigned integer initialized to 0 in the range [0,8].  Not only that,
> the option is accepted by gcobol; it's just not passed to the
> compiler.
>
> The documentation does not say an option taking an argument must
> end in "=" and does not recommend it begin with "f".
>
> Marek Polacek  wrote:
> > > 2.  GCC accepts a  -fno- alternative, automatically
> >
> > Right, unless it's RejectNegative.
>
> Yes, and RejectNegative is an instrument of accidental complexity. If
> -f options automatically accept a -fno- option, then a -f option that
> does not want a -fno- alternative should use another name.  There are
> 25 other lowercase letters available.
>
> > > 3.  The "f" stands for "flag", meaning on/off.
> >
> > It does stand for "flag", and it looks like at some point in ancient
> > history if was on/off, but then came options like -falign-loops=N.
>
> IME, someone made a mistake in the past, and that mistake is now
> becoming mistaken for a standard.  I don't mind living with some cruft
> -- it's not as though gcc is unique in that regard -- but at the same
> time I see no reason to vernerate it or perpetuate it.
>
> In plain words, if we recognize that -f indicates an on/off switch,
> let's use it that way, deprecate those that don't, and not add new -f
> options that take arguments.
>
> One last, final minor point,
>
> > >  By default, all options beginning with "f", "W" or "m" are
> > >  implicitly assumed to take a "no-" form.
>
> > > More accurate would be
> > > to say a "fno-" form is automatically accepted or generated.
> >
> > TBH, I don't see how that would be any more accurate that what we
> > have now.
>
> Words matter. No one is assuming anything, a fact hidden by the passive
> "are implicitly assumed".  I don't know whether -fno- is "accepted" or
> "generated", or by what.  I'm suggesting the agent be stated and the
> verb not hide what's happening.  I would say:
>
> "Options beginning with "f", "W" or "m" also
> 
> a "no-" form generated by .
>
> I wouldn't say "by default", because it's not by default.  It's by
> design, and the alternative is contained in the next sentence.
>
> I've said my peace.  I have my option, and I'll use

LoongArch port accepted and maintainers appointed

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has accepted
the LoongArch port for inclusion in GCC and appointed Chenghua Xu and
Lulu Cheng as maintainers.

Please work with Richard Sandiford on the final technical review and
approval of the patches.  Please coordinate with the GCC Release
Managers for merging the port into the development tree, hopefully for
inclusion in GCC 12 release.

Please join me in congratulating Chenghua and Lulu on their new roles.
Please update your listing in the MAINTAINERS file.

Happy hacking!
David

Kewen Lin as PowerPC port co-maintainer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has
appointed Kewen Lin as GCC PowerPC port Co-Maintainer.

Please join me in congratulating Kewen on his new role.
Kewen, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: How target.md file with target.c/.cc file invoke assembly instructions

[David Edelsohn via Gcc]

On Wed, May 11, 2022 at 1:46 AM RICHU NORMAN  wrote:
>
> Hi,
> I am new in gcc development and I am focusing on cross-compilers.I have
> added a few instructions for the target machine in binutils and invoked it
> using asm() from c program.Now I want to add those instructions to gcc and
> define that instruction in target.md file.I have a few queries regarding
> the working of gcc.

You might find the GCC introduction at the GCC Resource Center at IIT
Bombay of assistance:
https://www.cse.iitb.ac.in/grc/

Also, please see the description of the GCC Machine Description

https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc

> 1. Do *target.md* files along with* target.cc/.c  *files
> help to invoke assembly instructions automatically?

The machine description (MD file, C file and headers) describe the
processor (as well as the ABI and other details for the target
platform supported by the processor).

> 2.What is the input for this ?(.gimple or .cfg files)

The machine description is not an independent program that takes input
from a file.  The GCC compiler runs the various passes, including the
ones derived from the information in the MD files.

> 3.How does it work internally?
> 4.I have defined an instruction in target.md alone.But that does not
> work.How to make it work?

Please see the documentation linked above and try to understand how
the other patterns in the MD file that you modified work.  You need to
ensure that the pattern you added corresponds to valid RTL that is
generated in the port.  At a very simplistic level, GCC invokes
well-known, named patterns in the MD file to generate RTL, transforms
and optimizes the RTL both with generic optimizations and
optimizations described in the MD files, and then re-recognizes the
RTL to match patterns in the MD file to determine which assembly
language to generate.

> 5.What is the use of target.c file and how cost is computed in it?
> 6.Which file to be examined in rtl-dump of object file for getting the
> input and output to this stage in gcc?

https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#Developer-Options

You probably want to use -fdump-rtl-all and see if the expected RTL
for your new pattern ever is generated or where it is being lost.  Or
maybe your pattern is not expecting the canonical form of the RTL into
which it is transformed.

You need to learn more about the basic internals of GCC.  The GCC
community can help answer technical questions but cannot debug your
machine description changes for you.

Thanks, David

Re: GNU Tools Cauldron 2022

[David Edelsohn via Gcc]

On Sat, May 14, 2022 at 7:03 PM Jan Hubicka via Gcc  wrote:
>
> Hello,
>
> We are pleased to invite you all to the next GNU Tools Cauldron,
> taking place in Paris on September 16-18, 2022.  We are looking forward
> to meet you again after three years!

Did you intend to announce the location as Prague, Czechia, not Paris, France?

>
> As for the previous instances, we have setup a wiki page for
> details:
>
>  https://gcc.gnu.org/wiki/cauldron2022  
> 
>
> In previous years we have been able to make the Cauldron free to all to attend
> thanks to the generosity of our sponsors. However this year we are having to
> charge for attendance. We are still working out what we will need to charge,
> but it will be no more than £200.
>
> Attendance will remain free for community volunteers and others who do not 
> have
> a commercial backer and we will be providing a small number of travel 
> bursaries
> for students to attend.
>
> We will also make it possible to attend remotely in the hybrid form and
> remote attendance will be for free as well.
>
> Please email to tools-cauldron-admin AT googlegroups.com if you would like to
> attend, indicating your T-shirt size and any dietary requirements. We'll
> contact you later in the year with details of how to pay.
>
> To send abstracts or ask administrative questions, please email to
> tools-cauldron-admin AT googlegroups.com  .
>
> The Cauldron is organized by a group of volunteers. We are keen to add some
> more people so others can stand down. If you'd like to be part of that
> organizing committee, please email the same address.
>
> This announcement is being sent to the main mailing list of the following
> groups: GCC, GDB, binutils, CGEN, DejaGnu, newlib and glibc.
>
> Please feel free to share with other groups as appropriate.
>
> Honza

Re:

[David Edelsohn via Gcc]

On Sun, May 22, 2022 at 5:21 PM Skrab Skrab via Gcc  wrote:
>
> How can i contribute to gcc.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

Re: remove intl/ directory?

[David Edelsohn via Gcc]

On Sat, Jun 18, 2022 at 1:44 PM Iain Sandoe via Gcc  wrote:
>
> Hi Bruno,
>
> > On 18 Jun 2022, at 18:01, Bruno Haible  wrote:
>
> > As the long-term GNU gettext maintainer, I would suggest to remove the intl/
> > directory from the GCC distribution.
> >
> > The effect for the users would be:
> >  * On systems without glibc, users who want an internationalized GCC
> >installation would have to install GNU gettext first. Then the GCC
> >binaries would be linked with the shared library libintl.so
> >(unless gettext was built with --disable-shared); they would no longer
> >contain the libintl code in 'cc1', 'cc1plus', etc.
>
> As a maintainer for GCC on a non-glibc system, I would:
>
>  (a) welcome a more modern version of intl, with the bug-fixes etc.
>  (b) not want to [force] add a shared lib dependency for my downstream.
>
> - so, please could we follow the pattern for GMP et. al. where the library
> can be provided with —with-intl= pointing to an installation, or be built in-
> tree by symlinking an approved version into the GCC tree.
>
> For such [non-glibs] systems where these libraries are not ’normally’
> installed, it is still very much preferable to be able to statically link them
> so that a compiler can be distributed with no deps other than those
> provided by the OS (and we can test what we ship and ship what we test).

As another maintainer for GCC of a non-GLIBC system, I echo Iain's request.

The broad list of systems supported by GCC requires effort, but is one
of its advantages. Making it more difficult to support GCC on
non-GLIBC systems will be detrimental to GCC.

Thanks, David

>
> thanks,
> Iain
>
>
> >  * On systems with glibc, no change.
> >
> > The effect for the GCC maintainers would be:
> >  * Easier to stay up-to-date with upstream libintl.
> >  * Less maintenance work with *.m4 files such as
> >  codeset.m4
> >  glibc21.m4
> >  intdiv0.m4
> >  inttypes_h.m4
> >  inttypes.m4
> >  inttypes-pri.m4
> >  lcmessage.m4
> >  stdint_h.m4
> >  uintmax_t.m4
> >  ulonglong.m4
> >  * Reduced risk of a CVE that would impact GCC binaries.
> >
> > Rationale:
> >  * This intl/ code is from 2003; of course several bugs have been
> >fixed in it over the last 19 years.
> >  * At that time GNU packages were still favouring static libraries.
> >GNU libtool became widely reliable only about in 2005.
> >  * Since then, distros have been favouring shared libraries over
> >static libraries, in order to be able to fix CVEs without
> >rebuilding many dependent binaries.
> >  * For this reason, GNU gettext removed the support for this way
> >of packaging libintl in version 0.20 (May 2019). The NEWS entry
> >said:
> >- The --intl option of the gettextize program (deprecated since 2010) is
> >  no longer available. Instead of including the intl sources in your
> >  package, we suggest making the libintl library an optional prerequisite
> >  of your package. This will simplify the build system of your package.
> >- Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone
> >  as well.
> >
> > This point came up while discussing with Eric Gallager, who is working on
> > the GCC configury.
> >
> > I don't volunteer to implement this suggestion, but I can give advice where
> > needed.
> >
> > Bruno
> >
> >
> >
>

Re: Wants to contribute!!

[David Edelsohn via Gcc]

On Tue, Jul 5, 2022 at 3:32 AM Aman Jha via Gcc  wrote:
>
> Hii,
>
> I wants to contribute in gcc, i have contributed in some good open source
> project like Libreoffice.
>
> I have good knowledge of c++ and git I am still learning c++ and want to
> contribute.
>
> I also participated in hactoberfest and contributed in various open source
> project.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

David Malcolm has written a wonderful introduction to GCC for newcomers:
https://gcc-newbies-guide.readthedocs.io/en/latest/

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

>
> Regards,
> Aman Jha

Re: Rust front-end

[David Edelsohn via Gcc]

On Mon, Jun 27, 2022 at 10:52 AM Philip Herron
 wrote:
>
> Hi everyone,
>
> Since November 2020, I've worked full-time on the Rust front-end for
> GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
> am writing to this mailing list to seek feedback from the collective
> experience here early to plan a path for upstreaming the front-end
> into GCC.
>
> 1. What is the actual process of merging a prominent feature like this 
> upstream
>   - How do we review this?
>   - Do we create a "mega-commit" patch
>   - How long should we expect this review process to take
>   - Is there anything we can do to make this easier?
>
> 2. What sort of quality does the GCC community expect?
>   - I think it is essential that we can compile valid test cases from
> a testsuite and real projects before merging.
>   - It seems reasonable that our error handling may not be 100% but be
> expected to improve over time
>   - Upon merging, can features like Rust be marked as experimental
>
> 3. How do GCC releases work?
>   - If you miss a window can we still merge code into the front-end?
>   - Can we merge without a borrow checker and backport this in the future?
>
> 4. What about the possibility of merging sooner rather than later,
> which would help the project gain interest through the increased
> visibility of it as part of the GCC family.
>   - Does this still allow for development churn, or will it cause friction?
>
> 5. Does anyone have prior experience or advice they could give us?
>
> For some context, my current project plan brings us to November 2022
> where we (unexpected events permitting) should be able to support
> valid Rust code targeting Rustc version ~1.40 and reuse libcore,
> liballoc and libstd. This date does not account for the borrow checker
> feature and the proc macro crate, which we have a plan to implement,
> but this will be a further six-month project.
>
> Regarding patch management, we currently do our development on GitHub:
> https://github.com/Rust-GCC/gccrs; this means we can integrate our
> issue tracking with the official Rust project by linking back to the
> official Rust project's RFC issues, for example. The downside is that
> when someone uses our compiler and hits an ICE, they will be directed
> to the GCC Bugzilla, which is correct but can lead to a mismatch in
> issue tracking. Nevertheless, I think it's essential to have the
> GitHub link here to integrate with the broader Rust community. I
> believe we can triage Rust issues on the Bugzilla and raise associated
> ones on Github to manage this.
>
> From my perspective as the lead on this front-end, we are currently
> under heavy development, so this means a fair amount of code churn
> still, and I don't see this changing until we can successfully compile
> the libcore crate later this year. Although I would love to see us
> merged into GCC 13, I want to make sure this project is a success for
> everyone, and this might mean pushing back to the next release window
> to make sure this is manageable to produce a quality front-end to sit
> alongside the others.
>
> I wish to thank you those in the GCC developer community, who have
> inspired me and helped me navigate my journey to this point in time.
>
> - Thomas Schwinge
> - Mark Wielaard
> - Tom Tromey
> - Ian Lance Taylor
> - David Edelsohn
> - David Malcolm
> - Martin Jambor

Congratulations! The GCC Steering Committee has voted to accept the
contribution of the Rust Frontend (aka GCC Rust) to GCC.  Please work
with the GCC Global Reviewers and GCC Release Managers for technical
review and technical approval of the patches.  We look forward to
including a preliminary, beta version of GCC Rust in GCC 13 as a
non-default language.

Thanks, David

Re: Inquiry: Country of Origin for gfortran

[David Edelsohn via Gcc]

Should this question be posed to the Linux distribution that NASA is using?

Thanks, David

On Sun, Jul 17, 2022 at 4:56 AM Thomas Koenig via Gcc  wrote:
>
> Hi Cynthia,
>
>  > Hello, my name is Cynthia and I am a Supply Chain Risk Management
>  > Analyst at NASA. NASA is currently conducting a supply chain
>  > assessment of gfortran. As stated in Sections 208 and 514 of the
>  > Consolidated Appropriations Act, 2022, Public Law 117-103,
>  > enacted March 15, 2022, a required step of our process is to
>  > verify the Country of Origin (CoO) information for the
>  > product (i.e., the country where the products were developed,
>  > manufactured, and assembled.)
>
>  > As gfortran is open source, we understand that this inquiry is
>  > not directly applicable, as contributions may be made from
>  > individuals from around the world. In this case, NASA is
>  > interested in confirming the following information:
>
>  > 1.  Is there an organization which sponsors/publishes the project, or
>  > a primary developer who audits the code for potential
> vulnerabilities, > errors, or malicious code? Y/N
>
> gfortran is not an independent project, it is part of the Gnu Compiler
> Collection, https://gcc.gnu.org/ .  As such, any evaluation you
> may already have made of gcc also should also apply to gfortran,
> and I am also addressing this mail to the gcc mailing list, where
> it is more appropriate, especially since I personally am unclear
> about the current relationship with the Free Software Foundation.
>
> Regarding gfortran specifically:  Code changes are reviewed by
> the individuals listed in the file
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=MAINTAINERS;hb=HEAD
>
> (where you can search for Fortran).
>
>  > 2.  Does gfortran have an overseeing organization or individual
>  >   along these lines? Y/N
>
> See my previous reply.
>
>  > 1.  If so, please provide the name of the organization and country
>  > they are established in
>
>  > If the information above is unknown or cannot be provided, we
>  > request that you provide the country or list of countries where
>  > the majority of contributions originate from to satisfy Sections
>  > 208 and 514 of the Consolidated Appropriations Act, 2022, Public
>  > Law 117-103, enacted March 15, 2022.
>
> Main contributions to gfortran, i.e. the Fortran front end to gcc and
> its supporting library, came (in no particular order) from the UK, the
> US, France, Finland, Germany, the Netherlands and the Czech Republic.
> Up to 2006, there were also some contributors from China.
>
> Best regards
>
> Thomas
>

Marc Poulhies appointed Ada co-maintainer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Marc Poulhies as Ada co-maintainer.

Please join me in congratulating Marc on his new role.

Marc, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: State of AutoFDO in GCC

[David Edelsohn via Gcc]

On Tue, Jul 26, 2022 at 4:13 PM Eugene Rozenfeld via Gcc
 wrote:
>
> Hello GCC community.
>
> I started this thread on the state of AutoFDO in GCC more than a year ago. 
> Here is the first message in the thread: 
> https://gcc.gnu.org/pipermail/gcc/2021-April/235860.html
>
> Since then I committed a number of patches to revive AutoFDO in GCC:
>
> Fix a typo in an AutoFDO error 
> string
> Update gen_autofdo_event.py and 
> gcc-auto-profile.
> Fixes for AutoFDO 
> tests
> Fix indir-call-prof-2.c with 
> AutoFDO
> Fixes for AutoFDO 
> testing
> Fix indirect call inlining with 
> AutoFDO
> Improve AutoFDO count propagation 
> algorithm
> AutoFDO: don't set param_early_inliner_max_iterations to 
> 10.
> AutoFDO: Don't try to promote indirect calls that result in recursive direct 
> calls
> Fix profile count maintenance in vectorizer 
> peeling.
>
> I also made a number of fixes and improvements to create_gcov tool in 
> https://github.com/google/autofdo .
>
> AutoFDO in GCC is in a much better shape now.
>
> I have a further set of patches that improve DWARF discriminator support in 
> GCC and enable AutoFDO to use discriminators. It's based on commits in an old 
> Google vendor branch as described in Andi's mail below
> but uses a different approach for keeping track of per-instruction 
> discriminators.
>
> I submitted the first (and the biggest) of these patches almost 2 months ago 
> on June 2: 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5af22024f62f1f596a35d3c138d41d47d5697ca0
> but only got a review from Andi 
> (https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596549.html) who is not 
> allowed to approve patches for commit. I pinged gcc-patches twice with no 
> success.
>
> I would appreciate help in getting a review on this patch so that I can get 
> it committed and submit patches that depend on it.

Hi, Eugene

Thanks for your efforts to fix and improve AutoFDO in GCC.  I believe
that part of the difficulty with obtaining a review of the patches is
that the original authors have dispersed and no one in the GCC
community officially is the maintainer for the feature.  Because you
seem to be one of the primary users and developers, would you be
interested to take on the responsibility of maintaining the
AutoFDO-specific portions of the code, with guidance and mentorship
from other GCC maintainers, especially the ones responsible for gcov
and PDO?

Thanks, David

>
> Thank you,
>
> Eugene
>
> -Original Message-
> From: Andi Kleen 
> Sent: Monday, May 10, 2021 10:21 AM
> To: Joseph Myers 
> Cc: Jan Hubicka ; gcc ; Eugene Rozenfeld 
> 
> Subject: [EXTERNAL] Re: State of AutoFDO in GCC
>
> On Mon, May 10, 2021 at 04:55:50PM +, Joseph Myers wrote:
> > On Mon, 10 May 2021, Andi Kleen via Gcc wrote:
> >
> > > It's difficult to find now because it was a branch in the old SVN
> > > that wasn't converted. Sadly the great git conversion was quite lossy.
> >
> > All branches and tags, including deleted ones, were converted (under
> > not-fetched-by-default refs in some cases); the git repository has
> > everything that might plausibly be useful, omitting only a few things
> > that would have been meaningless to convert, such as mistaken branch
> > creations in the root of the repository and the SVN hooks directory.
> > Use "git ls-remote git://gcc.gnu.org/git/gcc.git" to see the full list
> > of over 5000 refs available in the repository (or do a clone with
> > --mirror to fetch them all).
>
> Okay thanks. I don't see them in any of the web interfaces, neither on
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fgit%2Fgitweb.cgi%3Fp%3Dgcc.git&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7C9d79b87018f24bcbf8cc08d913d80bd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562640903545786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ts53XULDtR3o7fevlntCJdtzRqTo9R85LrxJ0ZfOBnE%3D&reserved=0
> nor on
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgcc-mirror%2Fgcc&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7

Indu Bhagat and David Faust appointed CTF and BTF Reviewers

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Indu Bhagat and David Faust as CTF and BTF Reviewers.

Please join me in congratulating Indu and David on their new role.

Indu and David, please update your listings in the MAINTAINERS file.

Happy hacking!
David

Eugene Rozenfeld appointed AutoFDO maintainer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Eugene Rozenfeld as AutoFDO maintainer.

Please join me in congratulating Eugene on his new role.

Eugene, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: Reproducible builds - supporting relative paths in *-prefix-map

[David Edelsohn via Gcc]

On Mon, Aug 15, 2022 at 10:28 AM Richard Purdie via Gcc  wrote:
>
> On Mon, 2022-08-15 at 12:13 +0100, Richard Purdie via Gcc wrote:
> > Hi,
> >
> > I'm wondering if we'd be able to improve path handling in the -f*-
> > prefix-map compiler options to cover relative paths?
> >
> > Currently it works well for absolute paths but if a file uses a
> > relative path or a path with a symlink in, or a non-absolute path, it
> > will miss those cases. For relative paths in particular it is
> > problematic as you can't easily construct a compiler commandline that
> > would cover all relative path options.
> >
> > At first glance this is relatively straight forward, for example:
> >
> > Index: gcc-12.1.0/gcc/file-prefix-map.cc
> > ===
> > --- gcc-12.1.0.orig/gcc/file-prefix-map.cc
> > +++ gcc-12.1.0/gcc/file-prefix-map.cc
> > @@ -70,19 +70,25 @@ remap_filename (file_prefix_map *maps, c
> >file_prefix_map *map;
> >char *s;
> >const char *name;
> > +  char *realname;
> >size_t name_len;
> >
> > +  realname = lrealpath (filename);
> > +
> >for (map = maps; map; map = map->next)
> > -if (filename_ncmp (filename, map->old_prefix, map->old_len) == 0)
> > +if (filename_ncmp (realname, map->old_prefix, map->old_len) == 0)
> >break;
> > -  if (!map)
> > +  if (!map) {
> > +free (realname);
> >  return filename;
> > -  name = filename + map->old_len;
> > +  }
> > +  name = realname + map->old_len;
> >name_len = strlen (name) + 1;
> >
> >s = (char *) ggc_alloc_atomic (name_len + map->new_len);
> >memcpy (s, map->new_prefix, map->new_len);
> >memcpy (s + map->new_len, name, name_len);
> > +  free (realname);
> >return s;
> >  }
> >
> > which address a realpath() call into the prefix mapping code. I did
> > experiment with this and found it breaks compiling ruby and xen-tools
> > which both have code which does:
> >
> > #include __FILE__
> >
> > It may be possible to make the remapping conditional of not being
> > directly in a #include statement but I didn't find the gcc code
> > responsible for that as yet. I also noticed some valgrind tests fails
> > after it, I've not looked into why that would be yet.
> >
> > I wanted to ask if there would be any interest in adding support for
> > something like this? I suspect the include/__FILE__ issue is probably a
> > latent bug anyway. If anyone has any pointers to the code I could
> > improve my patch with I'm also happy to have them!
>
> To answer my own question, something like:
>
> +Index: gcc-12.1.0/libcpp/macro.cc
> +===
> +--- gcc-12.1.0.orig/libcpp/macro.cc
>  gcc-12.1.0/libcpp/macro.cc
> +@@ -563,7 +563,7 @@ _cpp_builtin_macro_text (cpp_reader *pfi
> +   if (!name)
> + abort ();
> + }
> +-  if (pfile->cb.remap_filename)
> ++  if (pfile->cb.remap_filename && !pfile->state.in_directive)
> + name = pfile->cb.remap_filename (name);
> +   len = strlen (name);
> +   buf = _cpp_unaligned_alloc (pfile, len * 2 + 3);
>
> seems to do roughly what I was wondering about.
>
> I'd be interested to understand whether some patch along the lines I've
> mentioned here would stand a chance of being accepted or not.

Thanks for recognizing this issue and proposing a solution.  It's
probably more effective to submit this as an actual patch to
gcc-patches and cc David Malcolm, libcpp maintainer, than to ask
hypotheticals on the GCC mailing list.

Thanks, David

The GNU Toolchain Infrastructure project

[David Edelsohn via Gcc]

Carlos O'Donell and I are proud to announce and provide more detail about
the GNU Toolchain Infrastructure project.

https://sourceware.org/pipermail/overseers/2022q3/018896.html

Thanks, David

Re: The GNU Toolchain Infrastructure project

[David Edelsohn via Gcc]

On Tue, Sep 27, 2022 at 4:05 PM David Edelsohn  wrote:

> Carlos O'Donell and I are proud to announce and provide more detail about
> the GNU Toolchain Infrastructure project.
>
> https://sourceware.org/pipermail/overseers/2022q3/018896.html
>
> Thanks, David
>

The minutes from the first GTI TAC meeting, the slides of the LF IT
presentation, and the video recording of the meeting have been published on
the GNU LIBC website:

https://sourceware.org/pipermail/libc-alpha/2022-September/142288.html

Thanks, David

Re: gcc-bug in gcc-11

[David Edelsohn via Gcc]

On Tue, Oct 4, 2022 at 12:18 PM Shivam Rajput via Gcc 
wrote:

> Hey, I was trying to build clang's libcxx on my ubuntu 22.04 and it has
> gcc-11.2 by default most prolly, but while building libcxx there was an
> error about using the deleted function but it seems that overloaded
> resolution in gcc-11 has a bug https://godbolt.org/z/GPTPYaobb , it
> consider wrong overloaded function , although i build libcxx using gcc-12 .
>

Thanks for alerting us to the issue.  Please use the process described at
the following link to report bugs.

https://gcc.gnu.org/bugs/

Thanks, David

Re: Question regarding copyright assignment

[David Edelsohn via Gcc]

On Thu, Oct 6, 2022 at 8:58 PM Antoni Boucher via Gcc 
wrote:

> Hi.
> I contribute to gcc outside of work, but I'm about to sign a new work
> contract which contains a work ownership clause saying that I give the
> ownership to the company of any work not listed in some appendix.
>
> What exactly should I list to make sure my contributions to GCC are not
> affected by this?
> Do I need to do something more than this to make sure there are no
> issues with the FSF copyright assignment?
>
>
We cannot provide legal advice, employment advice or labor advice.

One option is for you to contribute through a copyright assignment by your
company or DCO authorized by your company.  Another option is to enumerate
FOSS projects in your employment agreement, if your company and hiring
manager will permit that.  The term GCC (GNU Compiler Collection) is
interpreted to include the compiler and all components, including runtime
libraries.  You also might consider listing GLIBC, GDB and BINUTILS for
completeness and potential overlap.  Those four components are the terms
used for Free Software Foundation copyright assignment forms and in the FSF
file listing copyright assignments.

Thanks, David

Re: How to get started with the contribution

[David Edelsohn via Gcc]

On Wed, Oct 12, 2022 at 1:43 AM zunzarrao deore via Gcc 
wrote:

> Respected Sir/ Mam ,
> I am Zunzarrao Deore, a computer science undergrad. I have just entered my
> second year at D.Y. Patil college of engineering, Pune. I am new to open
> source contribution but I am well aware of programming languages like C++,
> Python, html and CSS also I have moderate  knowledge of Data Structures and
> Algorithms.
> I would like to contribute to your organizations but could you tell me how
> to get started ?
> Hoping to hear from you soon.
>

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

David Malcolm has written a wonderful introduction to GCC for newcomers:
https://gcc-newbies-guide.readthedocs.io/en/latest/

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David


> Regards
> Zunzarrao.
>

Toolchain Infrastructure project statement of support

[David Edelsohn via Gcc]

We're excited to post a statement of support for the direction we're moving
with the infrastructure for the GNU Toolchain:
https://sourceware.org/pipermail/overseers/2022q4/018981.html We look
forward to supporting the GTI TAC and community to work through the
technical details of the proposal to use LF IT services.

Thanks,
David and Carlos

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

Re: Interested to contribute!

[David Edelsohn via Gcc]

On Mon, Oct 24, 2022 at 4:57 PM StreetCodeC - via Gcc 
wrote:

> Hi!
> I am interested in contributing to GCC but I am fairly new to this project
> and wish for some heads up and guidance about how to start working! Please
> help me understand where are the 'issues' and source code.
> Regards,
> Aman.
>

Hi, Aman

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

David Malcolm has written a wonderful introduction to GCC for newcomers:
https://gcc-newbies-guide.readthedocs.io/en/latest/

and browse other recent answers to similar questions in the archives
of this mailing list.


Thanks, David

Re: GCC 13 bootstrap failure on i686-w64-mingw32

[David Edelsohn via Gcc]

Yes, AIX as well.

Thanks, David

On Sun, Nov 20, 2022 at 2:18 PM Jonathan Wakely via Gcc 
wrote:

> This fails on macOS too (and probably everything non-gnu).
>
> On Sun, 20 Nov 2022, 12:36 LIU Hao via Gcc,  wrote:
>
> > This is caused by 2efb237ffc68ec9bb17982434f5941bfa14f8b50, which has
> > references to `strchrnul`,
> > which does not exist on i686w-64-mingw32:
> >
> >```
> >g++ -std=c++11  -fno-PIE -c  -DIN_GCC_FRONTEND -g -D__USE_MINGW_ACCESS
> > -DIN_GCC
> > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> > -Wno-narrowing -Wwrite-strings
> > -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
> > -pedantic -Wno-long-long
> > -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Icp
> > -I../../gcc/gcc
> > -I../../gcc/gcc/cp -I../../gcc/gcc/../include
> > -I../../gcc/gcc/../libcpp/include
> > -I../../gcc/gcc/../libcody -I/mingw32/include -I/mingw32/include
> > -I/mingw32/include
> > -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
> > -I../libdecnumber
> > -I../../gcc/gcc/../libbacktrace -I/mingw32/include
> > -D__USE_MINGW_ANSI_STDIO=1 -I/mingw32/include -o
> > cp/error.o -MT cp/error.o -MMD -MP -MF cp/.deps/error.TPo
> > ../../gcc/gcc/cp/error.cc
> >../../gcc/gcc/cp/contracts.cc: In function 'bool role_name_equal(const
> > char*, const char*)':
> >../../gcc/gcc/cp/contracts.cc:213:21: error: 'strchrnul' was not
> > declared in this scope; did you
> > mean 'strchr'?
> >  213 |   size_t role_len = strchrnul (role, ':') - role;
> >  | ^
> >  | strchr
> >make[3]: *** [Makefile:1146: cp/contracts.o] Error 1
> >make[3]: *** Waiting for unfinished jobs
> >```
> >
> >
> > Proposed solution:
> >
> >```
> >size_t role_len = strcspn (role, ":");
> >```
> >
> >
> >
> > --
> > Best regards,
> > LIU Hao
> >
>

Gaius Mulley appointed Modula-2 front-end maintainer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Gaius Mulley as Modula-2 front-end maintainer.

Please join me in congratulating Gaius on his new role.

Gaius, please update your listings in the MAINTAINERS file.

Happy Holidays!
Happy hacking!
David

Philip Herron and Arthur Cohen appointed Rust front-end maintainers

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Philip Herron and Arthur Cohen as Rust front-end maintainers.

Please join me in congratulating Philip and Arthur on their new role.

Philip and Arthur, please update your listings in the MAINTAINERS file.

Happy holidays!
Happy hacking!
David

Apology to Dr. Elena Zannoni

[David Edelsohn via Gcc]

At GNU Cauldron 2022 during the GNU Toolchain Infrastructure BoF session I
displayed inappropriate and uncharacteristic behavior towards Dr. Elena
Zannoni. Because I realized that my behavior was inappropriate, I
proactively apologized to Dr. Zannoni during a conversation immediately
after the BoFs.  She graciously accepted my apology and responded
that everything was okay.

I wish to reiterate my apology publicly to her. I am sorry if the incident
might have caused anyone discomfort at the event, or about GNU Cauldron or
the GNU Toolchain community.  I will be more careful in the future.

Happy Holidays and Happy New Year,
David

Re: Stepping down as gcov maintainer and callgraph reviewer

[David Edelsohn via Gcc]

On Thu, Feb 16, 2023 at 10:54 AM Martin Liška  wrote:

> Hello GCC community.
>
> After spending last decade (including my diploma thesis even more)
> of my life working on GCC, I decided to leave the project and try
> a different job. I would like to thank all the community members I had
> change to interact with, I learned so much and enjoyed the journey!
> I'll be leaving somewhen at the beginning of May.
>
> That said, I'm stepping down from my 2 positions as I won't have a time
> for proper patch review and bugs in the area I'm responsible for.
>
> I wish the project all the best!
>

Hi, Martin

Thank you very much for your great work on GCC over the past years.  Your
excellent technical contributions to GCC and to the development environment
behind the scenes have helped create and maintain a world-class toolchain
that powers the world.

Wishing you much success in the next steps of your career and I eagerly
await to see the tremendous impact where you choose to apply your skills
next.

Thanks, David

Re: #include cobol

[David Edelsohn via Gcc]

On Mon, Feb 27, 2023 at 10:13 AM James K. Lowden 
wrote:

> To the GCC community and GCC Steering Committee:  Greetings!
>
> We at COBOLworx would like GCC to consider our gcobol front-end for
> inclusion in the GCC project.  We would like to contribute it to the
> GNU Toolchain and have it merged into GCC.
>
> We believe our work is further along than any previous GCC Cobol
> effort.  As you may know, we have been working on the project for over
> a year. Much of the last 9 months have been devoted to testing for
> correctness.  The compiler now passes the core module of the NIST
> CCVS-85 test suite.  Although not ready for production use by any
> means, we expect to pass all relevant aspects of CCVS-85 later this
> year.
>
> Old as it is, Cobol is far from dead.  Estimates run into billions of
> lines written, with millions more added each year, even today.  But --
> because there has never been a free, fully functional,
> source-to-machine compiler for it -- Cobol remains largely locked
> behind expensive, proprietary walls.  GCC can change that.
>
> Cobol also offers a window into what was and might yet be.  In Seibel's
> "Coders at Work", Fran Allen put it this way:
>
> "There was a debate between Steve Johnson, of Bell Labs, who
> were supporting C, and one of our people, Bill Harrison  The nubbin
> of the debate was Steve's defense of not having to build optimizers
> anymore because the programmer would take care of it."
>
> and
>
> "By 1960, we had a long list of amazing languages: Lisp, APL,
> Fortran, COBOL, Algol 60.  These are higher-level than C.  We have
> seriously regressed since C developed."
>
> Modern hardware, and GCC's 100 optimization passes, are evidence Fran
> Allen was right.  Cobol, with its 2 dozen high-level verbs and
> integrated I/O, provides a theoretical opportunity to surpass even C's
> performance in its problem domain, because the compiler has more
> information and more leeway.
>
> As a technical matter, to be sure we are far from achieving that goal.
> It is, as I said, an opportunity.  As we hone our skills, we look
> forward to learning together with others to make it a reality.
>
> Signed,
>
> Marty Heyman, James K. Lowden, Robert Dubner
>

The GCC Steering Committee has approved GCobol as a new front-end for the
GNU Compiler Collection.  Congratulations!

This is the administrative approval.  The initial patches must be
technically approved by a GCC Global Reviewer.  Please coordinate this with
the GCC Global Reviewers and Release Managers for the next or future Stage
1 development cycle.

GCC welcomes support for new languages. COBOL is an important but niche
language in 2023.  GCobol will not be a primary language that is considered
critical for a GCC Release, and if GCobol becomes a maintenance burden, the
GCC SC and community may revisit support for COBOL.

We look forward to COBOL support in a future release of GCC.

Thanks, David

Re: More C type errors by default for GCC 14

[David Edelsohn via Gcc]

On Tue, May 9, 2023 at 8:16 AM Florian Weimer via Gcc 
wrote:

> TL;DR: This message is about turning implicit-int,
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.
>
> A few of you might remember that I've been looking into turning some
> type errors from warnings into errors by default.  Mainly I've been
> looking at implicit function declarations because in too many cases, the
> synthesized declaration does not match the prototype used at function
> definition and can cause subtle ABI issues.
>
> To recap, the main challenge is that GCC has to serve disparate groups
> of users: some use GCC for writing programs themselves, but others just
> need GCC to build sources that they have obtained from somewhere.  The
> first group benefits from more type errors because they catch errors
> earlier during development (experience shows that compiler warnings are
> easy to miss in a long build log).  The second group might find these
> errors challenging because the sources they have no longer build.
>

Hi, Florian

Thanks for working on this and proposing this.

Yes, GCC has two, distinct user groups / use cases, but GCC also has a very
unique and crucial role, as the foundation for a large portion of the
GNU/Linux and FOSS software ecosystem.  This proposal is missing a
motivation for this change, especially making new errors the default.

GCC needs to be proactive, not reactive, without annoying and frustrating
its user base.  Clang has been making some aggressive changes in warnings,
but its constituency expects that.  Developers who want that experience
already will use Clang, so why annoy developers who prefer the GCC
experience and behavior?  The new warnings and errors help some developers
and improve software security, but also drive some developers away, or at
least cause them to reass their choice of toolchain.

Maybe we need additional front-end aliases "gcclang" and "gcclang++" for
GCC to provide an experience more like Clang for those who desire that.
GCC isn't Clang and I fear that GCC is going down a path that annoys and
frustrates both user groups -- it's not sufficiently aggressive for those
who prefer Clang and it's too aggressive for those who wish backward
compatibility.

Thoughts?

Thanks, David


>
> To see how large the impact is on that second group, we've mostly
> removed implicit function declarations and implicit ints from Fedora:
>
>   
>   
>
> Roughly 870 packages out of ~14,500 that have GCC present during the
> build needed fixing (or flagging that they can't be built with the
> additional errors), so 6%.  Most of the changes are mechanical in
> nature, like adding additional headers to configure checks.  For about
> ~150 packages, automated patching could be used to rewrite problematic
> built-in checks generated by long-obsolete autoconf versions.
>
> Some of these changes prevent the compiler behavior for altering the
> build results silently because the new errors changed the outcome of
> autoconf checks.  (We had one of those in libstdc++, changing the ABI on
> GNU/Linux because futex support oculd no longer be detected.)
> Unfortunately, I did not record numbers about them, but think those were
> quite rare; most autoconf problems were also accompanied with other
> problems, or the incorrect results from autoconf led to build failures
> later.  So it seems to me that the risk that the second group mentioned
> above would silently get unexpected build results is fairly low.
>
> Where possible, we tried to upstream patches, to simplify sharing across
> distributions and to help those who compile upstream sources directly.
> We also benefited from other distributions upstreaming changes along
> similar lines (notably Gentoo for their Clang 16 project, but also from
> Homebrew to a lesser extent).
>
> An area we started exploring only recently for Fedora is implicit
> conversions between integers and pointers (covered by -Wint-conversion).
> These add another ~170 packages, but some of those are false positives
> (due to our instrumented compiler approach) that do not change the build
> outcome at all.  I'm still negotiating whether we have the capacity to
> develop fixes for these packages proactively.
>
> I brought up the matter with distributions, and the feedback was neutral
> (not overly negative, as in “this would be the end of the world for
> us”).
>
>   <
> https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390
> >
>   
>   <
> https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J
> >
>
> (I tried to contact Arch, but my message didn't make it past the
> moderators, it seems.)
>
> All in all, the whole situation is not great, but it still seems
> manageable