Re: SIGSEV in user-defined elemental function

[Paul Thomas <paulthomas2 at wanadoo dot fr>]

Daniel,

If I replace the write statement in your example by an assignment, for 
the sake of clarity, the main program produces the following code.

MAIN__ ()
{
 logical4 ans[100];
 struct array1_atype t;
 static logical4 func (struct atype &);

 t.data = 0B;
 _gfortran_set_std (70, 127, 0);
 t.data = 0B;
 {
   int4 D.1008;
   int4 D.1007;
   int4 D.1006;
   struct atype[0:] * D.1005;

   D.1005 = (struct atype[0:] *) t.data;
   D.1006 = t.offset;
   D.1007 = t.dim[0].lbound;
   D.1008 = D.1007 + -1;
   {
     int4 D.1010;
     int4 S.0;

     D.1010 = t.dim[0].stride;
     S.0 = 1;
     while (1)
       {
         if (S.0 > 100) goto L.1; else (void) 0;
         ans[NON_LVALUE_EXPR <S.0> + -1] = func 
(&(*D.1005)[(NON_LVALUE_EXPR <S.0> + D.1008) * D.1010 + D.1006]);
         S.0 = S.0 + 1;
       }
     L.1:;
   }
 }
}

The &(*D.1005)[(NON_LVALUE_EXPR <S.0> + D.1008) * D.1010 + D.1006] is 
something of a problem in runtime!

The dereferencing of D.1005, or of t.data, is what produces the 
segfault.  It seems to me that you are obliged to check the status of 
the pointer when using it; in this case in the main program.

I would be dead against putting default runtime checks in there but if 
anybody feels motivated to do it, an option could be added to check 
pointer actual arguments, if the formal argument is not a pointer.  This 
could be part of -fbounds-check, for the sake of economy and 
convenience.  In this context, if the write statement is replaced by and 
assignment to an array, -fbounds-check picks up the mismatch in array size.

Cheers

Paul