* [tree-ssa] bug analysis for 20000603-1.c
@ 2003-10-13 23:06 Steven Bosscher
2003-10-14 0:40 ` law
0 siblings, 1 reply; 9+ messages in thread
From: Steven Bosscher @ 2003-10-13 23:06 UTC (permalink / raw)
To: gcc; +Cc: dnovillo
Hi,
Dunno if anyone had already looked at some of the too-many failures on
tree-ssa, but I've got a reduced test case for 20000603-1.c here:
struct s1 { double d; };
struct s2 { double d; };
int
main(void)
{
struct s1 a;
a.d = 0.0;
((struct s2 *) &a)->d = 1.0;
if (a.d != 1.0)
abort ();
return 0;
}
This works at and -O1, but aborts at -O2.
Apparently there is some tree alias-analysis we do at -O2 (I didn't know
that -- what/where is it?). We mess things up there: At -O1 we properly
have a VDEF for a for the "((struct s2 *) &a)->d = 1.0;" assignment, but
at -O2 that is suddenly turned into a VDEF of a memory tag that wasn't
there before:
t12.ssa1 dump at -O1:
# a_2 = VDEF <a_1>;
a.d = 0.0;
a.1_3 = (struct s2 *)&a;
# a_4 = VDEF <a_2>;
a.1_3->d = 1.0e+0;
# VUSE <a_4>;
T.2_5 = a.d;
if (T.2_5 != 1.0e+0)
t12.ssa1 dump at -O2:
# a_2 = VDEF <a_1>;
a.d = 0.0;
a.1_3 = (struct s2 *)&a;
# MT.1_5 = VDEF <MT.1_4>;
a.1_3->d = 1.0e+0;
# VUSE <a_2>;
T.2_6 = a.d;
if (T.2_6 != 1.0e+0)
So at -O2 we fail to notice that the assignment to a.1_3 is a necessary
store, and DCE kills it: Deleting : a.1_3->d = 1.0e+0.
Gr.
Steven
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-13 23:06 [tree-ssa] bug analysis for 20000603-1.c Steven Bosscher
@ 2003-10-14 0:40 ` law
2003-10-14 0:46 ` Steven Bosscher
0 siblings, 1 reply; 9+ messages in thread
From: law @ 2003-10-14 0:40 UTC (permalink / raw)
To: Steven Bosscher; +Cc: gcc, dnovillo
In message <1066083523.27865.34.camel@steven.lr-s.tudelft.nl>, Steven Bosscher
writes:
>Hi,
>
>Dunno if anyone had already looked at some of the too-many failures on
>tree-ssa, but I've got a reduced test case for 20000603-1.c here:
>
>struct s1 { double d; };
>struct s2 { double d; };
>
>int
>main(void)
>{
> struct s1 a;
> a.d = 0.0;
> ((struct s2 *) &a)->d = 1.0;
> if (a.d != 1.0)
> abort ();
> return 0;
>}
>
>This works at and -O1, but aborts at -O2.
>
>Apparently there is some tree alias-analysis we do at -O2 (I didn't know
>that -- what/where is it?). We mess things up there: At -O1 we properly
>have a VDEF for a for the "((struct s2 *) &a)->d = 1.0;" assignment, but
>at -O2 that is suddenly turned into a VDEF of a memory tag that wasn't
>there before:
>
>t12.ssa1 dump at -O1:
> # a_2 = VDEF <a_1>;
> a.d = 0.0;
> a.1_3 = (struct s2 *)&a;
>
> # a_4 = VDEF <a_2>;
> a.1_3->d = 1.0e+0;
>
> # VUSE <a_4>;
> T.2_5 = a.d;
> if (T.2_5 != 1.0e+0)
>
>t12.ssa1 dump at -O2:
> # a_2 = VDEF <a_1>;
> a.d = 0.0;
> a.1_3 = (struct s2 *)&a;
>
> # MT.1_5 = VDEF <MT.1_4>;
> a.1_3->d = 1.0e+0;
>
> # VUSE <a_2>;
> T.2_6 = a.d;
> if (T.2_6 != 1.0e+0)
>
>So at -O2 we fail to notice that the assignment to a.1_3 is a necessary
>store, and DCE kills it: Deleting : a.1_3->d = 1.0e+0.
This testcase has been extensively analyzed. AT this time it's not 100%
clear if the code in the test is valid or not.
jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-14 0:40 ` law
@ 2003-10-14 0:46 ` Steven Bosscher
2003-10-14 0:47 ` law
2003-10-14 4:04 ` law
0 siblings, 2 replies; 9+ messages in thread
From: Steven Bosscher @ 2003-10-14 0:46 UTC (permalink / raw)
To: law; +Cc: gcc, dnovillo
Op di 14-10-2003, om 00:47 schreef law@redhat.com:
> This testcase has been extensively analyzed.
Well, mind sharing with us what other test cases have also already been
analyzed, so there's not too much duplication of effort?
> AT this time it's not 100%
> clear if the code in the test is valid or not.
It has been like this since a long time, according to
http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00081.html. Perhaps time
to get let loose the language lawyers on this one :-)
Gr.
Steven
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-14 0:46 ` Steven Bosscher
@ 2003-10-14 0:47 ` law
2003-10-14 4:04 ` law
1 sibling, 0 replies; 9+ messages in thread
From: law @ 2003-10-14 0:47 UTC (permalink / raw)
To: Steven Bosscher; +Cc: gcc, dnovillo
In message <1066085644.16921.40.camel@steven.lr-s.tudelft.nl>, Steven Bosscher
writes:
>Op di 14-10-2003, om 00:47 schreef law@redhat.com:
>> This testcase has been extensively analyzed.
>
>Well, mind sharing with us what other test cases have also already been
>analyzed, so there's not too much duplication of effort?
>
>> AT this time it's not 100%
>> clear if the code in the test is valid or not.
>
>It has been like this since a long time, according to
>http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00081.html. Perhaps time
>to get let loose the language lawyers on this one :-)
Even the language lawyers aren't exactly sure on this one...
jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-14 0:46 ` Steven Bosscher
2003-10-14 0:47 ` law
@ 2003-10-14 4:04 ` law
2003-10-14 11:37 ` Richard Henderson
1 sibling, 1 reply; 9+ messages in thread
From: law @ 2003-10-14 4:04 UTC (permalink / raw)
To: Steven Bosscher; +Cc: gcc, dnovillo
In message <1066085644.16921.40.camel@steven.lr-s.tudelft.nl>, Steven Bosscher
writes:
>Op di 14-10-2003, om 00:47 schreef law@redhat.com:
>> This testcase has been extensively analyzed.
>
>Well, mind sharing with us what other test cases have also already been
>analyzed, so there's not too much duplication of effort?
Well, I know what the tree-ssa.exp failures are since I cobbled together
most of those tests. I think everyone else just ignores them :-)
Jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-14 4:04 ` law
@ 2003-10-14 11:37 ` Richard Henderson
2003-10-14 12:01 ` Steven Bosscher
2003-10-14 16:46 ` law
0 siblings, 2 replies; 9+ messages in thread
From: Richard Henderson @ 2003-10-14 11:37 UTC (permalink / raw)
To: law; +Cc: Steven Bosscher, gcc, dnovillo
On Mon, Oct 13, 2003 at 07:45:22PM -0600, law@redhat.com wrote:
> >Well, mind sharing with us what other test cases have also already been
> >analyzed, so there's not too much duplication of effort?
> Well, I know what the tree-ssa.exp failures are since I cobbled together
> most of those tests. I think everyone else just ignores them :-)
I've been trying to work the last two weeks or so fixing or
xfailing all of them. We really need to be able to tell at
a glance whether a patch causes a regression.
r~
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-14 11:37 ` Richard Henderson
@ 2003-10-14 12:01 ` Steven Bosscher
2003-10-14 16:57 ` Richard Henderson
2003-10-14 16:46 ` law
1 sibling, 1 reply; 9+ messages in thread
From: Steven Bosscher @ 2003-10-14 12:01 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc
Op di 14-10-2003, om 09:30 schreef Richard Henderson:
> On Mon, Oct 13, 2003 at 07:45:22PM -0600, law@redhat.com wrote:
> > >Well, mind sharing with us what other test cases have also already been
> > >analyzed, so there's not too much duplication of effort?
> > Well, I know what the tree-ssa.exp failures are since I cobbled together
> > most of those tests. I think everyone else just ignores them :-)
>
> I've been trying to work the last two weeks or so fixing or
> xfailing all of them. We really need to be able to tell at
> a glance whether a patch causes a regression.
Oh, I didn't know you were going through all of 'em. I started looking
at them yesterday because there are so many and they've been around for
so long :-) There really should be a plan for what to do about all
those builtins failures...
Any reason why noreturn-1.c and return-type-1.c have the wrong line for
a warning? All other tests for these warnings have them at the right
lines.
Gr.
Steven
Index: noreturn-1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/noreturn-1.c,v
retrieving revision 1.7.28.3
diff -c -3 -p -r1.7.28.3 noreturn-1.c
*** noreturn-1.c 11 Mar 2003 00:15:13 -0000 1.7.28.3
--- noreturn-1.c 13 Oct 2003 23:27:13 -0000
*************** extern void exit (int);
*** 7,14 ****
extern void foo1(void) __attribute__ ((__noreturn__));
void
foo1(void)
! { /* { dg-warning "`noreturn' function does return" "detect falling off end of noreturn" } */
! }
extern void foo2(void) __attribute__ ((__noreturn__));
void
--- 7,14 ----
extern void foo1(void) __attribute__ ((__noreturn__));
void
foo1(void)
! {
! } /* { dg-warning "`noreturn' function does return" "detect falling off end of noreturn" } */
extern void foo2(void) __attribute__ ((__noreturn__));
void
Index: return-type-1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/return-type-1.c,v
retrieving revision 1.3.26.3
diff -c -3 -p -r1.3.26.3 return-type-1.c
*** return-type-1.c 11 Mar 2003 00:15:13 -0000 1.3.26.3
--- return-type-1.c 13 Oct 2003 23:27:13 -0000
***************
*** 5,9 ****
/* { dg-options "-O -Wreturn-type" } */
int
foo(void)
! { /* { dg-warning "control reaches end of non-void function" "warning for falling off end of non-void function" } */
! }
--- 5,9 ----
/* { dg-options "-O -Wreturn-type" } */
int
foo(void)
! {
! } /* { dg-warning "control reaches end of non-void function" "warning for falling off end of non-void function" } */
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-14 11:37 ` Richard Henderson
2003-10-14 12:01 ` Steven Bosscher
@ 2003-10-14 16:46 ` law
1 sibling, 0 replies; 9+ messages in thread
From: law @ 2003-10-14 16:46 UTC (permalink / raw)
To: Richard Henderson; +Cc: Steven Bosscher, gcc, dnovillo
In message <20031014073000.GB27340@redhat.com>, Richard Henderson writes:
>On Mon, Oct 13, 2003 at 07:45:22PM -0600, law@redhat.com wrote:
>> >Well, mind sharing with us what other test cases have also already been
>> >analyzed, so there's not too much duplication of effort?
>> Well, I know what the tree-ssa.exp failures are since I cobbled together
>> most of those tests. I think everyone else just ignores them :-)
>
>I've been trying to work the last two weeks or so fixing or
>xfailing all of them. We really need to be able to tell at
>a glance whether a patch causes a regression.
I won't disagree at all. Each merge has tended to bring in new tests
which fail for one reason or another. We tend to hit a critical mass of
failures, then someone (Diego, myself, now you) goes through and nails as
many as they can and the cycle starts again.
It's one of the reasons why I think it's critical that we be focused on the
goal of getting this work into the mainline sources. :-)
jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [tree-ssa] bug analysis for 20000603-1.c
2003-10-14 12:01 ` Steven Bosscher
@ 2003-10-14 16:57 ` Richard Henderson
0 siblings, 0 replies; 9+ messages in thread
From: Richard Henderson @ 2003-10-14 16:57 UTC (permalink / raw)
To: Steven Bosscher; +Cc: gcc
On Tue, Oct 14, 2003 at 09:42:42AM +0200, Steven Bosscher wrote:
> Any reason why noreturn-1.c and return-type-1.c have the wrong line for
> a warning? All other tests for these warnings have them at the right
> lines.
These two must have already been tweeked for the branch.
Mainline does put the warning at the end of the function,
and I had tweeked branch to match (which fixed oodles of
other tests).
r~
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-10-14 16:44 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-13 23:06 [tree-ssa] bug analysis for 20000603-1.c Steven Bosscher
2003-10-14 0:40 ` law
2003-10-14 0:46 ` Steven Bosscher
2003-10-14 0:47 ` law
2003-10-14 4:04 ` law
2003-10-14 11:37 ` Richard Henderson
2003-10-14 12:01 ` Steven Bosscher
2003-10-14 16:57 ` Richard Henderson
2003-10-14 16:46 ` law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).