[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CUT0JKSDQ452.288XGLOHO41ZF@cq14>
Date: Tue, 15 Aug 2023 09:32:52 +0000
From: "alice" <alice@...ya.dev>
To: <musl@...ts.openwall.com>
Subject: Re: add loongarch64 port v7.
On Tue Aug 15, 2023 at 9:24 AM UTC, Hongliang Wang wrote:
>
> > In fenv.S:
> >
> >> ++#ifdef __clang__
> >> ++#define FCSR $fcsr0
> >> ++#else
> >> ++#define FCSR $r0
> >> ++#endif
> >
> > It's not clear to me what's going on here. Is there a clang
> > incompatibility in the assembler language you're working around? Or
> > what? If so that seems like a tooling bug that should be fixed.
> >
> The GNU assembler cannot correctly recognize $fcsr0, but the
> LLVM IAS does not have this issue, so make a distinction.
> This issue has been fixed in GNU assembler 2.41. but for compatible
> with GNU assembler 2.40 and below, $r0 need reserved.
>
> The linux kernel also has a similar distinction:
the kernel patch checks if the assembler supports fcsr, and then uses that, or
falls back to r.
in this case, you only check for ifdef clang- which means even with binutils
2.41, it will not use fcsr (__clang__ is not defined). don't you need to perform
a similar test, so clang or binutils>=2.41 both use the top path? most likely,
you need a ./configure test.
>
> commit 38bb46f94544c5385bc35aa2bfc776dcf53a7b5d
> Author: WANG Xuerui <git@...0n.name>
> Date: Thu Jun 29 20:58:43 2023 +0800
>
> LoongArch: Prepare for assemblers with proper FCSR class support
>
> The GNU assembler (as of 2.40) mis-treats FCSR operands as GPRs, but
> the LLVM IAS does not. Probe for this and refer to FCSRs as"$fcsrNN"
> if support is present.
>
> Signed-off-by: WANG Xuerui <git@...0n.name>
> Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
