Re: Question about git: merging to gccgo branch

[Martin Liška]

On 3/30/20 7:54 PM, Joseph Myers wrote:

Email sending for user branches makes perfect sense, to make visible the
development going on.


If so, can we then come up with a naming convention that will block the email
sending. I mean something like me/PR123456-fix-that-private?
I see the limitation really baseless.

Martin

Re: Blog post about static analyzer in GCC 10

[Andrew Stubbs]

On 26/03/2020 22:30, David Malcolm via Gcc wrote:

I wrote a blog post "Static analysis in GCC 10" giving an idea of the
current status of the -fanalyzer feature:
https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/

At some point I'll write up the material for our changes.html page.


This is some very cool stuff! :-)

It's too bad that tmux has been hiding this from me up to now. Fingers 
crossed for an implementation soon.


Just one thing that ought to be fixed before GCC 10 though: the URL for 
the -Wanalyzer-double-free option points to the wrong documentation 
page. It points to Warning-Options.html when it should be 
Static-Analyzer-Options.html.


I expect you knew that already. I'll shut up now.

Andrew

GSoC

[Yerassyl Sagynov]

Hi there! I would like to choose a project called “Parallelize compilation
using threads, part two”. My first programming language was C++ at school.
I used it for competitive programming. Later in university I have improved
this skill by taking courses related to C/C++. Precisely, Programming 1
course which includes basic knowledge about C like variables, types,
structures, pointers, arrays and different algorithms. In addition to that
I took courses called Programming Languages, Performance and Data
Structures, Operating Systems which taught deeper knowledge about C++,
various algorithms and data structures. Also by the end of the course
Operating
systems I made a project which is CLI based Quiz Server. In order to
complete this project threads, mutexes, semaphores, syscalls of Unix and
other stuff of currency were used. Since I am experienced with threads, I
would be very excited to work with parallelize compilation using threads.

Kind Regards!

Re: How to update .debug_frame CFA offset for function epilogues?

[Segher Boessenkool]

Hi Jozef,

On Thu, Mar 26, 2020 at 12:33:38PM +, Jozef Lawrynowicz wrote:
> In some cases, I can fix the CFA offset by marking these epilogue insns as
> frame_related anyway, and adding reg notes which describe the stack pointer
> operations. For some other epilogue insns, marking them frame_related results 
> in
> an ICE, which I'm assuming comes back to the fact that epilogue insns 
> shouldn't
> be marked frame related.

> What is the standard way for updating the CFA offset in the epilogue?

What you already say you do: add notes, and often frame_related is set
as well.  I agree that shouldn't be done, but it often is harmless.

You need reg_notes for more than just the stack updates: importantly,
also for the restores of any saved register.


Segher

Re: Can we please have the old mailing list back

[Bernd Edlinger]

On 3/26/20 4:27 PM, Bernd Edlinger wrote:
> On 3/26/20 4:16 PM, Christopher Faylor wrote:
>> On Wed, Mar 25, 2020 at 09:29:03PM +0100, Bernd Edlinger wrote:
>>> -On 3/25/20 7:55 PM, Christopher Faylor wrote:
 On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
> I believe the canonical place for the "Linux suff" mailing lists these 
> days is
> lore.kernel.org, powered by public-inbox[1]. ISTM that software can 
> address most
> if not all needs of those involved in GCC development and even has NNTP 
> support,
> though I've no idea whether it could be an acceptable solution from the
> overseers' perspective.
>
> [1] https://public-inbox.org/public-inbox.git

 The overseers are trying hard to use only software that can be installed
 via the RHEL packaging system so as not to duplicate the mistake that
 kept us dependent on poorly supported mail software.  Is there a
 public-inbox rpm package for RHEL or CentOS?

 FWIW, this particular overseer is is also pretty exhausted from the
 effort of moving sourceware to a new system + new software and would not
 relish the effort involved in getting all of this moved to new software.

>>>
>>> Honestly this is not about blaming you at all.
>>>
>>> I do not quite understand what is the exact software which
>>> was used previously?
>>>
>>> what is the exact problem that prevents it from being used any longer?
>>>
>>> Which software is being used now?
>>>
>>> Why is gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org.  and fort...@gcc.gnu.org
>>> even this e-mail thread visible
>>> on marc.info: https://marc.info/?l=gcc&m=158512515107459&w=2
>>> but not gdb-patches ?
>>>
>>> Could you add a link to https://marc.info/?l=gcc-patches
>>> https://marc.info/?l=gcc
>>> https://marc.info/?l=gcc-fortran
>>> note the unsystematic name gcc-fortran, the list is fort...@gcc.gnu.org
>>>
>>> There is no gcc-help on marc.info
>>> There is https://marc.info/?l=gcc
>>> but there is no gdb-patches
>>>
>>> what needs to be done to host those lists on marc.info as well?
>>>
>>> What needs to be done to host these lists on spinics for instance,
>>> or what else exists that can be used to search the messages?
>>
>> marc.info is an independent site that is not associated with
>> sourceware.org.  We don't control it.  If you have questions about their
>> site then ask them.
>>
>> The mailing list software is all easily discernible by investigating
>> email headers and via google but someone else answered your questions
>> later in this thread.
>>
> 
> But don't you think that we change something in 6.3 to make them break.
> like no longer sending updates, or something?
> 
> Don't you have any idea what changed on our side?
> 
> I mean what should I tell them they should do to fix that?
> 
> 

Ah, marc.info is fixed, it turned out that the messages were just Quarantined
because due to the change in the ip adresses, mailing software etc.
marc.info was under the impression that all these messages were just spam.

That is what they told me:

"For lists that often get spammed, we set up some silent header-checks
so that mails that don't look like they came from the real listserver
get quarrantined, and don't appear when viewing that list.

Well, that can break when mailing list software changes - like when they
switched away from ezmlm to Mailman.

I've updated our filter check and un-quarrantined about 4500 mails to
various gcc- lists that landed there this month."

So indeed all our mailing list message are again on marc.info,
I think when it can handle lkml it can handle gcc-patches as well.

Many Thanks go to Hank Leininger who does a gread job with marc.info.


Bernd.