On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > bounced... again, without html. > > > Hi Richard, > > while working on another bug in the area of -fstrict-volatile-bitfields > I became aware of another example where -fstrict-volatile-bitfields may > generate > wrong code. This is reproducible on a !STRICT_ALIGNMENT target like x86_64. > > The problem is that strict_volatile_bitfield_p tries to allow more than > necessary > if !STRICT_ALIGNMENT. Everything works OK on ARM for instance. > > If this function returns true, we may later call narrow_bit_field_mem, and > the check in strict_volatile_bitfield_p should mirror the logic there: > narrow_bit_field_mem just uses GET_MODE_BITSIZE (mode) and does not > care about STRICT_ALIGNMENT, and in the end *new_bitnum + bitsize may > reach beyond the end of the region. This causes store_fixed_bit_field_1 > to silently fail to generate correct code.
Hmm, but the comment sounds like if using GET_MODE_ALIGNMENT is more correct (even for !strict-alignment) - if mode is SImode and mode alignment is 16 (HImode aligned) then we don't need to split the load if bitnum is 16 and bitsize is 32. So maybe narrow_bit_field_mem needs to be fixed as well? Thanks, Richard. > The attached patch was boot-strapped and > regression-tested on x86_64-linux-gnu. > > OK for trunk and 4.9? > > > Thanks > Bernd. >
