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

Kim Barrett kim.barrett at oracle.com
Thu Jul 12 04:03:42 UTC 2018


> On Jul 11, 2018, at 6:52 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> 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>

Looks good.



More information about the ppc-aix-port-dev mailing list