This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]