This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/31309] 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
- From: "matz at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Jan 2008 10:32:07 -0000
- Subject: [Bug middle-end/31309] 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
- References: <bug-31309-12838@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #18 from matz at gcc dot gnu dot org 2008-01-09 10:32 -------
It seems that this should work too: bitsize is 8 in this example IIRC, so
copy_mode would be byte_mode, which is what we need here. Additionally using
word_mode when we can seems worthwhile too.
One thing would bother me, though: If TYPE_ALIGN(type) is very funny, then
bitsize is too, so that mode_for_size could return BLKmode, so word_mode would
be chosen to copy, which might then trip over the same problem. But for that
TYPE_ALIGN must be so funny like 3 bits, i.e. something for which no INT mode
exists. I believe it's impossible that TYPE_ALIGN is neither a multiple of
word_mode nor a number for which mode_for_size ever returns BLKmode (i.e.
either it returns BLKmode, but then only for very large aligns, which are
multiples of word_mode, or it will return something != BLKmode, which we then
can use).
IOW: it's impossible that TYPE_ALIGN ever is something like 3*BITS_PER_UNIT.
So, with that "argumentation" I think this would work, except for my probably
theoretical fear from comment #9, that the mode argument for extract_bit_field
is only a suggestion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309