Re: [PATCH] loongarch: ignore zero-size fields in calling convention

2022-04-24 Thread Xi Ruoyao via Gcc-patches
Ping. Normally we shouldn't ping a patch after only a few days, but we're running out of time to catch GCC 12 milestone. And once GCC 12 is released the patch will become far more complicated for a psABI warning. And please note that the ABI difference between GCC and G++ should be considered a

Re: [PATCH 0/1] RISC-V: Fix canonical extension order (K and J)

2022-04-24 Thread Kito Cheng
Hi Tsukasa: LGTM, and did you mind adding Signed-off-by to your patch and resending again? I think this patch is small enough and the copyright process should not be a blocker for this patch :) See also: https://gcc.gnu.org/dco.html On Sun, Apr 24, 2022 at 1:25 PM Tsukasa OI wrote: > >

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

2022-04-24 Thread Kito Cheng
> > and so it doesn't make > > sense to mandate any particular ordering. > > No. It affects Z* extension ordering... +1, we really need the order in ISA spec so that we could know the canonical order for z* exts.

[PATCH] libstdc++: Add pretty printer for std::initializer_list

2022-04-24 Thread Philipp Fent via Gcc-patches
Re-using the std::span printer, this now shows the contents of the initializer list instead of the pointer and length members. Signed-off-by: Philipp Fent --- libstdc++-v3/python/libstdcxx/v6/printers.py | 23 +-- .../libstdc++-prettyprinters/cxx11.cc | 6 + 2

[PATCH] libgo: Recognize off64_t / loff_t type definition of musl libc

2022-04-24 Thread soeren--- via Gcc-patches
From: Sören Tempel The libgo code assumes both off64_t and loff_t to be present. For example, for the splice(2) function prototype. Similar to glibc, musl libc supports these types but defines them as macros, not as typedefs. Unfortunately, -fdump-go-spec only recognizes types defined using

[PATCH] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)

2022-04-24 Thread Yang Yujie
Hello, This patch fixes libgccjit link failure on loongarch* targets, and could probably be useful for future ports. Currently libgccjit is linked with objects from $(EXTRA_GCC_OBJS) and libbackend.a, which is in turn linked with $(EXTRA_OBJS) files. Thus, common object files that's shared

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

2022-04-24 Thread Tsukasa OI via Gcc-patches
Hello, > Neither K nor J is an extension that exists, That is correct. > and so it doesn't make > sense to mandate any particular ordering. No. It affects Z* extension ordering... On 2022/04/24 14:36, Andrew Waterman wrote: > Neither K nor J is an extension that exists, and so it doesn't