Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c -O -Wuninitiali zed -S -o uninit-13.s (timeout = 300) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c: In function 'foo': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function output is: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c: In function 'foo': /home/dave/gnu/gcc/gcc/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: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: arm-none-linux-gnueabi Configured with: ../gcc/configure --host=arm-none-linux-gnueabi --target=arm-non e-linux-gnueabi --build=arm-none-linux-gnueabi --disable-stage1-checking --enabl e-languages=c,c++,fortran --enable-shared --enable-threads --disable-multilib -- disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit - -disable-libstdcxx-pch --disable-checking --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0 --with-gmp=/home/dave/opt/gnu Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144268] (GCC)
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)
I can see this with trunk at r147467
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).
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.
At what point does the direct access to IMAGPART<retval> appear? That looks like the bug. Why isn't a temporary used for this? Does s390 return the complex number in memory?
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>; f = COMPLEX_EXPR <D.2684, 0.0>; D.2685 = f; return D.2685; } s390x: foo () { float D.2702; C f; D.2702 = REALPART_EXPR <f>; f = COMPLEX_EXPR <D.2702, 0.0>; <retval> = f; return <retval>; } The assignment to the imaginary part is introduced by cplxlower: foo () { float f$real; C f; float D.2702; <bb 2>: f$real_2 = f$real_6(D); f_3 = COMPLEX_EXPR <f$real_2, 0.0>; REALPART_EXPR <<retval>> = f$real_2; IMAGPART_EXPR <<retval>> = 0.0; return <retval>; } expand_complex_operations_1 is invoked for gimple stmt: # .MEM_5 = VDEF <.MEM_4(D)> <retval> = f_3; the code falls through to the default label and invokes emit_complex_move in tree-complex.c:1459 Since <retval> 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 <<retval>> = f$real_2; IMAGPART_EXPR <<retval>> = 0.0;
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 (dougkwan@google.com) or my manager Bhaskar (bjanakiraman@google.com). Thanks, Jing
*** Bug 41895 has been marked as a duplicate of this bug. ***
*** Bug 51983 has been marked as a duplicate of this bug. ***
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 <f> = 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 <f>' bit. D.4063 = REALPART_EXPR <f>; f = COMPLEX_EXPR <D.4063, 0.0>; <retval> = f; return <retval>; } cplxlower1 ========== foo () { float f$real; C f; <bb 2>: f$real_2 = f$real_6(D); f_3 = COMPLEX_EXPR <f$real_2, 0.0>; REALPART_EXPR <<retval>> = f$real_2; IMAGPART_EXPR <<retval>> = 0.0; return <retval>; } dce2 ==== foo () { float f$real; C f; <bb 2>: ; 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 <<retval>> = f$real_6(D); IMAGPART_EXPR <<retval>> = 0.0; return <retval>; } 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 <f>' bit. D.4062 = REALPART_EXPR <f>; f = COMPLEX_EXPR <D.4062, 0.0>; D.4063 = f; return D.4063; } cplxlower1 ========== foo () { float f$real; C f; <bb 2>: f$real_2 = f$real_5(D); f_3 = COMPLEX_EXPR <f$real_2, 0.0>; return f_3; } dce2 ==== foo () { float f$real; C f; <bb 2>: ; NOTE: Warning about unused variable on next statement, ; which is associated with the '__imag__ f = 0;' line. f_3 = COMPLEX_EXPR <f$real_5(D), 0.0>; return f_3; }
(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 { 7 C f; 8 __imag__ f = 0; /* { dg-warning "is used" "unconditional" } */ __real__ f = 0; 9 return f; 10 } there is no warning, no?
A patch to fix this is currently under discussion on gcc-patches at: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00164.html
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-postmaster@arm.com Thank you.
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 <thomas.preudhomme@arm.com> 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
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 <thomas.preudhomme@arm.com> 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
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 <thomas.preudhomme@arm.com> 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
Solved in GCC 5.0 as of r210200, no backport intended.