https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #49 from Sergey Fedorov ---
If someone happens to have some WIP on this, more recent than 2012, please
share, if possible.
On 10/7/23 15:30, Sam James wrote:
Jeff Law writes:
On 10/4/23 16:19, Roger Sayle wrote:
The recent patch to remove poly_int_pod triggers a bug in g++
4.8.5's
C++ 11 support which mistakenly believes poly_uint16 has a non-trivial
constructor. This in turn prohibits it from being used as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111621
--- Comment #2 from liu xu ---
I'm sorry about that and will notice that next time.
The toolchain I used was built using the gcc master branch, and another point
that needs to be added is that only the vadd.vi instruction with mask will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111718
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111718
--- Comment #3 from Andrew Pinski ---
For comment #2 from EVRP:
Folding statement: _3 = _2 / a_5(D);
Applying pattern match.pd:934, gimple-match-4.cc:2021
gimple_simplified to _3 = 2;
Which corresponds to the match pattern:
/* Simplify (t * 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94395
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111718
--- Comment #2 from Yi <652023330028 at smail dot nju.edu.cn> ---
We noticed one change between gcc-13.2 and the current gcc-trunk:
https://godbolt.org/z/j5Mnvno9n
In the following code, gcc-13.2 does not yet have the ability to optimize as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
Jiu Fu Guo changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Ready push to trunk.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_build_const_vector): Handle V2HF
and V4HFmode.
(ix86_build_signbit_mask): Ditto.
* config/i386/mmx.md (mmxintvecmode): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Ready push to trunk.
gcc/ChangeLog:
* config/i386/mmx.md (VHF_32_64): New mode iterator.
(3): New define_expand, merged from ..
(v4hf3): .. this and
(v2hf3): .. this.
(movd_v2hf_to_sse_reg):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111723
--- Comment #1 from Andrew Pinski ---
I think this is correct behavior really.
Note even clang with libc++ has the same behavior ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111723
Bug ID: 111723
Summary: #pragma GCC system_header suppresses errors from
narrowing conversions
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Keywords:
Since -mapxf works similar as -muintr that will emit error for 32bit
target, add !ia32 target guard for apx related tests.
Committed as obvious fix after test.
gcc/testsuite/ChangeLog:
* gcc.target/i386/apx-egprs-names.c: Compile for non-ia32.
*
Hi, Jeff.
Address your comments and fix on V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632239.html
I think it look reasonable good for a long term maintenance now.
Ok for trunk ?
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-10-07 23:09
To: Juzhe-Zhong; gcc-patches
CC:
This patch fixes the following dumple FAILs:
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
optimized " = \\.COND_SUB"
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
vect " = \\.COND_ADD"
FAIL: gcc.dg/vect/vect-cond-arith-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
--- Comment #5 from Zeb Figura ---
(In reply to Andrew Pinski from comment #4)
> There is no bug here.
> ICF finds that your definition of memcpy is the same as memmove and merges
> the 2 and then calls memcpy from your memmove and then inlines
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Sunday, October 8, 2023 12:13 AM
To: Wang, Yanzhang ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pan2
Subject: Re: [PATCH] RISC-V: add static-pie support
On 10/7/23 05:32,
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, October 7, 2023 10:44 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: rguent...@suse.de
Subject: Re: [PATCH] TEST: Fix XPASS of TSVC testsuites for RVV
On 10/7/23 03:23, Juzhe-Zhong wrote:
> Fix these
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, October 7, 2023 10:48 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; rdapp@gmail.com
Subject: Re: [PATCH] RISC-V: Enable more tests of "vect" for RVV
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94039
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
--- Comment #3 from Zeb Figura ---
Created attachment 56072
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56072=edit
testcase
Attaching a reduced-ish testcase, that contains the unmodified code of memcpy()
and memmove(), plus two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
Zeb Figura changed:
What|Removed |Added
Version|unknown |13.2.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
Bug ID: 111722
Summary: gcc generates wrong code with
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111721
Bug ID: 111721
Summary: RISC-V: Failed to SLP for gather_load in RVV
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #12 from JuzheZhong ---
Hi, Andrew.
I have another try:
https://godbolt.org/z/heKxcMWsY
change the load into normal load of arr:
vuint8m1_t varr = *(vuint8m1_t*)arr;
Like you said,
The issue is gone (as good as LLVM):
fn:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #11 from JuzheZhong ---
(In reply to Andrew Pinski from comment #10)
> The issues is GCC does prop the load/store for arr into __riscv_vle8_v_u8m1
> really.
Ok. Do you know why GCC prop load/store for arr into __riscv_vle8_v_u8m1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #10 from Andrew Pinski ---
The issues is GCC does prop the load/store for arr into __riscv_vle8_v_u8m1
really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #9 from JuzheZhong ---
(In reply to Andrew Pinski from comment #7)
> .
Besides, if we remove the data initialization:
https://godbolt.org/z/qcjcP7s1c
#include
vuint8m1_t fn() {
uint8_t arr[32];
uint8_t m = 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #8 from JuzheZhong ---
(In reply to Andrew Pinski from comment #6)
> I suspect if __riscv_vle8_v_u8m1 gets lowered into a load on the gimple
> level, it might just work ...
>
> But it gets expanded as:
> (insn 14 13 0 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #6 from Andrew Pinski ---
I suspect if __riscv_vle8_v_u8m1 gets lowered into a load on the gimple level,
it might just work ...
But it gets expanded as:
(insn 14 13 0 (set (reg/v:RVVM1QI 134 [ varrD.56526 ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #5 from JuzheZhong ---
Similar issue in GCC 13.2:
https://godbolt.org/z/axKc4qj47
fn:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
ld a1,0(a5)
ld a2,8(a5)
ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #4 from JuzheZhong ---
I found this is not because VLS modes.
with --param=riscv-autovec-preference=fixed-vlmax
disabling VLS modes also see unnecessary load/store:
fn:
lui a5,%hi(.LANCHOR0)
addisp,sp,-32
Snapshot gcc-13-20231007 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20231007/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #3 from JuzheZhong ---
(In reply to Andrew Pinski from comment #2)
> I noticed there is an ABI difference here.
>
> GCC is returning via a store to a0:
> vsm.v v1,0(a0)
>
> While LLVM is returning via v0 .
>
> Which one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #2 from Andrew Pinski ---
I noticed there is an ABI difference here.
GCC is returning via a store to a0:
vsm.v v1,0(a0)
While LLVM is returning via v0 .
Which one is correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #1 from JuzheZhong ---
The root cause is unnecessary VLS modes data movement:
(insn 10 9 11 2 (set (reg:V4DI 143)
(mem/u/c:V4DI (reg:DI 142) [0 S32 A128])) "/app/example.c":4:13 1119
{*movv4di}
(nil))
(insn 11 10 12 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
--- Comment #10 from dave.anglin at bell dot net ---
On 2023-10-06 3:50 a.m., rguenth at gcc dot gnu.org wrote:
> Does it work on trunk?
No. Test results with gcc trunk are identical to with Debian gcc-13.
Tried just rebuilding s_fma.c, and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
Bug ID: 111720
Summary: RISC-V: Ugly codegen in RVV
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Do you mean change it like this ?
/* { dg-final { scan-tree-dump-times { = \.COND_L?E?N?_?RDIV} 1 "optimized" {
target vect_double_cond_arith } } } */
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-10-07 23:09
To: Juzhe-Zhong; gcc-patches
CC: rguenther; rdapp.gcc
Subject: Re: [PATCH] TEST:
Jeff Law writes:
> On 10/4/23 16:19, Roger Sayle wrote:
>> The recent patch to remove poly_int_pod triggers a bug in g++
>> 4.8.5's
>> C++ 11 support which mistakenly believes poly_uint16 has a non-trivial
>> constructor. This in turn prohibits it from being used as a member in
>> a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699
--- Comment #10 from CVS Commits ---
The releases/gcc-11 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:9d4caf90e7bf1824ebabf0bc0541bfea511ef03b
commit r11-11054-g9d4caf90e7bf1824ebabf0bc0541bfea511ef03b
Author: Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:a63238cd52d974d364677def97d4ed70d26a7410
commit r12-9915-ga63238cd52d974d364677def97d4ed70d26a7410
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:add2afa9e25f1776fdfbeb1b99fd1efcf850f91f
commit r13-7938-gadd2afa9e25f1776fdfbeb1b99fd1efcf850f91f
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111384
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2023-10-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109414
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64215
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
I've been told that previous patch generated with 'git diff -b' was not
applying properly so here is the same patch again with a simple 'git diff'.
On 07/10/2023 14:25, François Dumont wrote:
Hi
Here is a rebased version of this patch.
There are few test failures when running 'make
Hello All:
This patch add new pass to replace contiguous addresses vector load lxv with
mma instruction
lxvp. This patch addresses one regressions failure in ARM architecture.
Bootstrapped and regtested with powepc64-linux-gnu.
Thanks & Regards
Ajit
rs6000: Add new pass for replacement of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110859
--- Comment #3 from John David Anglin ---
FAIL: 23_containers/vector/bool/110807.cc -std=gnu++17 (test for excess
errors)
Excess errors:
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:440:
warning: 'void*
On 10/4/23 16:19, Roger Sayle wrote:
The recent patch to remove poly_int_pod triggers a bug in g++ 4.8.5's
C++ 11 support which mistakenly believes poly_uint16 has a non-trivial
constructor. This in turn prohibits it from being used as a member in
a union (rtxunion) that constructed
On 10/7/23 05:32, yanzhang.w...@intel.com wrote:
From: Yanzhang Wang
We only need to pass options to the linker when static-pie is passed.
There's another patch to enable static-pie in glibc. And we need to
enable in GCC first.
gcc/ChangeLog:
* config/riscv/linux.h: Pass the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111718
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment
Strictly structured blocks are '!$omp ' directly
followed by 'BLOCK ... END BLOCK', i.e. a Fortran block construct.
I did run into this issue because 'integer :: n; n = 5; !$omp ...;
block; integer :: A(n)' was not accepted.
Well, it turned out that was because the BLOCK handling was not quite
On 10/7/23 05:45, Juzhe-Zhong wrote:
This patch fixes the following dumple FAILs:
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump optimized
" = \\.COND_SUB"
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump vect "
= \\.COND_ADD"
On 10/7/23 01:04, Juzhe-Zhong wrote:
This patch enables almost full coverage vectorization tests for RVV, except
these
following tests (not enabled yet):
1. Will enable soon:
check_effective_target_vect_call_lrint
check_effective_target_vect_call_btrunc
On 10/7/23 03:23, Juzhe-Zhong wrote:
Fix these following XPASS FAILs of TSVC for RVV:
XPASS: gcc.dg/vect/tsvc/vect-tsvc-s1115.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 1 loops"
XPASS: gcc.dg/vect/tsvc/vect-tsvc-s1115.c scan-tree-dump vect "vectorized 1
loops"
XPASS:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111719
Bug ID: 111719
Summary: Omitting data-sharing attribute for function return
value in OpenMP does not raise an error.
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Hi, I've recently been working on static local variables in C. I would
like to ask about some questions about that.
For example, for the following program,
void foo() {
static int x = 0;
x++;
}
int main() {
foo();
}
After optimization with the -O3 -flto option, the entire program will
Robin Dapp writes:
> Hi Richard,
>
> cool, thanks. I just gave it a try with my test cases and it does what
> it is supposed to do, at least if I disable the register pressure check :)
> A cursory look over the test suite showed no major regressions and just
> some overly specific tests.
>
> My
Saurabh Jha writes:
> On 10/6/2023 2:24 PM, Saurabh Jha wrote:
>> Hey,
>>
>> This patch adds support for the Cortex-X4 CPU to GCC.
>>
>> Regression testing for aarch64-none-elf target and found no regressions.
>>
>> Okay for gcc-master? I don't have commit access so if it looks okay,
>> could
Hi
Here is a rebased version of this patch.
There are few test failures when running 'make check-c++' but nothing new.
Still, there are 2 patches awaiting validation to fix some of them, PR
c++/111524 to fix another bunch and I fear that we will have to live
with the others.
libstdc++:
Richard Earnshaw writes:
> On 03/10/2023 16:18, Victor Do Nascimento wrote:
>> In implementing the ACLE read/write system register builtins it was
>> observed that leaving argument type checking to be done at expand-time
>> meant that poorly-formed function calls were being "fixed" by certain
>>
This patch fixes the following dumple FAILs:
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
optimized " = \\.COND_SUB"
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
vect " = \\.COND_ADD"
FAIL: gcc.dg/vect/vect-cond-arith-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92798
--- Comment #6 from Jonathan Wakely ---
We could add an enumerator that forces sizeof(_Rb_tree_color) == sizeof(int),
which would be valid for C++98.
Richard Biener writes:
>> Am 07.10.2023 um 11:23 schrieb Richard Sandiford
>> >> Richard Biener writes:
>>> On Thu, 5 Oct 2023, Tamar Christina wrote:
>>>
> I suppose the idea is that -abs(x) might be easier to optimize with other
> patterns (consider a - copysign(x,...), optimizing
From: Yanzhang Wang
We only need to pass options to the linker when static-pie is passed.
There's another patch to enable static-pie in glibc. And we need to
enable in GCC first.
gcc/ChangeLog:
* config/riscv/linux.h: Pass the static-pie specific options to
the linker.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29
Jonathan Wakely changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111718
Bug ID: 111718
Summary: Missed optimization of '(a+a)/a'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
> Am 07.10.2023 um 11:23 schrieb Richard Sandiford :
>
> Richard Biener writes:
>> On Thu, 5 Oct 2023, Tamar Christina wrote:
>>
I suppose the idea is that -abs(x) might be easier to optimize with other
patterns (consider a - copysign(x,...), optimizing to a + abs(x)).
Also I have reverted your commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=066a43ce72ab6559ba14af9628df19daa0b85cdf
Plz test the patch and verify it doesn't cause any FAILs if the toolchain
doesn't have "zvfh_zfh".
juzhe.zh...@rivai.ai
From: juzhe.zh...@rivai.ai
Date: 2023-10-07 17:49
Richard Biener writes:
> On Thu, Oct 5, 2023 at 10:46 PM Tamar Christina
> wrote:
>>
>> > -Original Message-
>> > From: Richard Sandiford
>> > Sent: Thursday, October 5, 2023 9:26 PM
>> > To: Tamar Christina
>> > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> > ; Marcus
These testcases cause multiple FAILs:
I think you should
/* { dg-do run { target { riscv_v && riscv_zvfh_hw && riscv_zfh_ok } } } */
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-10-07 14:25
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Add
Fix these following XPASS FAILs of TSVC for RVV:
XPASS: gcc.dg/vect/tsvc/vect-tsvc-s1115.c -flto -ffat-lto-objects
scan-tree-dump vect "vectorized 1 loops"
XPASS: gcc.dg/vect/tsvc/vect-tsvc-s1115.c scan-tree-dump vect "vectorized 1
loops"
XPASS: gcc.dg/vect/tsvc/vect-tsvc-s114.c -flto
Richard Biener writes:
> On Thu, 5 Oct 2023, Tamar Christina wrote:
>
>> > I suppose the idea is that -abs(x) might be easier to optimize with other
>> > patterns (consider a - copysign(x,...), optimizing to a + abs(x)).
>> >
>> > For abs vs copysign it's a canonicalization, but (negate (abs
Unfortunately, I was unable to reproduce the problem mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631933.html
Heres's a possible fix without testing. Please tell me if this works.
On Sat, Oct 07, 2023 at 04:50:14PM +0800, Yang Yujie wrote:
> -TM_H += loongarch-multilib.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111634
Patrick O'Neill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
gcc/ChangeLog:
* config.gcc: Add loongarch-driver.h to tm_files.
* config/loongarch/loongarch.h: Do not include loongarch-driver.h.
* config/loongarch/t-loongarch: Append loongarch-multilib.h to $(GTM_H)
instead of $(TM_H) for building generator programs.
---
> It would be nice to add to the documentation that INSN_BASE_REG_CLASS,
> INSN_INDEX_REG_CLASS, and REGNO_OK_FOR_INSN_BASE_P if defined have
> priority over older corresponding macros as it is already documented for
> REGNO_MODE_CODE_OK_FOR_BASE_P relating to REGNO_OK_FOR_BASE_P. But this
> small
Hi!
On Sat, 2023-10-07 15:08:34 +0800, Xi Ruoyao wrote:
> On Sat, 2023-10-07 at 11:41 +0800, Yang Yujie wrote:
> > Thanks for the testing!
> >
> > This error seems to be difficult to reproduce since it is a makefile
> > dependency
> > problem. I think appending loongarch-multilib.h to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108338
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi,
David Edelsohn writes:
> This Message Is From an External Sender
> This message came from outside your organization.
> Report Suspicious
>
> On Thu, Oct 5, 2023 at 12:14 AM Jiufu Guo wrote:
>
> Hi,
>
> As mentioned in PR108338, on p9, we could use mtvsrws to implement
> the
Hi,
David Edelsohn writes:
>
> On Thu, Oct 5, 2023 at 12:50 AM Jiufu Guo wrote:
>
> Hi,
>
> Currently, we have the pattern "movsf_from_si2" which was trying
> to support moving high part DI to SF.
>
> But current pattern only accepts "ashiftrt":
> XX:SF=bitcast:SF(subreg(YY:DI>>32),0),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108338
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:537d7a445ca0ed677751afd3cdcf8465ccd5fb7e
commit r14-4445-g537d7a445ca0ed677751afd3cdcf8465ccd5fb7e
Author: Jiufu Guo
Date: Thu Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108338
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:5f56b76ff1c15118200204569389f85cca4e32d3
commit r14--g5f56b76ff1c15118200204569389f85cca4e32d3
Author: Jiufu Guo
Date: Thu Sep
On Sat, 2023-10-07 at 11:41 +0800, Yang Yujie wrote:
> Thanks for the testing!
>
> This error seems to be difficult to reproduce since it is a makefile
> dependency
> problem. I think appending loongarch-multilib.h to $(GTM_H) instead of
> $(TM_H)
> could help.
FWIW such issues are easier to
This patch enables almost full coverage vectorization tests for RVV, except
these
following tests (not enabled yet):
1. Will enable soon:
check_effective_target_vect_call_lrint
check_effective_target_vect_call_btrunc
check_effective_target_vect_call_btruncf
check_effective_target_vect_call_ceil
Hello All:
This patch add new pass to replace contiguous addresses vector load lxv with
mma instruction
lxvp.
Bootstrapped and regtested with powepc64-linux-gnu.
Thanks & Regards
Ajit
rs6000: Add new pass for replacement of contiguous lxv with lxvp.
New pass to replace contiguous addresses
OK
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-10-07 14:25
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Add more run test for FP rounding autovec
From: Pan Li
For _Float16 types, add run test for:
* ceil
* floor
* nearbyint
* rint
*
Hi all,
Sorry for the patch revision delay since just back from the vacation.
I have slightly revised this patch for the __EVEX256__ request with the code:
diff --git a/gcc/config/i386/i386-c.cc b/gcc/config/i386/i386-c.cc
index 47768fa0940..9c44bd7fb63 100644
--- a/gcc/config/i386/i386-c.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110368
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8
1 - 100 of 101 matches
Mail list logo
