[PING wwwdocs PATCH v2] document zero-width field ABI changes on MIPS

Ping. On Wed, 2022-04-06 at 23:26 +0800, Xi Ruoyao via Gcc-patches wrote: > Document ABI changes in r12-7961, 7962, and 8023.  Ok for wwwdocs? > > --- >  htdocs/gcc-12/changes.html | 25 - >  1 file changed, 24 insertions(+), 1 deletion(-) > > diff

Re: [PATCH] Remove size limit of PCH

On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote: > Subject: [PATCH] Remove size limit of PCH Make it "Remove size limit of PCH [PR14940]", so once it's committed a message will show up in bugzilla. > Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 > Signed-off-by:

Re: [RFC/PATCH] C++ constexpr vs. floating point exceptions.

On Tue, 2021-09-21 at 12:41 +0100, Roger Sayle wrote: > > I was wondering if I may ask the C++ language experts for their > opinion > on whether (potential) floating point exceptions/traps can be ignored > in constant expressions; this is related to PR c++/96862.  I think my > question boils down

Re: [RFC/PATCH] C++ constexpr vs. floating point exceptions.

On Tue, 2021-09-21 at 14:15 +0100, Roger Sayle wrote: > > Can you double check?  Integer division by zero is undefined, but isn't > floating point > division by zero defined by the appropriate IEEE standards? It's an undefined behavior in C++ standard. Even if we assume C++ *was* IEEE-754 confor

Re: [RFC/PATCH] C++ constexpr vs. floating point exceptions.

On Tue, 2021-09-21 at 21:38 +0800, Xi Ruoyao via Gcc-patches wrote: > BTW the "correct" way to get a NaN in C++ seems: > > #include > constexpr double my_nan = std::numeric_limits::quiet_NaN(); Sorry, we were discussing inf, not NaN... Then constexpr double my_inf

Re: [PATCH v1 0/7] Add LoongArch support.

On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote: > > This is a series of patch sets to support LoongArch. > > The LoongArch architecture (LoongArch) is an Instruction Set > Architecture (ISA) that has a Reduced Instruction Set Computer (RISC) > style. > The documents are on > https://loongso

Re: [PATCH v1 3/7] LoongArch Port: libgcc

On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote: /* snip */ > diff --git a/libgcc/config/loongarch/crti.S b/libgcc/config/loongarch/crti.S > new file mode 100644 > index 000..bac029874b5 > --- /dev/null > +++ b/libgcc/config/loongarch/crti.S > @@ -0,0 +1,43 @@ > +/* Copyright (C) 202

Re: [PATCH v1 6/7] LoongArch Port: gcc/testsuite

On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote: > diff --git a/gcc/testsuite/gcc.dg/20020312-2.c > b/gcc/testsuite/gcc.dg/20020312-2.c > index 52c33d09b90..2e35d443a1d 100644 > --- a/gcc/testsuite/gcc.dg/20020312-2.c > +++ b/gcc/testsuite/gcc.dg/20020312-2.c > @@ -49,6 +49,8 @@ extern void ab

Re: [PATCH v1 5/7] LoongArch Port: libgomp

On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote: > From: chenglulu > > libgomp/ > > * configure.tgt: Add LoongArch tuple. "tuple" should be "triplet". -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University

Re: [PATCH v1 1/7] LoongArch Port: gcc

On Mon, 2021-11-08 at 10:30 +0800, Chenghua Xu wrote: > This patch does not arrive at  mail list. Send as an attachment in a > compressed format. I think .patch.gz is perferred instead of .tar.gz. And is it possible to seperate this into multiple commits? For example the whole "-march=native" s

[PATCH] fixincludes: don't assume getcwd() can handle NULL argument

POSIX says: On some implementations, if buf is a null pointer, getcwd() may obtain size bytes of memory using malloc(). In this case, the pointer returned by getcwd() may be used as the argument in a subsequent call to free(). Invoking getcwd() with buf as a null pointer is not rec

Re: [PATCH v1 1/7] LoongArch Port: gcc

On Mon, 2021-11-08 at 23:14 +, Joseph Myers wrote: /* snip */ > Please make sure the back end builds cleanly with current GCC mainline.  > This can be tested either with a native bootstrap, or by building a cross > compiler, using a native compiler of the same GCC mainline version for the

Re: [PATCH v1 1/7] LoongArch Port: gcc

On Tue, 2021-11-09 at 21:53 +0800, Xi Ruoyao via Gcc-patches wrote: > On Mon, 2021-11-08 at 23:14 +, Joseph Myers wrote: > > /* snip */ > > > Please make sure the back end builds cleanly with current GCC mainline.  > > This can be tested either with a native boo

Re: [PATCH v1 1/7] LoongArch Port: gcc

On Tue, 2021-11-09 at 23:52 +0800, Xi Ruoyao via Gcc-patches wrote: > > gcc trunk does not build with glibc-2.34+ and --enable-werror-always > > :( > > > > I've sent the fix as > > https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html. > >

Re: [PATCH] fixincludes: don't assume getcwd() can handle NULL argument

On Wed, 2021-11-10 at 00:02 +, Joseph Myers wrote: > On Tue, 9 Nov 2021, Xi Ruoyao via Gcc-patches wrote: > > > POSIX says: > > > >     On some implementations, if buf is a null pointer, getcwd() may > > obtain > >     size bytes of memory using

[PATCH] fixincludes: fix portability issues about getcwd() [PR21283, PR80047]

[Revised to handle PR 21283.] POSIX says: On some implementations, if buf is a null pointer, getcwd() may obtain size bytes of memory using malloc(). In this case, the pointer returned by getcwd() may be used as the argument in a subsequent call to free(). Invoking getcwd() with b

Re: [PATCH] fixincludes: fix portability issues about getcwd() [PR21283, PR80047]

On Fri, 2021-11-12 at 12:59 -0800, Bruce Korb wrote: > If you are going to be excruciatingly, painfully correct, free() is > going to be unhappy about freeing a static string in the event > getcwd() fails for some inexplicable reason. I'd replace the free() + > return with a call to exit. Maybe eve

[PATCH] fixincludes: simplify handling for access() failure [PR21283, PR80047]

POSIX says: On some implementations, if buf is a null pointer, getcwd() may obtain size bytes of memory using malloc(). In this case, the pointer returned by getcwd() may be used as the argument in a subsequent call to free(). Invoking getcwd() with buf as a null pointer is not rec

committed: [PATCH] fixincludes: simplify handling for access() failure [PR21283, PR80047]

On Sat, 2021-11-13 at 08:13 -0800, Bruce Korb wrote: > Perfect. Committed at r12-5234 with minor format fix. > On 11/12/21 1:58 PM, Xi Ruoyao wrote: > > diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c > > index 6dba2f6e830..ee57fbf61b4 100644 > > --- a/fixincludes/fixincl.c > > +++ b/f

Re: PING: [PATCH] mips: check MSA support for vector modes [PR100760,PR100761,PR100762]

On Thu, 2021-07-08 at 17:20 -0600, Jeff Law wrote: > > On 7/5/2021 8:04 PM, Paul Hua wrote: > > Looks good to me,  but I have no right to approve. > But your opinions are well respected :-) > > I'll go ahead and ACK, though in general I'm stepping away from > reviewing target specific work. Tha

Re: [PATCH] testsuite: mips: use noinline attribute instead of -fno-inline

On Thu, 2021-07-08 at 17:44 -0600, Jeff Law wrote: > > > On 6/25/2021 8:40 AM, Richard Sandiford wrote: > > Xi Ruoyao via Gcc-patches writes: > > > On Fri, 2021-06-25 at 01:02 +0800, Xi Ruoyao wrote: > > > > On Thu, 2021-06-24 at 10:48 -0600, Jeff Law wro

Re: PING: [PATCH] mips: check MSA support for vector modes [PR100760,PR100761,PR100762]

On Fri, 2021-07-09 at 14:01 +0800, Xi Ruoyao wrote: > On Thu, 2021-07-08 at 17:20 -0600, Jeff Law wrote: > > > > On 7/5/2021 8:04 PM, Paul Hua wrote: > > > Looks good to me,  but I have no right to approve. > > But your opinions are well respected :-) > > > > I'll go ahead and ACK, though in gene

PING^2: [PATCH] mips: add MSA vec_cmp and vec_cmpu expand pattern [PR101132]

PING again. On Thu, 2021-07-01 at 16:11 +0800, Xi Ruoyao wrote: > Ping. > > On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote: > > Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, > > causing > > ICE on MIPS with MSA enabled.  Add the pattern to prevent it. > > > > Bootstrapped and

PING^2: [PATCH] mips: Fix up mips_atomic_assign_expand_fenv [PR94780]

Ping again. On Mon, 2021-06-28 at 21:50 +0800, Xi Ruoyao wrote: > Ping.  CC several maintainers who may help to review MIPS patches. > Sorry if it sounds buzzing. > > On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote: > > Commit message shamelessly copied from 1777beb6b129 by jakub: > > > > Th

[PATCH] ipa-devirt: check precision mismatch of enum values [PR101396]

We are comparing enum values (in wide_int) to check ODR violation. However, if we compare two wide_int values with different precision, we'll trigger an assert, leading to ICE. With enum-base introduced in C++11, it's easy to sink into this situation. To fix the issue, we need to explicitly check

PING^3: [PATCH] mips: Fix up mips_atomic_assign_expand_fenv [PR94780]

Ping again. On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote: > Commit message shamelessly copied from 1777beb6b129 by jakub: > > This function, because it is sometimes called even outside of function > bodies, uses create_tmp_var_raw rather than create_tmp_var.  But in > order > for that to wo

PING^3: [PATCH] mips: add MSA vec_cmp and vec_cmpu expand pattern [PR101132]

Ping again. I heard that Matthew is too busy to deal with MIPS things from someone's private mail. Hope someone else can review it. On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote: > Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing > ICE on MIPS with MSA enabled.  Add the

PING^1: [PATCH] ipa-devirt: check precision mismatch of enum values [PR101396]

Ping. On Sun, 2021-07-11 at 01:48 +0800, Xi Ruoyao wrote: > We are comparing enum values (in wide_int) to check ODR violation. > However, if we compare two wide_int values with different precision, > we'll trigger an assert, leading to ICE.  With enum-base introduced > in C++11, it's easy to sink

Re: [PATCH] testsuite: mips: use noinline attribute instead of -fno-inline

On Fri, 2021-07-23 at 04:21 +0200, Maciej W. Rozycki wrote: > On Fri, 9 Jul 2021, Richard Sandiford via Gcc-patches wrote: > > > > > > > The "smallest fix" is simply adding -fno-inline into > > > > > > mips.exp.  > > > > > > However > > > > > > I don't like it because I agree with you that mips.ex

Re: [PATCH] testsuite: mips: use noinline attribute instead of -fno-inline

On Fri, 2021-07-23 at 11:18 +0800, Xi Ruoyao wrote: > On Fri, 2021-07-23 at 04:21 +0200, Maciej W. Rozycki wrote: > > On Fri, 9 Jul 2021, Richard Sandiford via Gcc-patches wrote: > > > > > > > > > The "smallest fix" is simply adding -fno-inline into > > > > > > > mips.exp.  > > > > > > > However >

PING^4: [PATCH] mips: add MSA vec_cmp and vec_cmpu expand pattern [PR101132]

Ping again. On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote: > Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing > ICE on MIPS with MSA enabled.  Add the pattern to prevent it. > > Bootstrapped and regression tested on mips64el-linux-gnu. > Ok for trunk? > > gcc/ > >

PING^4: [PATCH] mips: Fix up mips_atomic_assign_expand_fenv [PR94780]

Ping again. On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote: > Commit message shamelessly copied from 1777beb6b129 by jakub: > > This function, because it is sometimes called even outside of function > bodies, uses create_tmp_var_raw rather than create_tmp_var.  But in order > for that to work

PING^5: [PATCH] mips: add MSA vec_cmp and vec_cmpu expand pattern [PR101132]

Ping again. On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote: > Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing > ICE on MIPS with MSA enabled.  Add the pattern to prevent it. > > Bootstrapped and regression tested on mips64el-linux-gnu. > Ok for trunk? > > gcc/ > >

PING^5: [PATCH] mips: Fix up mips_atomic_assign_expand_fenv [PR94780]

Ping again. On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote: > Commit message shamelessly copied from 1777beb6b129 by jakub: > > This function, because it is sometimes called even outside of function > bodies, uses create_tmp_var_raw rather than create_tmp_var.  But in > order > for that to wo

PING^w: [PATCH] ipa-devirt: check precision mismatch of enum values [PR101396]

Ping again. On Sun, 2021-07-11 at 01:48 +0800, Xi Ruoyao wrote: > We are comparing enum values (in wide_int) to check ODR violation. > However, if we compare two wide_int values with different precision, > we'll trigger an assert, leading to ICE.  With enum-base introduced > in C++11, it's easy to

Re: PING^w: [PATCH] ipa-devirt: check precision mismatch of enum values [PR101396]

On Fri, 2021-07-30 at 15:00 +0800, Kewen.Lin wrote: > Hi Ruoyao, > > on 2021/7/30 下午12:57, Xi Ruoyao via Gcc-patches wrote: > > Ping again. > > > > This ping-ed patch has been approved by Richard at > > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/57

[PATCH committed] ipa-devirt: check precision mismatch of enum values [PR101396]

On Fri, 2021-07-30 at 15:21 +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2021-07-30 at 15:00 +0800, Kewen.Lin wrote: > > Hi Ruoyao, > > > > on 2021/7/30 下午12:57, Xi Ruoyao via Gcc-patches wrote: > > > Ping again. > > > > > > >

Re: PING^5: [PATCH] mips: add MSA vec_cmp and vec_cmpu expand pattern [PR101132]

On Fri, 2021-07-30 at 09:04 +0100, Richard Sandiford wrote: > Xi Ruoyao writes: > > Ping again. > > Sorry that this has gone unreviewed for so long.  I think in practice > the MIPS port is essentially unmaintained at this point -- it would > be great if someone would volunteer :-) A company work

Re: PING^5: [PATCH] mips: Fix up mips_atomic_assign_expand_fenv [PR94780]

On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote: > Xi Ruoyao writes: > > Ping again. > > > > On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote: > > > Commit message shamelessly copied from 1777beb6b129 by jakub: > > > > > > This function, because it is sometimes called even outside o

committed: [PATCH] mips: add MSA vec_cmp and vec_cmpu expand pattern [PR101132]

On Fri, 2021-07-30 at 16:17 +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2021-07-30 at 09:04 +0100, Richard Sandiford wrote: > > Xi Ruoyao writes: > > > Ping again. > > > > Sorry that this has gone unreviewed for so long.  I think in > > pract

committed: [PATCH] mips: Fix up mips_atomic_assign_expand_fenv [PR94780]

On Fri, 2021-07-30 at 16:23 +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote: > > Xi Ruoyao writes: > > > Ping again. > > > > > > On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote: > > > > Commit

committed: [PATCH] mips: Fix up mips_atomic_assign_expand_fenv [PR94780]

On Sat, 2021-07-31 at 02:08 +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2021-07-30 at 16:23 +0800, Xi Ruoyao via Gcc-patches wrote: > > On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote: > > > Xi Ruoyao writes: > > > > Ping again. > > > >

Re: [PATCH v1] libffi: Backport of LoongArch support for libffi.

On Tue, 2023-08-22 at 20:42 +0800, Lulu Cheng wrote: > This is a backport of , > and contains modifications to commit 5a4774cd4d, as well as the LoongArch > schema portion of commit ee22ecbd11. This is needed for libgo. > > > libffi/ChangeLog:

PING^2: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant

Ping again. On Fri, 2023-08-18 at 13:04 +0200, Stefan Schulze Frielinghaus via Gcc-patches wrote: > Ping.  Since this fixes bootstrap problem PR110939 for Loongarch I'm > pingen this one earlier. > > On Thu, Aug 10, 2023 at 03:04:03PM +0200, Stefan Schulze Frielinghaus wrote: > > In the former f

Re: [PATCH v5 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

On Thu, 2023-08-24 at 11:13 +0800, Chenghui Pan wrote: > - Add dg-skip-if for loongarch*-*-* in vshuf test in g++.dg/torture, because >   vshuf/xvshuf insn's result is undefined when 6 or 7 bit of vector's element > is set, >   and insns with this condition are generated in these testcases. I'm a

Re: [PATCH v5 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

On Thu, 2023-08-24 at 11:40 +0800, Xi Ruoyao via Gcc-patches wrote: > On Thu, 2023-08-24 at 11:13 +0800, Chenghui Pan wrote: > > - Add dg-skip-if for loongarch*-*-* in vshuf test in g++.dg/torture, because > >   vshuf/xvshuf insn's result is undefined when 6 or 7 bit of vect

Re: [PATCH v2] LoongArch: Enable '-free' starting at -O2.

On Mon, 2023-08-28 at 11:46 +0800, Lulu Cheng wrote: > v1 -> v2: > 1. Modify Changelog information format. > > gcc/ChangeLog: > > * common/config/loongarch/loongarch-common.cc: > Enable '-free' on O2 and above. > * doc/invoke.texi: Modify the description informatio

Re: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant

Hi Jeff, Can you take a look at the patch? It fixes a bootstrap failure on LoongArch. And in this month 3 related bugzilla tickets have been created (110939, 24, 71). On Thu, 2023-08-10 at 15:04 +0200, Stefan Schulze Frielinghaus via Gcc- patches wrote: > In the former fix in commit 41e

Re: RFC: Top level configure: Require a minimum version 6.8 texinfo

On Tue, 2023-08-29 at 19:01 +0300, Eli Zaretskii via Gcc-patches wrote: > > Date: Tue, 29 Aug 2023 17:45:20 +0200 > > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org, > >  binut...@sourceware.org > > From: Jakub Jelinek via Gdb-patches > > > > On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nic

Re: [PATCH v2 3/4] LoongArch: add new configure option --with-strict-align-lib

On Wed, 2023-08-30 at 09:58 +0800, Yang Yujie wrote: > LoongArch processors may not support memory accesses without natural > alignments.  Building libraries with -mstrict-align may help with > toolchain binary compatiblity and performance on these implementations > (e.g. Loongson 2K1000LA). > > N

Re: [PATCH v2 3/4] LoongArch: add new configure option --with-strict-align-lib

On Wed, 2023-08-30 at 14:51 +0800, Yujie Yang wrote: > > > LoongArch processors may not support memory accesses without natural > > > alignments.  Building libraries with -mstrict-align may help with > > > toolchain binary compatiblity and performance on these implementations > > > (e.g. Loongson 2

Re: RFC: Introduce -fhardened to enable security-related flags

On Tue, 2023-08-29 at 15:42 -0400, Marek Polacek via Gcc-patches wrote: > + if (UNLIKELY (flag_hardened) > + && (opt->code == OPT_D || opt->code == OPT_U)) > +   { > + if (!fortify_seen_p) > +   fortify_seen_p = !strncmp (opt->arg, "_FORTIFY_SOURC

Re: [PATCH v4] LoongArch:Implement 128-bit floating point functions in gcc.

On Thu, 2023-08-31 at 10:46 +0800, chenxiaolong wrote: > +;; Implement __builtin_fabs128 function. > + > +(define_expand "abstf2" > +  [(match_operand:TF 0 "register_operand") > +   (match_operand:TF 1 "register_operand")] > +  "TARGET_64BIT" > +{ > +  loongarch_emit_move (operands[0], operands[1])

Re: [PATCH v5] LoongArch:Implement 128-bit floating point functions in gcc.

On Thu, 2023-08-31 at 15:02 +0800, chenxiaolong wrote: > +;; Implement __builtin_copysignf128 function. > + > +(define_insn_and_split "copysigntf3" > +  [(set (match_operand:TF 0 "register_operand" "=&r") > +   (unspec:TF [(match_operand:TF 1 "register_operand" "r") > +   (match

Re: [PATCH v6 0/4] Add Loongson SX/ASX instruction support to LoongArch target.

On Thu, 2023-08-31 at 17:08 +0800, Chenghui Pan wrote: > This is an update of: > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628303.html > > Changes since last version of patch set: > - "dg-skip-if"-related Changes of the g++.dg/torture/vshuf* testcases are > reverted. >   (Replaced by

Re: [PATCH] LoongArch: Support loading floating-point zero into MEM[base + index].

LGTM. Nit: it should be "storing" floating-point zero into MEM, not "loading". On Sat, 2023-09-02 at 12:47 +0800, Guo Jie wrote: > gcc/ChangeLog: > > * config/loongarch/loongarch.md: Support 'G' -> 'k' in > movsf_hardfloat and movdf_hardfloat. > > gcc/testsuite/ChangeLog: > >  

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: >  /* Note: optimize_size may vary across functions, >     while -m[no]-memcpy imposes a global constraint.  */ >  #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P  > loongarch_do_optimize_block_move_p() >   > -#ifndef HAVE_AS_EXPLICIT_RELOCS > -#define H

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Tue, 2023-09-05 at 20:01 +0800, chenglulu wrote: > > 在 2023/9/5 下午7:51, Xi Ruoyao 写道: > > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > > >   /* Note: optimize_size may vary across functions, > > > while -m[no]-memcpy imposes a global constraint.  */ > > >   #define TARGET_DO_OPTI

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > * Support options for LoongArch SIMD extensions: >   new configure options --with-simd={none,lsx,lasx}; >   new compiler option -msimd={none,lsx,lasx}; >   new driver options -m[no]-l[a]sx. Hmm... In my build (a cross compiler configured with

Re: [PATCH] LoongArch: Link c++ header directory in the default ABI to the toplevel.

On Wed, 2023-09-06 at 18:06 +0800, Yang Yujie wrote: > When multilib is enabled, the c++ header directory of the default multilib > variant needs to be linked to the toplevel since g++ does not search the > toplevel in this case. > > libstdc++-v3/ChangeLog: > > * configure.host: Register

[PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

If mask is a constant with value ((1 << N) - 1) << M we can perform this optimization. gcc/ChangeLog: PR target/111252 * config/loongarch/loongarch-protos.h (loongarch_pre_reload_split): Declare new function. (loongarch_use_bstrins_for_ior_with_mask): Likewise.

Re: [PATCH v1 4/4] LoongArch: Add tests for Loongson SX floating-point conversion instructions.

On Wed, 2023-09-06 at 18:45 +0800, Xiaolong Chen wrote: > +  *((int*)& __m128_op0[3]) = 0x004200a0; > +  *((int*)& __m128_op0[2]) = 0x; > +  *((int*)& __m128_op0[1]) = 0x004200a0; > +  *((int*)& __m128_op0[0]) = 0x0021; These are aliasing rule violation and they will suddenly blow up w

Re: [PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

Forgot to mention: I've bootstrapped and regtested this patch on loongarch64-linux-gnu (with PR110939 patch applied to unbreak the bootstrapping). Ok for trunk? On Wed, 2023-09-06 at 18:46 +0800, Xi Ruoyao wrote: > If mask is a constant with value ((1 << N) - 1) << M we can perform this > optimi

Re: [PATCH v1 1/4] LoongArch: Add tests of -mstrict-align option.

On Wed, 2023-09-06 at 18:43 +0800, Xiaolong Chen wrote: > gcc/testsuite/ChangeLog: > > * gcc.target/loongarch/strict-align.c: New test. A question: is there really a CPU model with LSX/LASX but without unaligned access support? If not I think we'd just reject -mstrict- align -mlsx. Curr

Re: [PATCH v2 2/4] LoongArch: Add testsuite framework for Loongson SX/ASX.

On Thu, 2023-09-07 at 15:00 +0800, Xiaolong Chen wrote: /* snip */ > diff --git > a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h > b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h > new file mode 100644 > index 000..7be199ee3a0 > --- /dev/null >

Re: [PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

On Thu, 2023-09-07 at 10:15 +0800, chenglulu wrote: > > 在 2023/9/6 下午6:58, Xi Ruoyao 写道: > > Forgot to mention: I've bootstrapped and regtested this patch on > > loongarch64-linux-gnu (with PR110939 patch applied to unbreak the > > bootstrapping).  Ok for trunk? > > LGTM! > > Thanks! Pushed r14

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Wed, 2023-09-06 at 09:04 +0800, Yang Yujie wrote: > On Tue, Sep 05, 2023 at 09:31:56PM +0800, Xi Ruoyao wrote: > > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > > > * Support options for LoongArch SIMD extensions: > > >   new configure options --with-simd={none,lsx,lasx}; > > >   new co

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Thu, 2023-09-07 at 17:31 +0800, Yang Yujie wrote: > > This is bad.  It makes BOOT_CFLAGS=-mlasx or CFLAGS_FOR_TARGET=-mlasx > > silently ignored so we cannot test a LSX/LASX or vectorizer change with > > them. > > > > Why do we need to purge all user-specified -m options here? > > Yes, that is

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Thu, 2023-09-07 at 17:47 +0800, Xi Ruoyao wrote: /* snip */ > I've made some local experiment too, I think we can add a "-mbuild- > multilib" option which does nothing but in the hacked spec we can wrap > the line in %{mbuild-multilib:...}: > > %{mbuild-multilib:% %{mabi=lp64d:-march=la464 -m

[PATCH] LoongArch: Use LSX and LASX for block move

gcc/ChangeLog: * config/loongarch/loongarch.h (LARCH_MAX_MOVE_PER_INSN): Define to the maximum amount of bytes able to be loaded or stored with one machine instruction. * config/loongarch/loongarch.cc (loongarch_mode_for_move_size): New static function.

[PATCH] LoongArch: Slightly simplify loongarch_block_move_straight

gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_block_move_straight): Check precondition (delta must be a power of 2) and use popcount_hwi instead of a homebrew loop. --- I've not run a full bootstrap with this, but it should be obvious. Ok for trunk? gcc/confi

Re: [PATCH] LoongArch: Enable -fsched-pressure by default at -O1 and higher.

On Fri, 2023-09-08 at 10:00 +0800, Guo Jie wrote: > gcc/ChangeLog: > > * common/config/loongarch/loongarch-common.cc: "common/" should be removed. You can use "git gcc-verify" to figure out this kind of error before sending a patch in the future. > (default_options loongarch_opt

Re: [PATCH] LoongArch: Enable -fsched-pressure by default at -O1 and higher.

On Fri, 2023-09-08 at 16:29 +0800, Guo Jie wrote: > Hi, > > What I wanna change is "gcc/common/config/loongarch/loongarch- > common.cc", > > and the patch is automatically generated by "git gcc-commit-mklog". > > Is it necessary to  to remove "common/" ? My bad. I didn't realized the file has

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Sat, 2023-09-09 at 10:46 +0800, Yang Yujie wrote: > The next option I can think of would be MULTILIB_EXTRA_OPTS, where > -fmultiflags > fit in nicely.  However, these options won't reach the toplevel builds, and > tweaking config-ml.in for getting it there would be quite tedious and perhaps > u

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Sat, 2023-09-09 at 14:26 +0800, Yang Yujie wrote: > I remember you were against it because you think non-multilib users > would be punished because the libdir layout changes (no toplevel). > However this directory should be (mostly) private to each gcc instance, > so I don't see real consequence

Pushed: [PATCH v2] LoongArch: Use LSX and LASX for block move

Pushed r14-3818 with test cases added. The pushed patch is attached. On Sat, 2023-09-09 at 14:10 +0800, chenglulu wrote: > > 在 2023/9/8 上午12:14, Xi Ruoyao 写道: > > gcc/ChangeLog: > > > > * config/loongarch/loongarch.h (LARCH_MAX_MOVE_PER_INSN): > > Define to the maximum amount of

Pushed: [PATCH] LoongArch: Slightly simplify loongarch_block_move_straight

Pushed r14-3819. On Sat, 2023-09-09 at 14:16 +0800, chenglulu wrote: > > 在 2023/9/8 上午12:33, Xi Ruoyao 写道: > > gcc/ChangeLog: > > > > * config/loongarch/loongarch.cc > > (loongarch_block_move_straight): > > Check precondition (delta must be a power of 2) and use > > popco

Re: [PATCH] LoongArch: Use LSX and LASX for block move

On Sat, 2023-09-09 at 15:04 +0800, chenglulu wrote: > Hi,RuoYao: > >   I think the test example memcpy-vec-3.c submitted in r14-3818 is > implemented incorrectly. > > The 16-byte length in this test example will cause can_move_by_pieces to > return true when with '-mstrict-align', so no vector

Re: [PATCH] LoongArch: Use LSX and LASX for block move

On Sat, 2023-09-09 at 15:14 +0800, chenglulu wrote: > > 在 2023/9/9 下午3:06, Xi Ruoyao 写道: > > On Sat, 2023-09-09 at 15:04 +0800, chenglulu wrote: > > > Hi,RuoYao: > > > > > >    I think the test example memcpy-vec-3.c submitted in r14-3818 is > > > implemented incorrectly. > > > > > > The 16-byte

Re: [PATCH v1] LoongArch: Fix bug of 'di3_fake'.

On Sat, 2023-09-09 at 15:42 +0800, Lulu Cheng wrote: > PR 111334 > > gcc/ChangeLog: > > * config/loongarch/loongarch.md: Fix bug of di3_fake. > > gcc/testsuite/ChangeLog: > > * gcc.target/loongarch/pr111334.c: New test. Ok. Despite I still think we should use unspec in

[PATCH] LoongArch: Fix up memcpy-vec-3.c test case

The generic code will split 16-byte copy into two 8-byte copies, so the vector code wouldn't be used even if -mno-strict-align. This contradicted with the purpose of this test case. gcc/testsuite/ChangeLog: * gcc.target/loongarch/memcpy-vec-3.c: Increase the amount of copied byte

Re: [PATCH] LoongArch: Fix up memcpy-vec-3.c test case

On Sat, 2023-09-09 at 16:21 +0800, chenglulu wrote: > LGTM! Pushed r14-3821. > 在 2023/9/9 下午4:20, Xi Ruoyao 写道: > > The generic code will split 16-byte copy into two 8-byte copies, so the > > vector code wouldn't be used even if -mno-strict-align.  This > > contradicted with the purpose of this t

PING^4: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant

Ping. > > > On Thu, Aug 10, 2023 at 03:04:03PM +0200, Stefan Schulze Frielinghaus > > > wrote: > > > > In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I > > > > completely missed the fact that the normal form of a generated constant > > > > for a > > > > mode with fewer bits

Re: [PATCH v3 4/9] LoongArch:Added support for SX vector floating-point instructions.

The subject should be "Add tests for SX vector floating-point instructions". The "support" has already been added. Likewise for patches 5-9. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University

Re: [PATCH] LoongArch: gcc: Modify gas uleb128 support test.

On Thu, 2023-09-14 at 19:21 +0800, Lulu Cheng wrote: > diff --git a/gcc/configure.ac b/gcc/configure.ac > index 09082e8ccae..072fe1d2b48 100644 > --- a/gcc/configure.ac > +++ b/gcc/configure.ac > @@ -3226,6 +3226,19 @@ L2: > .uleb128 0x8000 >  ], >  [[ > +case "$target" in > + 

Re: [PATCH] LoongArch: gcc: Modify gas uleb128 support test.

On Thu, 2023-09-14 at 19:54 +0800, chenglulu wrote: > Sorry, it's my problem. We will modify it as soon as possible. Try this: diff --git a/gcc/configure.ac b/gcc/configure.ac index cb4be11facd..10027a4 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -3229,10 +3229,18 @@ AC_MSG_RESULT

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, 2023-09-14 at 15:57 +, Qing Zhao via Gcc-patches wrote: > Currently, GCC behaves as following: > > /* True if overflow wraps around for the given integral or pointer type.  That >    is, TYPE_MAX + 1 == TYPE_MIN.  */ > #define TYPE_OVERFLOW_WRAPS(TYPE) \ >   (POINTER_TYPE_P (TYPE) 

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > > > CLANG already provided -fsanitize=unsigned-integer-overflow. GCC > > > might need to do the same. > > > > NO. There is no such thing as unsigned integer overflow. That option > > is badly designed and the GCC community has rejected a few ti

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, 2023-09-15 at 15:37 +, Qing Zhao wrote: > > > > On Sep 15, 2023, at 11:29 AM, Richard Biener > > wrote: > > > > > > > > > Am 15.09.2023 um 17:25 schrieb Qing Zhao : > > > > > >  > > > > > > > On Sep 15, 2023, at 8:41 AM, Arsen Arsenović > > > > wrote: > > > > > > > > > > > >

PING^5: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant

Ping^5. > > > On Thu, Aug 10, 2023 at 03:04:03PM +0200, Stefan Schulze Frielinghaus > > > wrote: > > > > In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I > > > > completely missed the fact that the normal form of a generated constant > > > > for a > > > > mode with fewer bi

[PATCH 0/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

This is a series of patches essentially adding order statistics directly into pb_ds binary search trees. The main purpose is to resolve PR 81806 (spliting a splay tree needs linear time). The first patch removes two redundant statements which are confusing. It should be applied anyway, disregard

Re: [PATCH 0/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

> The first patch removes two redundant statements which are confusing. It > should > be applied anyway, disregarding other patches. The patch is attached, to prevent my mail client from destroying it :(. libstdc++-v3/ChangeLog: * include/ext/pb_ds/detail/bin_search_tree_/insert_fn_imp

[PATCH 1/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

> The first patch removes two redundant statements which are confusing. It > should > be applied anyway, disregarding other patches. The patch is attached, to prevent my mail client from destroying it :(. Please ignore a previous duplication of this mail with wrong title :(. libstdc++-v3/Change

[PATCH 2/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

> The second and third patch together resolve PR 81806. The attached patch keeps the subtree size in binary search tree nodes. libstdc++-v3/ChangeLog: * include/ext/pb_ds/detail/rb_tree_map_/node.hpp (rb_tree_node_::size_type): New typedef. (rb_tree_node_::m_subtree_

[PATCH 3/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

> The second and third patch together resolve PR 81806. The attached patch modifies split_finish to use the subtree size we maintained in the previous patch, resolving libstdc++/81806. libstdc++-v3/ChangeLog: PR libstdc++/81806 * include/ext/pb_ds/detail/bin_search_tree_/split_j

[PATCH 4/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

> The fourth patch converts the point_iterator of rb_tree and splay_tree based > maps to random access iterator. With the subtree size kept we can implement > the > operators required by random access iterator in logarithm time. The patch is attached. libstdc++-v3/ChangeLog: * include/

[PATCH 5/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

> The fifth patch moves the functionality of tree_order_statistics_node_update > into the implementation of binary search trees (they are now order-statistics > trees), makes tree_order_statistics_node_update no-op, and deprecates it. The patch is attached. libstdc++-v3/ChangeLog: * inc

[PATCH] MIPS: Fix PR target/98491

An invalid use of MSA_SUPPORTED_MODE_P is causing ICE on mips64el with -mmsa. The detailed analysis is posted on bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491 The attached patch fixes this issue by handling the special case of MSA_SUPPORTED_MODE_P explicitly. Please keep me in CC

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

On 2021-01-01 07:29 +0800, Xi Ruoyao wrote: > An invalid use of MSA_SUPPORTED_MODE_P is causing ICE on mips64el with -mmsa. > The detailed analysis is posted on bugzilla: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491 > > The attached patch fixes this issue by handling the special case of

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

Hi Jeff and Jakub, On 2021-01-04 14:19 -0700, Jeff Law wrote: > On 1/4/21 2:00 PM, Jakub Jelinek wrote: > > On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote: > > > > Sorry, I forgot to include the ChangeLog: > > > > > > > >     gcc/ChangeLog: > > > >     > > > >     2020-

<    1   2   3   4   5   6   >