I noticed while looking into some code generation of bitmap_single_bit_set_p,
that sometimes:
```
if (uns > 1)
return 0;
return uns == 1;
```
Would not optimize down to just:
```
return uns == 1;
```
In this case, VRP likes to change `a == 1` into `(bool)a` if
a has a range of [0,1] due
On Mon, 2023-08-07 at 12:01 +0800, chenxiaolong wrote:
> +/* Count the number of functions with "q" as the suffix */
> +static int MATHQ_NUMS=(int)LARCH_MAX_FTYPE_MAX-(int)LARCH_BUILTIN_HUGE_VALQ;
This is obviously not the GCC coding standard... It should have some
white spaces:
static int
From: Xiaolong Chen
In the implementation process, the "q" suffix function is
Re-register and associate the "__float128" type with the
"long double" type so that the compiler can handle the
corresponding function correctly. The functions implemented
I am not quite sure if I understand it correctly, but I bet below enums are
required by RISC-V mode switching, like FRM_MODE_DYN in entry, or
FRM_MODE_CALL/EXIT in emit.
> ;; Defines rounding mode of an floating-point operation.
> -(define_attr "frm_mode"
What about using similar way as vlmul?
# NOTE: diff is based on your patch.
[kitoc@hsinchu02 riscv]$ git diff
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 33f7cb1d670..3cb5c23cb09 100644
--- a/gcc/config/riscv/riscv-protos.h
+++
Hi,
Gentle ping...
On 2023-07-18 22:05, Jiufu Guo wrote:
Hi,
Integer expression "(X - N * M) / N" can be optimized to "X / N - M"
if there is no wrap/overflow/underflow and "X - N * M" has the same
sign with "X".
Compare the previous version:
Sure thing, let’s wait kito’s comment for this.
Pan
From: juzhe.zh...@rivai.ai
Sent: Monday, August 7, 2023 9:31 AM
To: Li, Pan2 ; gcc-patches
Cc: Wang, Yanzhang ; kito.cheng
Subject: Re: RE: [PATCH v1] RISC-V: Refactor RVV frm_mode attr for rounding
mode intrinsic
I have no ideal. I would
I have no ideal. I would prefer kito makes decision here.
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-07 09:22
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Wang, Yanzhang; kito.cheng
Subject: RE: [PATCH v1] RISC-V: Refactor RVV frm_mode attr for rounding mode
intrinsic
We will have
We will have below error if there is no cast here.
../gcc/config/riscv/vector.md:6134:36: error: invalid conversion from 'int' to
'attr_frm_mode' [-fpermissive]
Or we can return attr_frm_mode in get_frm_mode but it requires some additional
header files. Is there any guidance here in GCC coding
+ (set (attr "frm_mode")
+ (symbol_ref "(enum attr_frm_mode) riscv_vector::get_frm_mode
(operands[8])"))])
I don't think we need "(enum attr_frm_mode)"
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-06 11:36
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
On Thu, 3 Aug 2023 at 17:48, Richard Biener wrote:
>
> On Thu, 3 Aug 2023, Richard Biener wrote:
>
> > On Thu, 3 Aug 2023, Richard Biener wrote:
> >
> > > On Thu, 3 Aug 2023, Prathamesh Kulkarni wrote:
> > >
> > > > On Wed, 2 Aug 2023 at 14:17, Richard Biener via Gcc-patches
> > > > wrote:
> > >
Hi,
If loop is ifconverted and later versioning by vectorizer, vectorizer will
reuse the scalar loop produced by ifconvert. Curiously enough it does not seem
to do so for versions produced by loop distribution while for loop distribution
this matters (since since both ldist versions survive to
My apologies (again), I managed to mess up the 64-bit version of the
test case for PR 110792. Unlike the 32-bit version, the 64-bit case
contains exactly the same load instructions, just in a different order
making the correct and incorrect behaviours impossible to distinguish
with a
Hi,
Epilogue peeling expects the scalar loop to have same number of executions as
the vector loop which is true at the beggining of vectorization. However if the
epilogues are vectorized, this is no longer the case. In this situation the
loop preheader is replaced by new guard code with correct
On 8/5/23 5:53 PM, David Malcolm wrote:
...but the warning branch uses "warning", which implicitly uses the
input_location global variable. Is the warning reported at the correct
place? It's better to use warning_at and pass it the location at which
the warning should be emitted.
Thanks, I
DR 2386 updated the tuple_size requirements for structured binding and
it now requires tuple_size to be considered only if
std::tuple_size names a complete class type with member value. GCC
before this patch does not follow the updated requrements, and this
patch is intended to implement it.
On 7/19/23 11:46 AM, jeevitha via Gcc-patches wrote:
> gcc/
> PR target/110411
> * config/rs6000/mma.md (define_insn_and_split movoo): Disallow
> AltiVec address in movoo and movxo pattern.
No need to mention movxo here, since the next change covers movxo.
And maybe better as
loongarch_move_integer does not support splitting 64-bit integer into
two 32-bit ones. Thus, define_split is removed from movdi_32bit and
TARGET_64BIT is added to the split condition of movdi_64bit to avoid
using it for loongarch32.
gcc/ChangeLog:
* config/loongarch/loongarch.md
The compiler emits a warning if the current target (-march=loongarch32)
mismatches with abi(-march-lp64d). Adding: Add -march=loongarch64
explicitly fixes the tests.
gcc/testsuite/ChangeLog:
* g++.target/loongarch/bytepick.C: Add -march=loongarch64
*
Bring back 64-bit move splitting for loongarch32. The code was removed
in commit 16fc26d4e7a (`LoongArch: Support split symbol.`) for unknown
reason.
gcc/ChangeLog:
* config/loongarch/loongarch.md: Handle move splitting for
64-bit operands.
---
Introduce loongarch32 target and ilp32 abi variants. The ilp32d abi
variant is selected as the default abi of loongarch32 target.
contrib/ChangeLog:
* config-list.mk: Add loongarch32-linux-gnu*.
gcc/ChangeLog:
* config.gcc: Add target triple loongarch32-*-*-* and
In loongarch32 target, conversions between SF/DF and DI are not
supported.
gcc/ChangeLog:
* config/loongarch/loongarch.md: Check TARGET_64BIT in insns
regarding SF/DF <-> DI conversion.
---
gcc/config/loongarch/loongarch.md | 8
1 file changed, 4 insertions(+), 4
When rhs equals to 0x7fff, adding 1 to rhs overflows SI, generating
invalid const_int.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_emit_int_compare):
Call trunc_int_mode to ensure valid rhs.
---
gcc/config/loongarch/loongarch.cc | 1 +
1 file changed, 1
When loongarch_arch_target is called, la_target has not been
initialized, thus the macro LARCH_ACTUAL_ARCH always equals to zero.
This commit fixes by expanding the macro and reading the latest value.
It permits -march=loongarch64 when the default target is loongarch32 and
vice versa.
Add TARGET_64BIT check for loongarch64-only handling of SI division. It
shall not promote SI to DI before division in loongarch32 target.
gcc/ChangeLog:
* config/loongarch/loongarch.md: Add TARGET_64BIT check for
loongarch64-only handling of SI division.
---
The operand order of movgr2frh.w was wrong. The correct order should be
`movgr2frh.w fd, rj`.
gcc/ChangeLog:
* config/loongarch/loongarch.md (movgr2frh): Correct
movgr2frh.w operand order.
---
gcc/config/loongarch/loongarch.md | 2 +-
1 file changed, 1 insertion(+), 1
libstdc++: [_GLIBCXX_INLINE_VERSION] Add __cxa_call_terminate symbol export
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu-versioned-namespace.ver: Add __cxa_call_terminate
symbol export.
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
On Fri, 4 Aug 2023 at 20:36, Richard Sandiford
wrote:
>
> Full review this time, sorry for the skipping the tests earlier.
Thanks for the detailed review! Please find my responses inline below.
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> > index
28 matches
Mail list logo
