Question about GCC warnings


Building LLVM with a newer GCC version seems to generate several compiler warnings, some of which look like false positives. For example, the ‘-Winit-list-lifetime’ warning added in GCC9 triggers for one of the constructors for ArrayRef, the one taking an initializer_list.

How are false positive warnings dealt with in LLVM in general? It’s of course possible to just ignore them or use compiler flags to disable them, but with that I think you would risk missing other actual meaningful warnings.
Would it make sense to add explicit diagnostic pragmas in the code for such cases, to only silence the warning where they are known to be false positives, or would such a patch be likely to face pushback during review?

I apologize if this question is already answered somewhere in the documentation, I tried looking there first but I could not find anything.


Hello Eric,

Not having much experience with LLVM to speak of here …

It may be useful to compile with a recent version of clang from your distribution. On Xubuntu that would be

apt install clang

I am also using the llvm lld linker that does not use as much memory.

apt install lld

The clang build command here is


The default CMAKE_BUILD_TYPE is “Debug” that uses more memory and much more disk space than “Release”.

“LLVM_ENABLE_ASSERTIONS=On” is noted on the Testing Guide page.

Putting all the terminal output in cmake.log allows easy review of any issues.

Also add the following two lines to /etc/environment to default to compiling with clang. Log out and back in to get these to take. echo $CC to confirm.

export CC=clang
export CXX=clang++

The idea of using clang instead of gcc is that any issues should be reduced (the context scale is reduced) and that remaining issues will be directly related to the user environment on this list.

Regards, Neil Nelson

I don’t think we’ve got any formal policy here - and some folks appear to be trying to preserve GCC warning cleanliness for the LLVM build (but I imagine that work lags new GCC releases, etc)

One more aggressive stance (which I kind of like): Disable any non-clang warning that has an unfavorable false positive (even if we lose the true positives) - improve Clang by adding any missing warnings if they’re sufficiently valuable. (& if Clang warnings have false positives - fix those in clang rather than working around them in the codebase)

  • Dave

Are the initializer_list<>s in question temporary arguments? Maybe the warning is triggering because the ArrayRef will outlive the initializer_list<>.

Hi all,

Thanks for the replies.


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!

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.


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.