Add a new warning to warn when passing uninitialized variables as const reference parameters to a function

[zequanwu]

Summary

Add a new warning -Wuninitialized-const-reference as a subgroup of -Wuninitialized to address a bug filed here: https://bugs.llvm.org/show_bug.cgi?id=45624
This warning is controlled by -Wuninitialized and can be disabled by -Wno-uninitialized-const-reference.

The warning is diagnosed when passing uninitialized variables as const reference parameters to a function.

[rnk]

Arthur recently went through the process of refining a diagnostic, so he should be able to help guide you in this if you have more questions.

clang/lib/Analysis/UninitializedValues.cpp

425

Based on Richard's comment here:
https://bugs.llvm.org/show_bug.cgi?id=45624#c7
... this should be its own classification kind, perhaps ConstRefUse or something like that.

This will allow us to put this finding under it's own diagnostic group, maybe named something like -Wuninitialized-const-reference, and then users can enable or disable it separately. It is likely that this new behavior will find many new instances over existing codebases, for example Chromium, that compile with -Wuninitialized enabled. So, if we don't leave a way for users to disable the new warnings (-Wno-uninitialized-const-ref), it is harder for them (us) to update the compiler.

[zequanwu]

Add new warning as subgroup of Uninitialized.

[zequanwu]

Use another mapvector constRefUses to store uninitialized const reference uses so that the new warning can be easily disable by -Wno-initialized-const-reference

[aeubanks]

The summary of this change should be "add warning..." not "fix warning..."

Could you add more detail into the commit description? About newly introduced diagnostic groups, etc.

Also, I thought I saw tests in a previous revision but now they seem to be gone?

[zequanwu]

Since the new warning is controlled by -Wuninitialized, I disabled it in existing test case and added a separate test case for -Wuninitialized-const-reference.

[aeubanks]

clang/include/clang/Basic/DiagnosticSemaKinds.td

2110 ↗

(On Diff #264300)

s/passes/passed

clang/test/SemaCXX/warn-uninitialized-const-reference.cpp

23 ↗

(On Diff #264300)

For my knowledge, is this to make sure that this other warning takes precedence over the one introduced in this change? If it is, a comment would be nice.

[rnk]

clang/lib/Sema/AnalysisBasedWarnings.cpp

1518 ↗

(On Diff #264300)

If possible, it would be nice to avoid having a second map.

[zequanwu]

clang/lib/Sema/AnalysisBasedWarnings.cpp

1518 ↗

(On Diff #264300)

I use second map to let the new warning be orthogonal to existing warnings. That means when we have both -Wuninitialized and -Wno-uninitialized-const-reference, the old test cases about uninitialized variables should all passed. Otherwise, I need to somehow detect the presence of -Wno-uninitialized-const-reference, which I don't see a way to do that. Consider this code if we have only one map:

void consume_const_ref(const int &n);
int test_const_ref() {
  int n;
  consume_const_ref(n);
  return n;
}

No matter if the flag`-Wno-uninitialized-const-reference` is present or not, we still need to add n in consume_const_ref(n); to uses map and then let S.Diag to decide to diagnose it or not depend on the presence of -Wno-uninitialized-const-reference. If the flag is given, S.Diag will just ignore the warning, but uninit var warning will diagnose if Use.getKind() returns Always in https://github.com/llvm/llvm-project/blob/master/clang/lib/Sema/AnalysisBasedWarnings.cpp#L814 . That is not desired. Since the original behavior is to ignore the n in consume_const_ref(n); by not adding it to the uses map.

If there is a way to detect the presence of -Wno-uninitialized-const-reference or to know if Sema::Diag(SourceLocation Loc, unsigned DiagID) actually diagnosed a warning, the use of second map can be avoid.

[rsmith]

clang/lib/Sema/AnalysisBasedWarnings.cpp

1518 ↗

(On Diff #264300)

Interesting testcase :)

Ideally we want the set of diagnostics from a particular compilation to be the same you'd get by building with -Weverything and then filtering out the ones you didn't want. So it's better to not ask whether -Wuninitialized-const-reference is enabled or not.

I think we only populate this map after we've found an uninitialized use; if so, the cost of a second map seems likely to be acceptable.

FYI, there is a mechanism to ask the "is this diagnostic enabled?" question, but generally we'd prefer if it's only used to avoid doing work that would be redundant if the warning is disabled. You can use Diag.isIgnored(diag::warn_..., Loc) to determine if a diagnostic with the given ID would be suppressed at the given location. (In fact, it looks like this is already being called in a later change in this file.)

1590–1600 ↗

(On Diff #264300)

Do we want any idiomatic-self-init special-case handling here? For example:

void f(const int&);
void g() {
  int a = a;
  f(a);
}

Following the logic above, should that warn on the int a = a; not on the f(a) call? Or should we warn only on the f(a) call itself in this case? It seems like it might be surprising to say that a is "uninitialized" here, since an initializer was provided, even though it was a garbage one.

[xbolva00]

Can you provide some compile time data with warning enabled/disabled?

[zequanwu]

Fix typo.
Diagnose self-init warning if the self-init variable is used as const reference later.

[zequanwu]

clang/lib/Sema/AnalysisBasedWarnings.cpp

1518 ↗

(On Diff #264300)

I think second map is necessary. So, Diag.isIgnored is not abused.

1590–1600 ↗

(On Diff #264300)

For this case, I think we should warn at int a = a, like the comment in DiagnoseUninitializedUse said, https://github.com/llvm/llvm-project/blob/master/clang/lib/Sema/AnalysisBasedWarnings.cpp#L986-L996

f(a) is considered as accessing a.

clang/test/SemaCXX/warn-uninitialized-const-reference.cpp

23 ↗

(On Diff #264300)

No, original behavior of -Wuninitialized for line 24 is silence. Now the new warning will be emitted because it is const use of uninitialized variable.

[zequanwu]

In D79895#2042992, @xbolva00 wrote:

Can you provide some compile time data with warning enabled/disabled?

I compiled the test case with warning enabled and disabled. Since it is controlled by -Wuninitialzed, it will diagnose when the flag is given.

$ clang -ftime-report -fsyntax-only warn-uninitialized-const-reference.cpp
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 0.0094 seconds (0.0094 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   0.0091 (100.0%)   0.0003 (100.0%)   0.0094 (100.0%)   0.0094 (100.0%)  Clang front-end timer
   0.0091 (100.0%)   0.0003 (100.0%)   0.0094 (100.0%)   0.0094 (100.0%)  Total

$ clang -ftime-report -Wuninitialized -fsyntax-only warn-uninitialized-const-reference.cpp
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 0.0131 seconds (0.0131 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   0.0046 (100.0%)   0.0086 (100.0%)   0.0131 (100.0%)   0.0131 (100.0%)  Clang front-end timer
   0.0046 (100.0%)   0.0086 (100.0%)   0.0131 (100.0%)   0.0131 (100.0%)  Total

$ clang -ftime-report -Wuninitialized -Wno-uninitialized-const-reference -fsyntax-only warn-uninitialized-const-reference.cpp
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 0.0109 seconds (0.0109 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   0.0073 (100.0%)   0.0036 (100.0%)   0.0109 (100.0%)   0.0109 (100.0%)  Clang front-end timer
   0.0073 (100.0%)   0.0036 (100.0%)   0.0109 (100.0%)   0.0109 (100.0%)  Total

clang/test/SemaCXX/warn-uninitialized-const-reference.cpp

23 ↗

(On Diff #264300)

I meant "const reference use". It was typo.

[aeubanks]

One last nit, otherwise lgtm. But I'm not super familiar with this area, it'd be good to get another review from somebody more familiar.

clang/lib/Sema/AnalysisBasedWarnings.cpp

1523 ↗

(On Diff #264976)

this is very confusing since it shadows the uses member variable from UninitValsDiagReporter

1590–1600 ↗

(On Diff #264300)

Doesn't DiagnoseUninitializedUse say that we shouldn't warn at int a = a?

[zequanwu]

rename parameter uses to um

clang/lib/Sema/AnalysisBasedWarnings.cpp

1590–1600 ↗

(On Diff #264300)

The last sentence of the comment says that int a = a left a as uninitialized state, and we should warn at int a = a if there is an access of a in uninitialized state. Otherwise, we don't need to warn.

[zequanwu]

@rsmith Are you okay with this patch?

[hans]

Very nice! I only have minor comments.

Also I'm curious to see what this will find in Chromium. I guess we'll find out :-)

clang/include/clang/Analysis/Analyses/UninitializedValues.h

118 ↗

(On Diff #265605)

nit: May put this after handleUseOfUninitVariable() instead, since it's very similar.

clang/include/clang/Basic/DiagnosticSemaKinds.td

2110 ↗

(On Diff #265605)

Minor detail, but I think it should say "argument" instead of "parameter".

My understanding is that parameters are names used when declaring/defining functions, e, g.
int foo(int x) { ... }
here x is a parameter.

And arguments are used when calling functions:
foo(42);
here 42 is an argument.

(https://en.wikipedia.org/wiki/Parameter_(computer_programming))

clang/lib/Analysis/UninitializedValues.cpp

880

I'd probably move this to right after handleUseOfUninitVariable() since they're similar.

clang/lib/Sema/AnalysisBasedWarnings.cpp

1590 ↗

(On Diff #265605)

nit: capital f and period at the end.

clang/test/SemaCXX/warn-uninitialized-const-reference.cpp

5 ↗

(On Diff #265605)

nit: I think 2 spaces for indentation is more common in this code (applies also below).

[zequanwu]

Rebase and address comments.

[MaskRay]

clang/lib/Analysis/UninitializedValues.cpp

674

This should use isAlwaysUninit. I fixed it in 7096e04a6831d4668c39b388ccd166f84de69191

Otherwise there are multiple false positives in stage2 build of llvm-project, e.g.

if (a < 42)
  var = 1;
if (a < 42)
  const_ref_use(var);

[zequanwu]

clang/lib/Analysis/UninitializedValues.cpp

674

Thanks for the fix

[sylvestre.ledru]

@zequanwu could you please update the release notes? thanks
https://github.com/llvm/llvm-project/blob/master/clang/docs/ReleaseNotes.rst

[zequanwu]

In D79895#2073698, @sylvestre.ledru wrote:

@zequanwu could you please update the release notes? thanks
https://github.com/llvm/llvm-project/blob/master/clang/docs/ReleaseNotes.rst

Done.

[nick]

This diagnostic bring headaches because frequently -Wunused-variable suppression is done via no-op pseudo-consuming function like [boost::ignore_unused](https://www.boost.org/doc/libs/1_73_0/libs/core/doc/html/core/ignore_unused.html). Particularly, it fires in Boost here https://github.com/boostorg/concept_check/blob/e69c81326d5a4359ac53f9c6fe53fc2baf24df50/include/boost/concept_check.hpp#L135-L141.
Is it possible to make the diagnostic not fire for empty body consuming functions?

[zequanwu]

In D79895#2107604, @nick wrote:

This diagnostic bring headaches because frequently -Wunused-variable suppression is done via no-op pseudo-consuming function like [boost::ignore_unused](https://www.boost.org/doc/libs/1_73_0/libs/core/doc/html/core/ignore_unused.html). Particularly, it fires in Boost here https://github.com/boostorg/concept_check/blob/e69c81326d5a4359ac53f9c6fe53fc2baf24df50/include/boost/concept_check.hpp#L135-L141.
Is it possible to make the diagnostic not fire for empty body consuming functions?

This warning can be turned off by the flag -Wno-uninitialized-const-reference. I don't think we can just make the diagnostic not fire for empty body consuming functions, if the function declaration and definition are in different translation units.

[nick]

This warning can be turned off by the flag -Wno-uninitialized-const-reference.

Suggesting to turn off the warning should be the last resort. I am pointing to the false positives for large existing code bases from -Wall diagnostic.

I don't think we can just make the diagnostic not fire for empty body consuming functions, if the function declaration and definition are in different translation units.

I am talking about the particular situation that is involves only inline functions with empty bodies. boost::ignore_unused-like functions are obviously come with definition.

[aeubanks]

In D79895#2107796, @nick wrote:

This warning can be turned off by the flag -Wno-uninitialized-const-reference.

Suggesting to turn off the warning should be the last resort. I am pointing to the false positives for large existing code bases from -Wall diagnostic.

I don't think we can just make the diagnostic not fire for empty body consuming functions, if the function declaration and definition are in different translation units.

I am talking about the particular situation that is involves only inline functions with empty bodies. boost::ignore_unused-like functions are obviously come with definition.

I feel like doing interprocedural analysis for this is overkill. What is the benefit of boost::ignore_unused(foo); rather than the more common (void) foo;? Any examples?

[hans]

In D79895#2107604, @nick wrote:

This diagnostic bring headaches because frequently -Wunused-variable suppression is done via no-op pseudo-consuming function like [boost::ignore_unused](https://www.boost.org/doc/libs/1_73_0/libs/core/doc/html/core/ignore_unused.html).

I haven't seen boost::ignore_unused before. In my experience, the idiomatic way of ignoring an unused variable in C/C++ is to cast it to void, as Arthur said.

Particularly, it fires in Boost here https://github.com/boostorg/concept_check/blob/e69c81326d5a4359ac53f9c6fe53fc2baf24df50/include/boost/concept_check.hpp#L135-L141.
Is it possible to make the diagnostic not fire for empty body consuming functions?

The combination of having an uninitialized variable and explicitly marking it unused like this seems to me like it would be unusual.

[nick]

I feel like doing interprocedural analysis for this is overkill. What is the benefit of boost::ignore_unused(foo); rather than the more common (void) foo;? Any examples?

I haven't seen boost::ignore_unused before. In my experience, the idiomatic way of ignoring an unused variable in C/C++ is to cast it to void, as Arthur said.

This is a weak argument to have false positives, don't you agree? You may have not seen it, but it exists and is used: https://github.com/search?q=%22boost%3A%3Aignore_unused%22+NOT+%22Boost+Software+License%22&type=Code

The combination of having an uninitialized variable and explicitly marking it unused like this seems to me like it would be unusual.

It could be a variable used exclusively inside an assert or some other conditionally no-op macro-function.

[hans]

In D79895#2109414, @nick wrote:

I feel like doing interprocedural analysis for this is overkill. What is the benefit of boost::ignore_unused(foo); rather than the more common (void) foo;? Any examples?

I haven't seen boost::ignore_unused before. In my experience, the idiomatic way of ignoring an unused variable in C/C++ is to cast it to void, as Arthur said.

This is a weak argument to have false positives, don't you agree? You may have not seen it, but it exists and is used: https://github.com/search?q=%22boost%3A%3Aignore_unused%22+NOT+%22Boost+Software+License%22&type=Code

There are plenty of warnings which have false positives on non-idiomatic code though. The question is how common this pattern of using a function to ignore an unused variable is. We didn't see it in the code bases I work with, so is boost a special case, or an example of a common practice? If it's just boost, fixing the code seems better (it will compile faster too).

[nick]

We didn't see it in the code bases I work with, so is boost a special case, or an example of a common practice?

I do not have resources to make such statistics, but there are compilers where casting to void is not enough to suppress the warning. https://herbsutter.com/2009/10/18/mailbag-shutting-up-compiler-warnings/#comment-1509 https://godbolt.org/z/pS_iQ3

If it's just boost, fixing the code seems better

Have you tried to push a fix for a warning in Boost? If it was that simple. A part of my warning-fixing PRs are not merged in years. And considering that fixing this warning will reintroduce warnings for other compilers I probably will have a bad luck with this one too.

(it will compile faster too).

Should I open a PR with replacing std::forward with static_cast because it compiles faster? :-)

[aeubanks]

In D79895#2110345, @nick wrote:

We didn't see it in the code bases I work with, so is boost a special case, or an example of a common practice?

I do not have resources to make such statistics, but there are compilers where casting to void is not enough to suppress the warning. https://herbsutter.com/2009/10/18/mailbag-shutting-up-compiler-warnings/#comment-1509 https://godbolt.org/z/pS_iQ3

If it's just boost, fixing the code seems better

Have you tried to push a fix for a warning in Boost? If it was that simple. A part of my warning-fixing PRs are not merged in years. And considering that fixing this warning will reintroduce warnings for other compilers I probably will have a bad luck with this one too.

(it will compile faster too).

Should I open a PR with replacing std::forward with static_cast because it compiles faster? :-)

Perhaps asking for more opinions in cfe-dev will be better.

clang/lib/Analysis/UninitializedValues.cpp

void ClassifyRefs::VisitCallExpr(CallExpr *CE) {
   // Classify arguments to std::move as used.
   if (CE->isCallToStdMove()) {
     // RecordTypes are handled in SemaDeclCXX.cpp.
     if (!CE->getArg(0)->getType()->isRecordType())
       classify(CE->getArg(0), Use);
     return;
   }
 
-  // If a value is passed by const pointer or by const reference to a function,
+  // If a value is passed by const pointer to a function,
   // we should not assume that it is initialized by the call, and we
   // conservatively do not assume that it is used.
+  // If a value is passed by const reference to a function,
+  // it should already be initialized.
   for (CallExpr::arg_iterator I = CE->arg_begin(), E = CE->arg_end();
        I != E; ++I) {
     if ((*I)->isGLValue()) {
       if ((*I)->getType().isConstQualified())
-        classify((*I), Ignore);
+        classify((*I), Use);
     } else if (isPointerToConst((*I)->getType())) {
       const Expr *Ex = stripCasts(DC->getParentASTContext(), *I);
       const auto *UO = dyn_cast<UnaryOperator>(Ex);
       if (UO && UO->getOpcode() == UO_AddrOf)
         Ex = UO->getSubExpr();
       classify(Ex, Ignore);
     }
   }

 void TransferFunctions::reportUse(const Expr *ex, const VarDecl *vd) {
   Value v = vals[vd];
   if (isUninitialized(v))
     handler.handleUseOfUninitVariable(vd, getUninitUse(ex, vd, v));
 }
 
 void TransferFunctions::VisitObjCForCollectionStmt(ObjCForCollectionStmt *FS) {
   // This represents an initialization of the 'element' value.
   if (const auto *DS = dyn_cast<DeclStmt>(FS->getElement())) {
     const auto *VD = cast<VarDecl>(DS->getSingleDecl());
     if (isTrackedVar(VD))
       vals[VD] = Initialized;
   }
 }
 
 void TransferFunctions::VisitOMPExecutableDirective(
     OMPExecutableDirective *ED) {
struct PruneBlocksHandler : public UninitVariablesHandler {
   /// Called when the uninitialized variable analysis detects the
   /// idiom 'int x = x'.  All other uses of 'x' within the initializer
   /// are handled by handleUseOfUninitVariable.
   void handleSelfInit(const VarDecl *vd) override {
     hadUse[currentBlock] = true;
     hadAnyUse = true;
   }
 };
 
 } // namespace
 
 void clang::runUninitializedVariablesAnalysis(
     const DeclContext &dc,
     const CFG &cfg,
     AnalysisDeclContext &ac,
     UninitVariablesHandler &handler,
     UninitVariablesAnalysisStats &stats) {

clang/test/SemaCXX/uninit-variables.cpp

 void test_bitcasts_2() {
   int x;  // expected-note {{initialize the variable 'x' to silence this warning}}
   int y = (float &)x; // expected-warning {{uninitialized when used here}}
 }
 
 void consume_const_ref(const int &n);
 int test_const_ref() {
   int n; // expected-note {{variable}}
-  consume_const_ref(n);
-  return n; // expected-warning {{uninitialized when used here}}
+  consume_const_ref(n); // expected-warning {{variable 'n' is uninitialized when used here}}
+  return n;
 }
 
 // Don't crash here.
 auto PR19996 = [a=0]{int t; return a;};

clang/test/SemaCXX/uninitialized.cpp

 
 void test_stuff () {
   int a = a; // no-warning: used to signal intended lack of initialization.
   int b = b + 1; // expected-warning {{variable 'b' is uninitialized when used within its own initialization}}
   int c = (c + c); // expected-warning {{variable 'c' is uninitialized when used within its own initialization}}
   int d = ({ d + d ;}); // expected-warning {{variable 'd' is uninitialized when used within its own initialization}}
   int e = static_cast<long>(e) + 1; // expected-warning {{variable 'e' is uninitialized when used within its own initialization}}
   int f = foo(f); // expected-warning {{variable 'f' is uninitialized when used within its own initialization}}
+  int j = far(j); // expected-warning {{variable 'j' is uninitialized when used within its own initialization}}
 
   // These don't warn as they don't require the value.
   int g = sizeof(g);
   void* ptr = &ptr;
   int h = bar(&h);
   int i = boo(i);
-  int j = far(j);
   int k = __alignof__(k);
 
   int l = k ? l : l;  // expected-warning {{variable 'l' is uninitialized when used within its own initialization}}
   int m = 1 + (k ? m : m);  // expected-warning {{'m' is uninitialized when used within its own initialization}}
   int n = -n;  // expected-warning {{variable 'n' is uninitialized when used within its own initialization}}
   int o = std::move(o);  // expected-warning {{variable 'o' is uninitialized when used within its own initialization}}
   const int p = std::move(p);  // expected-warning {{variable 'p' is uninitialized when used within its own initialization}}
   int q = moved(std::move(q));  // expected-warning {{variable 'q' is uninitialized when used within its own initialization}}
void test_stuff () {
 
   for (;;) {
     int a = a; // no-warning: used to signal intended lack of initialization.
     int b = b + 1; // expected-warning {{variable 'b' is uninitialized when used within its own initialization}}
     int c = (c + c); // expected-warning {{variable 'c' is uninitialized when used within its own initialization}}
     int d = ({ d + d ;}); // expected-warning {{variable 'd' is uninitialized when used within its own initialization}}
     int e = static_cast<long>(e) + 1; // expected-warning {{variable 'e' is uninitialized when used within its own initialization}}
     int f = foo(f); // expected-warning {{variable 'f' is uninitialized when used within its own initialization}}
+    int j = far(j); // expected-warning {{variable 'j' is uninitialized when used within its own initialization}}
 
     // These don't warn as they don't require the value.
     int g = sizeof(g);
     void* ptr = &ptr;
     int h = bar(&h);
     int i = boo(i);
-    int j = far(j);
     int k = __alignof__(k);
 
     int l = k ? l : l;  // expected-warning {{variable 'l' is uninitialized when used within its own initialization}}
     int m = 1 + (k ? m : m);  // expected-warning {{'m' is uninitialized when used within its own initialization}}
     int n = -n;  // expected-warning {{variable 'n' is uninitialized when used within its own initialization}}
     int o = std::move(o);  // expected-warning {{variable 'o' is uninitialized when used within its own initialization}}
     const int p = std::move(p);  // expected-warning {{variable 'p' is uninitialized when used within its own initialization}}
     int q = moved(std::move(q));  // expected-warning {{variable 'q' is uninitialized when used within its own initialization}}
void setupA(bool x) {
   const A a30 = a30;  // expected-warning {{variable 'a30' is uninitialized when used within its own initialization}}
 
   A a31 = std::move(a31);  // expected-warning {{variable 'a31' is uninitialized when used within its own initialization}}
   A a32 = moveA(std::move(a32));  // expected-warning {{variable 'a32' is uninitialized when used within its own initialization}}
   A a33 = A(std::move(a33));   // expected-warning {{variable 'a33' is uninitialized when used within its own initialization}}
   A a34(std::move(a34));   // expected-warning {{variable 'a34' is uninitialized when used within its own initialization}}
   A a35 = std::move(x ? a34 : (37, a35));  // expected-warning {{variable 'a35' is uninitialized when used within its own initialization}}
 
-  A a36 = const_refA(a36);
-  A a37(const_refA(a37));
+  A a36 = const_refA(a36); // expected-warning {{variable 'a36' is uninitialized when used within its own initialization}}
+  A a37(const_refA(a37)); // expected-warning {{variable 'a37' is uninitialized when used within its own initialization}}
 
   A a38({a38});  // expected-warning {{variable 'a38' is uninitialized when used within its own initialization}}
   A a39 = {a39};  // expected-warning {{variable 'a39' is uninitialized when used within its own initialization}}
   A a40 = A({a40});  // expected-warning {{variable 'a40' is uninitialized when used within its own initialization}}
 
   A a41 = !a41;  // expected-warning {{variable 'a41' is uninitialized when used within its own initialization}}
   A a42 = !(a42);  // expected-warning {{variable 'a42' is uninitialized when used within its own initialization}}
   A a43 = a43 != a42;  // expected-warning {{variable 'a43' is uninitialized when used within its own initialization}}
-  A a44 = a43 != a44;  // expected-warning {{variable 'a44' is uninitialized when used within its own initialization}}
+  A a44 = a43 != a44;  // expected-warning 2{{variable 'a44' is uninitialized when used within its own initialization}}
   A a45 = a45 != a45;  // expected-warning 2{{variable 'a45' is uninitialized when used within its own initialization}}
-  A a46 = 0 != a46;  // expected-warning {{variable 'a46' is uninitialized when used within its own initialization}}
+  A a46 = 0 != a46;  // expected-warning 2{{variable 'a46' is uninitialized when used within its own initialization}}
 
   A a47(a47.set(a47.num));  // expected-warning 2{{variable 'a47' is uninitialized when used within its own initialization}}
   A a48(a47.set(a48.num));  // expected-warning {{variable 'a48' is uninitialized when used within its own initialization}}
   A a49(a47.set(a48.num));
 }
 
 bool cond;