Re: GCC-13 Branch with RISC-V Performance-Related Backports

> > Based on some discussions, it looks like a handful of vendors are > > planning on maintaining GCC-13 branches that include various > > performance-related backports (ie, patches not suitable for the standard > > GCC-13 release branch). Did you consider also include necessary vectorizeor stuffs

Re: ideas on PR/109279

I would prefer defer to GCC 14 too Jeff Law 於 2023年3月31日 週五，21:34寫道： > > > On 3/31/23 03:11, Vineet Gupta wrote: > > Hi Jeff, Kito, > > > > I need some ideas to proceed with PR/109279: pertaining to longer term > > direction and short term fix. > > > &

RISC-V: Public review for Non-ISA Specification: psABI

psABI Task Group will recommend the updated specifications be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors. Thanks to all the contributors for all their hard work. Kito Cheng

Public review for RISC-V psABI v1.0-rc1

Hi all: It’s Kito Cheng from the RISC-V community, Jessica Clarke and I are working on releasing a stable version of the psABI, and are seeking feedback from the open source community. The goal of this stable release is having a stable version to let people use as a reference point. We are

New vendor branch for RISC-V: integration and experimental branch

Hi all: I am Kito Cheng, one of the RISC-V port maintainers. I would like to announce we have created two vendor branches for accepting unratified extension support, in order to focus the development energy on FSF repo. RISC-V is an open standard instruction set architecture, many ISA extensions

How to skip dg-module-cmi?

Hi Nathan: Recently I am clean up the failed case for bare-matel riscv64 target, and that not support omp due to lack of pthread support (e.g. gcc/testsuite/g++.dg/modules/omp-1_a), however even I add `dg-require-effective-target pthread`, `dg-module-cmi` seems still try to test and then get faile

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

> The RISC-V document linked to suggests that won't be an issue for RISC-V > with hardware _Float16 support, though obviously it's still necessary to > decide what to do when using _Float16 on RISC-V systems without the > hardware support, if that is allowed at all. My thought is that _Float16 is

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

Hi Jonathan: > I would forget about the decimal types. I thought you were just > talking about _Float16? > > You will need to decide on a mangling for it in C++, which should be > co-ordinated with other compilers that are likely to support the type. > You could mangle it as "u8_Float16" which is

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

Hi Jonathan: > > C++ also has another proposal for extended floating-point types > > (https://wg21.link/p1467), which included half-precision types, so in > > my understanding, _Float16 won't be a portable typen between C/C++. > > Why not just make _Float16 available in C++ as a GCC extension? No

[RFC] Appropriate portable data type for IEEE half-precision on C/C++

Hi: It's Kito, a RISC-V folks, recently RISC-V has an ISA extension draft for IEEE half-precision operations [4], including arithmetic, conversion, comparison...a full set of support for IEEE half-precision. So we are seeking the data type for IEEE half-precision, and then we have few candi

Re: IEEE Interchange floating point and extended floating point for C++

Hi Joseph: > I don't know if C++ has reached any conclusions about what form C++ > support for such types should take, but my expectation was that something > library-based, similar to the support for decimal floating-point types, > might be used. Thanks, my understanding is that we are not inten

Re: IEEE Interchange floating point and extended floating point for C++

; > On 3/11/21 1:56 PM, Jonathan Wakely via Gcc wrote: > > > > On Thu, 11 Mar 2021 at 09:43, Kito Cheng via Gcc > > > > wrote: > > > >> Hi: > > > >> > > > >> Would it be possible to support interchange flo

IEEE Interchange floating point and extended floating point for C++

Hi: Would it be possible to support interchange floating point and/or extended floating point for C++, which is introduced by ISO/IEC TS 18661-3? I've read the note about C++ support from the initial commit log[1], so I know there is some concern about C++ support for that, is it possible to enab

[RFC] RISC-V Vector Intrinsics

Hi, We, EPI, SiPearl, and SiFive, have come out with a RFC for RISC-V vector intrinsics. If you are interested in the RISC-V vector intrinsics design, welcome to join the discussion. We have created a github repository[0] for the documents. In this RFC[1], we defined the type system, programming

Re: GCC changes for Fedora + riscv64

>> You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME >> environment variable to change the uname for qemu. > > But be aware that the emulated environment still assumes that all system > calls implemented by 4.15 are available, and qemu linux-user generally > just passes them thr

Re: GCC changes for Fedora + riscv64

Hi Jeff: You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME environment variable to change the uname for qemu. On Tue, Apr 10, 2018 at 6:50 AM, Jeff Law wrote: > On 04/09/2018 04:47 PM, Stef O'Rear wrote: >> On Mon, Apr 9, 2018 at 6:37 PM, Jeff Law wrote: >>> On 04/09/2018 12

Re: Question about rtx format for insn, call_insn and junp_insn

sorry I get incorrect gcc version info the correct version which doing dump is gcc 4.1.2 I dump rtl with the gcc 4.4.1 have the line info thanks for you reply 2010/5/20 Ian Lance Taylor : > kito writes: > >> Hello every body >> I have read the rtl.h & rtl.c, >> bu

Question about rtx format for insn, call_insn and junp_insn

Hello every body I have read the rtl.h & rtl.c, but I don't realize the format for  insn, call_insn and junp_insn it's define in rtl.def DEF_RTL_EXPR(JUMP_INSN, "jump_insn", "iuuBieie0", RTX_INSN) and it's dump by some real program (jump_insn 14  /*  i */            13         /*  u */