public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "krebbel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
Date: Fri, 25 Feb 2011 14:51:00 -0000	[thread overview]
Message-ID: <bug-39246-4-QtInmSj2aj@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-39246-4@http.gcc.gnu.org/bugzilla/>

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.


       reply	other threads:[~2011-02-25 14:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-39246-4@http.gcc.gnu.org/bugzilla/>
2011-02-25 14:51 ` krebbel at gcc dot gnu.org [this message]
2011-02-25 15:52 ` rguenth at gcc dot gnu.org
2011-03-01 18:08 ` krebbel at gcc dot gnu.org
2011-03-01 18:09 ` jingyu at google dot com
2012-01-24 21:59 ` pinskia at gcc dot gnu.org
2012-01-24 22:00 ` pinskia at gcc dot gnu.org
2013-06-19 20:24 ` meadori at gcc dot gnu.org
2013-06-19 21:00 ` manu at gcc dot gnu.org
2014-05-04  9:53 ` thomas.preudhomme at arm dot com
2014-05-04  9:54 ` StaffLeavers at arm dot com
2014-05-04  9:54 ` StaffLeavers at arm dot com
2014-05-04  9:55 ` StaffLeavers at arm dot com
2014-05-04  9:56 ` StaffLeavers at arm dot com
2014-05-04  9:57 ` StaffLeavers at arm dot com
2014-05-04  9:57 ` StaffLeavers at arm dot com
2014-05-04  9:58 ` StaffLeavers at arm dot com
2014-05-04  9:59 ` StaffLeavers at arm dot com
2014-05-04 10:00 ` StaffLeavers at arm dot com
2014-05-04 10:01 ` StaffLeavers at arm dot com
2014-05-04 10:02 ` StaffLeavers at arm dot com
2014-05-04 10:02 ` StaffLeavers at arm dot com
2014-05-04 10:04 ` StaffLeavers at arm dot com
2014-05-04 10:05 ` StaffLeavers at arm dot com
2014-05-04 10:06 ` StaffLeavers at arm dot com
2014-05-04 10:06 ` StaffLeavers at arm dot com
2014-05-04 10:08 ` StaffLeavers at arm dot com
2014-05-04 10:09 ` StaffLeavers at arm dot com
2014-05-04 10:10 ` StaffLeavers at arm dot com
2014-05-04 10:11 ` StaffLeavers at arm dot com
2014-05-04 10:12 ` StaffLeavers at arm dot com
2014-05-04 10:12 ` StaffLeavers at arm dot com
2014-05-08  1:19 ` jye2 at gcc dot gnu.org
2014-05-08  1:21 ` jye2 at gcc dot gnu.org
2014-05-08  1:23 ` jye2 at gcc dot gnu.org
2015-01-27  1:42 ` thopre01 at gcc dot gnu.org
2009-02-19 16:44 [Bug c/39246] New: " danglin at gcc dot gnu dot org
2009-04-15 20:41 ` [Bug middle-end/39246] " jingyu at google dot com
2009-05-13 10:08 ` ramana at gcc dot gnu dot org
2009-10-17 22:09 ` mikpe at it dot uu dot se

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-39246-4-QtInmSj2aj@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).