http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> 2011-04-21 15:48:10 UTC --- On Thu, 21 Apr 2011, joseph at codesourcery dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696 > > --- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery > dot com> 2011-04-21 15:43:27 UTC --- > On Wed, 20 Apr 2011, rguenth at gcc dot gnu.org wrote: > > > > If gcc has forgotten the underlying type, and only looks at the bitfield > > > size > > > and offset, gcc will likely never do a good job at it unless gcc gets > > > _really_ > > > smart and looks at all the accesses around it and decides "I need to do > > > these > > > as 'int' just because (ie in the example, the "unsigned" base type is as > > > important as is the "bits 0..5" range information). > > > > Unfortunately the underlying type isn't easily available (at least I didn't > > yet find it ...). But I suppose we have to guess anyway considering > > targets that don't handle unaligned accesses well or packed bitfields. > > Thus, an idea was to use aligned word-size loads/stores and only at the > > start/end of a structure fall back to smaller accesses (for strict align > > targets). I still hope to eventually find that underlying type info > > somewhere ... > > The underlying type is used for -fstrict-volatile-bitfields, so it must be > available in the cases needed for that option. It relies on the mode, thus the start of the bitfield is at bitpos % mode-size and its size is mode-size if it is aligned. I'm not sure -fstrict-volatile-bitfields works for the unaligned/packed case.
