[Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562

[Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562

[jan.smets@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

            Bug ID: 58970
           Summary: internal compiler error: in get_bit_range, at
                    expr.c:4562
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.smets@alcatel-lucent.com

/tmp/minimal9.i: In function 'function':
/tmp/minimal9.i:15:28: internal compiler error: in get_bit_range, at
expr.c:4562
     pInfo->mode[x].member1 = 0;
                            ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.



struct info
{
    struct {
        unsigned char member1 : 1;
        unsigned char member2;
    } mode[1];
};

extern void call(void);

void function(int x, struct info *pInfo)
{
    if (x != -1)
        call();
    pInfo->mode[x].member1 = 0;
    if (pInfo->mode[x].member2 == (((x) == 1) ? 2 : 1))
    {
        call();
    }
}

[Bug middle-end/58970] internal compiler error: in get_bit_range, at expr.c:4562

[jan.smets@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #1 from Jan Smets <jan.smets@alcatel-lucent.com> ---
And compile with -O1 or -O2. Reproducible on x86 and mips.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
struct S
{
  struct
  {
    int b:1;
  } mode[1];
};

void
foo (int x, struct S *s)
{
  if (x == -1)
    s->mode[x].b = 0;
}

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #4 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 31145
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31145&action=edit
For a possible patch.

This patch is assuming that a statement like "s->mode[-1].b = 0;"
is basically invoking undefined behaviour, so it should not matter
if we have correct bitregion_start/end values or just set them to zero
in this case.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jan.smets@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #5 from Jan Smets <jan.smets@alcatel-lucent.com> ---
Seems to work. Thanks!

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #4)
> Created attachment 31145 [details]
> For a possible patch.
> 
> This patch is assuming that a statement like "s->mode[-1].b = 0;"
> is basically invoking undefined behaviour, so it should not matter
> if we have correct bitregion_start/end values or just set them to zero
> in this case.

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;
}

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.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

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.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #7)
> (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.

But this is really nothing the expansion code should rely on to detect if the
code is undefined behavior or not.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31147
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31147&action=edit
gcc49-pr58970.patch

Untested fix.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #10 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
but this should'nt be neccessary then?

   if (bitoffset > *bitpos)
     {
       HOST_WIDE_INT adjust = bitoffset - *bitpos;
-
       gcc_assert ((adjust % BITS_PER_UNIT) == 0);
-      gcc_assert (*offset != NULL_TREE);

       *bitpos += adjust;
-      *offset
-    = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
+      if (*offset == NULL_TREE)
+    *offset = size_int (-adjust / BITS_PER_UNIT);
+      else
+    *offset
+      = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
       *bitstart = 0;
     }

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #10)
> but this should'nt be neccessary then?
> 
>    if (bitoffset > *bitpos)
>      {
>        HOST_WIDE_INT adjust = bitoffset - *bitpos;
> -
>        gcc_assert ((adjust % BITS_PER_UNIT) == 0);
> -      gcc_assert (*offset != NULL_TREE);
>  
>        *bitpos += adjust;
> -      *offset
> -	= size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
> +      if (*offset == NULL_TREE)
> +	*offset = size_int (-adjust / BITS_PER_UNIT);
> +      else
> +	*offset
> +	  = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
>        *bitstart = 0;
>      }

Can you prove it isn't necessary?  I mean, *bitpos could still be smaller than
bitoffset, even when not negative, say with some packed+aligned structures
containing bitfields or similar.  NULL_TREE *offset is the same thing as zero
at that spot, just perhaps less efficient in that case, so I think if we can't
prove it will not be hit, it is easy to handle it.
>From gcc-bugs-return-433416-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 04 10:03:21 2013
Return-Path: <gcc-bugs-return-433416-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14955 invoked by alias); 4 Nov 2013 10:03:20 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11674 invoked by uid 48); 4 Nov 2013 10:01:17 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
Date: Mon, 04 Nov 2013 10:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-58978-4-sHUI5PeGz2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58978-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58978-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/msg00193.txt.bz2
Content-length: 401

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX978

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|mpolacek at gcc dot gnu.org        |jakub at gcc dot gnu.org

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Reassigning.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #12 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Bernd Edlinger from comment #10)
> > but this should'nt be neccessary then?
> > 
> >    if (bitoffset > *bitpos)
> >      {
> >        HOST_WIDE_INT adjust = bitoffset - *bitpos;
> > -
> >        gcc_assert ((adjust % BITS_PER_UNIT) == 0);
> > -      gcc_assert (*offset != NULL_TREE);
> >  
> >        *bitpos += adjust;
> > -      *offset
> > -	= size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
> > +      if (*offset == NULL_TREE)
> > +	*offset = size_int (-adjust / BITS_PER_UNIT);
> > +      else
> > +	*offset
> > +	  = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
> >        *bitstart = 0;
> >      }
> 
> Can you prove it isn't necessary?  I mean, *bitpos could still be smaller
> than bitoffset, even when not negative, say with some packed+aligned
> structures containing bitfields or similar.  NULL_TREE *offset is the same
> thing as zero at that spot, just perhaps less efficient in that case, so I
> think if we can't prove it will not be hit, it is easy to handle it.

hmm, my english...

I meant the change here is not necessary, because after the
if (*bitpos < 0) {...},
*offset can no longer be NULL, and I'd leave the assertion untouched.
>From gcc-bugs-return-433419-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 04 10:12:40 2013
Return-Path: <gcc-bugs-return-433419-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25309 invoked by alias); 4 Nov 2013 10:12:40 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22764 invoked by uid 48); 4 Nov 2013 10:10:38 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/51671] g++ fails to allow a redundant typedef if the redundant typedef depends on a template parameter
Date: Mon, 04 Nov 2013 10:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-51671-4-LdJGPYyWq7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-51671-4@http.gcc.gnu.org/bugzilla/>
References: <bug-51671-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/msg00196.txt.bz2
Content-length: 251

http://gcc.gnu.org/bugzilla/show_bug.cgi?idQ671

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Another testcase:

template <typename T, typename U>
struct S
{
  static void f()
  {
    typedef T q;
    typedef U q;
  }
};

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #12)
> I meant the change here is not necessary, because after the
> if (*bitpos < 0) {...},
> *offset can no longer be NULL, and I'd leave the assertion untouched.

Sure, if *bitpos was initially negative, then *offset won't be NULL there.
But what I mean, are you sure that non-negative *bitpos will never be smaller
than bitoffset if *offset is NULL?  Of course not on this testcase...

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #14 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Bernd Edlinger from comment #12)
> > I meant the change here is not necessary, because after the
> > if (*bitpos < 0) {...},
> > *offset can no longer be NULL, and I'd leave the assertion untouched.
> 
> Sure, if *bitpos was initially negative, then *offset won't be NULL there.
> But what I mean, are you sure that non-negative *bitpos will never be
> smaller than bitoffset if *offset is NULL?  Of course not on this testcase...

If *bitpos is initially negative, I can proove that *offset is initially NULL.

The second statement cannot be prooved,
because after *bitpos &= ... *bitpos is between 0..7.

For instance 

struct S
{
  struct T
  {
    int a:8;
    int b:1;
  } mode[1];
};

Consider "p->mode[-1].b = 0", I'd expect bitoffset=8, less than *bitpos=0.

Right?

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #15 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Bernd Edlinger from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > (In reply to Bernd Edlinger from comment #12)
> > > I meant the change here is not necessary, because after the
> > > if (*bitpos < 0) {...},
> > > *offset can no longer be NULL, and I'd leave the assertion untouched.
> > 
> > Sure, if *bitpos was initially negative, then *offset won't be NULL there.
> > But what I mean, are you sure that non-negative *bitpos will never be
> > smaller than bitoffset if *offset is NULL?  Of course not on this testcase...
> 
> If *bitpos is initially negative, I can proove that *offset is initially
> NULL.

However we can be sure (to assert), that if offset is initially NULL,
and *bitpos is initially >= 0, then
the bit offset of the bitfield representative must be >= 0 too.
because otherwiese, the bitfield would start at offset < 0 and end
at an offset > 0. Which is not possible.

Therefore bitoffset <= *bitpos if *bitpos is initially >= 0 and *offset is
initially == NULL. QED?

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #15)
> (In reply to Bernd Edlinger from comment #14)
> > (In reply to Jakub Jelinek from comment #13)
> > > (In reply to Bernd Edlinger from comment #12)
> > > > I meant the change here is not necessary, because after the
> > > > if (*bitpos < 0) {...},
> > > > *offset can no longer be NULL, and I'd leave the assertion untouched.
> > > 
> > > Sure, if *bitpos was initially negative, then *offset won't be NULL there.
> > > But what I mean, are you sure that non-negative *bitpos will never be
> > > smaller than bitoffset if *offset is NULL?  Of course not on this testcase...
> > 
> > If *bitpos is initially negative, I can proove that *offset is initially
> > NULL.
> 
> However we can be sure (to assert), that if offset is initially NULL,
> and *bitpos is initially >= 0, then
> the bit offset of the bitfield representative must be >= 0 too.
> because otherwiese, the bitfield would start at offset < 0 and end
> at an offset > 0. Which is not possible.

Why is it not possible?
struct __attribute__((packed, aligned (2))) T { int a : 31; int b : 1; };
void
foo (char *p)
{
  ((struct T *)(p - 2))->b = 1;
}
Here, *bitpos could be (at least in theory) 15, while bitoffset 31 and *offset
could still be NULL_TREE, because the bitpos fits in signed HWI.
Again, perhaps it is right now optimized into a MEM_REF and get_bit_range won't
see that, but can you rule that out just because of that?

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #17 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
struct T {
  unsigned char b : 8;
  unsigned char s : 1;
};

struct S {
  char x;
  struct T t[1];
};

void function(int x, struct S *p)
{
  if (x == -1)
    p->t[x].s = 0;
}

another test case. so this is possible...

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #18 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Well, how about this version?
Does'nt it look like a much smaller change?

--- expr.c.jj    2013-10-31 14:57:05.000000000 +0100
+++ expr.c    2013-11-04 12:51:55.013931114 +0100
@@ -4582,7 +4582,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b
       HOST_WIDE_INT adjust = bitoffset - *bitpos;

       gcc_assert ((adjust % BITS_PER_UNIT) == 0);
-      gcc_assert (*offset != NULL_TREE);
+      if (*offset == NULL_TREE)
+    *offset = size_zero_node;

       *bitpos += adjust;
       *offset

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #18)
> Well, how about this version?
> Does'nt it look like a much smaller change?
> 
> --- expr.c.jj	2013-10-31 14:57:05.000000000 +0100
> +++ expr.c	2013-11-04 12:51:55.013931114 +0100
> @@ -4582,7 +4582,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b
>        HOST_WIDE_INT adjust = bitoffset - *bitpos;
>  
>        gcc_assert ((adjust % BITS_PER_UNIT) == 0);
> -      gcc_assert (*offset != NULL_TREE);
> +      if (*offset == NULL_TREE)
> +	*offset = size_zero_node;
>  
>        *bitpos += adjust;
>        *offset

But you then have undefined behavior if *bitpos is HOST_WIDE_INT_MIN.  Or could
for very small other *bitpos and not really small bitoffset, etc.  And, while
you save a few characters on the line, it means it is more expensive at
runtime.
>From gcc-bugs-return-433436-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 04 14:07:54 2013
Return-Path: <gcc-bugs-return-433436-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28948 invoked by alias); 4 Nov 2013 14:07:53 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27785 invoked by uid 48); 4 Nov 2013 14:05:50 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
Date: Mon, 04 Nov 2013 14:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords target_milestone
Message-ID: <bug-58944-4-ORN2ZPNnDy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58944-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58944-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/msg00213.txt.bz2
Content-length: 477

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX944

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
   Target Milestone|---                         |4.9.0

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like a system_header check doesn't work anymore.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
Eric declared negative bitpos to be a nono that the expander is not handling
well.  Thus, Eric, please chime in here.

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If expansion has issues with that, then supposedly the
+  if (*bitpos < 0)
+    {
+      gcc_assert (*offset == NULL_TREE);
+      *offset = size_int (*bitpos >> (BITS_PER_UNIT == 8
+                                     ? 3 : exact_log2 (BITS_PER_UNIT)));
+      *bitpos &= BITS_PER_UNIT - 1;
+    }
hunk with s/\*//g could be moved to the get_bit_range caller, right above the
call.  But, do we have testcases that fail now?

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #22 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Eric declared negative bitpos to be a nono that the expander is not handling
> well.  Thus, Eric, please chime in here.

Well, that's a basic sanity requirement, all the routines in expmed.c dealing
with bitfields use unsigned HOST_WIDE_INT so, yes, better avoid negative values
unless you really know what you're doing...

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #23 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
hmm...

all examples I can see, where bitpos is negative,
or less than the representative's bitoffset with offset=NULL,
are just blandtly invalid.

The only valid example would be

struct S { unsigned char s : 1; };
void function(struct S *p)
{
  p[-1].s = 0;
}

However this one is gimplified to

  D.1590 = p + -1;
  D.1590->s = 0;

no ARRAY_REFs at all, never.

Handling all that negative bitoffsets seems to be
a bit too much complication just to generate
valid code for invalid C.

At least returning negative bitoffset could be easily
avoided in get_inner_reference:

--- expr.c.jj    2013-10-31 14:57:05.000000000 +0100
+++ expr.c    2013-11-05 09:24:39.821624212 +0100
@@ -6708,7 +6708,7 @@
       tem = tem.sext (TYPE_PRECISION (sizetype));
       tem = tem.lshift (BITS_PER_UNIT == 8 ? 3 : exact_log2 (BITS_PER_UNIT));
       tem += bit_offset;
-      if (tem.fits_shwi ())
+      if (tem.fits_shwi () && !tem.is_negative ())
     {
       *pbitpos = tem.to_shwi ();
       *poffset = offset = NULL_TREE;

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #31145|0                           |1
        is obsolete|                            |

--- Comment #24 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 31169
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31169&action=edit
Another (better) attempt at fixing this ICE.

This avoids any negative bitpos from get_inner_reference.
These negative bitpos values are just _very_ dangerous all the
way down to expmed.c

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Nov  6 07:48:50 2013
New Revision: 204444

URL: http://gcc.gnu.org/viewcvs?rev=204444&root=gcc&view=rev
Log:
    PR middle-end/58970
    * expr.c (get_bit_range): Handle *offset == NULL_TREE.
    (expand_assignment): If *bitpos is negative, set *offset
    and adjust *bitpos, so that it is not negative.

    * gcc.c-torture/compile/pr58970.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr58970-1.c
    trunk/gcc/testsuite/gcc.c-torture/compile/pr58970-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jan.smets@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #28 from Jan Smets <jan.smets@alcatel-lucent.com> ---
Can this be backported to 4.8 please.
Thanks

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Nov 11 07:57:11 2013
New Revision: 204663

URL: http://gcc.gnu.org/viewcvs?rev=204663&root=gcc&view=rev
Log:
    Backported from mainline
    2013-11-06  Jakub Jelinek  <jakub@redhat.com>

    PR middle-end/58970
    * expr.c (get_bit_range): Handle *offset == NULL_TREE.
    (expand_assignment): If *bitpos is negative, set *offset
    and adjust *bitpos, so that it is not negative.

    * gcc.c-torture/compile/pr58970-1.c: New test.
    * gcc.c-torture/compile/pr58970-2.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/compile/pr58970-1.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/compile/pr58970-2.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/expr.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jan.smets@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #30 from Jan Smets <jan.smets@alcatel-lucent.com> ---
Thanks!

[Bug middle-end/58970] [4.7 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
      Known to work|                            |4.9.0
            Summary|[4.7/4.8/4.9 Regression]    |[4.7 Regression] internal
                   |internal compiler error: in |compiler error: in
                   |get_bit_range, at           |get_bit_range, at
                   |expr.c:4562                 |expr.c:4562

[Bug middle-end/58970] [4.7 Regression] internal compiler error: in get_bit_range, at expr.c:4562

[jan.smets@alcatel-lucent.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Jan Smets <jan.smets@alcatel-lucent.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #31 from Jan Smets <jan.smets@alcatel-lucent.com> ---
Fixed in 4.8 and newer.