RFR(S): 8207011: Remove uses of the register storage class specifier

[Mikael Vidstedt]

That is correct.

Kim, Vladimir - thanks for the reviews!

Martin, fyi: I’ll run some final testing on this and if all goes well I’ll likely push later today.

Cheers,
Mikael

> On Jul 12, 2018, at 3:45 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Seems good to me.
> 
> Only 'register' keyword was removed except one place in os_linux_x86.cpp where intptr_t* esp; was replaced with void* esp; to be consistent as I understand.
> 
> Thanks,
> Vladimir
> 
> On 7/11/18 3:52 PM, Mikael Vidstedt wrote:
>> Please review the below change which removes *most* uses of the register keyword/storage class specifier.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 <https://bugs.openjdk.java.net/browse/JDK-8207011>
>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/>
>> * Background (from the bug)
>> The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14.
>> * Commentary
>> The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like:
>> address os::current_stack_pointer() {
>> …
>> #else // gcc
>>   register void *esp __asm__ (SPELL_REG_SP);
>>   return (address) esp;
>> #endif
>> }
>> Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the “clang” style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I’ll keep my eyes on that to make sure we don’t collide (and cc:ing Martin for good luck).
>> Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes.
>> Cheers,
>> Mikael
>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html>