This is an archive of the discontinued LLVM Phabricator instance.

[Clang] -Wunused-but-set-variable warning - handle also pre/post unary operators
ClosedPublic

Authored by xbolva00 on Mar 22 2022, 4:27 PM.

Details

Summary

Clang fails to diagnose:

void test() {
    int j = 0;
    for (int i = 0; i < 1000; i++)
            j++;
    return;
}

Reason: Missing support for UnaryOperator.

We should not warn with volatile variables... so add check for it.

Diff Detail

Event Timeline

xbolva00 created this revision.Mar 22 2022, 4:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2022, 4:27 PM
xbolva00 requested review of this revision.Mar 22 2022, 4:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2022, 4:27 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

LGTM. Maybe @efriedma can look at this as well.

This revision is now accepted and ready to land.Mar 23 2022, 11:43 AM
kamaub added a subscriber: kamaub.Mar 25 2022, 7:55 AM

This option appears to incorrectly warn warning that unsigned NumEntries = getNumEntries(); is "set but not used" in llvm/include/llvm/ADT/DenseMap.h:129 and so it is breaking the ppc64le-lld-multistage-test bot.
This could be because the only use is in an assert which is in a corner case maybe?

const KeyT EmptyKey = getEmptyKey(), TombstoneKey = getTombstoneKey();
if (std::is_trivially_destructible<ValueT>::value) {
  // Use a simpler loop when values don't need destruction.
  for (BucketT *P = getBuckets(), *E = getBucketsEnd(); P != E; ++P)
    P->getFirst() = EmptyKey;
} else {
  unsigned NumEntries = getNumEntries();
  for (BucketT *P = getBuckets(), *E = getBucketsEnd(); P != E; ++P) {
    if (!KeyInfoT::isEqual(P->getFirst(), EmptyKey)) {
      if (!KeyInfoT::isEqual(P->getFirst(), TombstoneKey)) {
        P->getSecond().~ValueT();
        --NumEntries;
      }
      P->getFirst() = EmptyKey;
    }
  }
  assert(NumEntries == 0 && "Node count imbalance!");
}

I noticed you were commit NFCI changes to makes sure you did not break any builds before reapplying but it appears you missed llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp:3924 which is causing build breaks to both the sanitizer-ppc64be-linux and sanitizer-ppc64le-linux bots. Is there an NFCI planned for it by you? If not I'll submit an NFC change myself in a few minutes.

I'm sorry I took so long to notify you but I need to bring these bots back to green as soon as possible, they have been broken too long.

xbolva00 added a comment.EditedMar 25 2022, 9:08 AM

This option appears to incorrectly warn warning that unsigned NumEntries = getNumEntries(); is "set but not used" in llvm/include/llvm/ADT/DenseMap.h:129 and so it is breaking the ppc64le-lld-multistage-test bot.
This could be because the only use is in an assert which is in a corner case maybe?

const KeyT EmptyKey = getEmptyKey(), TombstoneKey = getTombstoneKey();
if (std::is_trivially_destructible<ValueT>::value) {
  // Use a simpler loop when values don't need destruction.
  for (BucketT *P = getBuckets(), *E = getBucketsEnd(); P != E; ++P)
    P->getFirst() = EmptyKey;
} else {
  unsigned NumEntries = getNumEntries();
  for (BucketT *P = getBuckets(), *E = getBucketsEnd(); P != E; ++P) {
    if (!KeyInfoT::isEqual(P->getFirst(), EmptyKey)) {
      if (!KeyInfoT::isEqual(P->getFirst(), TombstoneKey)) {
        P->getSecond().~ValueT();
        --NumEntries;
      }
      P->getFirst() = EmptyKey;
    }
  }
  assert(NumEntries == 0 && "Node count imbalance!");
}

I noticed you were commit NFCI changes to makes sure you did not break any builds before reapplying but it appears you missed llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp:3924 which is causing build breaks to both the sanitizer-ppc64be-linux and sanitizer-ppc64le-linux bots. Is there an NFCI planned for it by you? If not I'll submit an NFC change myself in a few minutes.

This option appears to incorrectly warn warning that

Warns correctly in configurations where assert is removed. (void) trick will solve that.
Sorry, I missed this one, as this was outside common code + X86. Will push fix soon.

Edit: fixes pushed.

Hi,

I noticed these to warning when compiling libunwind/src/UnwindLevel1.c with this patch:

00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:175:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:293:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 2 warnings generated.

Hi,

I noticed these to warning when compiling libunwind/src/UnwindLevel1.c with this patch:

00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:175:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:293:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 2 warnings generated.

Hi,

I noticed these to warning when compiling libunwind/src/UnwindLevel1.c with this patch:

00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:175:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:293:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 2 warnings generated.

A warning was improved so fires more often.

Clearly, sometimes in __unw_phase2_resume, “fn” is ignored (so passed framesWalked is throw away as well). I see nothing wrong to warn here.

(void)framesWalked; will silence it.