[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||thopre01 at gcc dot gnu.org Known to work||5.0 Resolution|--- |FIXED --- Comment #38 from thopre01 at gcc dot gnu.org --- Solved in GCC 5.0 as of r210200, no backport intended.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #37 from jye2 at gcc dot gnu.org --- Author: jye2 Date: Thu May 8 01:23:01 2014 New Revision: 210200 URL: http://gcc.gnu.org/viewcvs?rev=210200&root=gcc&view=rev Log: 2014-05-07 Thomas Preud'homme PR middle-end/39246 * tree-complex.c (expand_complex_move): Keep line info when expanding complex move. * tree-ssa-uninit.c (warn_uninit): New argument. Ignore assignment of complex expression. Use new argument to display correct location for values coming from phi statement. (warn_uninitialized_vars): Adapt to new signature of warn_uninit. (warn_uninitialized_phi): Pass location of phi argument to warn_uninit. * tree-ssa.c (ssa_undefined_value_p): For SSA_NAME initialized by a COMPLEX_EXPR, recurse on each part of the COMPLEX_EXPR. testsuite: * gcc.dg/uninit-13.c: Move warning on the actual source line where the uninitialized complex is used. * gcc.dg/uninit-17.c: New test to check partial initialization of complex with branches. * gcc.dg/uninit-17-O0.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/uninit-17-O0.c trunk/gcc/testsuite/gcc.dg/uninit-17.c
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #36 from jye2 at gcc dot gnu.org --- Author: jye2 Date: Thu May 8 01:20:17 2014 New Revision: 210199 URL: http://gcc.gnu.org/viewcvs?rev=210199&root=gcc&view=rev Log: 2014-05-07 Thomas Preud'homme PR middle-end/39246 * tree-complex.c (expand_complex_move): Keep line info when expanding complex move. * tree-ssa-uninit.c (warn_uninit): New argument. Ignore assignment of complex expression. Use new argument to display correct location for values coming from phi statement. (warn_uninitialized_vars): Adapt to new signature of warn_uninit. (warn_uninitialized_phi): Pass location of phi argument to warn_uninit. * tree-ssa.c (ssa_undefined_value_p): For SSA_NAME initialized by a COMPLEX_EXPR, recurse on each part of the COMPLEX_EXPR. testsuite: * gcc.dg/uninit-13.c: Move warning on the actual source line where the uninitialized complex is used. * gcc.dg/uninit-17.c: New test to check partial initialization of complex with branches. * gcc.dg/uninit-17-O0.c: Likewise. Modified: trunk/gcc/testsuite/gcc.dg/uninit-13.c trunk/gcc/tree-complex.c trunk/gcc/tree-ssa-uninit.c trunk/gcc/tree-ssa.c
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #35 from jye2 at gcc dot gnu.org --- Author: jye2 Date: Thu May 8 01:19:11 2014 New Revision: 210198 URL: http://gcc.gnu.org/viewcvs?rev=210198&root=gcc&view=rev Log: 2014-05-07 Thomas Preud'homme PR middle-end/39246 * tree-complex.c (expand_complex_move): Keep line info when expanding complex move. * tree-ssa-uninit.c (warn_uninit): New argument. Ignore assignment of complex expression. Use new argument to display correct location for values coming from phi statement. (warn_uninitialized_vars): Adapt to new signature of warn_uninit. (warn_uninitialized_phi): Pass location of phi argument to warn_uninit. * tree-ssa.c (ssa_undefined_value_p): For SSA_NAME initialized by a COMPLEX_EXPR, recurse on each part of the COMPLEX_EXPR. testsuite: * gcc.dg/uninit-13.c: Move warning on the actual source line where the uninitialized complex is used. * gcc.dg/uninit-17.c: New test to check partial initialization of complex with branches. * gcc.dg/uninit-17-O0.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #34 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #33 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #32 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #31 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #30 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #29 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #28 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #27 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #26 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #25 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #24 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #23 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #22 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #21 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #20 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #19 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #18 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #17 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #16 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #15 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #14 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #13 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 Thomas Preud'homme changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #12 from Thomas Preud'homme --- A patch to fix this is currently under discussion on gcc-patches at: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00164.html
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #11 from Manuel López-Ibáñez ---
(In reply to meadori from comment #10)
> I just bumped into this again while looking through some XFAILS.
> I think Andreas' analysis is correct, but I am not sure how to
> fix the problem.
This explanation would be clearer if you used the option -lineno (or -all) when
dumping.
Ideally, the warning should be given in "return f". Perhaps there is a way to
adjust the locations?
I guess that for:
4 typedef _Complex float C;
5 C foo()
6 {
7C f;
8__imag__ f = 0; /* { dg-warning "is used" "unconditional" } */
__real__ f = 0;
9return f;
10 }
there is no warning, no?
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
meadori at gcc dot gnu.org changed:
What|Removed |Added
CC||meadori at gcc dot gnu.org
--- Comment #10 from meadori at gcc dot gnu.org ---
I just bumped into this again while looking through some XFAILS.
I think Andreas' analysis is correct, but I am not sure how to
fix the problem.
Note that for ARM that the test passes for '-mfloat-abi=hard'.
For `arm-none-eabi-gcc -O -Wuninitialized` we get:
original
{
C f;
C f;
IMAGPART_EXPR = 0.0;
return f;
}
gimple
==
foo ()
{
float D.4063;
C f;
; NOTE: The partial store was promoted to a total store which
; introduces the 'REALPART_EXPR ' bit.
D.4063 = REALPART_EXPR ;
f = COMPLEX_EXPR ;
= f;
return ;
}
cplxlower1
==
foo ()
{
float f$real;
C f;
:
f$real_2 = f$real_6(D);
f_3 = COMPLEX_EXPR ;
REALPART_EXPR <> = f$real_2;
IMAGPART_EXPR <> = 0.0;
return ;
}
dce2
foo ()
{
float f$real;
C f;
:
; NOTE: Warning about unused variable on next statement, which is
; associated with the 'C f;' declaration because the statements
; below as introduced by cplxlower1 don't have any location info.
REALPART_EXPR <> = f$real_6(D);
IMAGPART_EXPR <> = 0.0;
return ;
}
For `arm-none-eabi-gcc -O -Wuninitialized -mfloat-abi=hard` things are very
similar until we get to complex lowering:
gimple
==
foo ()
{
float D.4062;
C D.4063;
C f;
; NOTE: The partial store was promoted to a total store which
; introduces the 'REALPART_EXPR ' bit.
D.4062 = REALPART_EXPR ;
f = COMPLEX_EXPR ;
D.4063 = f;
return D.4063;
}
cplxlower1
==
foo ()
{
float f$real;
C f;
:
f$real_2 = f$real_5(D);
f_3 = COMPLEX_EXPR ;
return f_3;
}
dce2
foo ()
{
float f$real;
C f;
:
; NOTE: Warning about unused variable on next statement,
; which is associated with the '__imag__ f = 0;' line.
f_3 = COMPLEX_EXPR ;
return f_3;
}
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #8 from Andrew Pinski 2012-01-24 19:48:16 UTC --- *** Bug 41895 has been marked as a duplicate of this bug. ***
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 Andrew Pinski changed: What|Removed |Added CC||Greta.Yorsh at arm dot com --- Comment #9 from Andrew Pinski 2012-01-24 19:48:24 UTC --- *** Bug 51983 has been marked as a duplicate of this bug. ***
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #7 from Jing Yu 2011-03-01 18:08:57 UTC --- I am on leave from 02/01/2011 to 05/30/2011. I may not reply your email during this period. If you have Android toolchain questions/issues/requests, please contact Doug (dougk...@google.com) or my manager Bhaskar (bjanakira...@google.com). Thanks, Jing
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
--- Comment #6 from Andreas Krebbel 2011-03-01
18:08:11 UTC ---
The first difference between x86_64 and s390x appears in 004t.gimple since
s390x returns complex numbers in memory:
x86_64:
foo ()
{
float D.2684;
C D.2685;
C f;
D.2684 = REALPART_EXPR ;
f = COMPLEX_EXPR ;
D.2685 = f;
return D.2685;
}
s390x:
foo ()
{
float D.2702;
C f;
D.2702 = REALPART_EXPR ;
f = COMPLEX_EXPR ;
= f;
return ;
}
The assignment to the imaginary part is introduced by cplxlower:
foo ()
{
float f$real;
C f;
float D.2702;
:
f$real_2 = f$real_6(D);
f_3 = COMPLEX_EXPR ;
REALPART_EXPR <> = f$real_2;
IMAGPART_EXPR <> = 0.0;
return ;
}
expand_complex_operations_1 is invoked for gimple stmt:
# .MEM_5 = VDEF <.MEM_4(D)>
= f_3;
the code falls through to the default label and invokes emit_complex_move in
tree-complex.c:1459
Since is no SSA_NAME emit_complex_move falls through to the code in
tree-complex.c:826 which splits the complex move to:
REALPART_EXPR <> = f$real_2;
IMAGPART_EXPR <> = 0.0;
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #5 from Richard Guenther 2011-02-25 14:51:22 UTC --- At what point does the direct access to IMAGPART appear? That looks like the bug. Why isn't a temporary used for this? Does s390 return the complex number in memory?
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment #4 from Andreas Krebbel 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 {
7C f;
8__imag__ f = 0; /* { dg-warning "is used" "unconditional" } */
9return 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;
:
[gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR ;
return f_3;
}
s390x: uninit-13.i.083t.dce2
foo ()
{
float f$real;
:
REALPART_EXPR <> = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <> = 0.0;
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return ;
}
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;
:
[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 ;
REALPART_EXPR <> = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <> = 0.0;
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return ;
}
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.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
--- Comment #3 from mikpe at it dot uu dot se 2009-10-17 22:08 ---
I just had a look at some gcc-4.4.2 testsuite failure on arm-linux-gnueabi, and
came across the uninit-13.c one and this PR.
The error is not that uninit-13.c triggers an "is used uninitialized" warning,
it's supposed to do that, but that on ARM the line number for the warning is
off-by-one.
On armv5tel-linux-gnueabi:
uninit-13.c: In function 'foo':
uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function
On i686-pc-linux-gnu:
uninit-13.c: In function 'foo':
uninit-13.c:8: warning: '__real__ f' is used uninitialized in this function
Apparently x86-64 is also off-by-one, while my powerpc64 box agrees with i686.
If I replace the _Complex float with a struct of two floats like this:
typedef struct { float x; float y; } C;
C foo()
{
float x; float y;
x = 0;
return (C){x, y};
}
then my i686 and ARM compilers emit identical warnings.
Something strange is happening with _Complex on ARM (and x86-64).
--
mikpe at it dot uu dot se changed:
What|Removed |Added
CC||mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 10:08 --- I can see this with trunk at r147467 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 10:08:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
--- Comment #1 from jingyu at google dot com 2009-04-15 20:41 --- I have observed the same error on host: x86_64-linux-gnu and i686-linux-gnu target: arm-unknown-eabi Executing on host: /usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/xgcc -B/usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/ /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13-O0.c -Wuninitialized -DSTACK_SIZE=16384 -S-o uninit-13-O0.s(timeout = 800) XFAIL: gcc.dg/uninit-13-O0.c unconditional (test for warnings, line 8) PASS: gcc.dg/uninit-13-O0.c (test for excess errors) Executing on host: /usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/xgcc -B/usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/ /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c -O -Wuninitialized -DSTACK_SIZE=16384 -S-o uninit-13.s(timeout = 800) /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c: In function 'foo': /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function output is: /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c: In function 'foo': /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function FAIL: gcc.dg/uninit-13.c unconditional (test for warnings, line 8) FAIL: gcc.dg/uninit-13.c (test for excess errors) Excess errors: /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function $arm-eabi-gcc -v Using built-in specs. Target: arm-eabi Configured with: /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/configure --prefix=/usr/local/google/tmp/gcc4.4_dejagnu/install --target=arm-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/usr/local/google/tmp/gcc4.4_dejagnu/install --with-mpfr=/usr/local/google/tmp/gcc4.4_dejagnu/install --enable-multilib --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ Thread model: single gcc version 4.4.0 20090415 (prerelease) (GCC) -- jingyu at google dot com changed: What|Removed |Added CC||jingyu at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
