* [Bug middle-end/58970] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
@ 2013-11-02 10:17 ` jan.smets@alcatel-lucent.com
2013-11-02 13:38 ` [Bug middle-end/58970] [4.7/4.8/4.9 Regression] " mpolacek at gcc dot gnu.org
` (27 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jan.smets@alcatel-lucent.com @ 2013-11-02 10:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
2013-11-02 10:17 ` [Bug middle-end/58970] " jan.smets@alcatel-lucent.com
@ 2013-11-02 13:38 ` mpolacek at gcc dot gnu.org
2013-11-03 19:16 ` bernd.edlinger at hotmail dot de
` (26 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2013-11-02 13:38 UTC (permalink / raw)
To: gcc-bugs
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;
}
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
2013-11-02 10:17 ` [Bug middle-end/58970] " jan.smets@alcatel-lucent.com
2013-11-02 13:38 ` [Bug middle-end/58970] [4.7/4.8/4.9 Regression] " mpolacek at gcc dot gnu.org
@ 2013-11-03 19:16 ` bernd.edlinger at hotmail dot de
2013-11-04 0:56 ` jan.smets@alcatel-lucent.com
` (25 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-03 19:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (2 preceding siblings ...)
2013-11-03 19:16 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 0:56 ` jan.smets@alcatel-lucent.com
2013-11-04 8:41 ` jakub at gcc dot gnu.org
` (24 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jan.smets@alcatel-lucent.com @ 2013-11-04 0:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #5 from Jan Smets <jan.smets@alcatel-lucent.com> ---
Seems to work. Thanks!
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (3 preceding siblings ...)
2013-11-04 0:56 ` jan.smets@alcatel-lucent.com
@ 2013-11-04 8:41 ` jakub at gcc dot gnu.org
2013-11-04 9:00 ` bernd.edlinger at hotmail dot de
` (23 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 8:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (4 preceding siblings ...)
2013-11-04 8:41 ` jakub at gcc dot gnu.org
@ 2013-11-04 9:00 ` bernd.edlinger at hotmail dot de
2013-11-04 9:31 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-04 9:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (5 preceding siblings ...)
2013-11-04 9:00 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 9:31 ` jakub at gcc dot gnu.org
2013-11-04 9:32 ` jakub at gcc dot gnu.org
` (21 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 9:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (6 preceding siblings ...)
2013-11-04 9:31 ` jakub at gcc dot gnu.org
@ 2013-11-04 9:32 ` jakub at gcc dot gnu.org
2013-11-04 9:54 ` bernd.edlinger at hotmail dot de
` (20 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 9:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (7 preceding siblings ...)
2013-11-04 9:32 ` jakub at gcc dot gnu.org
@ 2013-11-04 9:54 ` bernd.edlinger at hotmail dot de
2013-11-04 10:01 ` jakub at gcc dot gnu.org
` (19 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-04 9:54 UTC (permalink / raw)
To: gcc-bugs
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;
}
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (8 preceding siblings ...)
2013-11-04 9:54 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 10:01 ` jakub at gcc dot gnu.org
2013-11-04 10:07 ` bernd.edlinger at hotmail dot de
` (18 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 10:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (9 preceding siblings ...)
2013-11-04 10:01 ` jakub at gcc dot gnu.org
@ 2013-11-04 10:07 ` bernd.edlinger at hotmail dot de
2013-11-04 10:12 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-04 10:07 UTC (permalink / raw)
To: gcc-bugs
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;
}
};
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (10 preceding siblings ...)
2013-11-04 10:07 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 10:12 ` jakub at gcc dot gnu.org
2013-11-04 10:32 ` bernd.edlinger at hotmail dot de
` (16 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 10:12 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (11 preceding siblings ...)
2013-11-04 10:12 ` jakub at gcc dot gnu.org
@ 2013-11-04 10:32 ` bernd.edlinger at hotmail dot de
2013-11-04 11:07 ` bernd.edlinger at hotmail dot de
` (15 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-04 10:32 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (12 preceding siblings ...)
2013-11-04 10:32 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 11:07 ` bernd.edlinger at hotmail dot de
2013-11-04 11:30 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-04 11:07 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (13 preceding siblings ...)
2013-11-04 11:07 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 11:30 ` jakub at gcc dot gnu.org
2013-11-04 11:46 ` bernd.edlinger at hotmail dot de
` (13 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 11:30 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (14 preceding siblings ...)
2013-11-04 11:30 ` jakub at gcc dot gnu.org
@ 2013-11-04 11:46 ` bernd.edlinger at hotmail dot de
2013-11-04 12:10 ` bernd.edlinger at hotmail dot de
` (12 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-04 11:46 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (15 preceding siblings ...)
2013-11-04 11:46 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 12:10 ` bernd.edlinger at hotmail dot de
2013-11-04 12:15 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-04 12:10 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (16 preceding siblings ...)
2013-11-04 12:10 ` bernd.edlinger at hotmail dot de
@ 2013-11-04 12:15 ` jakub at gcc dot gnu.org
2013-11-04 14:28 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 12:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (17 preceding siblings ...)
2013-11-04 12:15 ` jakub at gcc dot gnu.org
@ 2013-11-04 14:28 ` rguenth at gcc dot gnu.org
2013-11-04 16:02 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-11-04 14:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (18 preceding siblings ...)
2013-11-04 14:28 ` rguenth at gcc dot gnu.org
@ 2013-11-04 16:02 ` jakub at gcc dot gnu.org
2013-11-04 17:55 ` ebotcazou at gcc dot gnu.org
` (8 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-04 16:02 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (19 preceding siblings ...)
2013-11-04 16:02 ` jakub at gcc dot gnu.org
@ 2013-11-04 17:55 ` ebotcazou at gcc dot gnu.org
2013-11-05 8:28 ` bernd.edlinger at hotmail dot de
` (7 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2013-11-04 17:55 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (20 preceding siblings ...)
2013-11-04 17:55 ` ebotcazou at gcc dot gnu.org
@ 2013-11-05 8:28 ` bernd.edlinger at hotmail dot de
2013-11-05 19:37 ` bernd.edlinger at hotmail dot de
` (6 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-05 8:28 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (21 preceding siblings ...)
2013-11-05 8:28 ` bernd.edlinger at hotmail dot de
@ 2013-11-05 19:37 ` bernd.edlinger at hotmail dot de
2013-11-06 7:50 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: bernd.edlinger at hotmail dot de @ 2013-11-05 19:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (22 preceding siblings ...)
2013-11-05 19:37 ` bernd.edlinger at hotmail dot de
@ 2013-11-06 7:50 ` jakub at gcc dot gnu.org
2013-11-06 14:11 ` jan.smets@alcatel-lucent.com
` (4 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-06 7:50 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (23 preceding siblings ...)
2013-11-06 7:50 ` jakub at gcc dot gnu.org
@ 2013-11-06 14:11 ` jan.smets@alcatel-lucent.com
2013-11-11 7:57 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jan.smets@alcatel-lucent.com @ 2013-11-06 14:11 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (24 preceding siblings ...)
2013-11-06 14:11 ` jan.smets@alcatel-lucent.com
@ 2013-11-11 7:57 ` jakub at gcc dot gnu.org
2013-11-11 9:41 ` jan.smets@alcatel-lucent.com
` (2 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-11 7:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (25 preceding siblings ...)
2013-11-11 7:57 ` jakub at gcc dot gnu.org
@ 2013-11-11 9:41 ` jan.smets@alcatel-lucent.com
2013-11-19 13:33 ` [Bug middle-end/58970] [4.7 " rguenth at gcc dot gnu.org
2014-04-23 12:39 ` jan.smets@alcatel-lucent.com
28 siblings, 0 replies; 30+ messages in thread
From: jan.smets@alcatel-lucent.com @ 2013-11-11 9:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #30 from Jan Smets <jan.smets@alcatel-lucent.com> ---
Thanks!
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (26 preceding siblings ...)
2013-11-11 9:41 ` jan.smets@alcatel-lucent.com
@ 2013-11-19 13:33 ` rguenth at gcc dot gnu.org
2014-04-23 12:39 ` jan.smets@alcatel-lucent.com
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-11-19 13:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug middle-end/58970] [4.7 Regression] internal compiler error: in get_bit_range, at expr.c:4562
2013-11-02 10:16 [Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562 jan.smets@alcatel-lucent.com
` (27 preceding siblings ...)
2013-11-19 13:33 ` [Bug middle-end/58970] [4.7 " rguenth at gcc dot gnu.org
@ 2014-04-23 12:39 ` jan.smets@alcatel-lucent.com
28 siblings, 0 replies; 30+ messages in thread
From: jan.smets@alcatel-lucent.com @ 2014-04-23 12:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread