The attached patch has been built and regression tested on
x86_64-*-freebsd. There were no regression.
If the scalar-numeric-expr in an arithmetic-if is ar
reference to NULL(), this is an invalid expression.
By resolving the expression, then entity is correctly
identified by EXPR_NULL. Thus, the patch prevents
an ICE when a messed up non-scalar-numeric-expr is
later translated in SSA form.
2015-09-25 Steven G. Kargl <ka...@gcc.gnu.org>
PR fortran/67614
* resolve.c (gfc_resolve_code): Prevent ICE for invalid EXPR_NULL.
2015-09-25 Steven G. Kargl <ka...@gcc.gnu.org>
PR fortran/67614
* gfortran.dg/pr67614.f90: New test.
--
Steve
Index: fortran/resolve.c
===================================================================
--- fortran/resolve.c (revision 228061)
+++ fortran/resolve.c (working copy)
@@ -10380,10 +10380,14 @@ gfc_resolve_code (gfc_code *code, gfc_na
{
gfc_expr *e = code->expr1;
+ gfc_resolve_expr (e);
+ if (e->expr_type == EXPR_NULL)
+ gfc_error ("Invalid NULL at %L", &e->where);
+
if (t && (e->rank > 0
|| !(e->ts.type == BT_REAL || e->ts.type == BT_INTEGER)))
gfc_error ("Arithmetic IF statement at %L requires a scalar "
- "REAL or INTEGER expression", &code->expr1->where);
+ "REAL or INTEGER expression", &e->where);
resolve_branch (code->label1, code);
resolve_branch (code->label2, code);
Index: testsuite/gfortran.dg/pr67614.f90
===================================================================
--- testsuite/gfortran.dg/pr67614.f90 (revision 0)
+++ testsuite/gfortran.dg/pr67614.f90 (working copy)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! { dg-options "-std=legacy" }
+! PR fortran/67614
+!
+program foo
+ implicit none
+ integer, pointer :: z
+ if (null(z)) 10, 20, 30 ! { dg-error "Invalid NULL" }
+10 continue
+20 continue
+30 continue
+end program foo
