Number of ALU in la464.md

Hi, According to the schematic (https://loongson.github.io/LoongArch-Documentation/Loongson-3A5000-usermanual-EN.html#la464-processor-core, Figure 5) we have 4 ALUs in LA464, but in la464.md we only define la464_alu1 and la464_alu2. Should we add la464_alu{3,4} as well, or am I missing something

Re: Number of ALU in la464.md

On Tue, 2022-09-27 at 10:40 +0800, Lulu Cheng wrote: > You are right, I just added it before, but I didn't see the performance > improvement, > > so I didn't change this place. Alright, so just left la464.md as-is for now. I'll try Phoronix bench suite on LoongArch once a binary distro is in a

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote: > Hello. > > Based on the very positive feedback I was given at the Cauldron Sphinx > Documentation BoF, > I'm planning migrating the documentation on 9th November. There are still > some minor comments > from Sandra when it comes to the PDF

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

(CC our team members.) On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote: > > Ouch.  This will be very painful for Linux From Scratch.  We'll need to > > add 23 Python modules to build the documentation, while we only have 88 > > packages in total currently...  And we don't want to omit GCC >

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Thu, 2022-10-20 at 13:53 +0200, Martin Liška wrote: > On 10/20/22 13:49, Xi Ruoyao wrote: > > (CC our team members.) > > > > On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote: > > > > Ouch.  This will be very painful for Linux From Scratch.  We'll need to > > > > add 23 Python modules to bu

"random" segment faults in expect running GCC regression test on LoongArch

Hi, This is a "help wanted" message. When I run GCC regression test on loongarch64-linux-gnu, expect occasionally crashes with a segment fault. The stack backtrace is like: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x70a35910 in TclpAlloc () from /usr/lib/libtcl8.6.

Re: GCC 13.0.0 Status Report (2022-11-14), Stage 3 in effect now

Hi Martin, Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd like to cherry pick some commits from LLVM [to fix some stupid errors I've made in LoongArch libasan :(]. On Mon, 2022-11-14 at 13:21 +, Richard Biener via Gcc-patches wrote: > Status > == > > The GCC develo

Re: "random" segment faults in expect running GCC regression test on LoongArch

On Wed, 2022-11-09 at 15:43 +0800, Xi Ruoyao wrote: > Hi, > > This is a "help wanted" message.  When I run GCC regression test on > loongarch64-linux-gnu, expect occasionally crashes with a segment fault. > The stack backtrace is like: /* snip */ > The crashes happen on both my own LoongArch boa

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

On Sun, 2023-02-05 at 16:31 +0100, Alejandro Colomar via Libc-alpha wrote: > The only correct way to use  different  types  in  an  API  is > through  a  union. I don't think this statement is true (in general). Technically we can write something like this: struct sockaddr { ... }; struct socka

Re: ISO C's [static] (was: _Nullable and _Nonnull in GCC's analyzer)

On Wed, 2023-08-09 at 12:42 +0200, Alejandro Colomar wrote: > I have a gripe with ISO C's [static].  As you mention, ISO > conflated two functionalities in [static]: > > -  The size of the array passed as argument must not be less >    than the size specified in the parameter's []. > > -  The poi

Re: 'posix_spawnp' error in build

On Mon, 2023-12-25 at 10:28 -0600, Segher Boessenkool wrote: > Hi! > > On Mon, Dec 25, 2023 at 08:11:23PM +0530, Prashant via Gcc-help wrote: > >  I'm trying to build the gcc repository. Based on the instructions given on > > the SummerOfCode - GCC Wiki (gnu.org) > >

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Fri, 2024-07-05 at 15:03 +0200, Alejandro Colomar wrote: > ISO C specifies these APIs as accepting a restricted pointer in their > first parameter: > > $ stdc c99 strtol > long int strtol(const char *restrict nptr, char **restrict endptr, int base); > $ stdc c11 strtol > long int strtol(const c

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Fri, 2024-07-05 at 17:23 +0200, Alejandro Colomar wrote: > > strtol does have  a "char * restrict * restrict" though, so the > > situation is different.   A "char **" and a "const char *" > > shouldn't alias anyway. > > Pedantically, it is actually declared as 'char **restrict' (the inner > on

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote: > At least, I hope there's consensus that while current GCC doesn't warn > about this, ideally it should, which means it should warn for valid uses > of strtol(3), which means strtol(3) should be fixed, in all of ISO, > POSIX, and glibc.

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Sat, 2024-07-06 at 00:01 +0800, Xi Ruoyao wrote: > On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote: > > At least, I hope there's consensus that while current GCC doesn't warn > > about this, ideally it should, which means it should warn for valid uses > > of strtol(3), which means str

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Sat, 2024-07-06 at 00:02 +0200, Alejandro Colomar wrote: > That's precisely the case with strtol(3): it doesn't access any objects > through *endptr, and so that pointer need not be restrict. > > Then, nptr is a read-only pointer, so is doesn't matter either if it's > accessed or not. Restrict

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Sat, 2024-07-06 at 10:24 +0800, Xi Ruoyao wrote: > On Sat, 2024-07-06 at 00:02 +0200, Alejandro Colomar wrote: > > That's precisely the case with strtol(3): it doesn't access any objects > > through *endptr, and so that pointer need not be restrict. > > > > Then, nptr is a read-only pointer, so

Re: LoongArch incorrect codegen for std::byte_swap

On Sat, 2024-07-27 at 17:38 -0700, Andrew Pinski via Gcc-help wrote: > On Sat, Jul 27, 2024 at 3:37 PM pifminns deettnta via Gcc > wrote: > > > > using uint_least64_t = __UINT_LEAST64_TYPE__; > > > > uint_least64_t testbswap(uint_least64_t a) noexcept > > { > >    return __builtin_bswap64(a); >

Late combine & mode switch

Hi Richard, When I hack the LoongArch backend I notice something like slli.d $r4, $r4, 2 add.w $r4, $r4, $r5 Or (set (reg:DI 4) (ashift:DI (reg:DI 4) (const_int 2)) (set (reg:DI 4) (sign_extend:DI (add:SI (reg:SI 4) (reg:SI 5 can appear after split. On LoongArch it can be done via an

Question regarding riscv_valid_lo_sum_p vs strict-align

Hi, When -mstrict-align was added for RISC-V, there was a change for riscv_valid_lo_sum_p: @@ -726,7 +733,8 @@ riscv_valid_lo_sum_p (enum riscv_symbol_type sym_type, enum machine_mode mode) /* We may need to split multiword moves, so make sure that each word can be accessed without indu