http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Jakub Jelinek from comment #6)
> That doesn't look safe, negative rbitpos is not necessarily undefined
> behavior.
> Can't you get the same with say
> struct S { unsigned char s : 1; };
>
> ...
> void function(struct S *p)
> {
> p[-1].s = 0;
> }
no. I checked that. This is folded quite differently:
MEM[(struct S *)p_1(D) + -1B].s = 0;
and there is no ICE in this case.
> Apparently get_inner_reference only gives negative bitpos if offset is
> NULL_TREE, otherwise it adjusts offset such that the bitpos is positive.
> I wonder if get_bit_range shouldn't do the same thing if it detects *bitpos
> is negative and *offset is NULL_TREE before doing the bitoffset > *bitpos
> comparison. It might be as easy as replacing the
> gcc_assert (*offset != NULL_TREE);
> with if (*offset == NULL_TREE) *offset = size_int (0);
> Of course, the comment would need to be adjusted.
That would work. But if all these negative bit-pos are due to
invalid code as I'd curently expect, we could also just stop generating
code for this type of access, to reduce code size.
What I'm kind of worried here, is that bitpos is signed int,
and bitregion_start/end is unsigned int, and later in the expmed.c
all that stuff is passed as unsigned int bitnum/bitsize.
Therefore, it would make sense to avoid all negative bitpos in
get_inner_reference, but probably only if there exist _valid_ code
with negative bitpos.
