Re: [Patch, fortran] PR92976 - [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

2020-03-01 Thread Thomas Koenig
Hi Paul, Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ? OK, and thanks for the patch. I think it makes sense to get this into gcc 9.3, which would need a backport before the 5th of March. Regards Thomas

Re: [Patch, fortran] PR92959 - ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

2020-03-01 Thread Thomas Koenig
Hi Paul, Regtested on FC31/x86_64 - OK for trunk? OK. Thanks for the patch! Regards Thomas

[PATCH] x32: Update baseline_symbols.txt

2020-03-01 Thread H.J. Lu
I am checking this into master and GCC 9 branches. H.J. --- * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. --- libstdc++-v3/ChangeLog | 4 .../abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt | 7 +++ 2 files chang

Darwin, libsanitizer: Adjust minimum supported Darwin version (PR93731).

2020-03-01 Thread Iain Sandoe
Hi, The current imported libsanitizer code produces kernel panics for Darwin 11 (macOS 10.7) and is unsupported for earlier versions already. It is not clear if the current sources are even intended to be supported on Darwin 11, so this patch causes the default to be build without sanitizers for

[Patch, fortran] PR93581 - [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

2020-03-01 Thread Paul Richard Thomas
This is a straightforward patch, especially for the bug in the PR! The additional fix ensures that expr%LEN always returns a scalar. Please note the comment in resolve.c about bounds checking. Regtests on trunk - OK for 9- and 10-branches? Paul 2020-03-01 Paul Thomas PR fortran/93581

Re: [Patch, fortran] PR92976 - [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

2020-03-01 Thread Paul Richard Thomas
Committed to head as r10-6954-g957a1b14e99596610abb0777ca86a1c80dde24e0. Thanks, Thomas Paul On Sun, 1 Mar 2020 at 13:43, Thomas Koenig wrote: > > Hi Paul, > > > Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ? > > OK, and thanks for the patch. > > I think it makes sense to get this

Re: [Patch, fortran] PR92959 - ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

2020-03-01 Thread Paul Richard Thomas
Committed to head as r10-6952-g7067f8c814088c1d02e40adf79a80f5ec53dbdde Thanks, Thomas Paul On Sun, 1 Mar 2020 at 13:44, Thomas Koenig wrote: > > Hi Paul, > > > Regtested on FC31/x86_64 - OK for trunk? > > > OK. Thanks for the patch! > > Regards > > Thomas -- "If you can't explain i

Re: Return slot optimization for stack protector strong

2020-03-01 Thread Stefan Schulze Frielinghaus
On Tue, Jan 28, 2020 at 06:18:41PM +0100, Stefan Schulze Frielinghaus wrote: > On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote: > > On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote: > > > some function calls trigger the stack-protector-strong although such >

[committed] coroutines: Test that we correctly use class data members.

2020-03-01 Thread Iain Sandoe
Hi, No code changes, just improve test coverage. tested on x86_64 darwin and linux applied to mainline. thanks Iain gcc/testsuite/ChangeLog: 2020-03-01 Iain Sandoe * g++.dg/coroutines/torture/class-07-data-member.C: New test. diff --git a/gcc/testsuite/g++.dg/coroutines/torture/clas

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

2020-03-01 Thread Andrew Benson
*ping* On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote: > I opened PR93486 for this problem: > > The following causes an ICE with revision > ad690d79cfbb905c5546c9333c5fd089d906505b: > > module ivs > interface l > module procedure l_ > end interface l > contains > func

Re: [PATCH][wwwdocs] Document GNU-stack support added to GCC 10 for MIPS

2020-03-01 Thread Dragan Mladjenovic
On 22.02.2020. 13:25, Gerald Pfeifer wrote: On Fri, 24 Jan 2020, Dragan Mladjenovic wrote: From: "Dragan Mladjenovic" diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index ef27c9b..7736990 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -623,7 +

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

2020-03-01 Thread Steve Kargl
On Sun, Mar 01, 2020 at 11:33:10AM -0800, Andrew Benson wrote: > *ping* > Andrew, The patch looks fine to me. PS: in general, after multiple pings, just commit the patch. -- Steve

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

2020-03-01 Thread Andrew Benson
Thanks, Steve. I'll get this committed tomorrow morning. -Andrew On Sunday, March 1, 2020 2:42:13 PM PST Steve Kargl wrote: > On Sun, Mar 01, 2020 at 11:33:10AM -0800, Andrew Benson wrote: > > *ping* > > Andrew, > > The patch looks fine to me. PS: in general, after multiple > pings, just commi

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

2020-03-01 Thread Thomas Koenig
Am 01.03.20 um 23:42 schrieb Steve Kargl: PS: in general, after multiple pings, just commit the patch. ... well, maybe after a "If there is no reply within a couple of days, I will commit this" :-) Regards Thomas

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

2020-03-01 Thread Steve Kargl
On Sun, Mar 01, 2020 at 11:43:23PM +0100, Thomas Koenig wrote: > Am 01.03.20 um 23:42 schrieb Steve Kargl: > > PS: in general, after multiple > > pings, just commit the patch. > > ... well, maybe after a "If there is no reply within a > couple of days, I will commit this" :-) > Andrew submitted

Re: maxval on -inf and nan in Fortran

2020-03-01 Thread Jiufu Guo
Joseph Myers writes: > On Fri, 28 Feb 2020, Tobias Burnus wrote: > >> Regarding MIN and MAX: I think the IEEE 754 decided at some point >> decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I >> recall correctly). I think one has to check what exactly the test case >> does and w

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

2020-03-01 Thread Paul Richard Thomas
Andrew, I agree with Steve. That said, I took a look at your patch and it's just fine. OK to commit. Cheers Paul On Mon, 2 Mar 2020 at 02:10, Steve Kargl wrote: > > On Sun, Mar 01, 2020 at 11:43:23PM +0100, Thomas Koenig wrote: > > Am 01.03.20 um 23:42 schrieb Steve Kargl: > > > PS: in general