[PATCH] fortran/66043 -- Check for NULL() in STORAGE_SIZE()

[PATCH] fortran/66043 -- Check for NULL() in STORAGE_SIZE()

[Steve Kargl]

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

Regression tested on trunk. OK to commit? 

The patch shuold be self-explanatory.

2015-05-XX  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/66043
	* check.c (gfc_check_storage_size): Prevent the direct use of NULL()
	in STORAGE_SIZE() reference.

2015-05-XX  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/66043
	* gfortran.dg/storage_size_6.f90: New tests.

-- 
Steve

[-- Attachment #2: pr66043.diff --]
[-- Type: text/x-diff, Size: 1232 bytes --]

Index: gcc/fortran/check.c
===================================================================
--- gcc/fortran/check.c	(revision 223094)
+++ gcc/fortran/check.c	(working copy)
@@ -6243,6 +6243,17 @@ gfc_check_and (gfc_expr *i, gfc_expr *j)
 bool
 gfc_check_storage_size (gfc_expr *a, gfc_expr *kind)
 {
+
+  if (a->expr_type == EXPR_NULL)
+    {
+      gfc_error ("%qs argument of %qs intrinsic at %L shall not be an "
+		 "unallocated allocatable variable or a disassociated or "
+		 "undefined pointer",
+		 gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
+		 &a->where);
+      return false;
+    }
+
   if (a->ts.type == BT_ASSUMED)
     {
       gfc_error ("%qs argument of %qs intrinsic at %L shall not be TYPE(*)",
Index: gcc/testsuite/gfortran.dg/storage_size_6.f90
===================================================================
--- gcc/testsuite/gfortran.dg/storage_size_6.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/storage_size_6.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/66043
+!
+! Original code from Gerhard Steinmetz
+! <gerhard dot steinmetz dot fortran at t-online dot de>
+program p
+   print *, storage_size(null()) ! { dg-error "shall not be an unallocated" }
+end

Re: [PATCH] fortran/66043 -- Check for NULL() in STORAGE_SIZE()

[FX]

Hi Steve,

+      gfc_error ("%qs argument of %qs intrinsic at %L shall not be an "
+		 "unallocated allocatable variable or a disassociated or "
+		 "undefined pointer”,

Given that we know explicitly that the expr is NULL, wouldn’t it be nicer to give only the relevant condition (here, I guess it’s “undefined pointer”)?

Regarding the other example mention in the PR’s comment #2, I guess there’s no requirement for the compiler to diagnose this, is there?

FX

Re: [PATCH] fortran/66043 -- Check for NULL() in STORAGE_SIZE()

[Steve Kargl]

On Fri, May 15, 2015 at 05:34:14PM +0200, FX wrote:
> Hi Steve,
> 
> +      gfc_error ("%qs argument of %qs intrinsic at %L shall not be an "
> +		 "unallocated allocatable variable or a disassociated or "
> +		 "undefined pointer???,
> 
> Given that we know explicitly that the expr is NULL, wouldn't
> it be nicer to give only the relevant condition (here, I guess
> it's "undefined pointer")?

The text above is essentially the wording from the standard.
I was unsure if I could catch all types of errors when I wrote
the error string.

I can change the error to something like

"Intrinsic function NULL() cannot be an actual argument to
STORAGE_SIZE because it returns a disassociated pointer"

>
> Regarding the other example mention in the PR's comment #2,
> I guess there's no requirement for the compiler to diagnose
> this, is there?
>

No.  This isn't a numbered constraint.  I spent an hour or so
tracing though parent namespaces and symbol trees to see if
I could catch the problem in comment #2.  I think that this
would require a runtime error (or adding an internal attribute
that explicitly tracks associate/disassociation and
allocation/deallocation).

-- 
Steve

Re: [PATCH] fortran/66043 -- Check for NULL() in STORAGE_SIZE()

[FX]

> I can change the error to something like
> 
> "Intrinsic function NULL() cannot be an actual argument to
> STORAGE_SIZE because it returns a disassociated pointer”

I think that’d be better, indeed.


> No.  This isn't a numbered constraint.  I spent an hour or so
> tracing though parent namespaces and symbol trees to see if
> I could catch the problem in comment #2.  I think that this
> would require a runtime error (or adding an internal attribute
> that explicitly tracks associate/disassociation and
> allocation/deallocation).

That seems likely.

Thus: OK to commit with adjusted error message (and testcase pattern).

FX