User account creation filtered due to spam.

Bug 39246 - FAIL: gcc.dg/uninit-13.c
Summary: FAIL: gcc.dg/uninit-13.c
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
: 41895 51983 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-19 16:44 UTC by John David Anglin
Modified: 2015-01-27 01:41 UTC (History)
9 users (show)

See Also:
Host: arm-none-linux-gnueabi,s390x-ibm-linux
Target: arm-none-linux-gnueabi,s390x-ibm-linux
Build: arm-none-linux-gnueabi,s390x-ibm-linux
Known to work: 5.0
Known to fail: 4.4.5, 4.5.3, 4.6.0
Last reconfirmed: 2009-05-13 10:08:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2009-02-19 16:44:31 UTC
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)
Comment 1 Jing Yu 2009-04-15 20:41:08 UTC
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)
Comment 2 Ramana Radhakrishnan 2009-05-13 10:08:01 UTC
I can see this with trunk at r147467
Comment 3 Mikael Pettersson 2009-10-17 22:08:57 UTC
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).
Comment 4 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  {
     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.
Comment 5 Richard Biener 2011-02-25 14:51:22 UTC
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?
Comment 6 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>;
  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;
Comment 7 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 (dougkwan@google.com) or my manager Bhaskar
(bjanakiraman@google.com).

Thanks,
Jing
Comment 8 Andrew Pinski 2012-01-24 19:48:16 UTC
*** Bug 41895 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Pinski 2012-01-24 19:48:24 UTC
*** Bug 51983 has been marked as a duplicate of this bug. ***
Comment 10 meadori 2013-06-19 20:24:01 UTC
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;

}
Comment 11 Manuel López-Ibáñez 2013-06-19 21:00:06 UTC
(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?
Comment 12 Thomas Preud'homme 2014-05-04 09:52:50 UTC
A patch to fix this is currently under discussion on gcc-patches at: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00164.html
Comment 13 StaffLeavers 2014-05-04 09:53:55 UTC
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.
Comment 14 StaffLeavers 2014-05-04 09:54:41 UTC
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.
Comment 15 StaffLeavers 2014-05-04 09:55:29 UTC
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.
Comment 16 StaffLeavers 2014-05-04 09:56:15 UTC
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.
Comment 17 StaffLeavers 2014-05-04 09:57:03 UTC
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.
Comment 18 StaffLeavers 2014-05-04 09:57:49 UTC
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.
Comment 19 StaffLeavers 2014-05-04 09:58:31 UTC
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.
Comment 20 StaffLeavers 2014-05-04 09:59:42 UTC
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.
Comment 21 StaffLeavers 2014-05-04 10:00:26 UTC
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.
Comment 22 StaffLeavers 2014-05-04 10:01:12 UTC
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.
Comment 23 StaffLeavers 2014-05-04 10:01:56 UTC
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.
Comment 24 StaffLeavers 2014-05-04 10:02:41 UTC
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.
Comment 25 StaffLeavers 2014-05-04 10:04:11 UTC
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.
Comment 26 StaffLeavers 2014-05-04 10:05:04 UTC
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.
Comment 27 StaffLeavers 2014-05-04 10:05:58 UTC
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.
Comment 28 StaffLeavers 2014-05-04 10:06:44 UTC
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.
Comment 29 StaffLeavers 2014-05-04 10:07:59 UTC
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.
Comment 30 StaffLeavers 2014-05-04 10:09:12 UTC
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.
Comment 31 StaffLeavers 2014-05-04 10:10:26 UTC
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.
Comment 32 StaffLeavers 2014-05-04 10:11:11 UTC
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.
Comment 33 StaffLeavers 2014-05-04 10:11:58 UTC
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.
Comment 34 StaffLeavers 2014-05-04 10:12:19 UTC
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.
Comment 35 jye2 2014-05-08 01:19:44 UTC
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
Comment 36 jye2 2014-05-08 01:20:49 UTC
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
Comment 37 jye2 2014-05-08 01:23:32 UTC
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
Comment 38 Thomas Preud'homme 2015-01-27 01:41:52 UTC
Solved in GCC 5.0 as of r210200, no backport intended.