[lld][NFC] Silence -Wuninitialized GCC warnings.

[cjacek]

A workaround for warnings reported in #69101. Use of those variables is guarded by lastType, so I don't think that they are actually used uninitialized and I don't see the warning on GCC 12.3.

[llvmbot]

@llvm/pr-subscribers-lld
@llvm/pr-subscribers-platform-windows

@llvm/pr-subscribers-lld-coff

Author: Jacek Caban (cjacek)

Changes

A workaround for warnings reported in #69101. Use of those variables is guarded by lastType, so I don't think that they are actually used uninitialized and I don't see the warning on GCC 12.3.

---

Full diff: https://github.com/llvm/llvm-project/pull/75183.diff

1 Files Affected:

• (modified) lld/COFF/Writer.cpp (+1-1)

diff --git a/lld/COFF/Writer.cpp b/lld/COFF/Writer.cpp
index 7b1ff8071e2e3..89e0f5b2df744 100644
--- a/lld/COFF/Writer.cpp
+++ b/lld/COFF/Writer.cpp
@@ -560,7 +560,7 @@ void Writer::createECCodeMap() {
   codeMap.clear();
 
   std::optional<chpe_range_type> lastType;
-  Chunk *first, *last;
+  Chunk *first = nullptr, *last = nullptr;
 
   auto closeRange = [&]() {
     if (lastType) {

[mstorsjo]

LGTM, thanks!

FTR, I did run into these warnings with GCC 11.

[dwblaikie]

I believe clang does a better job with sometimes-ininitialized warnings, perhaps we should just disable GCC's overly conservative warning, rather than adding unnecessary initializers? (that would hinder Clang's better warning and sanitizer detections)

[MaskRay]

I believe clang does a better job with sometimes-ininitialized warnings, perhaps we should just disable GCC's overly conservative warning, rather than adding unnecessary initializers? (that would hinder Clang's better warning and sanitizer detections)

I agree. I have seen several instances that GCC -Wuninitialized is annoying than useful.

[mstorsjo]

I believe clang does a better job with sometimes-ininitialized warnings, perhaps we should just disable GCC's overly conservative warning, rather than adding unnecessary initializers? (that would hinder Clang's better warning and sanitizer detections)

I agree. I have seen several instances that GCC -Wuninitialized is annoying than useful.

In this case, it seems like the issue only exists in older GCC versions though, but I'm not sure if we'd like to do such a change depending on GCC version either. So perhaps it would indeed be best to skip such warnings altogether on GCC.

[dwblaikie]

I believe clang does a better job with sometimes-ininitialized warnings, perhaps we should just disable GCC's overly conservative warning, rather than adding unnecessary initializers? (that would hinder Clang's better warning and sanitizer detections)

I agree. I have seen several instances that GCC -Wuninitialized is annoying than useful.

In this case, it seems like the issue only exists in older GCC versions though, but I'm not sure if we'd like to do such a change depending on GCC version either. So perhaps it would indeed be best to skip such warnings altogether on GCC.

We could disable the warning only on the GCC versions where it has a false positive - either by checking the version, or by writing a small snippet that tests the false positive case, and disabling if that snippet produces a warning. (I think we use this kind of code-based feature detection for some warning enablement/disablement - or have in the past - not sure exactly where it lives)

[cjacek]

I found that we already disable -Wmaybe-uninitialized. I created #76251 which disables all -Wuninitialized for GCCs older than 11. We could potentially try to utilize CHECK_C_SOURCE_COMPILES, but for cases like this, it's tricky to find reliable and simple enough tests case. I ended up using a compiler version check, but we could easily change it to be unconditional if that's preferred (that would mean that for some developers warnings would be unnoticed before pushing, through).

If/when #76251 lands, I will revert this PR.

[dwblaikie]

Could we revert this now that the warning's been disabled?

[cjacek]

It's already reverted in #76398.