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

[Mikael Gerdin]

Hi Volker,

On 2016-10-24 10:53, Volker Simonis wrote:
> 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 :)

Does this change make the definition of CONST64 / UCONST64 the same on 
all globalDefinitions_x variants?
If so can we move the definition to the common file instead of having it 
in the per-compiler files?

Thanks
/Mikael

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