This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 8.4 Status Report (2020-02-17)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>, Matthias Klose <doko at debian dot org>
- Date: Wed, 19 Feb 2020 10:24:08 +0100
- Subject: Re: GCC 8.4 Status Report (2020-02-17)
- References: <AM6PR03MB51701BBBF031F11257E27273E4110@AM6PR03MB5170.eurprd03.prod.outlook.com>
On Tue, Feb 18, 2020 at 8:37 PM Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
>
> > It has been almost a year since GCC 8.3 has been released and GCC 8.4
> > release should have been released already, so we should concentrate on
> > getting it out soon. Unfortunately we have two P1s, one of them is
> > waiting for reporter's input, so we might as well just ignore it unless
> > the input is provided, but the other, C++ FE one, looks something that
> > should be fixed. If we get rid of the P1s, I'd like to create
> > 8.4-rc1 on Wednesday, Feb 26th and release 8.4 the week afterwards.
> > If you have any queued backports, please commit them to 8 branch
> > (and 9 branch too, we'd like to release 9.3 soon too).
>
> Hi Jakub,
>
> it just occurred to me that my patch here is a kind of
> security relevant one:
>
> https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01060.html
>
> since every time the collect2 process is interrupted via a signal
> it can delete random files from the hard drive, since the
> signal handler may be using the path name, and passes it to the unlink
> function before it is initialized.
>
> The patch doe not apply cleanly to gcc-8, but just fixing
> that issue, without tackling the cleanup at the same time should
> be feasible, if you like that for this version?
Sure, these kind of fixes are always welcome, but please post them
for review.
Richard.
>
> Thanks
> Bernd.