[CMake] Disable -Wdangling-reference warnings on GCC #157541
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This gets rid of 99 warnings which mostly seem like false positives
(in a build of LLVM+Clang+LLDB).
The warnings look e.g. like this:
../lib/ObjCopy/COFF/COFFObjcopy.cpp: In function ‘uint64_t llvm::objcopy::coff::getNextRVA(const Object&)’:
../lib/ObjCopy/COFF/COFFObjcopy.cpp:38:18: warning: possibly dangling reference to a temporary [-Wdangling-reference]
38 | const Section &Last = Obj.getSections().back();
| ^~~~
../lib/ObjCopy/COFF/COFFObjcopy.cpp:38:47: note: the temporary was destroyed at the end of the full expression ‘(& Obj)->llvm::objcopy::coff::Object::getSections().llvm::ArrayRef<llvm::objcopy::coff::Section>::back()’
38 | const Section &Last = Obj.getSections().back();
| ~~~~~~~~~~~~~~~~~~~~~~^~
In this example, the `Object::getSections()` method returns an
`ArrayRef<Section>` from a `std::vector<Section>`. We invoke `back()`
on that, and store a reference in a local variable. Even though
the temporary `ArrayRef<Section>` has been destroyed, the reference
points to something which still is alive in the `std::vector<Section>`.
|
Yes, it seems so.
Yes, ideally... Do you feel like writing a report? I see that you had some analysis in #125538 already. The example I outline in the commit message here also is quite clear, both in why it isn't an issue, but also why it's understandably hard for the compiler to know whether it is an issue or not. |
TBH, no. I would need to reproduce them with the latest compiler and currently I have no LLVM build set up to begin with. |
MaskRay
approved these changes
Sep 9, 2025
|
Re upstream bug reports, I found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110358 which cover the majority of our cases. The gist of it:
Since GCC 14, this detects any class which looks like If compiling with GCC 15, I do see some of these warnings relating to ArrayRef to be silenced - but there's even more of them for other cases; with GCC 15, I see up to 274 of these warnings, while I "only" had 99 with GCC 13.
Since GCC 14, it's also possible to tag individual classes/functions with this attribute (classes like ArrayRef and similar), to excempt them from this warning. I did find one odd case which did seem like a separate true false positive though, which I filed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121871. |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/163/builds/26124 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/166/builds/2237 Here is the relevant piece of the build log for the reference |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This gets rid of 99 warnings which mostly seem like false positives (in a build of LLVM+Clang+LLDB, with GCC 13).
The warnings look e.g. like this:
In this example, the
Object::getSections()method returns anArrayRef<Section>from astd::vector<Section>. We invokeback()on that, and store a reference in a local variable. Even though the temporaryArrayRef<Section>has been destroyed, the reference points to something which still is alive in thestd::vector<Section>.