[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
mgrang added inline comments.
Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:47
+Features.push_back("+d");
+break;
+ }
Can you also add a case for pushing back +c here?
https://reviews.llvm.org/D39963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
asb marked an inline comment as done. asb added a comment. In https://reviews.llvm.org/D39963#931026, @apazos wrote: > Can you push this as a patch to review/commit instead of RFC? It has received > a lot of comments/corrections already and I think it is getting in a shape we > can merge. I might move the baremetal support to separate patch and discuss that on the mailing list. I'll remove the [RFC] tag in the next update, adding tests. Comment at: test/Preprocessor/init.c:9991 +// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \ +// RUN: | FileCheck -match-full-lines -check-prefix=RISCV32 %s +// RISCV32: #define _ILP32 1 apazos wrote: > Shouldn't we just check for the target specific defines in these tests? Many of the other tests seem to test a similarly large set of defines, plus I think you _do_ want to check the majority of these (especially the ones related to C types). https://reviews.llvm.org/D39963 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
apazos added a comment.
Can you push this as a patch to review/commit instead of RFC? It has received a
lot of comments/corrections already and I think it is getting in a shape we can
merge.
Comment at: lib/Driver/ToolChains/RISCV.cpp:86
+CmdArgs.push_back("-lc");
+CmdArgs.push_back("-lgloss");
+CmdArgs.push_back("--end-group");
asb wrote:
> apazos wrote:
> > mgrang wrote:
> > > How about if our sysroot is linux (as opposed to elf)? There won't be any
> > > libgloss.a, right? Also there won't be a crt0.o (instead there will be
> > > crt1.o).
> > Supporting linux target is desirable early on because most of us will be
> > using Qemu for running tests.
> Linux targets are not currently supported, as they require the ilp32d or
> lp64d (hard double precision) ABI. The only fiddly part is actually in the
> Clang frontend, handling structs composed of two reals or one integer + one
> real. This is obviously high up on the todo list.
I meant user code compiled with target=riscv32-unknown-linux march=rv32imafdc
and mabi=ilp32. This would run fine on qemu.
Comment at: test/Preprocessor/init.c:9991
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \
+// RUN: | FileCheck -match-full-lines -check-prefix=RISCV32 %s
+// RISCV32: #define _ILP32 1
Shouldn't we just check for the target specific defines in these tests?
https://reviews.llvm.org/D39963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
mgrang added inline comments. Comment at: lib/Driver/ToolChains/Gnu.cpp:1823 + "riscv64-unknown-linux-gnu", + "riscv32-unknown-elf"}; + I suppose we need riscv64-unknown-elf here too? Comment at: lib/Driver/ToolChains/Linux.cpp:228 const bool IsHexagon = Arch == llvm::Triple::hexagon; + const bool IsRISCV = Arch == llvm::Triple::riscv32 || llvm::Triple::riscv64; This seems incorrect. RHS should be: ``` Arch == llvm::Triple::riscv32 || Arch == llvm::Triple::riscv64; https://reviews.llvm.org/D39963 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
mgrang added inline comments. Comment at: test/Driver/riscv64-toolchain.c:1 +// A basic clang -cc1 command-line, and simple environment check. + mgrang wrote: > I just saw that this test fails with the error: > > error: backend data layout 'e-m:e-i64:64-n32:64-S128' does not match expected > target description 'e-m:e-p:64:64-i64:64-i128:128-n64-S128' Pushed a fix for this: https://reviews.llvm.org/D40145 https://reviews.llvm.org/D39963 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
asb marked 4 inline comments as done.
asb added inline comments.
Comment at: lib/Driver/ToolChains/RISCV.cpp:86
+CmdArgs.push_back("-lc");
+CmdArgs.push_back("-lgloss");
+CmdArgs.push_back("--end-group");
asb wrote:
> apazos wrote:
> > mgrang wrote:
> > > How about if our sysroot is linux (as opposed to elf)? There won't be any
> > > libgloss.a, right? Also there won't be a crt0.o (instead there will be
> > > crt1.o).
> > Supporting linux target is desirable early on because most of us will be
> > using Qemu for running tests.
> Linux targets are not currently supported, as they require the ilp32d or
> lp64d (hard double precision) ABI. The only fiddly part is actually in the
> Clang frontend, handling structs composed of two reals or one integer + one
> real. This is obviously high up on the todo list.
It seems I was mistaken - soft float linux targets with glibc are working fine,
meaning there's no need to wait for hardfloat ABI lowering.
Note that Linux targets are handled in lib/Driver/ToolChains/Linux.cpp
Comment at: lib/Driver/ToolChains/RISCV.h:42
+ : GnuTool("RISCV::Linker",
+TC.getTriple().isArch64Bit() ? "riscv64-ld" : "riscv32-ld",
+TC) {}
mgrang wrote:
> johnrusso wrote:
> > I wonder if we should construct the linker name based on the default triple
> > value? "riscv64-unknown-elf-ld" or "riscv32-unknown-elf-ld" as this is
> > likely what is in the user's PATH if they have installed the gnu tools.
> > The linker name could be modified in ConstructJob if the triple is
> > different from the default.
> I agree with @johnrusso . I always have errors: "riscv32-ld not found" and as
> a workaround I end up creating symlink pointing to the actual -ld.
Now updated so the bin dir from the given GCC install (passed by
--gcc-toolchain) is added to the PATH, and the default search logic will look
for an ld named after after the target triple.
https://reviews.llvm.org/D39963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
asb updated this revision to Diff 123229.
asb marked an inline comment as done.
asb added a comment.
Consider this a WIP update. This is not yet ready for merging, but could still
benefit from feedback.
This update adds support for RISC-V to the Linux toolchain driver, which
includes support for multilib selection. Unfortunately I had to add a special
case to lib/Driver/Toolchains/Linux.cpp for adding lib paths laid out according
to the RISC-V multilib conventions (e.g. $SYSROOT/lib32/ilp32,
$SYSROOT/usr/lib32/ilp32). I notice that Mips had to do something similar, and
ended up defining the MipsLinux class.
@jroelofs: Did you have any views one way or the other about extending
BareMetal to support RISC-V as well as ARM?
https://reviews.llvm.org/D39963
Files:
lib/Basic/CMakeLists.txt
lib/Basic/Targets.cpp
lib/Basic/Targets/RISCV.cpp
lib/Basic/Targets/RISCV.h
lib/Driver/CMakeLists.txt
lib/Driver/Driver.cpp
lib/Driver/ToolChains/Arch/RISCV.cpp
lib/Driver/ToolChains/Arch/RISCV.h
lib/Driver/ToolChains/Clang.cpp
lib/Driver/ToolChains/Clang.h
lib/Driver/ToolChains/Gnu.cpp
lib/Driver/ToolChains/Linux.cpp
lib/Driver/ToolChains/RISCV.cpp
lib/Driver/ToolChains/RISCV.h
test/Driver/frame-pointer.c
test/Driver/riscv-abi.c
test/Driver/riscv-features.c
test/Driver/riscv32-toolchain.c
test/Driver/riscv64-toolchain.c
test/Preprocessor/init.c
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -9987,3 +9987,398 @@
// ARM-DARWIN-BAREMETAL-64: #define __PTRDIFF_TYPE__ long int
// ARM-DARWIN-BAREMETAL-64: #define __SIZE_TYPE__ long unsigned int
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \
+// RUN: | FileCheck -match-full-lines -check-prefix=RISCV32 %s
+// RISCV32: #define _ILP32 1
+// RISCV32: #define __ATOMIC_ACQUIRE 2
+// RISCV32: #define __ATOMIC_ACQ_REL 4
+// RISCV32: #define __ATOMIC_CONSUME 1
+// RISCV32: #define __ATOMIC_RELAXED 0
+// RISCV32: #define __ATOMIC_RELEASE 3
+// RISCV32: #define __ATOMIC_SEQ_CST 5
+// RISCV32: #define __BIGGEST_ALIGNMENT__ 16
+// RISCV32: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// RISCV32: #define __CHAR16_TYPE__ unsigned short
+// RISCV32: #define __CHAR32_TYPE__ unsigned int
+// RISCV32: #define __CHAR_BIT__ 8
+// RISCV32: #define __DBL_DECIMAL_DIG__ 17
+// RISCV32: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// RISCV32: #define __DBL_DIG__ 15
+// RISCV32: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// RISCV32: #define __DBL_HAS_DENORM__ 1
+// RISCV32: #define __DBL_HAS_INFINITY__ 1
+// RISCV32: #define __DBL_HAS_QUIET_NAN__ 1
+// RISCV32: #define __DBL_MANT_DIG__ 53
+// RISCV32: #define __DBL_MAX_10_EXP__ 308
+// RISCV32: #define __DBL_MAX_EXP__ 1024
+// RISCV32: #define __DBL_MAX__ 1.7976931348623157e+308
+// RISCV32: #define __DBL_MIN_10_EXP__ (-307)
+// RISCV32: #define __DBL_MIN_EXP__ (-1021)
+// RISCV32: #define __DBL_MIN__ 2.2250738585072014e-308
+// RISCV32: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// RISCV32: #define __ELF__ 1
+// RISCV32: #define __FINITE_MATH_ONLY__ 0
+// RISCV32: #define __FLT_DECIMAL_DIG__ 9
+// RISCV32: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// RISCV32: #define __FLT_DIG__ 6
+// RISCV32: #define __FLT_EPSILON__ 1.19209290e-7F
+// RISCV32: #define __FLT_EVAL_METHOD__ 0
+// RISCV32: #define __FLT_HAS_DENORM__ 1
+// RISCV32: #define __FLT_HAS_INFINITY__ 1
+// RISCV32: #define __FLT_HAS_QUIET_NAN__ 1
+// RISCV32: #define __FLT_MANT_DIG__ 24
+// RISCV32: #define __FLT_MAX_10_EXP__ 38
+// RISCV32: #define __FLT_MAX_EXP__ 128
+// RISCV32: #define __FLT_MAX__ 3.40282347e+38F
+// RISCV32: #define __FLT_MIN_10_EXP__ (-37)
+// RISCV32: #define __FLT_MIN_EXP__ (-125)
+// RISCV32: #define __FLT_MIN__ 1.17549435e-38F
+// RISCV32: #define __FLT_RADIX__ 2
+// RISCV32: #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_INT_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_LONG_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
+// RISCV32: #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
+// RISCV32: #define __GNUC_MINOR__ {{.*}}
+// RISCV32: #define __GNUC_PATCHLEVEL__ {{.*}}
+// RISCV32: #define __GNUC_STDC_INLINE__ 1
+// RISCV32: #define __GNUC__ {{.*}}
+// RISCV32: #define __GXX_ABI_VERSION {{.*}}
+// RISCV32: #define __ILP32__ 1
+// RISCV32: #define __INT16_C_SUFFIX__
+// RISCV32: #define __INT16_MAX__ 32767
+// RISCV32: #define __INT16_TYPE__ short
+// RISCV32: #define __INT32_C_SUFFIX__
+// RISCV32: #define __INT32_MAX__ 2147483647
+// RISCV32: #define __INT32_TYPE__ int
+// RISCV32: #define
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
mgrang added inline comments. Comment at: test/Driver/riscv64-toolchain.c:1 +// A basic clang -cc1 command-line, and simple environment check. + I just saw that this test fails with the error: error: backend data layout 'e-m:e-i64:64-n32:64-S128' does not match expected target description 'e-m:e-p:64:64-i64:64-i128:128-n64-S128' https://reviews.llvm.org/D39963 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
mgrang added a comment. @asb I cherry-picked this patch and was able to compile a simple program for elf triple. By manually adding a few libs on the link line I was also able to make it link for linux triple. Could you please respond to the comment about risv32-ld? Other than that this patch LGTM! https://reviews.llvm.org/D39963 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
asb added inline comments.
Comment at: lib/Driver/ToolChains/RISCV.cpp:86
+CmdArgs.push_back("-lc");
+CmdArgs.push_back("-lgloss");
+CmdArgs.push_back("--end-group");
apazos wrote:
> mgrang wrote:
> > How about if our sysroot is linux (as opposed to elf)? There won't be any
> > libgloss.a, right? Also there won't be a crt0.o (instead there will be
> > crt1.o).
> Supporting linux target is desirable early on because most of us will be
> using Qemu for running tests.
Linux targets are not currently supported, as they require the ilp32d or lp64d
(hard double precision) ABI. The only fiddly part is actually in the Clang
frontend, handling structs composed of two reals or one integer + one real.
This is obviously high up on the todo list.
https://reviews.llvm.org/D39963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
apazos added inline comments.
Comment at: lib/Driver/ToolChains/RISCV.cpp:86
+CmdArgs.push_back("-lc");
+CmdArgs.push_back("-lgloss");
+CmdArgs.push_back("--end-group");
mgrang wrote:
> How about if our sysroot is linux (as opposed to elf)? There won't be any
> libgloss.a, right? Also there won't be a crt0.o (instead there will be
> crt1.o).
Supporting linux target is desirable early on because most of us will be using
Qemu for running tests.
https://reviews.llvm.org/D39963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
mgrang added inline comments.
Comment at: lib/Driver/ToolChains/RISCV.cpp:86
+CmdArgs.push_back("-lc");
+CmdArgs.push_back("-lgloss");
+CmdArgs.push_back("--end-group");
How about if our sysroot is linux (as opposed to elf)? There won't be any
libgloss.a, right? Also there won't be a crt0.o (instead there will be crt1.o).
Comment at: lib/Driver/ToolChains/RISCV.h:42
+ : GnuTool("RISCV::Linker",
+TC.getTriple().isArch64Bit() ? "riscv64-ld" : "riscv32-ld",
+TC) {}
johnrusso wrote:
> I wonder if we should construct the linker name based on the default triple
> value? "riscv64-unknown-elf-ld" or "riscv32-unknown-elf-ld" as this is
> likely what is in the user's PATH if they have installed the gnu tools. The
> linker name could be modified in ConstructJob if the triple is different from
> the default.
I agree with @johnrusso . I always have errors: "riscv32-ld not found" and as a
workaround I end up creating symlink pointing to the actual -ld.
https://reviews.llvm.org/D39963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
johnrusso added inline comments.
Comment at: lib/Driver/ToolChains/RISCV.h:42
+ : GnuTool("RISCV::Linker",
+TC.getTriple().isArch64Bit() ? "riscv64-ld" : "riscv32-ld",
+TC) {}
I wonder if we should construct the linker name based on the default triple
value? "riscv64-unknown-elf-ld" or "riscv32-unknown-elf-ld" as this is likely
what is in the user's PATH if they have installed the gnu tools. The linker
name could be modified in ConstructJob if the triple is different from the
default.
https://reviews.llvm.org/D39963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support
asb created this revision. Herald added subscribers: jordy.potman.lists, simoncook, johnrusso, rbar, mgorny. I'm marking this as an RFC as I'd initially like to get feedback on the testing approach and structure of this patch (is this about the right granularity or would you prefer to start with something more minimal?). Follow-up patches will add ABI lowering and expand command line option parsing. I wouldn't want to have the addition of RISC-V clang support gated on improving clang cross compilation support (e.g. config files or similar as has been discussed on the mailing list). However, if there's a straight-forward way I can reduce duplication and extend something already in-tree then of course I'd like to do that. One option might be to extend the BareMetal toolchain with RISC-V support, though I'd want the flexibility of using libgcc if preferred, and using the GNU linker rather than lld. What do you think Jonathan? Please do add reviewers who may be qualified and willing to help. I'm picking on Chandler for kindly offering to help get this reviewed (either personally or pointing me to the right person), Petr for your work on the Fuchsia driver and Jonathan for your work on the BareMetal driver. I'm currently reliant on the user setting up riscv32-ld or riscv64-ld symlinks. Is there some common code somewhere I'm missing for finding an appropriate linker in the GCC installation path? https://reviews.llvm.org/D39963 Files: lib/Basic/CMakeLists.txt lib/Basic/Targets.cpp lib/Basic/Targets/RISCV.cpp lib/Basic/Targets/RISCV.h lib/Driver/CMakeLists.txt lib/Driver/Driver.cpp lib/Driver/ToolChains/Clang.cpp lib/Driver/ToolChains/Clang.h lib/Driver/ToolChains/Gnu.cpp lib/Driver/ToolChains/RISCV.cpp lib/Driver/ToolChains/RISCV.h test/Driver/frame-pointer.c test/Driver/riscv-abi.c test/Driver/riscv-features.c test/Driver/riscv32-toolchain.c test/Driver/riscv64-toolchain.c test/Preprocessor/init.c Index: test/Preprocessor/init.c === --- test/Preprocessor/init.c +++ test/Preprocessor/init.c @@ -9987,3 +9987,398 @@ // ARM-DARWIN-BAREMETAL-64: #define __PTRDIFF_TYPE__ long int // ARM-DARWIN-BAREMETAL-64: #define __SIZE_TYPE__ long unsigned int +// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \ +// RUN: | FileCheck -match-full-lines -check-prefix=RISCV32 %s +// RISCV32: #define _ILP32 1 +// RISCV32: #define __ATOMIC_ACQUIRE 2 +// RISCV32: #define __ATOMIC_ACQ_REL 4 +// RISCV32: #define __ATOMIC_CONSUME 1 +// RISCV32: #define __ATOMIC_RELAXED 0 +// RISCV32: #define __ATOMIC_RELEASE 3 +// RISCV32: #define __ATOMIC_SEQ_CST 5 +// RISCV32: #define __BIGGEST_ALIGNMENT__ 16 +// RISCV32: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ +// RISCV32: #define __CHAR16_TYPE__ unsigned short +// RISCV32: #define __CHAR32_TYPE__ unsigned int +// RISCV32: #define __CHAR_BIT__ 8 +// RISCV32: #define __DBL_DECIMAL_DIG__ 17 +// RISCV32: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 +// RISCV32: #define __DBL_DIG__ 15 +// RISCV32: #define __DBL_EPSILON__ 2.2204460492503131e-16 +// RISCV32: #define __DBL_HAS_DENORM__ 1 +// RISCV32: #define __DBL_HAS_INFINITY__ 1 +// RISCV32: #define __DBL_HAS_QUIET_NAN__ 1 +// RISCV32: #define __DBL_MANT_DIG__ 53 +// RISCV32: #define __DBL_MAX_10_EXP__ 308 +// RISCV32: #define __DBL_MAX_EXP__ 1024 +// RISCV32: #define __DBL_MAX__ 1.7976931348623157e+308 +// RISCV32: #define __DBL_MIN_10_EXP__ (-307) +// RISCV32: #define __DBL_MIN_EXP__ (-1021) +// RISCV32: #define __DBL_MIN__ 2.2250738585072014e-308 +// RISCV32: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__ +// RISCV32: #define __ELF__ 1 +// RISCV32: #define __FINITE_MATH_ONLY__ 0 +// RISCV32: #define __FLT_DECIMAL_DIG__ 9 +// RISCV32: #define __FLT_DENORM_MIN__ 1.40129846e-45F +// RISCV32: #define __FLT_DIG__ 6 +// RISCV32: #define __FLT_EPSILON__ 1.19209290e-7F +// RISCV32: #define __FLT_EVAL_METHOD__ 0 +// RISCV32: #define __FLT_HAS_DENORM__ 1 +// RISCV32: #define __FLT_HAS_INFINITY__ 1 +// RISCV32: #define __FLT_HAS_QUIET_NAN__ 1 +// RISCV32: #define __FLT_MANT_DIG__ 24 +// RISCV32: #define __FLT_MAX_10_EXP__ 38 +// RISCV32: #define __FLT_MAX_EXP__ 128 +// RISCV32: #define __FLT_MAX__ 3.40282347e+38F +// RISCV32: #define __FLT_MIN_10_EXP__ (-37) +// RISCV32: #define __FLT_MIN_EXP__ (-125) +// RISCV32: #define __FLT_MIN__ 1.17549435e-38F +// RISCV32: #define __FLT_RADIX__ 2 +// RISCV32: #define __GCC_ATOMIC_BOOL_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_CHAR_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_INT_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_LONG_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_POINTER_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_SHORT_LOCK_FREE 1 +// RISCV32: #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1 +//
