Merge jdk-26+16 into rivos/main

doc/hotspot-style.html

@@ -86,8 +86,9 @@ <h1 class="title">HotSpot Coding Style</h1>
 <li><a href="#thread_local" id="toc-thread_local">thread_local</a></li>
 <li><a href="#nullptr" id="toc-nullptr">nullptr</a></li>
 <li><a href="#atomic" id="toc-atomic">&lt;atomic&gt;</a></li>
-<li><a href="#inline-variables" id="toc-inline-variables">Inline
-Variables</a></li>
+<li><a href="#variable-templates-and-inline-variables"
+id="toc-variable-templates-and-inline-variables">Variable Templates and
+Inline Variables</a></li>
 <li><a href="#initializing-variables-with-static-storage-duration"
 id="toc-initializing-variables-with-static-storage-duration">Initializing
 variables with static storage duration</a></li>
@@ -937,12 +938,18 @@ <h3 id="atomic">&lt;atomic&gt;</h3>
 "conservative" memory ordering, which may differ from (may be stronger
 than) sequentially consistent. There are algorithms in HotSpot that are
 believed to rely on that ordering.</p>
-<h3 id="inline-variables">Inline Variables</h3>
-<p>Variables with static storage duration may be declared
-<code>inline</code> (<a href="https://wg21.link/p0386r2">p0386r2</a>).
-This has similar effects as for declaring a function inline: it can be
-defined, identically, in multiple translation units, must be defined in
-every translation unit in which it is <a
+<h3 id="variable-templates-and-inline-variables">Variable Templates and
+Inline Variables</h3>
+<p>The use of variable templates (including static data member
+templates) (<a href="https://wg21.link/N3651">N3651</a>) is permitted.
+They provide parameterized variables and constants in a simple and
+direct form, instead of requiring the use of various workarounds.</p>
+<p>Variables with static storage duration and variable templates may be
+declared <code>inline</code> (<a
+href="https://wg21.link/p0386r2">p0386r2</a>), and this usage is
+permitted. This has similar effects as for declaring a function inline:
+it can be defined, identically, in multiple translation units, must be
+defined in every translation unit in which it is <a
 href="https://en.cppreference.com/w/cpp/language/definition"
 title="One Definition Rule">ODR used</a>, and the behavior of the
 program is as if there is exactly one variable.</p>
@@ -955,16 +962,17 @@ <h3 id="inline-variables">Inline Variables</h3>
 ordering constraints that exist for non-inline variables don't apply, as
 there isn't a single program-designated translation unit containing the
 definition.</p>
-<p>A <code>constexpr</code> static data member is implicitly
-<code>inline</code>. As a consequence, an <a
+<p>A <code>constexpr</code> static data member or static data member
+template is implicitly <code>inline</code>. As a consequence, an <a
 href="https://en.cppreference.com/w/cpp/language/definition"
-title="One Definition Rule">ODR use</a> of such a variable doesn't
-require a definition in some .cpp file. (This is a change from
-pre-C++17. Beginning with C++17, such a definition is considered a
-duplicate definition, and is deprecated.)</p>
-<p>Declaring a <code>thread_local</code> variable <code>inline</code> is
-forbidden for HotSpot code. <a href="#thread_local">The use of
-<code>thread_local</code></a> is already heavily restricted.</p>
+title="One Definition Rule">ODR use</a> of such a member doesn't require
+a definition in some .cpp file. (This is a change from pre-C++17.
+Beginning with C++17, such a definition is considered a duplicate
+definition, and is deprecated.)</p>
+<p>Declaring a <code>thread_local</code> variable template or
+<code>inline</code> variable is forbidden in HotSpot code. <a
+href="#thread_local">The use of <code>thread_local</code></a> is already
+heavily restricted.</p>
 <h3
 id="initializing-variables-with-static-storage-duration">Initializing
 variables with static storage duration</h3>
@@ -1851,11 +1859,6 @@ <h3 id="stdlaunder"><code>std::launder()</code></h3>
 <h3 id="additional-undecided-features">Additional Undecided
 Features</h3>
 <ul>
-<li><p>Trailing return type syntax for functions (<a
-href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm">n2541</a>)</p></li>
-<li><p>Variable templates (<a
-href="https://isocpp.org/files/papers/N3651.pdf">n3651</a>, <a
-href="http://wg21.link/p0127r2">p0127r2</a>)</p></li>
 <li><p>Member initializers and aggregates (<a
 href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html">n3653</a>)</p></li>
 <li><p>Rvalue references and move semantics</p></li>

doc/hotspot-style.md

@@ -856,14 +856,19 @@ ordering, which may differ from (may be stronger than) sequentially
 consistent.  There are algorithms in HotSpot that are believed to rely
 on that ordering.
 
-### Inline Variables
+### Variable Templates and Inline Variables
 
-Variables with static storage duration may be declared `inline`
-([p0386r2](https://wg21.link/p0386r2)). This has similar effects as for
-declaring a function inline: it can be defined, identically, in multiple
-translation units, must be defined in every translation unit in which it is
-[ODR used][ODR], and the behavior of the program is as if there is exactly one
-variable.
+The use of variable templates (including static data member templates)
+([N3651](https://wg21.link/N3651)) is permitted. They provide parameterized
+variables and constants in a simple and direct form, instead of requiring the
+use of various workarounds.
+
+Variables with static storage duration and variable templates may be declared
+`inline` ([p0386r2](https://wg21.link/p0386r2)), and this usage is
+permitted. This has similar effects as for declaring a function inline: it can
+be defined, identically, in multiple translation units, must be defined in
+every translation unit in which it is [ODR used][ODR], and the behavior of the
+program is as if there is exactly one variable.
 
 Declaring a variable inline allows the complete definition to be in a header
 file, rather than having a declaration in a header and the definition in a
@@ -874,13 +879,15 @@ make initialization order problems worse. The few ordering constraints
 that exist for non-inline variables don't apply, as there isn't a single
 program-designated translation unit containing the definition.
 
-A `constexpr` static data member is implicitly `inline`. As a consequence, an
-[ODR use][ODR] of such a variable doesn't require a definition in some .cpp
+A `constexpr` static data member or static data member template
+is implicitly `inline`. As a consequence, an
+[ODR use][ODR] of such a member doesn't require a definition in some .cpp
 file. (This is a change from pre-C++17. Beginning with C++17, such a
 definition is considered a duplicate definition, and is deprecated.)
 
-Declaring a `thread_local` variable `inline` is forbidden for HotSpot code.
-[The use of `thread_local`](#thread_local) is already heavily restricted.
+Declaring a `thread_local` variable template or `inline` variable is forbidden
+in HotSpot code.  [The use of `thread_local`](#thread_local) is already
+heavily restricted.
 
 ### Initializing variables with static storage duration
 
@@ -1846,13 +1853,6 @@ See Object Lifetime: C++17 6.8/8, C++20 6.7.3/8
 
 ### Additional Undecided Features
 
-* Trailing return type syntax for functions
-([n2541](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm))
-
-* Variable templates
-([n3651](https://isocpp.org/files/papers/N3651.pdf),
-[p0127r2](http://wg21.link/p0127r2))
-
 * Member initializers and aggregates
 ([n3653](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html))
 

make/autoconf/flags-cflags.m4

@@ -934,48 +934,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
         IF_FALSE: [$2FDLIBM_CFLAGS=""])
   fi
   AC_SUBST($2FDLIBM_CFLAGS)
-
-  # Check whether the compiler supports the Arm C Language Extensions (ACLE)
-  # for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does.
-  # ACLE and this flag are required to build the aarch64 SVE related functions in
-  # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
-  # that check.
-  if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
-    if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
-      AC_LANG_PUSH(C)
-      OLD_CFLAGS="$CFLAGS"
-      CFLAGS="$CFLAGS -march=armv8-a+sve"
-      AC_MSG_CHECKING([if Arm SVE ACLE is supported])
-      AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <arm_sve.h>],
-          [
-            svint32_t r = svdup_n_s32(1);
-            return 0;
-          ])],
-          [
-            AC_MSG_RESULT([yes])
-            $2SVE_CFLAGS="-march=armv8-a+sve"
-            # Switching the initialization mode with gcc from 'pattern' to 'zero'
-            # avoids the use of unsupported `__builtin_clear_padding` for variable
-            # length aggregates
-            if test "x$DEBUG_LEVEL" != xrelease && test "x$TOOLCHAIN_TYPE" = xgcc ; then
-              INIT_ZERO_FLAG="-ftrivial-auto-var-init=zero"
-              FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$INIT_ZERO_FLAG],
-                IF_TRUE: [
-                  $2SVE_CFLAGS="${$2SVE_CFLAGS} $INIT_ZERO_FLAG"
-                ]
-              )
-            fi
-          ],
-          [
-            AC_MSG_RESULT([no])
-            $2SVE_CFLAGS=""
-          ]
-      )
-      CFLAGS="$OLD_CFLAGS"
-      AC_LANG_POP(C)
-    fi
-  fi
-  AC_SUBST($2SVE_CFLAGS)
 ])
 
 AC_DEFUN_ONCE([FLAGS_SETUP_BRANCH_PROTECTION],

make/autoconf/flags-other.m4

@@ -107,6 +107,62 @@ AC_DEFUN([FLAGS_SETUP_NMFLAGS],
   AC_SUBST(NMFLAGS)
 ])
 
+# Check whether the compiler supports the Arm C Language Extensions (ACLE)
+# for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does.
+# ACLE and this flag are required to build the aarch64 SVE related functions
+# in libvectormath.
+AC_DEFUN([FLAGS_SETUP_SVE],
+[
+  AARCH64_SVE_AVAILABLE=false
+  # Apple Silicon does not support SVE; use macOS as a proxy for that check.
+  if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
+    if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
+      # check the compiler and binutils support sve or not
+      AC_MSG_CHECKING([if Arm SVE ACLE is supported])
+      AC_LANG_PUSH([C])
+      saved_cflags="$CFLAGS"
+      CFLAGS="$CFLAGS -march=armv8-a+sve $CFLAGS_WARNINGS_ARE_ERRORS ARG_ARGUMENT"
+      AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
+        [
+          #include <arm_sve.h>
+          svfloat64_t a() {}
+        ],
+        [
+          svint32_t r = svdup_n_s32(1)
+        ])],
+        [
+          AARCH64_SVE_AVAILABLE=true
+        ]
+      )
+      CFLAGS="$saved_cflags"
+      AC_LANG_POP([C])
+      AC_MSG_RESULT([$AARCH64_SVE_AVAILABLE])
+    fi
+  fi
+
+  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
+    RESULT: AARCH64_SVE_ENABLED,
+    DESC: [Use SVE when compiling libsleef],
+    AVAILABLE: $AARCH64_SVE_AVAILABLE)
+  SVE_CFLAGS=""
+  if test "x$AARCH64_SVE_ENABLED" = xtrue; then
+    SVE_CFLAGS="-march=armv8-a+sve"
+    # Switching the initialization mode with gcc from 'pattern' to 'zero'
+    # avoids the use of unsupported `__builtin_clear_padding` for variable
+    # length aggregates
+    if test "x$DEBUG_LEVEL" != xrelease && test "x$TOOLCHAIN_TYPE" = xgcc ; then
+      AC_MSG_CHECKING([Switching the initialization mode with gcc from pattern to zero])
+      INIT_ZERO_FLAG="-ftrivial-auto-var-init=zero"
+      FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$INIT_ZERO_FLAG],
+        IF_TRUE: [
+          SVE_CFLAGS="${SVE_CFLAGS} $INIT_ZERO_FLAG"
+        ]
+      )
+    fi
+  fi
+  AC_SUBST(SVE_CFLAGS)
+])
+
 ################################################################################
 # platform independent
 AC_DEFUN([FLAGS_SETUP_ASFLAGS],

make/autoconf/flags.m4

@@ -374,6 +374,7 @@ AC_DEFUN([FLAGS_SETUP_FLAGS],
   FLAGS_SETUP_RCFLAGS
   FLAGS_SETUP_NMFLAGS
 
+  FLAGS_SETUP_SVE
   FLAGS_SETUP_ASFLAGS
   FLAGS_SETUP_ASFLAGS_CPU_DEP([TARGET])
   FLAGS_SETUP_ASFLAGS_CPU_DEP([BUILD], [OPENJDK_BUILD_])

src/hotspot/cpu/aarch64/assembler_aarch64.inline.hpp

@@ -26,7 +26,7 @@
 #ifndef CPU_AARCH64_ASSEMBLER_AARCH64_INLINE_HPP
 #define CPU_AARCH64_ASSEMBLER_AARCH64_INLINE_HPP
 
-#include "asm/assembler.inline.hpp"
+#include "asm/assembler.hpp"
 #include "asm/codeBuffer.hpp"
 #include "code/codeCache.hpp"
 

src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp

@@ -275,7 +275,7 @@ address BarrierSetAssembler::patching_epoch_addr() {
 }
 
 void BarrierSetAssembler::increment_patching_epoch() {
-  Atomic::inc(&_patching_epoch);
+  AtomicAccess::inc(&_patching_epoch);
 }
 
 void BarrierSetAssembler::clear_patching_epoch() {

src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp

@@ -112,22 +112,22 @@ class NativeNMethodBarrier {
   }
 
   int get_value() {
-    return Atomic::load_acquire(guard_addr());
+    return AtomicAccess::load_acquire(guard_addr());
   }
 
   void set_value(int value, int bit_mask) {
     if (bit_mask == ~0) {
-      Atomic::release_store(guard_addr(), value);
+      AtomicAccess::release_store(guard_addr(), value);
       return;
     }
     assert((value & ~bit_mask) == 0, "trying to set bits outside the mask");
     value &= bit_mask;
-    int old_value = Atomic::load(guard_addr());
+    int old_value = AtomicAccess::load(guard_addr());
     while (true) {
       // Only bits in the mask are changed
       int new_value = value | (old_value & ~bit_mask);
       if (new_value == old_value) break;
-      int v = Atomic::cmpxchg(guard_addr(), old_value, new_value, memory_order_release);
+      int v = AtomicAccess::cmpxchg(guard_addr(), old_value, new_value, memory_order_release);
       if (v == old_value) break;
       old_value = v;
     }

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp

@@ -1623,7 +1623,7 @@ class MacroAssembler: public Assembler {
                     FloatRegister p, FloatRegister z, FloatRegister t1);
   void ghash_reduce_wide(int index, FloatRegister result, FloatRegister lo, FloatRegister hi,
                     FloatRegister p, FloatRegister z, FloatRegister t1);
-  void ghash_processBlocks_wide(address p, Register state, Register subkeyH,
+  void ghash_processBlocks_wide(Label& p, Register state, Register subkeyH,
                                 Register data, Register blocks, int unrolls);
 
 

src/hotspot/cpu/aarch64/macroAssembler_aarch64_aes.cpp

@@ -507,7 +507,7 @@ void MacroAssembler::ghash_modmul(FloatRegister result,
 //
 // Clobbers all vector registers.
 //
-void MacroAssembler::ghash_processBlocks_wide(address field_polynomial, Register state,
+void MacroAssembler::ghash_processBlocks_wide(Label& field_polynomial, Register state,
                                               Register subkeyH,
                                               Register data, Register blocks, int unrolls) {
   int register_stride = 7;
@@ -531,7 +531,10 @@ void MacroAssembler::ghash_processBlocks_wide(address field_polynomial, Register
   FloatRegister p = v31;
   eor(vzr, T16B, vzr, vzr); // zero register
 
-  ldrq(p, field_polynomial);    // The field polynomial
+  // load polynomial via label which must identify local data in the
+  // same code stub
+  adr(rscratch1, field_polynomial);
+  ldrq(p, rscratch1);    // The field polynomial
 
   ldrq(v0, Address(state));
   ldrq(Hprime, Address(subkeyH));