* [Bug middle-end/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
@ 2008-03-11 12:04 ` pinskia at gcc dot gnu dot org
2008-03-11 14:24 ` hjl dot tools at gmail dot com
` (37 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-03-11 12:04 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
Keywords| |wrong-code
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug middle-end/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
2008-03-11 12:04 ` [Bug middle-end/35518] " pinskia at gcc dot gnu dot org
@ 2008-03-11 14:24 ` hjl dot tools at gmail dot com
2008-03-15 19:20 ` rguenth at gcc dot gnu dot org
` (36 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: hjl dot tools at gmail dot com @ 2008-03-11 14:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from hjl dot tools at gmail dot com 2008-03-11 14:24 -------
Which revision isn't OK?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug middle-end/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
2008-03-11 12:04 ` [Bug middle-end/35518] " pinskia at gcc dot gnu dot org
2008-03-11 14:24 ` hjl dot tools at gmail dot com
@ 2008-03-15 19:20 ` rguenth at gcc dot gnu dot org
2008-03-30 15:34 ` pinskia at gcc dot gnu dot org
` (35 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-03-15 19:20 UTC (permalink / raw)
To: gcc-bugs
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu dot
| |org
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug middle-end/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (2 preceding siblings ...)
2008-03-15 19:20 ` rguenth at gcc dot gnu dot org
@ 2008-03-30 15:34 ` pinskia at gcc dot gnu dot org
2008-03-31 6:30 ` [Bug tree-optimization/35518] " pinskia at gcc dot gnu dot org
` (34 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-03-30 15:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 15:33 -------
I also see this failure on powerpc-darwin after changing MOVE_RATIO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (3 preceding siblings ...)
2008-03-30 15:34 ` pinskia at gcc dot gnu dot org
@ 2008-03-31 6:30 ` pinskia at gcc dot gnu dot org
2008-04-02 20:02 ` pinskia at gcc dot gnu dot org
` (33 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-03-31 6:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-31 06:30 -------
retmeN is being miscompiled by SRA, at least for powerpc-darwin with a changed
MOVE_RATIO.
retmeN (x)
{
<unnamed-unsigned:29> x$i;
<unnamed-unsigned:23> x$j;
long long unsigned int SR.21;
<bb 2>:
x$j = x.j;
x$i = x.i;
x.j = x$j;
x.i = x$i;
SR.21 = VIEW_CONVERT_EXPR<long long unsigned int>(x);
<retval>.i = x$i;
<retval>.j = x$j;
<retval> = VIEW_CONVERT_EXPR<struct N>((long long unsigned int)
((<unnamed-unsigned:12>) (SR.21 >> 52) >> 4) << 52 | VIEW_CONVERT_EXPR<long
long unsigned int>(<retval>) & 4503599627370495);
return <retval>;
}
This also produces way crappy code rather just doing a non bit-field copy. I
don't know what SRA is trying to prove here. The Move ratio value I changed
rs6000 to is 5 and this is definitely more than 5 words.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Component|middle-end |tree-optimization
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-03-31 06:30:07
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (4 preceding siblings ...)
2008-03-31 6:30 ` [Bug tree-optimization/35518] " pinskia at gcc dot gnu dot org
@ 2008-04-02 20:02 ` pinskia at gcc dot gnu dot org
2008-04-02 20:02 ` pinskia at gcc dot gnu dot org
` (32 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-04-02 20:02 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (5 preceding siblings ...)
2008-04-02 20:02 ` pinskia at gcc dot gnu dot org
@ 2008-04-02 20:02 ` pinskia at gcc dot gnu dot org
2008-04-27 18:02 ` danglin at gcc dot gnu dot org
` (31 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-04-02 20:02 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-02 20:01 -------
spu-elf also fails the same way.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
GCC build triplet|hppa2.0w-hp-hpux11.11 |
GCC host triplet|hppa2.0w-hp-hpux11.11 |
GCC target triplet|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11, spu-
| |elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (6 preceding siblings ...)
2008-04-02 20:02 ` pinskia at gcc dot gnu dot org
@ 2008-04-27 18:02 ` danglin at gcc dot gnu dot org
2008-04-29 16:09 ` dave at hiauly1 dot hia dot nrc dot ca
` (30 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: danglin at gcc dot gnu dot org @ 2008-04-27 18:02 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from danglin at gcc dot gnu dot org 2008-04-27 18:01 -------
I first saw this in 133010.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (7 preceding siblings ...)
2008-04-27 18:02 ` danglin at gcc dot gnu dot org
@ 2008-04-29 16:09 ` dave at hiauly1 dot hia dot nrc dot ca
2008-04-30 11:51 ` rguenth at gcc dot gnu dot org
` (29 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-04-29 16:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-04-29 16:08 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> I first saw this in 133010.
It was introduced in 132969.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (8 preceding siblings ...)
2008-04-29 16:09 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-04-30 11:51 ` rguenth at gcc dot gnu dot org
2008-05-29 18:38 ` dave at hiauly1 dot hia dot nrc dot ca
` (28 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-04-30 11:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-30 11:50 -------
Can you reduce the testcase so I can try to analyze this with a cross?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (9 preceding siblings ...)
2008-04-30 11:51 ` rguenth at gcc dot gnu dot org
@ 2008-05-29 18:38 ` dave at hiauly1 dot hia dot nrc dot ca
2008-06-22 20:03 ` danglin at gcc dot gnu dot org
` (27 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-05-29 18:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-05-29 18:37 -------
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
> Can you reduce the testcase so I can try to analyze this with a cross?
Here is a somewhat reduced testcase. The problem is with long long.
Dave
------- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2008-05-29 18:37 -------
Created an attachment (id=15703)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15703&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (10 preceding siblings ...)
2008-05-29 18:38 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-06-22 20:03 ` danglin at gcc dot gnu dot org
2008-06-22 20:05 ` dave at hiauly1 dot hia dot nrc dot ca
` (26 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: danglin at gcc dot gnu dot org @ 2008-06-22 20:03 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from danglin at gcc dot gnu dot org 2008-06-22 20:02 -------
The same change gcc.c-torture/execute/20040709-2.c on all hppa targets
(both 32 and 64 bit). On hppa64-hp-hpux11.11, testK is the first test
to fail. In this case, it appears retmeK is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (11 preceding siblings ...)
2008-06-22 20:03 ` danglin at gcc dot gnu dot org
@ 2008-06-22 20:05 ` dave at hiauly1 dot hia dot nrc dot ca
2008-06-22 20:45 ` danglin at gcc dot gnu dot org
` (25 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-06-22 20:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 20:04 -------
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
> to fail. In this case, it appears retmeK is miscompiled.
Simplified test attached.
Dave
------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 20:04 -------
Created an attachment (id=15805)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15805&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (12 preceding siblings ...)
2008-06-22 20:05 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-06-22 20:45 ` danglin at gcc dot gnu dot org
2008-06-22 21:14 ` rguenther at suse dot de
` (24 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: danglin at gcc dot gnu dot org @ 2008-06-22 20:45 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from danglin at gcc dot gnu dot org 2008-06-22 20:44 -------
retmeK (struct K x)
{
<unnamed-unsigned:10> SR.14;
<unnamed-unsigned:15> SR.13;
<unnamed-unsigned:7> SR.12;
<unnamed-unsigned:10> SR.11;
<unnamed-unsigned:15> SR.10;
<unnamed-unsigned:15> x$i;
<unnamed-unsigned:10> x$j;
<unnamed-unsigned:7> x$B0F7;
struct K D.1258;
<bb 2>:
x$B0F7_1 = 0;
x$j_2 = 0;
x$i_3 = 0;
SR.13_4 = x.i;
x$i_5 = SR.13_4;
SR.14_6 = x.j;
x$j_7 = SR.14_6;
x$B0F7_8 = BIT_FIELD_REF <x, 7, 0>;
D.1258.i ={v} x$i_5;
D.1258.j ={v} x$j_7;
SR.12_9 = x$B0F7_8 >> 1;
BIT_FIELD_REF <D.1258, 7, 0> ={v} SR.12_9;
return D.1258;
}
Don't understand...
At -O0, we just have
retmeK (struct K x)
{
struct K D.1260;
<bb 2>:
D.1260 = x;
return D.1260;
}
and it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (13 preceding siblings ...)
2008-06-22 20:45 ` danglin at gcc dot gnu dot org
@ 2008-06-22 21:14 ` rguenther at suse dot de
2008-06-22 21:34 ` dave at hiauly1 dot hia dot nrc dot ca
` (23 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2008-06-22 21:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from rguenther at suse dot de 2008-06-22 21:13 -------
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Sun, 22 Jun 2008, danglin at gcc dot gnu dot org wrote:
> ------- Comment #13 from danglin at gcc dot gnu dot org 2008-06-22 20:44 -------
> retmeK (struct K x)
> {
> <unnamed-unsigned:10> SR.14;
> <unnamed-unsigned:15> SR.13;
> <unnamed-unsigned:7> SR.12;
> <unnamed-unsigned:10> SR.11;
> <unnamed-unsigned:15> SR.10;
> <unnamed-unsigned:15> x$i;
> <unnamed-unsigned:10> x$j;
> <unnamed-unsigned:7> x$B0F7;
> struct K D.1258;
>
> <bb 2>:
> x$B0F7_1 = 0;
> x$j_2 = 0;
> x$i_3 = 0;
> SR.13_4 = x.i;
> x$i_5 = SR.13_4;
> SR.14_6 = x.j;
> x$j_7 = SR.14_6;
> x$B0F7_8 = BIT_FIELD_REF <x, 7, 0>;
> D.1258.i ={v} x$i_5;
> D.1258.j ={v} x$j_7;
> SR.12_9 = x$B0F7_8 >> 1;
> BIT_FIELD_REF <D.1258, 7, 0> ={v} SR.12_9;
> return D.1258;
>
> }
>
> Don't understand...
>
> At -O0, we just have
>
> retmeK (struct K x)
> {
> struct K D.1260;
>
> <bb 2>:
> D.1260 = x;
> return D.1260;
>
> }
>
> and it works.
Well, SRA is broken (cost-wise at least) since lxos changes.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (14 preceding siblings ...)
2008-06-22 21:14 ` rguenther at suse dot de
@ 2008-06-22 21:34 ` dave at hiauly1 dot hia dot nrc dot ca
2008-06-22 22:24 ` rguenther at suse dot de
` (22 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-06-22 21:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 21:34 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> > x$B0F7_8 = BIT_FIELD_REF <x, 7, 0>;
> > D.1258.i ={v} x$i_5;
> > D.1258.j ={v} x$j_7;
> > SR.12_9 = x$B0F7_8 >> 1;
> > BIT_FIELD_REF <D.1258, 7, 0> ={v} SR.12_9;
> > return D.1258;
> Well, SRA is broken (cost-wise at least) since lxos changes.
Why the shift? It seems incorrect.
SRA also seems to be manipulating the k and l fields together for
some reason. Why not all the fields since K is packed and the total
bit length is less than a word?
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (15 preceding siblings ...)
2008-06-22 21:34 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-06-22 22:24 ` rguenther at suse dot de
2008-06-22 22:44 ` dave at hiauly1 dot hia dot nrc dot ca
` (21 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2008-06-22 22:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from rguenther at suse dot de 2008-06-22 22:23 -------
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Sun, 22 Jun 2008, dave at hiauly1 dot hia dot nrc dot ca wrote:
>
>
> ------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 21:34 -------
> Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
> execution at -O2 and above
>
> > > x$B0F7_8 = BIT_FIELD_REF <x, 7, 0>;
> > > D.1258.i ={v} x$i_5;
> > > D.1258.j ={v} x$j_7;
> > > SR.12_9 = x$B0F7_8 >> 1;
> > > BIT_FIELD_REF <D.1258, 7, 0> ={v} SR.12_9;
> > > return D.1258;
>
> > Well, SRA is broken (cost-wise at least) since lxos changes.
>
> Why the shift? It seems incorrect.
It looks like it is only assigning the 6-bit part of the k, l
combination. Is the above after the SRA pass in question or after
some more optimizations?
Eventually this is a bit-field-ref vs. BITS_BIG_ENDIAN/BYTES_BIG_ENDIAN
issue -- it was never clear to me how the bit-field position in
a bit-field-ref relates to those.
> SRA also seems to be manipulating the k and l fields together for
> some reason. Why not all the fields since K is packed and the total
> bit length is less than a word?
The cost metric is of course simply broken.
I'll try to investigate at some point with a cross.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (16 preceding siblings ...)
2008-06-22 22:24 ` rguenther at suse dot de
@ 2008-06-22 22:44 ` dave at hiauly1 dot hia dot nrc dot ca
2008-06-23 13:39 ` rguenth at gcc dot gnu dot org
` (20 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-06-22 22:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 22:43 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> > ------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 21:34 -------
> > Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
> > execution at -O2 and above
> >
> > > > x$B0F7_8 = BIT_FIELD_REF <x, 7, 0>;
> > > > D.1258.i ={v} x$i_5;
> > > > D.1258.j ={v} x$j_7;
> > > > SR.12_9 = x$B0F7_8 >> 1;
> > > > BIT_FIELD_REF <D.1258, 7, 0> ={v} SR.12_9;
> > > > return D.1258;
> >
> > > Well, SRA is broken (cost-wise at least) since lxos changes.
> >
> > Why the shift? It seems incorrect.
>
> It looks like it is only assigning the 6-bit part of the k, l
> combination. Is the above after the SRA pass in question or after
> some more optimizations?
It appears first in the esra pass dump:
;; Function retmeK (retmeK)
Initial instantiation for x
Using element-copy for x
x$B0F7 -> x$B0F7
x.j -> x$j
x.i -> x$i
Initial instantiation for D.1258
Using block-copy for D.1258
Symbols to be put in SSA form
{ x x$B0F7 x$j x$i SR.10 SR.11 SR.12 SR.13 SR.14 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (17 preceding siblings ...)
2008-06-22 22:44 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-06-23 13:39 ` rguenth at gcc dot gnu dot org
2008-06-24 19:11 ` dave at hiauly1 dot hia dot nrc dot ca
` (19 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-06-23 13:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from rguenth at gcc dot gnu dot org 2008-06-23 13:39 -------
Created an attachment (id=15807)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15807&action=view)
patch
This "fixes" it for me. Can you check on hppa?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (18 preceding siblings ...)
2008-06-23 13:39 ` rguenth at gcc dot gnu dot org
@ 2008-06-24 19:11 ` dave at hiauly1 dot hia dot nrc dot ca
2008-06-25 8:42 ` rguenth at gcc dot gnu dot org
` (18 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-06-24 19:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-24 19:10 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> This "fixes" it for me. Can you check on hppa?
It also works on hppa. Tested on hhpa-unknown-linux-gnu and
hppa64-hp-hpux11.11.
Thanks,
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (19 preceding siblings ...)
2008-06-24 19:11 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-06-25 8:42 ` rguenth at gcc dot gnu dot org
2008-06-25 10:06 ` rguenth at gcc dot gnu dot org
` (17 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-06-25 8:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from rguenth at gcc dot gnu dot org 2008-06-25 08:41 -------
Subject: Bug 35518
Author: rguenth
Date: Wed Jun 25 08:41:14 2008
New Revision: 137100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137100
Log:
2008-06-25 Richard Guenther <rguenther@suse.de>
PR tree-optimization/35518
* fold-const.c (fold_ternary): Strip trivial BIT_FIELD_REFs.
* tree-sra.c (instantiate_element): Use fold_build3 to build
BIT_FIELD_REFs.
(try_instantiate_multiple_fields): Likewise.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/tree-sra.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (20 preceding siblings ...)
2008-06-25 8:42 ` rguenth at gcc dot gnu dot org
@ 2008-06-25 10:06 ` rguenth at gcc dot gnu dot org
2008-06-25 20:21 ` aoliva at gcc dot gnu dot org
` (16 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-06-25 10:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from rguenth at gcc dot gnu dot org 2008-06-25 10:05 -------
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (21 preceding siblings ...)
2008-06-25 10:06 ` rguenth at gcc dot gnu dot org
@ 2008-06-25 20:21 ` aoliva at gcc dot gnu dot org
2008-06-25 21:49 ` rguenther at suse dot de
` (15 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2008-06-25 20:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from aoliva at gcc dot gnu dot org 2008-06-25 20:20 -------
Sorry that it took me so long to look at this.
Richi, I have a feeling that your patch will just paper over the problem.
See, if we take a bit-range that's not the entire bit-field, it will emit the
same shifts, and it will break in the same way.
The problem is that there's a disconnect between the width of the underlying
mode/type and the width of the variable in which it is held.
When I introduced bit-fields in SRA, one of my goals was to introduce scalars
for "remaining" fields (i.e., those that didn't get scalar versions of their
own) in such a way that no extraneous shifting was needed: we'd just extract
the bits without shifting them around, for this would be just wasted
computation. It sufficed to apply masks to recombine these remaining fields
into their proper place.
Now, when you changed type from a mode-sized type to a nonstandard
bitfield-sized type and replaced some bitfield references with plain
conversions, you broke this property and removed the fix-ups that would have
taken care of ensuring the shifts (if any) matched.
At least that's my impression from looking at the dumps posted here, your
recent patch to work around the exposed problem and your earlier patch that
introduced it.
--
aoliva at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu dot
| |org
Status|RESOLVED |REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (22 preceding siblings ...)
2008-06-25 20:21 ` aoliva at gcc dot gnu dot org
@ 2008-06-25 21:49 ` rguenther at suse dot de
2008-06-26 0:35 ` aoliva at gcc dot gnu dot org
` (14 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2008-06-25 21:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from rguenther at suse dot de 2008-06-25 21:48 -------
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Wed, 25 Jun 2008, aoliva at gcc dot gnu dot org wrote:
> ------- Comment #22 from aoliva at gcc dot gnu dot org 2008-06-25 20:20 -------
> Sorry that it took me so long to look at this.
>
> Richi, I have a feeling that your patch will just paper over the problem.
I know.
> See, if we take a bit-range that's not the entire bit-field, it will emit the
> same shifts, and it will break in the same way.
>
> The problem is that there's a disconnect between the width of the underlying
> mode/type and the width of the variable in which it is held.
>
> When I introduced bit-fields in SRA, one of my goals was to introduce scalars
> for "remaining" fields (i.e., those that didn't get scalar versions of their
> own) in such a way that no extraneous shifting was needed: we'd just extract
> the bits without shifting them around, for this would be just wasted
> computation. It sufficed to apply masks to recombine these remaining fields
> into their proper place.
>
> Now, when you changed type from a mode-sized type to a nonstandard
> bitfield-sized type and replaced some bitfield references with plain
> conversions, you broke this property and removed the fix-ups that would have
> taken care of ensuring the shifts (if any) matched.
The _result_ type is what I changed. The result type of a BIT_FIELD_REF
needs to match the bitfield width. If you can point out where I changed
the field type that is referenced then you have found the error.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (23 preceding siblings ...)
2008-06-25 21:49 ` rguenther at suse dot de
@ 2008-06-26 0:35 ` aoliva at gcc dot gnu dot org
2008-06-26 9:34 ` rguenther at suse dot de
` (13 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2008-06-26 0:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from aoliva at gcc dot gnu dot org 2008-06-26 00:33 -------
It's not just the result type that changed. You actually changed the type of
the variable created to hold the group of bit fields, out of which we further
extract members that were not mapped to separate variables. This might affect
bitfield simplifications based on mode size rather than type width. I can't
say that's it, but I know I may have based some code on this assumption that
you broke.
It also seems to me that this change to the base type of the variable breaks
sra_build_elt_assignment(), because the by-design conditions might no longer be
met. Finally, I don't see how you could assume that the else block for the if
full-width bit-field could be extracted with as little as a cast.
This is what jumped at me at first. I haven't actually built compilers based
on the state before and after your patch to tell whether that's it, but these
are the most likely culprits.
I hope this helps,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (24 preceding siblings ...)
2008-06-26 0:35 ` aoliva at gcc dot gnu dot org
@ 2008-06-26 9:34 ` rguenther at suse dot de
2008-06-26 18:14 ` aoliva at gcc dot gnu dot org
` (12 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2008-06-26 9:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from rguenther at suse dot de 2008-06-26 09:33 -------
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Thu, 26 Jun 2008, aoliva at gcc dot gnu dot org wrote:
> ------- Comment #24 from aoliva at gcc dot gnu dot org 2008-06-26 00:33 -------
> It's not just the result type that changed. You actually changed the type of
> the variable created to hold the group of bit fields, out of which we further
> extract members that were not mapped to separate variables. This might affect
> bitfield simplifications based on mode size rather than type width. I can't
> say that's it, but I know I may have based some code on this assumption that
> you broke.
>
> It also seems to me that this change to the base type of the variable breaks
> sra_build_elt_assignment(), because the by-design conditions might no longer be
> met. Finally, I don't see how you could assume that the else block for the if
> full-width bit-field could be extracted with as little as a cast.
>
> This is what jumped at me at first. I haven't actually built compilers based
> on the state before and after your patch to tell whether that's it, but these
> are the most likely culprits.
>
> I hope this helps,
No, sorry. Please point me to the place where I changed the type of the
variable created to hold the group of bit fields.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (25 preceding siblings ...)
2008-06-26 9:34 ` rguenther at suse dot de
@ 2008-06-26 18:14 ` aoliva at gcc dot gnu dot org
2008-08-16 23:42 ` pinskia at gcc dot gnu dot org
` (11 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2008-06-26 18:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from aoliva at gcc dot gnu dot org 2008-06-26 18:13 -------
The place where you said you were just changing the type of the result. Note
that it's that type that determines the type of the scalar variable created to
hold the group. If it differs from the expected type, the type of the
BIT_FIELD_EXPR is adjusted *after* the temporary is created in
instantiate_missing_elements_1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (26 preceding siblings ...)
2008-06-26 18:14 ` aoliva at gcc dot gnu dot org
@ 2008-08-16 23:42 ` pinskia at gcc dot gnu dot org
2008-09-01 17:41 ` danglin at gcc dot gnu dot org
` (10 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-08-16 23:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from pinskia at gcc dot gnu dot org 2008-08-16 23:41 -------
Fixed for spu between:
-LAST_UPDATED: Thu May 8 15:05:11 UTC 2008 (revision 135088)
+LAST_UPDATED: Sun Jun 29 21:32:49 UTC 2008 (revision 137266)
And for PPC (with the cost change);
-LAST_UPDATED: Mon Jun 23 19:12:32 UTC 2008 (revision 137049)
+LAST_UPDATED: Tue Jul 8 16:22:03 UTC 2008 (revision 137638)
Any news on a patch that does not paper over the issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (27 preceding siblings ...)
2008-08-16 23:42 ` pinskia at gcc dot gnu dot org
@ 2008-09-01 17:41 ` danglin at gcc dot gnu dot org
2008-09-01 18:18 ` dave at hiauly1 dot hia dot nrc dot ca
` (9 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: danglin at gcc dot gnu dot org @ 2008-09-01 17:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from danglin at gcc dot gnu dot org 2008-09-01 17:40 -------
On hppa64-hp-hpux11.11, the test still fails at certain optimizations:
FAIL: gcc.c-torture/execute/20040709-1.c execution, -O0
FAIL: gcc.c-torture/execute/20040709-1.c execution, -O1
# ./xgcc -B./ -v
Reading specs from ./specs
Target: hppa64-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --disable-nls
--with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.4.0
--build=hppa64-hp-hpux11.11 --enable-threads=posix --disable-libmudflap
--with-gmp=/opt/gnu64/gcc/gcc-4.4.0 --enable-languages=c++
Thread model: posix
gcc version 4.4.0 20080831 (experimental) [trunk revision 139820] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (28 preceding siblings ...)
2008-09-01 17:41 ` danglin at gcc dot gnu dot org
@ 2008-09-01 18:18 ` dave at hiauly1 dot hia dot nrc dot ca
2008-09-02 9:17 ` rguenther at suse dot de
` (8 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-09-01 18:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-01 18:17 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> On hppa64-hp-hpux11.11, the test still fails at certain optimizations:
>
> FAIL: gcc.c-torture/execute/20040709-1.c execution, -O0
> FAIL: gcc.c-torture/execute/20040709-1.c execution, -O1
I'm also seeing the following two fails which appear at first sight to
be related:
FAIL: gcc.c-torture/execute/920908-2.c execution, -O0
FAIL: gcc.c-torture/execute/920908-2.c execution, -O1
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (29 preceding siblings ...)
2008-09-01 18:18 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-09-02 9:17 ` rguenther at suse dot de
2008-10-23 15:14 ` jakub at gcc dot gnu dot org
` (7 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2008-09-02 9:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #30 from rguenther at suse dot de 2008-09-02 09:16 -------
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Mon, 1 Sep 2008, dave at hiauly1 dot hia dot nrc dot ca wrote:
> ------- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-01 18:17 -------
> Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
> execution at -O2 and above
>
> > On hppa64-hp-hpux11.11, the test still fails at certain optimizations:
> >
> > FAIL: gcc.c-torture/execute/20040709-1.c execution, -O0
> > FAIL: gcc.c-torture/execute/20040709-1.c execution, -O1
>
> I'm also seeing the following two fails which appear at first sight to
> be related:
>
> FAIL: gcc.c-torture/execute/920908-2.c execution, -O0
> FAIL: gcc.c-torture/execute/920908-2.c execution, -O1
Interesting. The -O0 failure hints at either wrong IL from the start,
problems with expansion or with the backend itself (expansion of
bitfield operations nowadays expects to be able to truncate intermediate
results to the respective bitfield precision, in former times this
was not done).
Please try to reduce these large testcases and analyze the -O0 failure.
Thanks,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (30 preceding siblings ...)
2008-09-02 9:17 ` rguenther at suse dot de
@ 2008-10-23 15:14 ` jakub at gcc dot gnu dot org
2008-10-23 16:02 ` dave at hiauly1 dot hia dot nrc dot ca
` (6 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jakub at gcc dot gnu dot org @ 2008-10-23 15:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #31 from jakub at gcc dot gnu dot org 2008-10-23 15:13 -------
Both testcases involve passing of small structures, so might as well be the PA
small struct passing bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (31 preceding siblings ...)
2008-10-23 15:14 ` jakub at gcc dot gnu dot org
@ 2008-10-23 16:02 ` dave at hiauly1 dot hia dot nrc dot ca
2008-10-29 8:30 ` jakub at gcc dot gnu dot org
` (5 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-10-23 16:02 UTC (permalink / raw)
To: gcc-bugs
------- Comment #32 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-23 16:00 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> Both testcases involve passing of small structures, so might as well be the PA
> small struct passing bug.
Both testcases are fixed by Jakub's proposed fix for PR middle-end/37316.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (32 preceding siblings ...)
2008-10-23 16:02 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-10-29 8:30 ` jakub at gcc dot gnu dot org
2008-10-29 15:01 ` dave at hiauly1 dot hia dot nrc dot ca
` (4 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jakub at gcc dot gnu dot org @ 2008-10-29 8:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #33 from jakub at gcc dot gnu dot org 2008-10-29 08:29 -------
In this case they should be fixed with your backend change too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (33 preceding siblings ...)
2008-10-29 8:30 ` jakub at gcc dot gnu dot org
@ 2008-10-29 15:01 ` dave at hiauly1 dot hia dot nrc dot ca
2008-11-21 21:30 ` steven at gcc dot gnu dot org
` (3 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-10-29 15:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #34 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-29 15:00 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> In this case they should be fixed with your backend change too.
No, my change was only for the 64-bit targets. 32-bit targets
including hppa2.0w-hp-hpux11.11 pad downward.
The reason this PR is still open is comment #22.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (34 preceding siblings ...)
2008-10-29 15:01 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-11-21 21:30 ` steven at gcc dot gnu dot org
2008-11-21 22:27 ` dave at hiauly1 dot hia dot nrc dot ca
` (2 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: steven at gcc dot gnu dot org @ 2008-11-21 21:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #35 from steven at gcc dot gnu dot org 2008-11-21 21:29 -------
So is there a test case with current top-of-trunk that fails? This is marked
as a P1 regression, but IIUC we don't even have a test case, after Jakub's fix
for PR37316 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (35 preceding siblings ...)
2008-11-21 21:30 ` steven at gcc dot gnu dot org
@ 2008-11-21 22:27 ` dave at hiauly1 dot hia dot nrc dot ca
2008-11-21 23:20 ` jakub at gcc dot gnu dot org
2008-11-22 20:59 ` jakub at gcc dot gnu dot org
38 siblings, 0 replies; 40+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2008-11-21 22:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #36 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-21 22:26 -------
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> ------- Comment #35 from steven at gcc dot gnu dot org 2008-11-21 21:29 -------
> So is there a test case with current top-of-trunk that fails? This is marked
> as a P1 regression, but IIUC we don't even have a test case, after Jakub's fix
> for PR37316 ?
As noted in comment #34, the original PR was for the 32-bit target
hppa2.0w-hp-hpux11.11. The small struct fix that I applied for PR37316
doesn't affect this target.
Unless Alex can come up with a testcase to demonstrate his point, I
think the PR should be closed.
As a side note, I might have missed it, but I don't think Jakub's
change has been approved. I can improve the backend code if it is
approved.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (36 preceding siblings ...)
2008-11-21 22:27 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2008-11-21 23:20 ` jakub at gcc dot gnu dot org
2008-11-22 20:59 ` jakub at gcc dot gnu dot org
38 siblings, 0 replies; 40+ messages in thread
From: jakub at gcc dot gnu dot org @ 2008-11-21 23:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #37 from jakub at gcc dot gnu dot org 2008-11-21 23:18 -------
It hasn't been, I've pinged it 10 days ago, will try again next Monday.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
2008-03-09 22:23 [Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above danglin at gcc dot gnu dot org
` (37 preceding siblings ...)
2008-11-21 23:20 ` jakub at gcc dot gnu dot org
@ 2008-11-22 20:59 ` jakub at gcc dot gnu dot org
38 siblings, 0 replies; 40+ messages in thread
From: jakub at gcc dot gnu dot org @ 2008-11-22 20:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #38 from jakub at gcc dot gnu dot org 2008-11-22 20:58 -------
Closing, if somebody comes up with a testcase, please reopen.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
^ permalink raw reply [flat|nested] 40+ messages in thread