Hi Eric,
On Wed, 14 May 2014 09:28:55, Eric Botcazou wrote:
>
>>> So does this remove the last concern around Bernd's patch?
>>
>> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
>> by obj-c/c++ as well, but I can't find such use)
>
> Probably but, as previously indicated, I need to do some testing first.
>
> --
> Eric Botcazou
Ok sure, I'll be patient...
If I remove this line, the build fails:
gcc-interface/decl.c:gnat_to_gnu_entity:
/* Tell the middle-end that objects of tagged types are guaranteed to
be properly aligned. This is necessary because conversions to the
class-wide type are translated into conversions to the root type,
which can be less aligned than some of its derived types. */
if (Is_Tagged_Type (gnat_entity)
|| Is_Class_Wide_Equivalent_Type (gnat_entity))
TYPE_ALIGN_OK (gnu_type) = 1;
but only because this bit is read back in the ada/gcc-interface.
If I apply my patch, and additionally remove this line in expr.c,
which is one of the last references to TYPE_ALIGN_OK in the middle-end:
if (TYPE_ALIGN_OK (type))
{
/* ??? Copying the MEM without substantially changing it might
run afoul of the code handling volatile memory references in
store_expr, which assumes that TARGET is returned unmodified
if it has been used. */
op0 = copy_rtx (op0);
set_mem_align (op0, MAX (MEM_ALIGN (op0), TYPE_ALIGN (type)));
}
nothing changes. All test cases pass, and again I can not see any difference in
the
generated code (I compare gcc/ada/*.o with and without patch).
So, currently I am under the impression that TYPE_ALIGN_OK has some relevance
to the Ada front-end, but it should not be used in the middle-end and certainly
not
in the back-end.
Bernd.
