Re: -latomics vs riscv64

[Mathieu Malaterre <malat@debian.org>]

Jess,

On Mon, Jan 31, 2022 at 12:36 PM Jessica Clarke <jrtc27@debian.org> wrote:
>
> On 31 Jan 2022, at 08:37, Mathieu Malaterre <malat@debian.org> wrote:
> >
> > [cc me please]
> >
> > Dear riscv64 porters,
> >
> > I am trying to get JPEG-XL to compile on riscv64. After reading of:
> >
> > * https://github.com/riscv-collab/riscv-gcc/issues/12
> >
> > I am under the impression that the black magic to get -latomic passed
> > on the linker line is handled somewhere in gcc spec file.
> >
> > This also seems to be the case, per my reading of the log file at:
> >
> > * https://buildd.debian.org/status/fetch.php?pkg=jpeg-xl&arch=riscv64&ver=0.7.0%7Egit20220120.0647da4%2Bds-3&stamp=1643404075&raw=0
> >
> > The following c++11 code (1):
> >
> > ```
> > #include <atomic>
> > #include <cstdint>
> > std::atomic<uint64_t> num (0);
> > int main() {
> >  uint64_t i = num.load(std::memory_order_relaxed);
> >  return 0;
> > }
> > ```
> >
> > seems to compile and link nicely without the need for an explicit
> > `-latomic`. However somewhere later during the compilation, I receive
> > an error that:
> >
> > /usr/bin/ld: libjxl_dec.so.0.7.0: undefined reference to `__atomic_fetch_and_1'
> > /usr/bin/ld: libjxl_dec.so.0.7.0: undefined reference to `__atomic_fetch_or_1'
> >
> > So now it seems that I need an explicit `-latomic`
> >
> > Could someone please share his knowledge on -latomic on riscv64 Debian
> > arch ? Please note that the above c++11 code rightfully fails to
> > compile on armel/mipsel and powerpc which allow the buildsystem to
> > detect the need for an explicit `-latomic` being added by cmake.
>
> RISC-V only has 32-bit and 64-bit atomic instructions. GCC is supposed
> to convert smaller atomics to those larger ones via masking and
> shifting like LLVM, but it’s a known bug that it does not. This means
> anything that wants to use atomics on 1-byte or 2-byte types needs
> -latomic, but not 4-byte or 8-byte (though it does no harm).

Very interesting ! Thanks for the info.

I tried a shot in the dark to fix the issue, but it still fails (*).
The code was:

     #include <atomic>
     #include <cstdint>
     std::atomic<uint8_t> n8 (0);
     std::atomic<uint16_t> n16 (0);
     std::atomic<uint32_t> n32 (0);
     std::atomic<uint64_t> n64 (0);
     int main() {
       uint8_t i8 = n8.load(std::memory_order_relaxed);
       uint16_t i16 = n16.load(std::memory_order_relaxed);
       uint32_t i32 = n32.load(std::memory_order_relaxed);
       uint64_t i64 = n64.load(std::memory_order_relaxed);
       return 0;
     }

I am giving up on riscv64 until there are porteboxes available.

Regards
-M

(*)
-- Performing Test ATOMICS_LOCK_FREE_INSTRUCTIONS
-- Performing Test ATOMICS_LOCK_FREE_INSTRUCTIONS - Success
ref:
- https://buildd.debian.org/status/fetch.php?pkg=jpeg-xl&arch=riscv64&ver=0.7.0%7Egit20220120.0647da4%2Bds-4&stamp=1643635011&raw=0