gcc-8-20200507 is now available

Snapshot gcc-8-20200507 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200507/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: Stability of pipermail ml archive URLs

On Thu, May 07, 2020 at 02:23:30PM -0500, Segher Boessenkool wrote: >On Thu, May 07, 2020 at 11:48:18AM +0200, Thomas Schwinge wrote: >>By the way, the public-inbox software >>(), as recently mentioned in a >>different thread discussing deficiencies of Mailman'

Re: Stability of pipermail ml archive URLs

Hi! On Thu, May 07, 2020 at 11:48:18AM +0200, Thomas Schwinge wrote: > By the way, the public-inbox software > (), as recently mentioned in a > different thread discussing deficiencies of Mailman's Pipermail, also > does support this: >

Re: Stability of pipermail ml archive URLs

On Thu, May 07, 2020 at 01:56:04PM -0400, Frank Ch. Eigler wrote: >>>I was thinking we might be able to trick pipermail (the web archiver >>>component) to simply name the message web urls after some function of >>>the message-id instead of the sequence number. Will give this a try >>>very shortly.

Re: Stability of pipermail ml archive URLs

Hi - > >I was thinking we might be able to trick pipermail (the web archiver > >component) to simply name the message web urls after some function of > >the message-id instead of the sequence number. Will give this a try > >very shortly. > > I just want to go on record as saying that I think thi

Re: Stability of pipermail ml archive URLs

On Thu, May 07, 2020 at 06:14:55AM -0400, Frank Ch. Eigler wrote: >>Such a service is not currently available on sourceware, but it'd be >>possible to implement: as messages come in, you'd build a database >>mapping from the Message-ID header to "current Mailman's Pipermail >>URL". > >I was thinkin

Re: Stability of pipermail ml archive URLs

On Thu, May 07, 2020 at 11:48:18AM +0200, Thomas Schwinge wrote: >On 2020-05-06T10:44:46-0400, "Frank Ch. Eigler via Gcc" > wrote: >>>Can pipermail provide stable URLs at all? We really need those, we >>>reference those in commit messages, other mails, bugzilla etc. > >>It would be good to have a

GCC 10.1 Released

A year has lapsed away since the release of last major GCC release, more than 33 years passed since the first public GCC release and the GCC developers survived repository conversion from SVN to GIT earlier this year. Today, we are glad to announce another major GCC release, 10.1. This release ma

Re: Multilibs in stage-1

On 5/7/20 9:02 AM, Jonathan Wakely wrote: > On Thu, 7 May 2020 at 07:28, Uros Bizjak via Gcc wrote: >> >> On Thu, May 7, 2020 at 8:16 AM Richard Biener >> wrote: >>> >>> On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc >>> wrote: Hello! I wonder, if the build process rea

Re: Stability of pipermail ml archive URLs

Hi - > Such a service is not currently available on sourceware, but it'd be > possible to implement: as messages come in, you'd build a database > mapping from the Message-ID header to "current Mailman's Pipermail URL". I was thinking we might be able to trick pipermail (the web archiver componen

Re: Stability of pipermail ml archive URLs

Hi! On 2020-05-06T10:44:46-0400, "Frank Ch. Eigler via Gcc" wrote: >> Can pipermail provide stable URLs at all? We really >> need those, we reference those in commit messages, other mails, bugzilla >> etc. > It would be good to have another way of making permanent URLs for > individual messages

Re: Multilibs in stage-1

On Thu, May 7, 2020 at 9:24 AM Jakub Jelinek wrote: > > On Thu, May 07, 2020 at 09:02:58AM +0200, Richard Biener wrote: > > Hmm. IIRC it required special-handling in the individual libs - Jakub > > may remeber (IIRC > > he implemented short-cutting libsanitizer builds) > > Just fuzzy memories, bu

Re: Multilibs in stage-1

On Thu, May 07, 2020 at 09:02:58AM +0200, Richard Biener wrote: > Hmm. IIRC it required special-handling in the individual libs - Jakub > may remeber (IIRC > he implemented short-cutting libsanitizer builds) Just fuzzy memories, but I think the libsanitizer case was that it the build of that is e

Re: Question about alias or points-to analysis

On Wed, May 6, 2020 at 9:25 PM Erick Ochoa wrote: > > > > On 06/05/2020 18:40, Richard Biener wrote: > > On Wed, May 6, 2020 at 3:04 PM Erick Ochoa > > wrote: > >> > >> > >> > >> On 06/05/2020 14:25, Richard Biener wrote: > >>> On Wed, May 6, 2020 at 12:26 PM Erick Ochoa > >>> wrote: > > >>

Re: Multilibs in stage-1

On Wed, May 6, 2020 at 11:29 PM Uros Bizjak via Gcc wrote: > > On Thu, May 7, 2020 at 8:16 AM Richard Biener > wrote: > > > > On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc > > wrote: > > >Hello! > > > > > >I wonder, if the build process really needs to build all multilibs in > > >st

Re: Multilibs in stage-1

On Thu, May 7, 2020 at 8:25 AM Uros Bizjak wrote: > > On Thu, May 7, 2020 at 8:16 AM Richard Biener > wrote: > > > > On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc > > wrote: > > >Hello! > > > > > >I wonder, if the build process really needs to build all multilibs in > > >stage-1 boo

Re: Multilibs in stage-1

On Thu, 7 May 2020 at 07:28, Uros Bizjak via Gcc wrote: > > On Thu, May 7, 2020 at 8:16 AM Richard Biener > wrote: > > > > On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc > > wrote: > > >Hello! > > > > > >I wonder, if the build process really needs to build all multilibs in > > >stage