[llvm-dev] Question about GCC warnings

Erik Hogeman via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 19 05:02:40 PDT 2019


Hi all,

Thanks for the replies.

@Neil:
Thanks, what you say about using clang makes sense, unfortunately I do not have the option to not use GCC, which is why I am curious about the process around specifically GCC warnings. I appreciate your answer though, thanks!

@David:
I see, so there is no formal policy around this. Disabling the warnings completely does work around the issue indeed, and if that's the general opinion of people involved with LLVM I am fine with doing that locally. However, for me personally it would be convenient to fix the false positives in the code, since I don't have the option to completely use clang, thus the question here.
I assume that slightly massaging pieces of code to make warnings go away is considered OK, in this case I'm not sure how to do that without using a diagnostic pragma though, without completely removing the constructor GCC is warning about.

@Brian:
I think that's the case the warning is trying to catch indeed, however to me it seems like this is intended usage in the ArrayRef class, the typical use case I would see in the code is when a function parameter takes an 'ArrayRef', an initializer_list is used to construct a temporary list of a known number of objects to pass to that function, in which case if I understand the C++ specification correctly the lifetime of the temporary object would persist throughout the entire function call, so it seems like a valid usage to me.
The ArrayRef class also explicitly states that it's not safe to store ArrayRef objects in general, so it seems to be intended unless I'm confused.

I can also see why this warning would be useful in other cases though, which is why I'm hesitant to just disable it completely. But it's not clear to me how much other people care about specifically GCC warnings.

Thanks,
Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190719/45264fa8/attachment.html>


More information about the llvm-dev mailing list