[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-fortran
Subject:    Re: [patch, fortran] Fix PR 83012, rejects-valid regression with contiguous pointer
From:       Thomas Koenig <tkoenig () netcologne ! de>
Date:       2017-11-18 15:48:35
Message-ID: c2f975f6-58c9-5083-8420-97a73f33bead () netcologne ! de
[Download RAW message or body]

Steve,

>> +	  for (r = expr->ref; r; r = r->next)
>> +	    if (r->type == REF_COMPONENT)
>> +	      rc = r;
> 
> Should you have a break here?  As I understand it, you're walking a
> list, so you could have r, r->next, r->next->next, and so on.   Is
> it possible to have r->next->type = REF_COMPONENT and
> r->next->next->type = REF_COMPONENT, where you end up with the wrong
> one?

The point is to have the last of the r->next->next->next chain that
is a REF_COMPONENT (which I assign to rc, which I later use).

In the test case, it is indeed expr->ref->next that is of
interest, but there could be other references in between,
the type could be part of another type or there could be an
array reference - thus the loop, which should catch such
cases.

I tried to come up with a test case that breaks the patch, but I didn't
manage to do so.

Here's part of a debug session on the test case (breakpoint was in
gfc_is_simply_contiguous, the second time it was hit):

(gdb) p expr->ref->next.u.c.component
$13 = (gfc_component *) 0x23f1e90
(gdb) p expr->ref->next.u.c.component->ts.interface
$14 = (gfc_symbol *) 0x23ee510
(gdb) p expr->ref->next.u.c.component->ts.interface->attr.contiguous
$16 = 1

Regards

	Thomas
[prev in list] [next in list] [prev in thread] [next in thread]