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

[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

[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

[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 changed, 11 insertions(+)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 0ef42f084b3..509de8ae916 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,7 @@
+2020-03-01  H.J. Lu  
+
+   * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated.
+
 2020-02-29  John David Anglin  
 
* testsuite/17_intro/headers/c++1998/charset.cc: Skip on *-*-hpux*.
diff --git 
a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
index 7bea5e94608..990abf00d70 100644
--- a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
@@ -1829,6 +1829,7 @@ 
FUNC:_ZNSt10filesystem28recursive_directory_iteratorC2ERKNS_4pathENS_17directory
 FUNC:_ZNSt10filesystem28recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem28recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSEOS0_@@GLIBCXX_3.4.26
+FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSERKS0_@@GLIBCXX_3.4.27
 FUNC:_ZNSt10filesystem28recursive_directory_iteratorppEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsE@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsERSt10error_code@@GLIBCXX_3.4.26
@@ -1885,6 +1886,7 @@ 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorC2ERKNS0_4pathENS_17
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_@@GLIBCXX_3.4.26
+FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSERKS1_@@GLIBCXX_3.4.27
 
FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv@@GLIBCXX_3.4.26
 
FUNC:_ZNSt10filesystem7__cxx114path14_S_convert_locEPKcS3_RKSt6locale@@GLIBCXX_3.4.26
@@ -2060,13 +2062,17 @@ FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
 FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15
@@ -4402,6 +4408,7 @@ OBJECT:0:GLIBCXX_3.4.23
 OBJECT:0:GLIBCXX_3.4.24
 OBJECT:0:GLIBCXX_3.4.25
 OBJECT:0:GLIBCXX_3.4.26
+OBJECT:0:GLIBCXX_3.4.27
 OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
-- 
2.24.1

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

[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 Darwin <= 11.

tested on configurations for Darwin8..12
applied to master
thanks
Iain

2020-03-01  Iain Sandoe  

PR sanitizer/93731
* configure.tgt (x86_64-*-darwin*, i?86-*-darwin*): Enable by
default only for Darwin versions greater than 12 (macOS 10.8).

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index 2d93e19b9cb..5d46990eba4 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -60,7 +60,7 @@ case "${target}" in
TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_aarch64.lo
fi
;;
-  x86_64-*-darwin1[1-9]* | i?86-*-darwin1[1-9]*)
+  x86_64-*-darwin1[2-9]* | i?86-*-darwin1[2-9]*)
TSAN_SUPPORTED=no
;;
   x86_64-*-solaris2.11* | i?86-*-solaris2.11*)

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

[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
* resolve.c (gfc_resolve_ref): Modify array refs to be elements
if the ref chain ends in INQUIRY_LEN.
* trans-array.c (gfc_get_dataptr_offset): Provide the offsets
for INQUIRY_RE and INQUIRY_IM.

2020-03-01  Paul Thomas  

PR fortran/93581
* gfortran.dg/inquiry_type_ref_6.f90 : New test.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c	(revision 279842)
--- gcc/fortran/resolve.c	(working copy)
*** gfc_resolve_substring_charlen (gfc_expr
*** 5192,5199 
  bool
  gfc_resolve_ref (gfc_expr *expr)
  {
!   int current_part_dimension, n_components, seen_part_dimension;
!   gfc_ref *ref, **prev;
bool equal_length;

for (ref = expr->ref; ref; ref = ref->next)
--- 5192,5199 
  bool
  gfc_resolve_ref (gfc_expr *expr)
  {
!   int current_part_dimension, n_components, seen_part_dimension, dim;
!   gfc_ref *ref, **prev, *array_ref;
bool equal_length;

for (ref = expr->ref; ref; ref = ref->next)
*** gfc_resolve_ref (gfc_expr *expr)
*** 5239,5250 
--- 5239,5252 
current_part_dimension = 0;
seen_part_dimension = 0;
n_components = 0;
+   array_ref = NULL;

for (ref = expr->ref; ref; ref = ref->next)
  {
switch (ref->type)
  	{
  	case REF_ARRAY:
+ 	  array_ref = ref;
  	  switch (ref->u.ar.type)
  	{
  	case AR_FULL:
*** gfc_resolve_ref (gfc_expr *expr)
*** 5260,5265 
--- 5262,5268 
  	  break;

  	case AR_ELEMENT:
+ 	  array_ref = NULL;
  	  current_part_dimension = 0;
  	  break;

*** gfc_resolve_ref (gfc_expr *expr)
*** 5299,5305 
--- 5302,5334 
  	  break;

  	case REF_SUBSTRING:
+ 	  break;
+
  	case REF_INQUIRY:
+ 	  /* Implement requirement in note 9.7 of F2018 that the result of the
+ 	 LEN inquiry be a scalar.  */
+ 	  if (ref->u.i == INQUIRY_LEN && array_ref)
+ 	{
+ 	  array_ref->u.ar.type = AR_ELEMENT;
+ 	  expr->rank = 0;
+ 	  /* INQUIRY_LEN is not evaluated from the the rest of the expr
+ 		 but directly from the string length. This means that setting
+ 		 the array indices to one does not matter but might trigger
+ 		 a runtime bounds error. Suppress the check.  */
+ 	  expr->no_bounds_check = 1;
+ 	  for (dim = 0; dim < array_ref->u.ar.dimen; dim++)
+ 		{
+ 		  array_ref->u.ar.dimen_type[dim] = DIMEN_ELEMENT;
+ 		  if (array_ref->u.ar.start[dim])
+ 		gfc_free_expr (array_ref->u.ar.start[dim]);
+ 		  array_ref->u.ar.start[dim]
+ 			= gfc_get_int_expr (gfc_default_integer_kind, NULL, 1);
+ 		  if (array_ref->u.ar.end[dim])
+ 		gfc_free_expr (array_ref->u.ar.end[dim]);
+ 		  if (array_ref->u.ar.stride[dim])
+ 		gfc_free_expr (array_ref->u.ar.stride[dim]);
+ 		}
+ 	}
  	  break;
  	}

Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c	(revision 279842)
--- gcc/fortran/trans-array.c	(working copy)
*** gfc_get_dataptr_offset (stmtblock_t *blo
*** 6947,6952 
--- 6947,6970 
  	  tmp = gfc_build_array_ref (tmp, index, NULL);
  	  break;

+ 	case REF_INQUIRY:
+ 	  switch (ref->u.i)
+ 		{
+ 		case INQUIRY_RE:
+ 		  tmp = fold_build1_loc (input_location, REALPART_EXPR,
+ 	 TREE_TYPE (TREE_TYPE (tmp)), tmp);
+ 		  break;
+
+ 		case INQUIRY_IM:
+ 		  tmp = fold_build1_loc (input_location, IMAGPART_EXPR,
+ 	 TREE_TYPE (TREE_TYPE (tmp)), tmp);
+ 		  break;
+
+ 		default:
+ 		  break;
+ 		}
+ 	  break;
+
  	default:
  	  gcc_unreachable ();
  	  break;
Index: gcc/testsuite/gfortran.dg/inquiry_type_ref_6.f90
===
*** gcc/testsuite/gfortran.dg/inquiry_type_ref_6.f90	(nonexistent)
--- gcc/testsuite/gfortran.dg/inquiry_type_ref_6.f90	(working copy)
***
*** 0 
--- 1,24 
+ ! { dg-do run }
+ ! { dg-options "-fcheck=all" }
+ !
+ ! Test the fix for PR93581 and the implementation of note 9.7 of F2018.
+ ! The latter requires that the result of the LEN inquiry be a scalar
+ ! even for array expressions.
+ !
+ ! Contributed by Gerhard Steinmetz  
+ !
+ program p
+complex, target :: z(2) = [(1.0, 2.0),(3.0, 4.0)]
+character(:), allocatable, target :: c(:)
+real, pointer :: r(:)
+character(:), pointer :: s(:)
+
+r => z%re
+if (any (r .ne. real (z))) stop 1
+r => z%im
+if (any (r .ne. imag (z))) stop 2
+
+allocate (c, source = ['abc','def'])
+s(-2:-1) => c(1:2)
+if (s%len .ne. len (c)) stop 3  ! This is the reason for the -fcheck=all
+ end

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

[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 into gcc 9.3, which would need
> a backport before the 5th of March.
>
> Regards
>
> Thomas



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

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

[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 it simply, you don't understand it well enough"
- Albert Einstein

Re: Return slot optimization for stack protector strong

[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
> > > calls are later on implemented via calls to internal functions.
> > > Consider the following example:
> > > 
> > > long double
> > > rintl_wrapper (long double x)
> > > {
> > >   return rintl (x);
> > > }
> > > 
> > > On s390x a return value of type `long double` is passed via a return
> > > slot.  Thus according to function `stack_protect_return_slot_p` a
> > > function call like `rintl (x)` triggers the stack-protector-strong since
> > > rintl is not an internal function.  However, in a later stage, during
> > > `expand_call_stmt`, such a call is implemented via a call to an internal
> > > function.  This means in the example, the call `rintl (x)` is expanded
> > > into an assembler instruction with register operands only.  Thus this
> > > late time decision renders the usage of the stack protector superfluous.
> > 
> > I doubt your predicate gives any guarantees that the builtin will be
> > expanded inline rather than a library call.  Some builtins might be expanded
> > inline or as a library call depending on various options, or depending on
> > particular arguments etc.
> 
> My predicate is more or less just a copy of what happens in
> `expand_call_stmt` where we have
> 
> decl = gimple_call_fndecl (stmt);
> if (gimple_call_lhs (stmt)
> && !gimple_has_side_effects (stmt)
> && (optimize || (decl && called_as_built_in (decl
>   {
> internal_fn ifn = replacement_internal_fn (stmt);
> if (ifn != IFN_LAST)
>   {
> expand_internal_call (ifn, stmt);
> return;
>   }
>   }
> 
> There a decision is made whether a call is implemented as a call to an
> internal function or not.  Thus using the very same logic it should be
> possible to decide at an earlier stage that a call will be implemented
> as a call to an internal function.  Since an internal function has no
> linkage, it is therefore guaranteed that it will be inlined.

Ping. Any chance we can have a second look at this? I just outsourced the
logic used in `expand_call_stmt` in order to determine whether a call is
realized as a call to an internal function or not, into a predicate.
This predicate I'm then using to decide whether a function call should
trigger the stack protector or not.

I would have thought that this is fine since internal functions are
guaranteed to be inlined. Am I missing something?

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

[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/class-07-data-member.C 
b/gcc/testsuite/g++.dg/coroutines/torture/class-07-data-member.C
new file mode 100644
index 000..00a0df69758
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/torture/class-07-data-member.C
@@ -0,0 +1,61 @@
+//  { dg-do run }
+
+// Show that we are correctly accessing class variables.
+
+#include "../coro.h"
+
+// boiler-plate for tests of codegen
+#include "../coro1-ret-int-yield-int.h"
+
+class Foo
+{
+  int v;
+  public:
+  Foo () : v(0) {};
+  Foo (int x) : v(x) {};
+  coro1 meth ()
+{
+  PRINT ("coro1: about to return");
+  co_return v++;
+}
+};
+
+int main ()
+{
+  Foo inst (42);
+  int y;
+  {
+PRINT ("main: create coro1 [instance 1]");
+coro1 x = inst.meth ();
+if (x.handle.done())
+  abort();
+PRINT ("main: got coro1 - resuming (initial suspend)");
+x.handle.resume();
+PRINT ("main: after resume");
+y = x.handle.promise().get_value();
+if ( y != 42 )
+  abort ();
+if (!x.handle.done())
+  {
+PRINT ("main: apparently not done...");
+abort ();
+  }
+  }
+  PRINT ("main: create coro1 [instance 2]");
+  coro1 p = inst.meth ();
+  if (p.handle.done())
+abort();
+  PRINT ("main: got coro1 - resuming (initial suspend)");
+  p.handle.resume();
+  PRINT ("main: after resume");
+  y = p.handle.promise().get_value();
+  if ( y != 43 )
+abort ();
+  if (!p.handle.done())
+{
+  PRINT ("main: apparently not done...");
+  abort ();
+}
+  PRINT ("main: returning");
+  return 0;
+}

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

[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
>   function l_()
>   end function l_
> end module ivs
> 
> module aModeratleyLongModuleName
>   use ivs
>   interface
>  module subroutine cmo()
>  end subroutine cmo
>   end interface
> end module aModeratleyLongModuleName
> 
> submodule (aModeratleyLongModuleName)
> aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill
> contains
>   module procedure cmo
>   end procedure cmo
> end submodule aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill
> 
> submodule
> (aModeratleyLongModuleName:aNameForASubmoduleThatIsVeryLongButWhichIsLegalSt
> ill) sb
> end submodule sb
> 
> submodule (aModeratleyLongModuleName:sb) sc
> end submodule sc
> 
> 
> $ gfortran -v
> Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../
> libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/
> Tools_Devel --enable-languages=c,c++,fortran --disable-multilib
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.0.1 20200128 (experimental) (GCC)
> 
> 
> $ gfortran -c test.F90 -o test.o
> f951: internal compiler error: Segmentation fault
> 0xe1bc9f crash_signal
> ../../gcc-git/gcc/toplev.c:328
> 0x7f98119c71ef ???
>
> /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/
> sysv/linux/x86_64/sigaction.c:0
> 0x84b3f0 gfc_use_modules()
> ../../gcc-git/gcc/fortran/module.c:7315
> 0x85acc8 use_modules
> ../../gcc-git/gcc/fortran/parse.c:114
> 0x866daa parse_module
> ../../gcc-git/gcc/fortran/parse.c:6111
> 0x86733c gfc_parse_file()
> ../../gcc-git/gcc/fortran/parse.c:6428
> 0x8b780f gfc_be_parse_file
> ../../gcc-git/gcc/fortran/f95-lang.c:210
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> 
> The ICE goes away if the module and/or submodule names are made shorter.
> 
> The problem is caused when loading (generic or operator) interfaces from a
> module file. The module name can include the submodule name, so a size of
> 2*GFC_MAX_SYMBOL_LEN+2 is required to read this in.
> 
> The attached patch fixes this problem and regression tests cleanly *if* the
> patch for PR87103 is applied (otherwise that problem gets triggered by the
> new test case).
> 
> PR87103 has been a long-standing issue - there's a patch that works (either
> my original ugly fix, or the better fix proposed by Bernhard at https://
> gcc.gnu.org/ml/fortran/2018-09/msg00044.html ). It would be very nice to
> get one of these patches committed.
> 
> -Andrew


-- 

* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html

* Galacticus: https://github.com/galacticusorg/galacticus

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

[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 +623,14 @@ a work-in-progress.

  

-
+MIPS
+
+  The mips*-*-linux* targets now mark object files with 
appropriate GNU-stack note,
+facilitating use of non-executable stack hardening on GNU/Linux.
+The soft-float targets have this feature enabled by default, while
+for hard-float targets it requires use of glibc 2.31 or later.
+  
+


Thanksfor preparing this!  I did not see any response, but now
noticed the designated MIPS maintainer Matthew Fortune (per
gcc/MAINTAINERS) was not on copy.


Thanks for the replay. Sorry for the late response.



The first line is a bit long; can you please wrap?


Will do.



The note on hard-float targets does not seem completely clear to me:
I understand it requires glibc 2.31, but per the language it still
may not enabled by default even if in that case?  What is the
situation on the default in the hard-float case?


It retains the original behavior of not using GNU-stack notes at all.
You have to use --with-glibc-version=2.31 in all stages of gcc build
to enable GNU-stack note usage.



If believe you do not have commit access, but if you share an updated
patch I can apply for you.

Geral

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

[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

[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 commit the patch.


-- 

* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html

* Galacticus: https://github.com/galacticusorg/galacticus

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

[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

[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 the patch and pinged it twice.  gfortran
development is running on fumes.  Beating one's head 
against a wall seems counter productive.  I'm operating 
on a principle that if one has commit access for gfortran,
one is committing a patch with the best attentions.  Could
this lead to a regression?  Sure.  The alternative of 
constantly pinging patches is to simply stop submitting
patches.


-- 
Steve

Re: maxval on -inf and nan in Fortran

[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 what is guaranteed where. I also do not know whether a more
>> recent IEEE 754 (754:2019) has changed something again.
>
> It has.  The maxNum/minNum operations from IEEE 754-2008 were removed and 
> replaced by recommended operations maximum/minimum (treat NaNs the same 
> way as other operations do, i.e. produce a quiet NaN result if either 
> operand is a NaN) and maximumNumber/minimumNumber (return the number if 
> the other operand is a NaN, even a signaling NaN, with "invalid" raised in 
> the signaling NaN case).  Those new operations also treat +0 as greater 
> than -0, whereas maxNum/minNum did not specify the result in that case.  
> (The choice of which operand is the result is still unspecified when the 
> two operands are different DFP members of the same cohort, i.e. with 
> different quantum exponents.)

Hi,

Thanks for all your great comments!

IEEE 754 also updates the behavior of min/max on NaN, and
seems try to meet difference purpose with special operations.
So, I feel GNU Fortran manual is still a good decision as: 
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gfortran/MAX-and-MIN-intrinsics-with-REAL-NaN-arguments.html#MAX-and-MIN-intrinsics-with-REAL-NaN-arguments
It is undefined to use max/min on NaN without check IS_NAN or without
using specified IEEE operations.

Jiufu

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

[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, 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 the patch and pinged it twice.  gfortran
> development is running on fumes.  Beating one's head
> against a wall seems counter productive.  I'm operating
> on a principle that if one has commit access for gfortran,
> one is committing a patch with the best attentions.  Could
> this lead to a regression?  Sure.  The alternative of
> constantly pinging patches is to simply stop submitting
> patches.
>
>
> --
> Steve



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein