This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] Remove "keep_aligning" from get_inner_reference


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.
 		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]