[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20817|0                           |1
        is obsolete|                            |

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-12-03 19:07:03 UTC ---
Created attachment 22623
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22623
updated -Wmeminit patch for trunk (4.6.0)

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-07 21:45:44 UTC ---
new patch http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01068.html

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|gcc-bugs at gcc dot gnu.org |

--- Comment #17 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-08-21 17:20:06 UTC ---
Jon, are you actively working on this? I found this last message:

  http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01477.html

Let me know if I can help...

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-08-21 17:26:16 UTC ---
No, not at present. I tried using default_init_uninitialized_part but it either
missed cases or produce ICEs, and I never solved the problems. I can send you
my work-in-progress when I get home, it would be great if you could help me
with the issues I don't understand.

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

--- Comment #19 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-08-21 17:54:12 UTC ---
Eh, I'm of course not sure that I can help but I quickly went through the
exchange on gcc-patches and got the impression that your work was already in an
advanced stage, thus we should try to finish it! I'm pretty sure that we can
make it in time for 4.8.0 (maybe with one or two more rounds of focused tips
from Jason)

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #21 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #20)
> Perhaps a better alternative is to warn only if the uninitialized member is
> used in a mem-initializer. Then, when building the constructor call, mark
> the uninitialized members somehow as uninitialized for the middle-end, and
> let the middle-end handle the cases in the body of the constructor. The
> first part would already fix PR19808. The second part will fix this bug with
> fewer false positives than the proposed patch.

And this comment gives some ideas:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808#c9

Richard B, you say that: "using <error-mark> [for marking undefined memory] is
just a random (and probably bad) idea."  Intuitively this seems more scalable,
since one could propagate the undefined value like VRP does.

The other alternative "Introducing a SSA name default definition for A (even
though not of register type)", however, seems possible already. no? We do
already check for default definitions in virtual operands, tree-ssa-uninit.c
says:

      /* For memory the only cheap thing we can do is see if we
         have a use of the default def of the virtual operand.

So what is missing here?
>From gcc-bugs-return-462857-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 29 15:15:44 2014
Return-Path: <gcc-bugs-return-462857-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1903 invoked by alias); 29 Sep 2014 15:15:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1875 invoked by uid 48); 29 Sep 2014 15:15:37 -0000
From: "itay at phobotic dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63408] New: GCC emits incorrect FMA instruction
Date: Mon, 29 Sep 2014 15:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: itay at phobotic dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63408-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02691.txt.bz2
Content-length: 1035

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc408

            Bug ID: 63408
           Summary: GCC emits incorrect FMA instruction
           Product: gcc
           Version: 4.8.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: itay at phobotic dot com

When compiling the following function

float f(float a, int b)
{
    return a - (((float)b / 0x7fffffff) * 100);
}

with the following command-line options

arm-none-eabi-gcc -O2 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
-mcpu=cortex-m4

I get this code for f:

    fmsr    s14, r1    @ int
    flds    s15, .L2
    vcvt.f32.s32    s14, s14, #31
    fmsr    s13, r0
    vfma.f32    s13, s14, s15
    fmrs    r0, s13
    bx    lr
.L3:
    .align    2
.L2:
    .word    1120403456

The resulting code clearly adds the parenthesized expression to a rather than
subtracting it.

Replacing the minus sign with a plus sign results in the same code.

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
Bug 2972 depends on bug 19808, which changed state.

Bug 19808 Summary: miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[jwakely dot gcc at gmail dot com]

------- Comment #14 from jwakely dot gcc at gmail dot com  2010-06-03 11:24 -------
Created an attachment (id=20817)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20817&action=view)
better -Wmeminit patch

This version ignores empty classes and checks for a nontrivial default ctor
instead of layout_pod_type.

This patch doesn't enable the warning unless explicity requested. I realise
that this warning is about enforcing style ("members should be initialised in
the mem-initializer-list not in the ctor body") but that's ok because it's my
preferred style, I just don't want the compiler to enforce other people's
preferred style ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[paolo dot carlini at oracle dot com]

------- Comment #13 from paolo dot carlini at oracle dot com  2010-06-03 10:16 -------
About -Weffc++, we also have a PR (16166) about splitting it... Not that I
think we should really do that - adding a dozen of -Weffc++-type warnings - but
I believe it would be a good idea to finally resolve one way or the other all
those long standing -Weffc++ PRs (we have 5 or 6)... If you ask my opinion, we
should probably *not* split the option, and instead reduce *a lot* the false
positives for the various warnings, even if that means adding false negatives.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[jwakely dot gcc at gmail dot com]

------- Comment #12 from jwakely dot gcc at gmail dot com  2010-06-03 09:27 -------
Apart from the false positives, another problem is that the check for
layout_pod_type_p is not right.  An empty class is a POD but doesn't need
initialising.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[jwakely dot gcc at gmail dot com]

------- Comment #11 from jwakely dot gcc at gmail dot com  2010-06-03 09:18 -------
(In reply to comment #10)
> (In reply to comment #9)
> > I've been experimenting with this patch, which warns if there is a missing
> > mem-initializer for a scalar.
> > 
> > It gives a false positive for cases were the member is assigned to in the
> > constructor body, or otherwise initialized before use, but it's a start, and
> > has already helped me find some missing mem-initializers in real code.
> 
> Nice but I am afraid there may be too many false positives.

Yes, I'm not proposing it in that state. It's just an experiment but has been
useful for me already.

> And what is
> different between this and the -Weffc++ warning given just below it?

-Weffc++ also enables dozens of other warnings, most of which I don't find
useful.  It is about good style, not dangerous code, and I don't like the
compiler to enforce style.

In this specific case, the Weffc++ warning complains if *any* member has no
mem-initializer. I only care about POD members which will be uninitialized, I
don't want to add a mem-initializer for e.g. a std::string member which has a
default constructor.

> > +    case OPT_Wmeminit:
> > +      warn_meminit = value;
> > +      break;
> > +
> 
> You do not need this. This is handled automatically when you defined Var in the
> opt files.

Ah OK, thanks!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[manu at gcc dot gnu dot org]

------- Comment #10 from manu at gcc dot gnu dot org  2010-06-03 08:47 -------
(In reply to comment #9)
> I've been experimenting with this patch, which warns if there is a missing
> mem-initializer for a scalar.
> 
> It gives a false positive for cases were the member is assigned to in the
> constructor body, or otherwise initialized before use, but it's a start, and
> has already helped me find some missing mem-initializers in real code.

Nice but I am afraid there may be too many false positives. And what is
different between this and the -Weffc++ warning given just below it?


> 
> +    case OPT_Wmeminit:
> +      warn_meminit = value;
> +      break;
> +

You do not need this. This is handled automatically when you defined Var in the
opt files.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|gdr at gcc dot gnu dot org  |unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[redi at gcc dot gnu dot org]

------- Comment #9 from redi at gcc dot gnu dot org  2010-06-03 01:13 -------
I've been experimenting with this patch, which warns if there is a missing
mem-initializer for a scalar.

It gives a false positive for cases were the member is assigned to in the
constructor body, or otherwise initialized before use, but it's a start, and
has already helped me find some missing mem-initializers in real code.


--- c.opt.orig  2010-06-02 13:47:02.120129255 +0000
+++ c.opt       2010-06-02 13:07:51.944440072 +0000
@@ -304,6 +304,10 @@
 C ObjC C++ ObjC++ Var(warn_main) Init(-1) Warning
 Warn about suspicious declarations of \"main\"

+Wmeminit
+C++ Var(warn_meminit) Init(-1) Warning
+Warn about POD members which are not initialized in a constructor
initialization list
+
 Wmissing-braces
 C ObjC C++ ObjC++ Var(warn_missing_braces) Warning
 Warn about possibly missing braces around initializers
--- c-opts.c.orig       2010-06-02 13:46:49.774040694 +0000
+++ c-opts.c    2010-06-02 13:11:57.829233564 +0000
@@ -492,6 +492,10 @@
      cpp_opts->warn_invalid_pch = value;
      break;

+    case OPT_Wmeminit:
+      warn_meminit = value;
+      break;
+
    case OPT_Wmissing_include_dirs:
      cpp_opts->warn_missing_include_dirs = value;
      break;
--- cp/init.c.orig      2010-06-02 13:46:31.125713124 +0000
+++ cp/init.c   2010-06-02 13:21:01.473640135 +0000
@@ -424,6 +424,12 @@
  tree decl;
  tree type = TREE_TYPE (member);

+  /* warn if there is no initializer for a POD member */
+  if (warn_meminit && init == NULL_TREE && layout_pod_type_p
(strip_array_types (type)))
+    warning_at (DECL_SOURCE_LOCATION (current_function_decl), OPT_Wmeminit,
+               "%qD is not initialized in the member initialization list",
+               member);
+
  /* Effective C++ rule 12 requires that all data members be
     initialized.  */
  if (warn_ecpp && init == NULL_TREE && TREE_CODE (type) != ARRAY_TYPE)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[manu at gcc dot gnu dot org]

------- Comment #8 from manu at gcc dot gnu dot org  2010-02-24 13:05 -------
Related to PR 19808.

(In reply to comment #6)
> However -Wunitialized is taken over by the middle-end.  This is

That doesn't mean that you cannot produce uninitialized warnings in the
front-end for clear-cut cases like this. In fact, it is impossible to detect
this case in the middle-end because of the code produced by the C++ front-end,


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
  BugsThisDependsOn|                            |19808


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[bangerth at dealii dot org]

------- Comment #7 from bangerth at dealii dot org  2008-09-10 15:30 -------
Still the same with gcc version 4.4.0 20080801 (experimental) [trunk revision
138448]


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-12-11 21:47:09         |2008-09-10 15:30:28
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[gdr at gcc dot gnu dot org]

------- Comment #6 from gdr at gcc dot gnu dot org  2006-01-22 03:43 -------
(In reply to comment #5)
> Also, it should detect any scalar member variables that are not assigned to in
> any way in the constructor.

Agreed.
However -Wunitialized is taken over by the middle-end.  This is
one more case where I agre with Mark Mitchell that the middl-end
should not try those things.  Long term, we should move
such warnings to the front-end.  Yes I know, that is not a 
universally held opinon.


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[eric-gcc at omnifarious dot org]

------- Additional Comments From eric-gcc at omnifarious dot org  2004-01-07 03:35 -------
Also, it should detect any scalar member variables that are not assigned to in
any way in the constructor.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4                         |---