This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
- From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 02 Sep 2013 23:35:16 +0000
- Subject: [Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
- Auto-submitted: auto-generated
- References: <bug-57748-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #24 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 30743
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30743&action=edit
Yet another untested fix
Ok, this is somewhat similar to Martin's very first attempt
to fix this.
After staring at the code for quite a long time,
I believe the misalign code path is meant for structures
or unions that can be accessed in a mode != BLKmode which
is the mode of the largest member of a union for instance.
But if that mode has a movmisalign op that should be used.
However that is only an optimization, store_field will always
be able to store the value byte by byte if necessary.
If offset != 0 we have a non-constant (or maybe negative)
array index here.
If volatile we have a volatile access.
If bitpos + bitsize > GET_MODE_BITSIZE we probably
have an array with a constant index.
If any of these happens, better not go the misalign code path.
The second hunk is necessary because the if block
sets bitpos = 0, but leaves bitregion_start and bitregion_end untouched,
creating an inconsistent bitregion, which may or may not assert later.
Therefore check that this is no bitregion. If it is a bit region
store_field can handle it.
How do you like this patch?