public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]
@ 2020-02-11 15:25 Mark Eggleston
  2020-02-17 22:09 ` Thomas Koenig
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Eggleston @ 2020-02-11 15:25 UTC (permalink / raw)
  To: gcc-patches, fortran

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

Please find attached a patch, it is based on Steve Kargl's patch in 
PR93580 adding  a check for %len and test case.

The commit message in the patch includes change logs as I believe that 
is the intended way forward. One thing I'm unsure of it how handle 
multiple authors, it was easy in the ChangeLog files but it is not 
obvious for git commit messages.

OK for master and gcc 9 branch?

gcc/fortran/ChangeLog:

     Steven G. Kargl <kargl@gcc.gnu.org>
     Mark Eggleston <markeggleston@gcc.gnu.org>

     PR fortran/93580
     * primary.c (gfc_match_varspec): If the symbol following %
     is re or im and the primary expression type is not BT_COMPLEX
     issue an error. If the symbol is len and the primary
     expression type is not BT_CHARACTER is an error.

gcc/testsuite/ChangeLog:

     Mark Eggleston <markeggleston@gcc.gnu.org>

     PR fortran/93580
     * gfortran.dg/dg/pr93580.f90: New test.

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


[-- Attachment #2: 0001-fortran-ICE-in-gfc_validate_kind-Got-bad-kind-PR93580.patch --]
[-- Type: text/x-patch, Size: 2848 bytes --]

From 2d4fddda1ccd981c9956f798b3ed4871d8fcb4f1 Mon Sep 17 00:00:00 2001
From: Mark Eggleston <markeggleston@gcc.gnu.org>
Date: Wed, 5 Feb 2020 10:38:37 +0000
Subject: [PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]

Caused by using invalid part_refs in kind specifications,
e.g. %re or %im on non-complex expressions and %len on
non character expressions.

Check whether %re, %im and %len are valid when checking
kind specification.

The original patch from Steven G. Kargl  <kargl@gcc.gnu.org> only
checked for %re and %im.

gcc/fortran/ChangeLog:

	PR fortran/93580
	* primary.c (gfc_match_varspec): If the symbol following %
	is re or im and the primary expression type is not BT_COMPLEX
	issue an error. If the symbol is len and the primary
	expression type is not BT_CHARACTER is an error.

gcc/testsuite/ChangeLog:

	PR fortran/93580
	* gfortran.dg/dg/pr93580.f90: New test.
---
 gcc/fortran/primary.c                 | 24 ++++++++++++++++++++++--
 gcc/testsuite/gfortran.dg/pr93580.f90 | 13 +++++++++++++
 2 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93580.f90

diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index bd50827bb15..d73898473df 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2241,8 +2241,28 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool sub_flag,
 	  if (inquiry)
 	    sym = NULL;
 
-	  if (sep == '%' && primary->ts.type != BT_UNKNOWN)
-	    intrinsic = true;
+	  if (sep == '%')
+	    {
+	      if (tmp)
+		{
+		  if ((tmp->u.i == INQUIRY_RE || tmp->u.i == INQUIRY_IM)
+		      && primary->ts.type != BT_COMPLEX)
+		    {
+			gfc_error ("The RE or IM part_ref at %C must be "
+				   "applied to a COMPLEX expression");
+			return MATCH_ERROR;
+		    }
+		  else if (tmp->u.i == INQUIRY_LEN
+			   && primary->ts.type != BT_CHARACTER)
+		    {
+			gfc_error ("The LEN part_ref at %C must be applied "
+				   "to a CHARACTER expression");
+			return MATCH_ERROR;
+		    }
+		}
+	      if (primary->ts.type != BT_UNKNOWN)
+		intrinsic = true;
+	    }
 	}
       else
 	inquiry = false;
diff --git a/gcc/testsuite/gfortran.dg/pr93580.f90 b/gcc/testsuite/gfortran.dg/pr93580.f90
new file mode 100644
index 00000000000..4feaa112914
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93580.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PR fortran/93580
+
+program p
+   integer, parameter :: n = 4
+   complex(n%re) :: x    ! { dg-error "The RE or IM part_ref at" }
+   complex(n%im) :: y    ! { dg-error "The RE or IM part_ref at" }
+   complex(n%len) :: z   ! { dg-error "The LEN part_ref at" }
+   character(n%im) :: a  ! { dg-error "The RE or IM part_ref at" }
+   character(n%re) :: b  ! { dg-error "The RE or IM part_ref at" }
+   character(n%len) :: c ! { dg-error "The LEN part_ref at" }
+end
+
-- 
2.11.0


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]
  2020-02-11 15:25 [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580] Mark Eggleston
@ 2020-02-17 22:09 ` Thomas Koenig
  0 siblings, 0 replies; 5+ messages in thread
From: Thomas Koenig @ 2020-02-17 22:09 UTC (permalink / raw)
  To: Mark Eggleston, gcc-patches, fortran

Hi Mark,

> OK for master and gcc 9 branch?

Looks good.

Thanks!

Regards

	Thomas

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]
  2020-02-11 15:20 ` Steve Kargl
@ 2020-02-11 15:22   ` Mark Eggleston
  0 siblings, 0 replies; 5+ messages in thread
From: Mark Eggleston @ 2020-02-11 15:22 UTC (permalink / raw)
  To: sgk; +Cc: gcc-patches, fortran

So it does, I'll have an other go.


On 11/02/2020 15:20, Steve Kargl wrote:
> On Tue, Feb 11, 2020 at 02:41:26PM +0000, Mark Eggleston wrote:
>> Please find attached a patch, it is based on Steve Kargl's patch in PR93580
>> adding  a check for %len and test case.
>>
> Looks like the wrong diff was attached.
>
>>   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;

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]
  2020-02-11 14:41 Mark Eggleston
@ 2020-02-11 15:20 ` Steve Kargl
  2020-02-11 15:22   ` Mark Eggleston
  0 siblings, 1 reply; 5+ messages in thread
From: Steve Kargl @ 2020-02-11 15:20 UTC (permalink / raw)
  To: Mark Eggleston; +Cc: gcc-patches, fortran

On Tue, Feb 11, 2020 at 02:41:26PM +0000, Mark Eggleston wrote:
> Please find attached a patch, it is based on Steve Kargl's patch in PR93580
> adding  a check for %len and test case.
> 

Looks like the wrong diff was attached.

>  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;

-- 
steve

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]
@ 2020-02-11 14:41 Mark Eggleston
  2020-02-11 15:20 ` Steve Kargl
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Eggleston @ 2020-02-11 14:41 UTC (permalink / raw)
  To: gcc-patches, fortran

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

Please find attached a patch, it is based on Steve Kargl's patch in 
PR93580 adding  a check for %len and test case.

The commit message in the patch includes change logs as I believe that 
is the intended way forward. One thing I'm unsure of it how handle 
multiple authors, it was easy in the ChangeLog files but it is not 
obvious for git commit messages.

OK for master and gcc 9 branch?

gcc/fortran/ChangeLog:

     Steven G. Kargl  <kargl@gcc.gnu.org>
     Mark Eggleston  <markeggleston@gcc.gnu.org>

     PR fortran/93580
     * primary.c (gfc_match_varspec): If the symbol following %
     is re or im and the primary expression type is not BT_COMPLEX
     issue an error. If the symbol is len and the primary
     expression type is not BT_CHARACTER is an error.

gcc/testsuite/ChangeLog:

     Mark Eggleston <markeggleston@gcc.gnu.org>

     PR fortran/93580
     * gfortran.dg/dg/pr93580.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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-02-17 22:09 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-11 15:25 [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580] Mark Eggleston
2020-02-17 22:09 ` Thomas Koenig
  -- strict thread matches above, loose matches on Subject: below --
2020-02-11 14:41 Mark Eggleston
2020-02-11 15:20 ` Steve Kargl
2020-02-11 15:22   ` Mark Eggleston

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).