On Tue, 3 Dec 2013 22:55:32, Jef Law wrote: > > On 12/03/13 06:27, Bernd Edlinger wrote: >>> This comment is completely out of sync: There is no longer any force_reg in >>> that if-block, >>> and a constant address in TO_RTX has SImode or DImode in GET_MODE (XEXP >>> (to_rtx, 0)) >>> I do not know how to make it a VOIDmode, therefore the comment does not >>> help either. > I thought that comment looked familiar... That's because it was mine... > > The way that was triggered in the past can be found in this ancient posting: > > http://gcc.gnu.org/ml/gcc-patches/1999-03n/msg00654.html > > The code went through a major revamp in 2002 which removed the force_reg > calls without updating/removing the comment. > > Additionally, the way we represent and thus ultimately expand the memory > reference has changed in ways that make it harder, if not impossible to > have a constant address at these points. Even if were to hack up the > expanders to force a constant address rather than a REG it's still > nontrivial to get into that code with a constant address. > > I wouldn't be terribly surprised to find all kinds of dead code in the > expanders. > > So the comment clearly needs to get zapped. > > As for the consistency of bitregion_start/bitregion_end, I'm just not > familiar enough with this code or the issues for the C++ memory model to > comment. > > jeff
Thanks for this info. Regarding the consistency of bitregion_start/end , they should either both be zero, or bitregion_start <= bitpos && bitpos+bitsize-1 <= bitregion_end of course bitregion_start/end should be on byte-boundarys. So if I set bitpos=0, I must move bitregion_start/end accordingly. Of course bitregion_start can not become negative. Therefore I set it to zero, store_bit_field would never try to write at negative offsets anyway. This stuff with the bit region was introduced recently, and this if-block has been overlooked then. Thanks Bernd.
