http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
Andreas Krebbel <krebbel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |krebbel at gcc dot gnu.org
--- Comment #4 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-02-25
14:08:20 UTC ---
I also see uninit-13.c failing on s390x.
The warning here is also emitted for line 7 while being expected in
line 8.
4 typedef _Complex float C;
5 C foo()
6 {
7 C f;
8 __imag__ f = 0; /* { dg-warning "is used" "unconditional" } */
9 return f;
10 }
The question is why do we expect the warning in line 8 at all?! To me
it makes sense to either emit the warning on the uninitialized use -
that would be the "return f;" in line 9 or emit it for the declaration
of the uninitialized variable - that would be line 7 then.
To my understanding line 8 is the only one not directly related to the
warning.
warn_uninit in tree-ssa.c seems to implement exactly this. It uses
either the location of the using gimple expression if available or it
falls back to the var decl. On s390x I see the var decl being used as
location while for x86_64 there is a stmt having its own location which
is used instead.
x86_64: uninit-13.c.083t.dce2:
foo ()
{
float f$real;
C f;
<bb 2>:
[gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR <f$real_5(D),
0.0>;
return f_3;
}
s390x: uninit-13.i.083t.dce2
foo ()
{
float f$real;
<bb 2>:
REALPART_EXPR <<retval>> = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <<retval>> = 0.0;
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return <retval>;
}
Before dce2 the line with the COMPLEX_EXPR exists also on s390x:
s390x: uninit-13.i.082t.reassoc1:
foo ()
{
float f$real;
C f;
float D.2702;
<bb 2>:
[gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f$real_2 = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR <f$real_6(D),
0.0>;
REALPART_EXPR <<retval>> = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <<retval>> = 0.0;
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return <retval>;
}
I think first we should fix the testcase - moving the warning one line
up and then find a way to fix the x86_64 problem. To me it currently
looks like this is a testcase bug.
