-fcheck-new not supported by LLVM/clang

Clang Frontend
#1

Hello LLVM/Clang,

With Xcode4.5, llvm/clang:

Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

we use -fcheck-new in our compiler settings which has been triggering this clang warning:

clang: warning: argument unused during compilation: ‘-fcheck-new’

We wonder if this gcc setting is not supported by clang.
gcc spec seems to say that without this the only mechanism against heap allocation returning null pointers
is through exceptions. However, we disabled exceptions for performance requirements. So this setting
is important to us.

Currently we have to use -Qunused-arguments to suppress the warnings, but
the real question is whether or not it is safe to work without -fcheck-new if it’s not supported by clang.

From web search, we also found the following links which implies that it could be a bug in LLVM/clang:

http://comments.gmane.org/gmane.comp.java.openjdk.hotspot.devel/4106

  •  If -fcheck-new is an important feature for you (and not a workaround for an old gcc
problem), please feel free to file a bug at [http://llvm.org/bugs/](http://llvm.org/bugs/)

http://weblogs.java.net/blog/simonis/archive/2011/02/10/compiling-hotspot-vm-clang

  • Except for the -fcheck-new option, Clang seems to understand all the other compiler options used during the HotSpot build process. For -fcheck-new a warning is issued advertising that the option will be ignored. So I just removed it frommake/linux/makefiles/clang.make. I have also removed obvious workarounds for some older GCC versions in the new Clang files which were derived from their corresponding GCC counterparts.

http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-February/003870.html

  • There was a longer discussion around the fix for the CHECK macros
about one and a half years ago. I started a patch that time but than
somehow forgot about it. Now with the new compiler (and the old
warnings) I remembered about it. I hope to get it done this time and
to send it out for review soon. Thank you for the offer to take care
about it.

Anybody has any comments?

Thanks!

Beinan

#2

It is not supported; "argument unused during compilation" is the
generic "I don't know what you're asking for, so I'm ignoring it":
warning.

-Eli

#3

I would note that on Linux, with overcommit, this is probably useless anyway.

Unless you grow out of address space, which is hard on 64 bits systems (2^47 bytes of available address space) which would lead the kernel not to allocate memory, the kernel will hand over a pointer to a memory page whenever malloc requires it, even though the page itself might be much smaller than the requested block, and the memory in the block will be effectively allocated when written to (or read from… I guess).

As such, malloc should never return a null pointer, making std::bad_alloc a somewhat mystic creature (even with exceptions enabled). And in the worst case, the constructor call (after new returned but before your applicative code is handed over the pointer) will write to a memory zone for which no page can be allocated and your program will crash (*).

So, at least on Linux, I would see -fcheck-new as a dubious flag.

– Matthieu

(*) Note: there is a oom killer process that is supposed to kill random programs on the machine to free up memory when it is exhausted…

#4

If at all possible, you should declare your allocation function with an empty exception specification (“throw()”), which is the standards-compliant way of forcing this null-checking behavior. Otherwise, it should be straightforward for even a newcomer to clang to add the -fcheck-new flag and alter IR-generation to honor it.

John.