RFR(XS): 8168490: Use the LL/ULL suffixes to define 64-bit integer literals on Windows

Volker Simonis volker.simonis at gmail.com
Mon Oct 24 08:53:26 UTC 2016


On Mon, Oct 24, 2016 at 9:14 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 24/10/2016 5:12 PM, Volker Simonis wrote:
>>
>> On Mon, Oct 24, 2016 at 2:43 AM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> Hi Volker,
>>>
>>> On 22/10/2016 1:35 AM, Volker Simonis wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> can I please have a review and sponsor for the following trivial fix:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8168490/
>>>> https://bugs.openjdk.java.net/browse/JDK-8168490
>>>>
>>>> Currently we use the i64/ui64 suffixes to declare 64-bit integer
>>>> literals on Windows (see
>>>> src/share/vm/utilities/globalDefinitions_visCPP.hpp).
>>>>
>>>> Unfortunately this suffix is not known to Eclipse so most of a hotspot
>>>> files have errors in an Eclipse project (e.g. NULL is defined as
>>>> '0i64' which gives a syntax error in Eclipse, but NULL is used in most
>>>> hotspot of the source files).
>>>>
>>>> Fortunately VS supports the more standard conforming LL/ULL suffixes
>>>> (see http://en.cppreference.com/w/cpp/language/integer_literal) since
>>>> at least VS2010 (see
>>>> https://msdn.microsoft.com/en-us/library/00a1awxf(v=vs.100).aspx).I
>>>> therefore propose to change the suffix for integer literals from
>>>> i64/ui64 to LL/ULL on Windows.
>>>
>>>
>>>
>>> In the sense that this changes the VIS specific code to use a more stand
>>> conforming form this seems fine.
>>>
>>> But as I wrote in the bug report, should we even be using this file with
>>> non
>>> Visual Studio compilers?
>>>
>>
>> What I meant with "Eclipse doesn't understand" the suffix is that the
>> Eclipse C++ parser doesn't understand it. Eclipse just parses all the
>> C++ files which belong to a project in order to build up its code
>> database for code navigation. As such it reads
>> globalDefinitions_visCPP.hpp on Windows (if we configure a
>> corresponding project) or  globalDefinitions_gcc.hpp on Linux, etc...
>>
>> This does not mean that we are using globalDefinitions_visCPP.hpp for
>> building with another compiler. And we have no IDE-specific headers
>> (this actually makes no sense since the IDEs should use the same
>> settings which are used for the actual builds).
>>
>> Not sure about other IDEs, but Eclipse's C++ parser doesn't understand
>> the i64/ui64 suffix and as there is a better, more standard-conforming
>> way of declaring 64-bit integer literals on Windows I've just proposed
>> the cleanup.
>>
>> Does this answer your question?
>
>
> Yes - thanks for clarifying.
>

Your welcome! Could you then please sponsor this change :)

>
> David
>
>> Thank you and best egards,
>> Volker
>>
>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>
>


More information about the hotspot-dev mailing list