RFE: configuration for compiling HotSpot with Clang

Coleen Phillimore coleen.phillimore at oracle.com
Tue Feb 15 08:41:34 PST 2011

Thanks Volker.  I've filed a bug against the VM for the hashtable.hpp 
bug and pointed to your bug (7019689).


On 2/15/2011 8:52 AM, Volker Simonis wrote:
> g++ 4.4.3 and 4.5.2 definitely don't find the bug.
> I filed a bug report with a slightly more complex example than that
> from the FAQ at:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47752
> Regards,
> Volker
> On Fri, Feb 11, 2011 at 10:37 PM, Mark Wielaard<mark at klomp.org>  wrote:
>> On Fri, 2011-02-11 at 19:24 +0100, Volker Simonis wrote:
>>> Notice that this patch contains one additional change compared to the
>>> patch in the blog. While I did the tests for the blog with an slightly
>>> outdated HS20b03 I synced a brand new version today to prepare the
>>> patch. With this new version I found a true C++ bug in
>>> "src/share/vm/utilities/hashtable.hpp" which was introduced recently
>>> by the "6990754: Use native memory and reference counting to implement
>>> SymbolTable" change and which has to do with name lookup of
>>> nondependent names in dependent base classes (see
>>> http://www.parashift.com/c++-faq-lite/templates.html#faq-35.19 for a
>>> nice explanation). Wouldn't have happened with Clang:)
>> I didn't try building HS20b03 yet, but g++ (at least version 4.1, 4.4
>> and 4.5) should be able to detect this. Trying to compile the FAQ
>> example gives:
>> t.cpp: In member function ‘void D<T>::g()’:
>> t.cpp:12:8: error: there are no arguments to ‘f’ that depend on a
>> template parameter, so a declaration of ‘f’ must be available
>> t.cpp:12:8: note: (if you use ‘-fpermissive’, G++ will accept your code,
>> but allowing the use of an undeclared name is deprecated)
>> If g++ didn't detect it in the hashtable.hpp case, could you file a bug
>> report for it http://gcc.gnu.org/bugzilla
>> Thanks,
>> Mark

More information about the hotspot-dev mailing list