[Patch, fortran] PR29786 - [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented

[Brooks Moses]

At 12:56 AM 6/9/2007, Paul Thomas wrote:
>Tobias had already taken a look at this and found a flaw involving derived 
>types that I was intending to fix this weekend.

Ok -- somehow I had missed that!

>>I think this is OK to commit, modulo a few questions/comments mentioned 
>>below, and one PR that will need to be filed against it.
>I was aware of some of your points and was hoping to address them before 
>resubmission.  However, I will take your review to give me the green light 
>to commit, once I have sorted them out.

That sounds reasonable to me.

>>>+  /* Now absorb all the initializer data into a single vector,
>>>+     whilst checking for overlapping, unequal values.  */
>>>+  data = (unsigned char*)alloca ((size_t)length);
>>
>>For large arrays, the data array could be quite large.  Do we really want 
>>to use alloca to put it on the stack?
>I did wonder about this when I changed from get_mem to alloca - I was of 
>the opinion that this equivalencing could/should only be done for small 
>arrays.  I'll revert it.

I think the relevant distinction there is that equivalencing with 
overlapping initializers probably _should_ only be done for small arrays, 
but there's no limit on what _can_ be done, so we should be prepared for it.

>>[...]
>>>+  for (i = 0; i < (int)len; i++)
>>>+    {
>>>+      if (data[i] && (check[i] != data[i]))
>>>+    {
>>>+      gfc_error ("Overlapping unequal initializers in EQUIVALENCE "
>>>+             "at %L", &e->where);
>>>+      return 0;
>>>+    }
>>>+    }
>>
>>This will, of course, fail to detect the overlapping unequal initializers 
>>if the first one is initializing things to zero.
>
>And this is at the root of the problem with derived types.  A previous 
>version had another array, matching 'data', that was filled with OxFF's 
>for every initialised element of the equivalence.  I might have to revert 
>to that.

That was essentially how I was expecting to solve it.  There are 
optimizations that can be done -- using a bitmap instead of a char array 
for recording the "initialized" information to save 87% of the space, for 
instance -- but I think that we are going to need to explicitly store that 
information somehow.

Alternately, you could go through the loop for creating the data array 
twice, using this check on the second time.  In that case, you'll only get 
this false positive if all of the things that access a given memory spot 
are initializing it to zero, which makes it actually a true positive.  :)

I think either of those approaches would be acceptable.  Whichever way you 
fix it, though, I think it would be good to add a testcase that confirms 
that we correctly find the error for EQUIVALENCE I, J; INTEGER :: I = 0, J 
= 1 or something of that nature.

In either case, a tricky piece is likely to be how derived types with 
default initializers for some components but not others are handled; you 
want to make sure that only the initialized bytes are recorded as 
initialized.  If that ends up getting complicated and you want me to have a 
look over the "fixed" version before you submit it, let me know.

- Brooks