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

[Paul Thomas]

Brooks,
>
> This seems to rely on the s->offset values being in ascending order; 
> otherwise there will be false positives.  Can we rely on this?
trans-common.c(add_segments) makes this so.  We can rely on it.
>
>> +  /* 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 reverted to gfc_getmem
>
>> +  memset (data, '\0', (size_t)length);
>
> I think this line should have a TODO comment above it, noting that it 
> may need to be changed (or at least looked at) when -finit-local-zero 
> sorts of options are implemented to provide values other than zero.
Done
>
> [...]
>> +  known_align = 0;
>> +  if (known_align == 0 || known_align > BIGGEST_ALIGNMENT)
>> +    known_align = BIGGEST_ALIGNMENT;
>
> This if-statement is always true, because of the preceeding line.  
> What did you really mean here?  :)
known_align = BIGGEST_ALIGNMENT;
>
> [...]
>> +  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.
Corrected using a check array.
>
> IMO, it's probably okay to go ahead and commit this with this flaw, 
> but if you do, please file a PR about it and add a TODO comment to the 
> code. Also, please assign the PR to me unless you think you'll have 
> time to fix it.  :)
Not needed - is fixed; as are the corresponding derived type problems.
>
>> +      len = len + gfc_merge_initializers (ts, c->expr, &data[len],
>> +                          length - len);
>> +
>> +      gcc_assert (len <= length);
>
> This assert is IMO unnecessary, since it can be seen solely from 
> analysis of this function that it will always be true.
Removed.
>
>> +  subroutine int4_int4
>> +      integer(4)         NUNITS(4)
>> +      integer(4)         o
>> +      equivalence (o,nunits(3))
>
> "o" seems like a singularly poor choice for a variable name, and 
> "NUNITS" looks like it should mean something but it doesn't.  Could 
> these perhaps be A and B instead?
>
>
>
Done.

In addition, equiv_7.f90 now includes the derived type example that 
Tobias provided.

The new patch is attached and will be committed, just as soon as 
regtesting is done- this is a bit of a formality because the code path 
is so specialized:)

Cheers

Paul

2007-06-11 Paul Thomas <pault@gcc.gnu.org>

    PR fortran/29786
    PR fortran/30875
    * trans-common.c (get_init_field): New function.
    (create_common): Call get_init_field for overlapping
    initializers in equivalence blocks.
    * resolve.c (resolve_equivalence_derived, resolve_equivalence):
    Remove constraints on initializers in equivalence blocks.
    * target-memory.c (expr_to_char, gfc_merge_initializers):
    New functions.
    (encode_derived): Add the bit offset to the byte offset to get
    the total offset to the field.
    * target-memory.h : Add prototype for gfc_merge_initializers.


2007-06-11 Paul Thomas <pault@gcc.gnu.org>

    PR fortran/29786
    * gfortran.dg/equiv_7.f90: New test.
    * gfortran.dg/equiv_constraint_7.f90: Change error message.


    PR fortran/30875
    * gfortran.dg/equiv_constraint_5.f90: Correct code and error.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr29786_0611.diff
Type: text/x-patch
Size: 18824 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070611/170c427a/attachment.bin>