This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: [RFC] When adding an offset to a lo_sum containing a symbol, check it is in range of the symbol's alignment
- From: Andrew Bennett <Andrew dot Bennett at imgtec dot com>
- To: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Robert Suchanek <Robert dot Suchanek at imgtec dot com>
- Date: Tue, 5 Apr 2016 15:20:09 +0000
- Subject: RE: [RFC] When adding an offset to a lo_sum containing a symbol, check it is in range of the symbol's alignment
- Authentication-results: sourceware.org; auth=none
- References: <0DA23CC379F5F945ACB41CF394B982776A65A0BF at LEMAIL01 dot le dot imgtec dot org> <5702D200 dot 2050102 at redhat dot com>
> It almost sounds like you need to be preventing the compiler from
> considering a lo_sum (whatever) as an offsettable memory address when
> the underlying object has had its alignment decreased from its natural
> alignment.
>
> I wouldn't be at all surprised if you do this you won't see the calls
> into adjust_address_1 occurring in the first place.
This would be a little heavy handed as the issue only happens in the case where
a high part calculation is used by multiple low part calculations. So far I have
found that this happens when we have to lower a DI mode load/store into two SI mode
load/stores where different offsets are applied to each load/store. I have found a case
in the MIPS backend where this occurs, and also when we are expanding a bitfield
load/store to RTL, but I am sure there are others. My worry is that it could be
hard to track down all cases that generate invalid lo_sums, and therefore it could
be easier to just perform the fixup in adjust_address_1.
Regards,
Andrew