[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (April 8, 201)

[吴伟]

Hi all,

There is the agenda for tomorrow's meeting. If you have topics to
discuss or share, please let me know and I can add them to the agenda.

## Agenda:
- Nelson prepares patches for integration branch, first version will
include zfh 0.1, v-ext 0.10 and sifive cache operation extension
  https://sourceware.org/pipermail/binutils/2021-March/115979.html
- github/riscv/riscv-glibc is archived now.
- github/riscv/riscv-gnu-toolchain has bumped qemu 5.2.0, glibc 2.33
and kernel header to 5.10
- Status update for RISC-V K, B, P, V, and Zfinx/Zce extensions.
- AOB

https://calendar.google.com/calendar/ical/lm5bddk2krcmtv5iputjgqvoio%40group.calendar.google.com/public/basic.ics

BEIJING, China
11:00pThu, Apr 8 2021 12:00aFri, Apr 9 2021

PDT/PST, Pacific Daylight Time (US)
8:00aThu, Apr 8 2021 9:00aThu, Apr 8 2021

LONDON, United Kingdom, England
4:00pThu, Apr 8 20215:00pThu, Apr 8 2021

Join Zoom Meeting
https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09

Meeting ID: 893 9360 0951
Passcode: 899662

Find your local number: https://zoom.com.cn/u/kWo4yMmVQ

-- 
Best wishes,
Wei Wu (吴伟)

GSoC 2021 - Bridging the gap between rustc and gccrs

[Arthur Cohen via Gcc]

Hi everyone,

It is my pleasure to announce that I will be applying for the Google Summer
of Code in order to work under the Rust-GCC organization.

I am a french systems programming and embedded systems programming student,
and love to work on anything related to the compilation or interpretation
of programming languages.

I would love for gccrs to become a solid alternative to rustc. I believe
that multiple compilers are a necessity for the language to grow and to be
available on more platforms. For that, I believe that it is important for
gccrs to be usable with Rust's build system, cargo. The subject of my GSoC
would therefore be to help make gccrs available under cargo, and make it
available for the compilation of small Rust projects.

With the help of Philip Herron, I have established the following proposal:
https://docs.google.com/document/d/1oUcpU-kGntdQ6FLfSVPP8co3TDJgcdEK2FmvdinlaNc/edit

Feel free to leave any comments or suggestions and I'll do my best to apply
them.

Kind regards,

Arthur Cohen

Re: GCC association with the FSF

[David Malcolm via Gcc]

On Wed, 2021-04-07 at 00:22 +0200, Mark Wielaard wrote:
> Hi,
> 
> Lets change the subject now that this is about GCC and the FSF.
> 
> On Wed, Mar 31, 2021 at 01:46:29PM +0100, Jonathan Wakely via Gcc
> wrote:
> > Probably unintentionally, but he has allowed the GNU Project to
> > become
> > a nasty cult of personality. The FSF seems to be imploding (with
> > mass
> > resignations in the past week). I don't think GCC benefits from
> > being
> > associated with either of them.
> 
> I admit it isn't looking very good and their last announcement is
> certainly odd: https://status.fsf.org/notice/3833062
> 
> But apparently the board is still meeting this week to discuss and
> might provide a better statement about the way out of this. So lets
> give them a couple more days before writing them off completely.
> 
> > Is there any incident where FSF being the copyright holder for GCC
> > has
> > made a difference?
> 
> Yes, at least in my experience it has been helpful that the FSF held
> copyright of code that had been assigned by various individuals and
> companies. It allowed the merger of GNU Classpath and libgcj for
> example. There have been various intances where it was helpful that
> the FSF could unilatrally adjust the license terms especially when
> the
> original contributor couldn't be found or didn't exist (as company)
> anymore.

This benefit arises from having a single entity own the copyright in
the code.  It doesn't necessarily have to be the FSF to gain this
benefit; it just happens that the FSF currently owns the copyright on
the code.

Another, transitional approach might be to find another Free Software
non-profit and for contributors to start assigning copyright on ongoing
work to that other non-profit.  That way there would be only two
copyright holders on the code; if the FSF somehow survives its current
death-spiral then the other nonprofit could assign copyright back to
the FSF;  if it doesn't, well, we've already got bigger problems.

> And it is really helpful that we don't have to ask permission of
> every
> individual contributor to be able to create the GCC manual (because
> the GPL code and GFDL text could otherwise not be combined) but that
> the FSF can grant an exception to one of the developers to create it.

Alternatively, the copyright holder could relicense the documentation
to a license that is explicitly compatible with the GPL, such as the
GPL itself, and not require us to jump through hoops.  (Or we could
start a non-GFDL body of documentation under a different copyright
holder, but I'm not volunteering for that effort).  In case it's not
clear, I think the GFDL is a terrible license, and that it's always a
mistake to use it for software documentation.

> > Are there any GPL violations involving GCC code
> > that were resolved only because all copyright resides with a single
> > entity, that couldn't have been resolved on behalf of individual
> > copyright holders?
> 
> I think it has been very helpful preventing those violations. If you
> only have individual copyright holders instead of an organisation
> with
> the means to actually resolve such violations people pay much more
> attention to play by the rules. See for example the linux kernel
> project. I believe there are so many GPL violations precisely because
> almost no individual has the means to take up a case.

Again, the "single entity" doesn't need to be the FSF.

> > Are we still worried about BigCorp trying to do a proprietary fork
> > of
> > GCC? Because BigCorp, OtherCorp etc. have shown that they would
> > prefer
> > to create a new toolchain from scratch rather than use GNU code.
> > And
> > if EvilCorp want to make their own proprietary compiler with secret
> > optimizations, they'll just use LLVM instead of bothering to
> > violate
> > the GPL. The work done to make it impossible to steal GCC code was
> > a
> > success: nobody is even interested in stealing it now. There is an
> > easier option.
> 
> I admit that the only way proprietary compiler writers can compete
> with GCC is by producing a lax-permissive licensed compiler is an odd
> way to win for Free Software. 
> But we should still make sure that GCC
> itself makes it so that users can actually get the sources of the
> compiler they are using and not just some sources that might or might
> not correspond to the binary they are using. Making sure that the
> code
> reaches actual users and not just some corporate hackers to create a
> proprietary compiler is what counts IMHO. And using strong copyleft
> and having a shared copyright pool of code held by an entity that can
> enforce that is still necessary IMHO.
> 
> > Can we break our (already weak) ties to GNU?

It's not clear to me to what extent "GNU" is a thing that exists.  I
agree with much of Andy Wingo's October 2019 blog post:
http://www.wingolog.org/archives/2019/10/08/thoughts-on-rms-and-gnu


IMHO, "GNU" can mean various things:
- the small family of "g"-prefixed toolchain/low-leve

Re: GCC association with the FSF

[Alfred M. Szmidt via Gcc]

   [...]  That "gnu-stucture" document was written by RMS a couple of
   months ago and doesn't represent how the GNU project and its
   maintainers have worked for years.

It reflects the same message that has been sent to new GNU maintainers
for the decades. The GNU structure and organization document
(https://www.gnu.org/gnu/gnu-structure.en.html) is basically a
reflection of that, and how we have been doing things for decades.

You can raise any issues you think do not reflect on the lists, or
with the GNU Advisory Committee.

   RMS indeed claims to be the "Chief GNUisance" of the GNU project and
   that that title somehow makes him the leader of the project and that
   he appoints GNU maintainers.

That is true, RMS appoints which projects become GNU projects or not,
and who maintains them.  And as maintainers we have a lot of freedom, as
can be seen here, and elsewhere.  

   The GNU Assembly is having a similar
   discussion right now

It should be noted that this group is not associated with the GNU
project, or represents it in anyway, despite pretending to.

Re: GCC association with the FSF

[David Malcolm via Gcc]

On Wed, 2021-04-07 at 10:51 -0400, Alfred M. Szmidt via Gcc wrote:
>    [...]  That "gnu-stucture" document was written by RMS a couple of
>    months ago and doesn't represent how the GNU project and its
>    maintainers have worked for years.
> 
> It reflects the same message that has been sent to new GNU
> maintainers
> for the decades. The GNU structure and organization document
> (https://www.gnu.org/gnu/gnu-structure.en.html) is basically a
> reflection of that, and how we have been doing things for decades.

"We've always done it this way" is not necessarily a good defence of an
existing practice.

> You can raise any issues you think do not reflect on the lists, or
> with the GNU Advisory Committee.
> 
>    RMS indeed claims to be the "Chief GNUisance" of the GNU project
> and
>    that that title somehow makes him the leader of the project and
> that
>    he appoints GNU maintainers.
> 
> That is true, RMS appoints which projects become GNU projects or not,
> and who maintains them.  And as maintainers we have a lot of freedom,
> as
> can be seen here, and elsewhere.  

What you're describing sounds like a dictatorship to me.

> 
>    The GNU Assembly is having a similar
>    discussion right now
> 
> It should be noted that this group is not associated with the GNU
> project, or represents it in anyway, despite pretending to.

I don't think you get to speak for who is or is not a member of the GNU
project.  As far as I know, "GNU" isn't trademarked.

My opinions, not my employer's, as usual
Dave

Re: GCC association with the FSF

[John Darrington]

On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc wrote:

 > It reflects the same message that has been sent to new GNU
 > maintainers
 > for the decades. The GNU structure and organization document
 > (https://www.gnu.org/gnu/gnu-structure.en.html) is basically a
 > reflection of that, and how we have been doing things for decades.
 
 "We've always done it this way" is not necessarily a good defence of an
 existing practice.

You are right.  The GNU Structure document doesn't claim to be. It just
documents the way things are.
 
 > That is true, RMS appoints which projects become GNU projects or not,
 > and who maintains them.  And as maintainers we have a lot of freedom,
 > as
 > can be seen here, and elsewhere.  
 
 What you're describing sounds like a dictatorship to me.

 I cannot see how you reach that conclusion.

 
 
 I don't think you get to speak for who is or is not a member of the GNU
 project.  As far as I know, "GNU" isn't trademarked.
 

It certainly used to be, unless those guys at the FSF have let it lapse again.

J'

Re: GCC association with the FSF

[Jonathan Wakely via Gcc]

On Wed, 7 Apr 2021 at 17:28, John Darrington wrote:
>
> On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc wrote:
>  I don't think you get to speak for who is or is not a member of the GNU
>  project.  As far as I know, "GNU" isn't trademarked.
>
>
> It certainly used to be, unless those guys at the FSF have let it lapse again.

The footnote at
https://mikegerwitz.com/2012/10/trademarks-in-free-software#fn1 gives
details.

Re: GCC association with the FSF

[Jonathan Wakely via Gcc]

On Wed, 7 Apr 2021 at 15:04, David Malcolm wrote:
> For myself, I'm interested in copyleft low-level tools being used to
> build a Free Software operating system, but the "GNU" name may be
> permanently tarnished for me; I have no wish to be associated with a
> self-appointed "chief GNUisance".  I hope the FSF can be saved, since
> it would be extremely inconvenient to have to move.

This matches my feelings. If the FSF can be saved, fine, but I don't
think GCC needs to remain associated with it.

If the GNU name is a problem, rename the projects to be simply "GCC",
"Glibc", "GDB" etc without being an initialism.

Re: GCC association with the FSF

[Jeff Law via Gcc]

On 4/7/2021 11:17 AM, Jonathan Wakely via Gcc wrote:

On Wed, 7 Apr 2021 at 15:04, David Malcolm wrote:

For myself, I'm interested in copyleft low-level tools being used to
build a Free Software operating system, but the "GNU" name may be
permanently tarnished for me; I have no wish to be associated with a
self-appointed "chief GNUisance".  I hope the FSF can be saved, since
it would be extremely inconvenient to have to move.

This matches my feelings. If the FSF can be saved, fine, but I don't
think GCC needs to remain associated with it.

If the GNU name is a problem, rename the projects to be simply "GCC",
"Glibc", "GDB" etc without being an initialism.


Speaking strictly for myself, that works for me as well and I'd support 
such a proposal.



jeff

Re: GCC association with the FSF

[Alfred M. Szmidt via Gcc]

   "We've always done it this way" is not necessarily a good defence of an
   existing practice.

That wasn't the claim, it is how we do it currently, and have been
doing for decades though.  If you have concrete suggestions, please
send them to the GNU Advisory Committee.

   >    The GNU Assembly is having a similar
   >    discussion right now
   > 
   > It should be noted that this group is not associated with the GNU
   > project, or represents it in anyway, despite pretending to.

   I don't think you get to speak for who is or is not a member of the GNU
   project.  As far as I know, "GNU" isn't trademarked.

I said that the group isn't speaking for the GNU project, nor does it
represent it.  If you want to know more, feel free reach out to the
GAC or RMS.

Re: GCC association with the FSF

[David Malcolm via Gcc]

On Wed, 2021-04-07 at 18:24 +0200, John Darrington wrote:
> On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc
> wrote:
> 
>  > It reflects the same message that has been sent to new GNU
>  > maintainers
>  > for the decades. The GNU structure and organization document
>  > (https://www.gnu.org/gnu/gnu-structure.en.html) is basically a
>  > reflection of that, and how we have been doing things for
> decades.
>  
>  "We've always done it this way" is not necessarily a good
> defence of an
>  existing practice.
> 
> You are right.  The GNU Structure document doesn't claim to be. It
> just
> documents the way things are.
>  
>  > That is true, RMS appoints which projects become GNU projects
> or not,
>  > and who maintains them.  And as maintainers we have a lot of
> freedom,
>  > as
>  > can be seen here, and elsewhere.  
>  
>  What you're describing sounds like a dictatorship to me.
> 
>  I cannot see how you reach that conclusion.

Having one guy at the top from whom all power flows.

What's the process for replacing the guy at the top, if he's become a
liability to the project?  What would a healthy structure look like?

My opinions, not my employer's, as usual
Dave

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: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm via Gcc]

On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
> Hi, apologies for the delayed reply. I was having some college
> commitments.
> On Wed, Mar 31, 2021 at 11:22 PM David Malcolm 
> wrote:
> 
> > On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> > > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <
> > > dmalc...@redhat.com>
> > > wrote:
> > > 
> > > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > > > dmalc...@redhat.com>
> > > > > wrote:
> > 

[...snip...]

> > > > Please do work on the formal proposal - without it we can't
> > > > accept
> > > > you
> > > > as a GSoC student.  The window for submitting proposals opened
> > > > yesterday, and I believe it closes in a couple of weeks, and
> > > > you
> > > > need
> > > > to do that, so any experimentation you do now should really
> > > > just be
> > > > in
> > > > support of writing a good proposal.  It would be a shame to not
> > > > have a
> > > > good prospective candidate because they didn't allow enough
> > > > time to
> > > > do
> > > > the proper GSoC paperwork before the deadline.
> > > > 
> > > Thanks for understanding. Here is an initial draft (
> > > 
> > > 
> >   
> > https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> > > )
> > > of my GSoC proposal. I am yet to fill in the missing blocks.
> > > Please, let me know if you have any comments on the document
> > > itself.
> > 
> > Caveat: I'm not familiar with the expected format of such
> > documents.
> > 
> > Looks like a good first draft.
> 
> I don't think there is any such expected format(I checked some
> previous
> years accepted proposals). I believe if we clearly write the expected
> goal
> and the tentative approach to reach it, that would be okay for the
> proposal.

Looking at:
  https://gcc.gnu.org/wiki/SummerOfCode#Application
we don't have a specific format to be followed.

That said, I saw this 
  https://google.github.io/gsocguides/student/writing-a-proposal
which seems to have useful advice to prospective GSoC students.  In
particular, the "Elements of a Quality Proposal" lists various things
that in your current draft are missing, and which would strengthen your
proposal.  So I'd recommend that you (and other prospective GSoC
candidates) have a look at that.

[...snip...]

> > - in Example 2, maybe spell out why it's a leak - when does the
> > allocated buffer stop being referenceable?
> > 
> Explained. Please let me know if you feel it has any loose ends.

I think the leak is actually at line 8, when the "catch" clause ends. 
Isn't the buffer passed into the exception-state of the thread, and
becomes live during the "catch" clause, but stops being live at the end
of the catch clause?

> 
> > - you have a simple example of a false negative; is it possible to
> > give
> > a simple example of a false positive?  (I think "new" is meant to
> > raise
> > an exception if it fails, so a diagnostics about a NULL-deref on
> > unchecked new might be a false positive.  I'm not sure)
> > 
> I tried the following example:
> 
> #include 
> #include 
> using namespace std;
> int *p;
> int* alloc() {
>    return new int;
> }
> void free() {
>    delete p;
> }

FWIW please don't create a top-level function called "free" that isn't
the C stdlib's free, it's confusing!

> int main()
> {
>    try {
>  p = alloc();
>  free();
>    } catch(...) {
>    }
>    return 0;
> }
> Please, have a look here (https://godbolt.org/z/8WvoaP67n). I believe
> it is
> a false positive, I am not sure, please confirm.

It looks like one to me.  I had a look at -fdump-analyzer-exploded-
graph and the false positive seems to be associated with the edge with
the EH flag (to the catch handler).

[...snip...]

> 
> > - "sample example programs": for "sample" did you mean to write
> > "simple" here?
> > 
> By sample examples, I meant the test cases that shall be used to
> prove the
> correctness of the patches during the course.

Isn't "sample examples" a tautology, though?  (or, at least, my
interpretation of "sample" here makes it so, I think).

> 
> > - as well as understanding code, you'll need to understand data,
> > specifically getting a feel for the kinds of control flow graphs
> > that
> > the analyzer is receiving as inputs i.e. what the analyzer "sees"
> > when
> > the user inputs various C++ language constructs; what
> > interprocedural
> > vs intraprocedural raise/try/catch situations look like, etc.
> > 
> I am in the process to understand how the analyzer works. I believe I
> have
> just got a gist of the approach being used. The gimple graph has been
> processed in a Worklist manner. We analyze each statement and add
> predecessors/successors if there is some new information coming out
> of the
> analyzed statement. 

When we process a node in the worklist, we only ever add successor
nodes, recording the next  pairs.

> For example, In the memory leak examples discussed
> her

Re: Default debug format for AVR

[Richard Biener via Gcc]

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.

it is premature.
>
>Thanks, David

Re: GCC association with the FSF

[John Darrington]

On Wed, Apr 07, 2021 at 06:34:12PM -0400, David Malcolm wrote:
 >  
 >  What you're describing sounds like a dictatorship to me.
 > 
 >  I cannot see how you reach that conclusion.
 
 Having one guy at the top from whom all power flows.

Power does not "flow" from RMS.  Since you have used a political analogy:
I think it is more akin to a constitutional monarchy.
 
 What's the process for replacing the guy at the top, if he's become a
 liability to the project?  What would a healthy structure look like?

Many countries have a single person as head of state with no formally
defined process for replacing him or her.   Most of those countries are not
usually descibed as "dictatorships".

Further, history has shown,  in cases where that head of state has been
forcibly removed (eg France, Russia). the regime that replaced them turned
out to be composed of murderous powermongers concerned with nobody's interest
but their own.   I for one, will not sit back and let that heppen to GNU.

J'