Re: Remove RMS from the GCC Steering Committee

[Nathan Sidwell]

Ian,
thank you for taking the time to write this.  I appreciate that you have 
reached out.  I do have a couple of comments though.


On 4/1/21 3:19 PM, Ian Lance Taylor wrote:

On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell  wrote:



I think you want the steering committee to issue a statement about
RMS's behavior.  I think that is approximately as likely as collecting
the GCC maintainers together to issue a statement about RMS's
behavior.  It's not impossible.  But it's not something anybody is
really trying to do.


And that speaks volumes.  The one thing we have in the form of structure 
is not trying to do that thing.



Going back to the GCC steering committee, you make several accusations
(I think that is a fair word to use here).  Again I'm going to give my
own personal reactions.  I'm telling the truth to the best of my
recollection, but I can't prove what I say.


That's understandable.

  /You/ gave him controlling rights.


No, we didn't.  The pattern of his interactions with the steering
committee, which were infrequent, was that he would ask us to do
something, and we would explain why we were not going to do that.


The appearance is that the SC did.  Another event that I've now 
remembered concerns powerpc floating point.  My understanding is that 
RMS vetoed something, and an SC member reached out to me, as if the 
personal interactions of another SC member was something I could 
control.  If RMS had no power, that conversation need not have happened.



Sorry, I don't quite understand this one.  It's not clear to me how
the committee misled anyone.


by observable behaviour, including the listing on the web page -- who 
other than the SC could tell it was incorrect?  (perhaps you're 
associating intent with 'misled'?  I'm associating 'impact')


You're quite likely right about the timing of the C++ change, but the 
earlier interaction caused damage.



2) Last year, I asked for libcody to be added as a subcomponent, with
its Apachev2 license intact.  AFAICT RMS was involved in that licensing
discussion, /for which I never received a response/.  He was not at the
FSF then, so he could not render any FSF licensing opinion.  Why was he
involved?  If he was not involved, how did he learn of it in order to
ask me questions about C++ modules?  I only emailed the SC and the
timing is too coincidental to draw a different conclusion.


Yes, we definitely dropped the ball on that.  Sorry.  If that ever
happens again I would encourage you to ping.

I checked the mailing list archives.  Jeff and I expressed support for
using libcody.  Nobody else said anything.  Certainly RMS didn't say
anything, and it would have been astonishing if he had.  But, yes, he
was CC'ed.


I've realized what happened was that I very quickly received an email 
saying just 'looks good to me'.  Which didn't read like an SC blessing 
at all.  I thought it was just personal comment.   You're right, I 
should have pinged, but one reason I didn't was because I was concerned 
RMS would veto the whole shebang.  Don't poke the sleeping bear.   Fault 
all round.


nathan
--
Nathan Sidwell

Re: Default debug format for AVR

[Jim Wilson]

On Sat, Apr 3, 2021 at 6:24 PM Simon Marchi via Gcc  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

Re: Default debug format for AVR

[Simon Marchi via Gcc]

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.

Simon

My GSoC proposal for the Rust frontend

[PKU via Gcc]

It’s about improving compiler dumps for the Rust frontend. Full proposal here: 
https://docs.google.com/document/d/1gyAOM-f3RyZh3HVpjmIMDSuQ5gBscal71sFY6XUMcHI/edit#

Yizhe