Patchwork [fortran] PR41859 ICE on invalid expression involving DT with pointer components in I/O

login
register
mail settings
Submitter Paul Richard Thomas
Date Aug. 18, 2010, 5:58 a.m.
Message ID <AANLkTinQ39-qeFeDJPGvvxV2U1Y87r2b9=Dj7BfoLuL+@mail.gmail.com>
Download mbox | patch
Permalink /patch/62000/
State New
Headers show

Comments

Paul Richard Thomas - Aug. 18, 2010, 5:58 a.m.
Dear Jerry,

> OK for trunk?

OK but for one tiny question:

Should you not check for parentheses, just to stop the code trying to
charge down, for example, binary operators?  Since expr1 has been
resolved already at the top of resolve_code, this should not matter -
it's just unnecessary.

eg.
Thanks for the patch!

Paul
   sym = exp->symtree->n.sym;
Jerry DeLisle - Aug. 18, 2010, 1:30 p.m.
On 08/17/2010 10:58 PM, Paul Richard Thomas wrote:
> Dear Jerry,
>
>> OK for trunk?
>
> OK but for one tiny question:
>
> Should you not check for parentheses, just to stop the code trying to
> charge down, for example, binary operators?  Since expr1 has been
> resolved already at the top of resolve_code, this should not matter -
> it's just unnecessary.
>

I was thinking of a case like this:

   print *, (-p)

Where p is invalid.  We need to drill down to run the check on it.

I also found I get a regression with integer_exponentiation.f90 if we do not 
drill down. This turns out to have a substatial mix of operators.  Interesting 
test case.

Thanks for review.

Jerry
Jerry DeLisle - Aug. 18, 2010, 1:45 p.m.
On 08/18/2010 06:30 AM, Jerry DeLisle wrote:
> On 08/17/2010 10:58 PM, Paul Richard Thomas wrote:
>> Dear Jerry,
>>
>>> OK for trunk?
>>
>> OK but for one tiny question:
>>
>> Should you not check for parentheses, just to stop the code trying to
>> charge down, for example, binary operators? Since expr1 has been
>> resolved already at the top of resolve_code, this should not matter -
>> it's just unnecessary.
>>
>
> I was thinking of a case like this:
>
> print *, (-p)
>
> Where p is invalid. We need to drill down to run the check on it.
>
I decided to try the above case and it gets caught earlier by unary operator 
checks so your suggestion should work well.  I will regression test it and 
commit if OK.

Jerry

Patch

Index: resolve.c
===================================================================
--- resolve.c	(revision 163259)
+++ resolve.c	(working copy)
@@ -7696,7 +7696,11 @@  resolve_transfer (gfc_code *code)

   exp = code->expr1;

-  if (exp->expr_type != EXPR_VARIABLE && exp->expr_type != EXPR_FUNCTION)
+  while (exp != NULL && exp->expr_type == EXPR_OP && exp->value.op.op
== INTRINSIC_PARENTHESES)
+    exp = exp->value.op.op1;
+
+  if (exp == NULL || (exp->expr_type != EXPR_VARIABLE
+		      && exp->expr_type != EXPR_FUNCTION))
     return;