From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cstnet.cn (smtp80.cstnet.cn [159.226.251.80]) by sourceware.org (Postfix) with ESMTP id 0D7CC3858D33 for ; Mon, 13 Feb 2023 06:17:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0D7CC3858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=isrc.iscas.ac.cn Authentication-Results: sourceware.org; spf=none smtp.mailfrom=isrc.iscas.ac.cn Received: from [192.168.223.33] (unknown [101.6.102.102]) by APP-01 (Coremail) with SMTP id qwCowABXcNTb1elj_aTeBA--.19233S2; Mon, 13 Feb 2023 14:16:59 +0800 (CST) Message-ID: <68996dd3-9fbe-b6ed-0642-0e1c860c3c78@isrc.iscas.ac.cn> Date: Mon, 13 Feb 2023 14:16:47 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v2] riscv: Add macros for FPUCW/fcsr in fpu_control.h To: Richard Henderson , libc-alpha@sourceware.org Cc: schwab@linux-m68k.org References: <20230212065214.2399-1-shiqi@isrc.iscas.ac.cn> From: Shiqi Zhang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:qwCowABXcNTb1elj_aTeBA--.19233S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Xr4kuF43GFyDWr17CF4DJwb_yoWDArc_AF W7J3WkA3Wjg3s5C3Z7Gr45uFW3Ar98Crs0gasrXwsFv343try8XFZrKrWfZr1fJw48tF4a kr4DCw47Aw13ZjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb28YjsxI4VWkKwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_JFC_Wr1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z2 80aVCY1x0267AKxVWUJVW8JwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAK zVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx 8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07beJ5wUUUUU= X-Originating-IP: [101.6.102.102] X-CM-SenderInfo: 5vkl1xw6lv2u4olvutnvoduhdfq/ X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KHOP_HELO_FCRDNS,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Honestly, no one should be using at all.  It was > originally an x86 specific thing.  The only reason to fill in this > header at all is to match the original x86 API.  Therefore the symbol > names should match ./sysdeps/x86/fpu_control.h. Actually other architectures also defines these arch-specific macros in ./sysdeps/***/fpu_control.h. And the symbol names doesn't match x86, too. For example I checked the macro _FPU_FPCR_MASK_OFE in ./sysdeps/aarch64/fpu/fpu_control.h, nothing in glibc referenced it so I think it can only be for the users to control FPU in an arch-specific manner. > > When porting applications to work on RISC-V, it would be much better > to update them to use , which is what ISO C standardized.  I > assume there would be more than a few ifdefs removed in the process. > The rounding mode RMM (Round to Nearest, ties to Max Magnitude) of RISC-V isn't part of the C standard. So I think it makes sense to define these macros in arch-specific headers.