------- Comment #4 from taschna at uni-muenster dot de 2006-07-31 06:32 -------
(In reply to comment #3)
Steve,
> Thanks for the patch, but I think it is only covering up the real
> problem. It's more a question of "why is it a NULL pointer?" not
> whether we can work around the NULL pointer. I suspect that some
> where in resolve.c, gfortran is not properly setting/propagating
> information about optional arguments and entry statements.
looking at the dump of the original tree below I would say that
it is okay to have the arguments n and vector equal NULL in
case of the call from nranin. The main problem is the code
emitted by gfc_trans_g77_array before the entry master switch.
The best solution in my opionion would be to emit the code in
the block following label L.2, but I didn't know how to do
this. Therefore I propose to do the same as we do in
gfc_trans_dummy_array_bias since revision 86128 (committed by Paul Brook)
and emit an if block surrounding the offending code.
---
MAIN__ ()
{
_gfortran_set_std (70, 127, 0);
{
real4 C.687 = 5.4321e+4;
nranin (&C.687);
}
nran (vector, n)
{
master.0.nran (0, 0B, n, vector);
nranin (v)
{
master.0.nran (1, v, 0B, 0B);
master.0.nran (__entry, v, n, vector)
{
int4 i;
int4 ubound.0;
int4 size.1;
int4 D.723;
bit_size_type D.724;
<unnamed type> D.725;
ubound.0 = *n;
size.1 = NON_LVALUE_EXPR <ubound.0>;
D.723 = size.1 - 1;
D.724 = (bit_size_type) (<unnamed type>) size.1 * 32;
D.725 = (<unnamed type>) size.1 * 4;
switch (__entry)
{
case 0:;
goto L.2;
case 1:;
goto L.4;
}
L.2:;
{
int4 D.716;
D.716 = *n;
i = 1;
if (i <= D.716)
{
while (1)
{
{
logical4 D.720;
(*vector)[NON_LVALUE_EXPR <i> + -1] = rndm (&i);
L.5:;
D.720 = i == D.716;
i = i + 1;
if (D.720) goto L.6; else (void) 0;
}
}
}
else
{
(void) 0;
}
L.6:;
}
goto __return_master.0.nran;
L.4:;
rdmin (v);
goto __return_master.0.nran;
__return_master.0.nran:;
}
rdmin (v)
{
(void) 0;
rndm (i)
{
real4 __result_rndm;
__result_rndm = (real4) *i;
return __result_rndm;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
