[Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

[Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

[Mark Eggleston]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Please find attached Steve Kargl's fix for PR93814.

OK to commit?

gcc/fortran/ChangeLog:

     Steven G. Kargl  <kargl@gcc.gnu.org>

     PR fortran/93814
     * resolve.c (gfc_verify_binding_labels): Handle symbols with
     the subroutine attribute separately from symbols with the
     function attribute.

gcc/testsuite/ChanheLog:

     Mark Eggleston  <mark.eggleston@codethink.com>

     PR fortran/93814
     * gfortran.dg/pr93814.f90: New test.

-- 
https://www.codethink.co.uk/privacy.html


[-- Attachment #2: 0001-fortran-ICE-using-undeclared-symbol-in-array-constru.patch --]
[-- Type: text/x-patch, Size: 2650 bytes --]

From 4a3db68ce1fc8696b0108b4b0633c1f0959dac80 Mon Sep 17 00:00:00 2001
From: Mark Eggleston <markeggleston@gcc.gnu.org>
Date: Tue, 11 Feb 2020 08:35:02 +0000
Subject: [PATCH] fortran: ICE using undeclared symbol in array constructor
 PR93484

Using undeclared symbol k in an expression in the following
array constructor results in an ICE:

    print *, [real(x(k))]

If the call to the intrinsic is not in a constructor a no IMPLICIT
type error is reported and the ICE does not occur.

Matching on an expression instead of an initialisation express an
and not converting a MATCH_ERROR return value into MATCH_NO results
in the no IMPLICIT error and no ICE.

Note: Steven G. Kargl  <kargl@gcc.gnu.org> is the author of the
changes except for the test cases.

gcc/fortran/ChangeLog:

	PR fortran/93484
	* match.c (gfc_match_type_spec): Replace gfc_match_init_expr with
	gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR.

gcc/testsuite

	PR fortran/93484
	* gfortran.dg/pr93484_1.f90: New test.
	* gfortran.dg/pr93484_2.f90: New test.
---
 gcc/fortran/match.c                     | 4 ++--
 gcc/testsuite/gfortran.dg/pr93484_1.f90 | 8 ++++++++
 gcc/testsuite/gfortran.dg/pr93484_2.f90 | 8 ++++++++
 3 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93484_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/pr93484_2.f90

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index a74cb8c5c19..03adfca9bd9 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -2222,9 +2222,9 @@ gfc_match_type_spec (gfc_typespec *ts)
 
 found:
 
-      m = gfc_match_init_expr (&e);
+      m = gfc_match_expr (&e);
       if (m == MATCH_NO || m == MATCH_ERROR)
-	return MATCH_NO;
+	return m;
 
       /* If a comma appears, it is an intrinsic subprogram. */
       gfc_gobble_whitespace ();
diff --git a/gcc/testsuite/gfortran.dg/pr93484_1.f90 b/gcc/testsuite/gfortran.dg/pr93484_1.f90
new file mode 100644
index 00000000000..3b6dbc9ad79
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93484_1.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+!
+program p
+  implicit none
+  integer :: x(4) = [1,2,3,4]
+  print *, [real(x(k))] ! { dg-error "Symbol 'k' at .1. has no IMPLICIT type" } 
+end
+
diff --git a/gcc/testsuite/gfortran.dg/pr93484_2.f90 b/gcc/testsuite/gfortran.dg/pr93484_2.f90
new file mode 100644
index 00000000000..4a7f4330ed9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93484_2.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+!
+program p
+  implicit none
+  integer, parameter :: x(4) = [1,2,3,4]
+  print *, [real(x(k))] ! { dg-error "Symbol 'k' at .1. has no IMPLICIT type" }
+end
+
-- 
2.11.0

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

[Thomas Koenig]

Hi Mark,

> Please find attached Steve Kargl's fix for PR93814.

The attached patch does not match the ChangeLog; it seems to
be for PR93484.

Regards

	Thomas

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

[Mark Eggleston]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Apologies, 2nd attempt:

gcc/fortran/ChangeLog:

     Steven G. Kargl  <kargl@gcc.gnu.org>

     PR fortran/93814
     * resolve.c (gfc_verify_binding_labels): Handle symbols with
     the subroutine attribute separately from symbols with the
     function attribute.

gcc/testsuite/ChanheLog:

     Mark Eggleston  <mark.eggleston@codethink.com>

     PR fortran/93814
     * gfortran.dg/pr93814.f90: New test.

OK to commit?

On 22/03/2020 17:46, Thomas Koenig wrote:
> Hi Mark,
>
>> Please find attached Steve Kargl's fix for PR93814.
>
> The attached patch does not match the ChangeLog; it seems to
> be for PR93484.
>
> Regards
>
>     Thomas
>
-- 
https://www.codethink.co.uk/privacy.html


[-- Attachment #2: 0001-fortran-ICE-in-build_entry_thunks-PR93814.patch --]
[-- Type: text/x-patch, Size: 2668 bytes --]

From 743b915bfef6c798e3b001ff8759739e9fc52ec1 Mon Sep 17 00:00:00 2001
From: Mark Eggleston <markeggleston@gcc.gnu.org>
Date: Fri, 21 Feb 2020 10:52:52 +0000
Subject: [PATCH] fortran: ICE in build_entry_thunks PR93814

Patch provided by Steve Kargl.  Test case provided by G. Steinmetz.

gcc/fortran/ChangeLog:

	PR fortran/93814
	* resolve.c (gfc_verify_binding_labels): Handle symbols with
	the subroutine attribute separately from symbols with the
	function attribute.

gcc/testsuite/ChanheLog:

	PR fortran/93814
	* gfortran.dg/pr93814.f90: New test.
---
 gcc/fortran/resolve.c                 | 23 ++++++++++++++++++++---
 gcc/testsuite/gfortran.dg/pr93814.f90 |  8 ++++++++
 2 files changed, 28 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93814.f90

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 8f5267fde05..81d855eaa54 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12236,9 +12236,26 @@ gfc_verify_binding_labels (gfc_symbol *sym)
       return;
     }
 
-  if ((sym->attr.function || sym->attr.subroutine)
-      && ((gsym->type != GSYM_SUBROUTINE && gsym->type != GSYM_FUNCTION)
-	   || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
+  if (sym->attr.function
+      && (gsym->type != GSYM_FUNCTION
+	  || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
+      && (sym != gsym->ns->proc_name)
+      && (module != gsym->mod_name
+	  || strcmp (gsym->sym_name, sym->name) != 0
+	  || (module && strcmp (module, gsym->mod_name) != 0)))
+    {
+      /* Print an error if the procedure is defined multiple times; we have to
+	 exclude references to the same procedure via module association or
+	 multiple checks for the same procedure.  */
+      gfc_error ("Procedure %qs with binding label %qs at %L uses the same "
+		 "global identifier as entity at %L", sym->name,
+		 sym->binding_label, &sym->declared_at, &gsym->where);
+      sym->binding_label = NULL;
+    }
+
+  if (sym->attr.subroutine
+      && (gsym->type != GSYM_SUBROUTINE
+	  || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
       && (sym != gsym->ns->proc_name && sym->attr.entry == 0)
       && (module != gsym->mod_name
 	  || strcmp (gsym->sym_name, sym->name) != 0
diff --git a/gcc/testsuite/gfortran.dg/pr93814.f90 b/gcc/testsuite/gfortran.dg/pr93814.f90
new file mode 100644
index 00000000000..9eb818ca478
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93814.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! Test case by G. Steinmetz
+
+function f() bind(c)
+character :: f, g ! { dg-error "1" }
+entry g() bind(c) ! { dg-error "Procedure 'g' with binding label 'g'" }
+end
+
-- 
2.11.0

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

[Mark Eggleston]

**ping**

On 23/03/2020 14:55, Mark Eggleston wrote:
> Apologies, 2nd attempt:
>
> gcc/fortran/ChangeLog:
>
>     Steven G. Kargl  <kargl@gcc.gnu.org>
>
>     PR fortran/93814
>     * resolve.c (gfc_verify_binding_labels): Handle symbols with
>     the subroutine attribute separately from symbols with the
>     function attribute.
>
> gcc/testsuite/ChanheLog:
>
>     Mark Eggleston  <mark.eggleston@codethink.com>
>
>     PR fortran/93814
>     * gfortran.dg/pr93814.f90: New test.
>
> OK to commit?
>
> On 22/03/2020 17:46, Thomas Koenig wrote:
>> Hi Mark,
>>
>>> Please find attached Steve Kargl's fix for PR93814.
>>
>> The attached patch does not match the ChangeLog; it seems to
>> be for PR93484.
>>
>> Regards
>>
>>     Thomas
>>
-- 
https://www.codethink.co.uk/privacy.html

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

[Tobias Burnus]

Hi Mark,

the error message does not make sense – and I also currently
do not see why that example should be invalid.

Regarding the error message:
    "uses the same global identifier"
In the test program (attached or PR) I do see one function "f"
and one entry "g" – and both "f" and "g" is only used once.

I also checked the F2018 standard and did not spot anything
which restricts this example.

Hence, I believe the test case is valid and, hence, the patch
does not solve the actual problem.

Cheers,

Tobias

On 3/23/20 3:55 PM, Mark Eggleston wrote:
> Apologies, 2nd attempt:
>
> gcc/fortran/ChangeLog:
>
>     Steven G. Kargl  <kargl@gcc.gnu.org>
>
>     PR fortran/93814
>     * resolve.c (gfc_verify_binding_labels): Handle symbols with
>     the subroutine attribute separately from symbols with the
>     function attribute.
>
> gcc/testsuite/ChanheLog:
>
>     Mark Eggleston  <mark.eggleston@codethink.com>
>
>     PR fortran/93814
>     * gfortran.dg/pr93814.f90: New test.
>
> OK to commit?
>
> On 22/03/2020 17:46, Thomas Koenig wrote:
>> Hi Mark,
>>
>>> Please find attached Steve Kargl's fix for PR93814.
>>
>> The attached patch does not match the ChangeLog; it seems to
>> be for PR93484.
>>
>> Regards
>>
>>     Thomas
>>
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter