From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-433401-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17485 invoked by alias); 4 Nov 2013 09:00:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 16972 invoked by uid 48); 4 Nov 2013 08:58:01 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
Date: Mon, 04 Nov 2013 09:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58970-4-aZibAZ2z8Q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58970-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58970-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00178.txt.bz2

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.