On Fri, 12 Sep 2025 08:51:50 GMT, SendaoYan <s...@openjdk.org> wrote:
>> Hi all, >> >> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report >> compilation failre, shows as >> [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777). >> >> This PR add the expression `svfloat64_t a() {}` to makefile which will >> trigger the compilation during configure stage. After this PR, at configure >> stage will check the gcc and assember support `-march=armv8-a+sve` or not >> more comprehensive. >> >> Testing: >> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as >> '-march=armv8-a+sve' >> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty >> >> >> The compilation fails demo as below: >> >> >> # cat sve.c >> #include <arm_sve.h> >> svfloat64_t a() {} >> # gcc -march=armv8-a+sve sve.c >> /tmp/ccVOzMzb.s: Assembler messages: >> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs' > > SendaoYan has updated the pull request incrementally with one additional > commit since the last revision: > > Remove unnecessary CFLAGS save and restore It's very close to ok now. make/autoconf/flags-other.m4 line 128: > 126: saved_cc="$CC" > 127: CFLAGS="$CFLAGS -march=armv8-a+sve $CFLAGS_WARNINGS_ARE_ERRORS > ARG_ARGUMENT" > 128: CC="$ARG_PREFIX[CC]" You shouldn't need to save `CC` and use a custom one here. `CC` should be the target compiler already. make/autoconf/flags-other.m4 line 140: > 138: [AVAILABLE=false] > 139: ) > 140: AC_MSG_RESULT([$AVAILABLE]) This will now print true/false instead of yes/no, which will look a bit weird. It's a consequence of us preferring `true/false` to express booleans internally. I think I would inline the call to `AC_MSG_RESULT` in each of the branches of `AC_COMPILE_IFELSE` to work around this. make/autoconf/flags.m4 line 380: > 378: # for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does. > 379: # ACLE and this flag are required to build the aarch64 SVE related > functions > 380: # in libvectormath. I think you misunderstood me here, I meant move it to the top of the macro declaration, not the call. I think it makes more sense to document it where it's defined. ------------- PR Review: https://git.openjdk.org/jdk/pull/27073#pullrequestreview-3216584548 PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344191092 PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344204464 PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344185294
