On Sep 21, 2023, Alexandre Oliva wrote:
> On Sep 15, 2023, Alexandre Oliva wrote:
>> On Jun 22, 2023, Alexandre Oliva wrote:
>>> On Jun 2, 2023, Alexandre Oliva wrote:
Introduce -finline-stringops
>>> Ping? https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620472.html
>> Ping?
>
On 9/22/23 17:18, Maciej W. Rozycki wrote:
In non-multilib installations system headers may not be available for
compilation options using a non-default model, causing build errors such
as:
In file included from .../include/features.h:527,
from .../include/assert.h:35,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111543
--- Comment #2 from Andrew Pinski ---
/* (X & ~Y) & Y -> 0 */
(simplify
(bit_and:c (bit_and @0 @1) @2)
(with { bool wascmp; }
(if (bitwise_inverted_equal_p (@0, @2, wascmp)
|| bitwise_inverted_equal_p (@1, @2, wascmp))
{ wascmp ?
Confirm it is a latent bug already existed long time ago but we were lucky that
we didn't trigger this issue before.
This patch didn't involve a new bug.
Li pan from intel will send a patch fix it soon.
Thanks for report.
juzhe.zh...@rivai.ai
From: Edwin Lu
Date: 2023-09-23 06:38
To:
gcc/ChangeLog:
* config/riscv/autovec-opt.md: Add VLS modes for conditional ABS/SQRT.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/cond_abs-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/cond_sqrt-1.c: New test.
---
gcc/config/riscv/autovec-opt.md
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-23 09:19
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v3] RISC-V: Suport FP floor auto-vectorization
From: Pan Li
This patch would like to support auto-vectorization for the
floor API in math.h.
From: Pan Li
This patch would like to support auto-vectorization for the
floor API in math.h. It depends on the -ffast-math option.
When we would like to call floor/floorf like v2 = floor (v1), we will
convert it into below insns (reference the implementation of llvm).
* vfcvt.x.f v3, v1, RDN
Committed, thanks Juzhe.
Pan
From: 钟居哲
Sent: Saturday, September 23, 2023 9:07 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Remove FP run test for ceil.
Ok
Ok
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-23 09:06
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Remove FP run test for ceil.
From: Pan Li
FP16 is not well reconciled when linking.
gcc/testsuite/ChangeLog:
*
From: Pan Li
FP16 is not well reconciled when linking.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c: Remove.
Signed-off-by: Pan Li
---
.../riscv/rvv/autovec/unop/math-ceil-run-0.c | 39 ---
1 file changed, 39 deletions(-)
delete
So when diamond bb support was added to minmax_replacement in
r13-1950-g9bb19e143cfe,
the code was not expecting the alt_middle_bb not to exist if it was empty (for
threeway_p).
So when factor_out_conditional_conversion was used to factor out conversions,
it turns out
the assumption for
LGTM. But I think you should remove FP16 run tests.
So plz send a patch first remove FP16 run test of CEIL first.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-23 08:40
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Suport FP floor
From: Pan Li
This patch would like to support auto-vectorization for the
floor API in math.h. It depends on the -ffast-math option.
When we would like to call floor/floorf like v2 = floor (v1), we will
convert it into below insns (reference the implementation of llvm).
* vfcvt.x.f v3, v1, RDN
Now that bootstrap has finished, I have gotten regressions in the
following libstdc++ tests:
Running libstdc++:libstdc++-dg/conformance.exp ...
FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++23 (test for excess errors)
FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++26 (test for excess
Hi Juzhe,
I'm seeing a few new regressions from this patch on glibc rv32gcv.
I filed a bugzilla for the ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111546
Patrick
On 9/19/23 19:24, Juzhe-Zhong wrote:
This patch extends 'VWEXT' iterator so that we will support
integer extension/integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111545
--- Comment #3 from Edwin Lu ---
(In reply to JuzheZhong from comment #2)
> Could you give me the code to reproduce this issue?
Testcase file:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111546
--- Comment #1 from Patrick O'Neill ---
Also checked to still be present on trunk at hash r14-4231-gfd35d72a3dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111546
Bug ID: 111546
Summary: [14 Regression] ICE: gfortran.dg/overload_5.f90:53:2:
internal compiler error: in emit_move_insn, at
expr.cc:4219 since r14-4163-gbea89f78f2f
In non-multilib installations system headers may not be available for
compilation options using a non-default model, causing build errors such
as:
In file included from .../include/features.h:527,
from .../include/assert.h:35,
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111545
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
Hi Juzhe,
I was testing this patch and found it introduced a gfortran regression
in gfortran.dg/host_assoc_function_7.f90. More info here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111545
Edwin
On 9/20/2023 7:17 PM, Juzhe-Zhong wrote:
Support INT <-> FP VLS auto-vectorization patterns.
Snapshot gcc-12-20230922 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20230922/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111545
--- Comment #1 from Edwin Lu ---
Created attachment 55971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55971=edit
objdump of executable on good hash
Here is the objdump of the executable created using the good hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111545
Bug ID: 111545
Summary: [14 Regression] RISC-V
gfortran.dg/host_assoc_function_7.f09 Illegal
instruction error
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #11 from seurer at gcc dot gnu.org ---
From, the original I cut it down to this. Compiles OK with r14-4110, error
with r14-4111.
bad3.c: In member function 'NameIdPoolEnumerator&
NameIdPoolEnumerator::operator=(const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Actually this is the reduced testcase:
> ```
> struct bs
> {
> int * const t;
> };
> template
> struct a
> {
> int * const t;
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #8)
> https://github.com/apache/xerces-c/commit/
> bc3189892c2e700bd3298b77cd8a523080fa74bb
https://issues.apache.org/jira/projects/XERCESC/issues/XERCESC-1259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #8 from Sam James ---
https://github.com/apache/xerces-c/commit/bc3189892c2e700bd3298b77cd8a523080fa74bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #7 from Andrew Pinski ---
Actually this is the reduced testcase:
```
struct bs
{
int * const t;
};
template
struct a
{
int * const t;
a (const a&, int *const tt, const a *c, const bs&);
};
template
a &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #6 from Andrew Pinski ---
MemoryManager* const fMemoryManager;
So reduced:
```
template
struct a
{
int * const t;
void f();
};
template
void a::f()
{
t = 0;
}
```
Yes this is invalid code that GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #5 from Sam James ---
Created attachment 55969
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55969=edit
DGXMLScanner.ii
Reproduced w/ DGXMLScanner.ii
1. wget
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #4 from Sam James ---
Am trying to build xerces-c-2.5.0 but am struggling for other reasons due to
its age...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
Andrew Pinski changed:
What|Removed |Added
Component|other |c++
Keywords|rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #2 from seurer at gcc dot gnu.org ---
I can't attach the whole thing but I am working on cutting it down.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497
--- Comment #4 from Vladimir Makarov ---
I've reproduced the bug. The problem is in combination of splitting pseudo live
range and sharing rtl.
I hope to fix this on the next Monday or Tuesday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95710
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
Dear all,
the attached simple and obvious patch fixes several NULL pointer
dereferences that are encountered for a duplicate declaration of
a class variable. Another one from Gerhard's torture tests...
Regtested on x86_64-pc-linux-gnu.
I intend to commit within 24h unless there are comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427
--- Comment #1 from Vladimir Makarov ---
Unfortunately, I did not manage to reproduce the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #1 from Sam James ---
Maybe attach a preprocessed version for completeness?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
Bug ID: 111544
Summary: [14 regression] assignment of read-only location after
r14-4111-g6e92a6a2a72d3b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111543
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111543
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111542
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|[11/12/13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111542
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111543
Bug ID: 111543
Summary: `(a & b) & ~a` could be optimized before reassociation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111542
Bug ID: 111542
Summary: [11/12/13/14 Regression]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111541
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111541
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111538
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
--- Comment #15 from Andrew Pinski ---
*** Bug 111540 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111540
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #6)
> The cause I guess, is just a bad fall-through in the arm/sync.md.
Or rather, optabs.cc:expand_atomic_test_and_set, which makes this issue
somewhat
On Fri, Sep 22, 2023 at 6:01 AM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> We were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading to
> problems with substitution of any wrapped expressions.
>
> Let's also not tell users that lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108026
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111541
Bug ID: 111541
Summary: missing optimization x & ~c | (y | c) -> x | (y | c)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111540
--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55968=edit
The compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111540
Bug ID: 111540
Summary: Segmentation fault with '-O3 -fno-dce -fno-tree-dce
-fno-tree-sra'
Product: gcc
Version: 11.4.1
Status: UNCONFIRMED
Severity: normal
On 9/22/23 06:56, Hongyu Wang wrote:
Like base_reg_class, INDEX_REG_CLASS also does not support backend insn.
Add index_reg_class with insn argument for lra/reload usage.
gcc/ChangeLog:
* addresses.h (index_reg_class): New wrapper function like
base_reg_class.
*
On 9/22/23 06:56, Hongyu Wang wrote:
From: Kong Lingling
Current reload infrastructure does not support selective base_reg_class
for backend insn. Add new macros with insn parameters to base_reg_class
for lra/reload usage.
gcc/ChangeLog:
* addresses.h (base_reg_class): Add insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111504
--- Comment #3 from Xiang Gao ---
Cross posted at: https://github.com/llvm/llvm-project/issues/67056
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111531
--- Comment #4 from Paul Haile ---
The only time I could imagine allowing type mismatch would be in allowing the
function pointer to allow void * in type erased contexts.
e.g.
typedef void (*b_fptr)(void *);
On Fri, Sep 22, 2023 at 02:21:15PM +0100, Jason Merrill wrote:
> On 9/21/23 09:41, Nathaniel Shead wrote:
> > I've updated the error messages, and also fixed another bug I found
> > while retesting (value-initialised unions weren't considered to have any
> > active member yet).
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #56 from Jürgen Reuter ---
What do we do now? We know the offending commit, and the commit that fixed (or
"fixed") it. Closing? Do we understand what happened here, so why it went wrong
and why it got fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111539
Bug ID: 111539
Summary: __is_range_adaptor_closure_fn is too loosely defined
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:fd35d72a3dcd5ba14d81a1890236acd0145497e1
commit r14-4231-gfd35d72a3dcd5ba14d81a1890236acd0145497e1
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As Jakub pointed out, the real problem here is that in a partial
substitution we're forgetting the conversion to the type of the non-type
template argument, because maybe_convert_nontype_argument doesn't do
anything with value-dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111538
Bug ID: 111538
Summary: Unhelpful message when returning initializer list when
deducing the return type
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The change of active member being non-constant (before C++20) results in a
CONSTRUCTOR with a null value for the first field, don't crash.
gcc/cp/ChangeLog:
* constexpr.cc (free_constructor): Handle null ce->value.
On 9/21/23 09:41, Nathaniel Shead wrote:
I've updated the error messages, and also fixed another bug I found
while retesting (value-initialised unions weren't considered to have any
active member yet).
Bootstrapped and regtested on x86_64-pc-linux-gnu.
-- >8 --
This patch adds checks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111529
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:9c62af101e11e1cce573c2b3d2e18b403412dbc8
commit r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading to
problems with substitution of any wrapped expressions.
Let's also not tell users that lambda templates are available in C++14.
PR c++/111529
Hello,
under which license is libgcc/config/sparc/lb1spc.S? The header says:
/* This is an assembly language implementation of mulsi3, divsi3, and modsi3
for the sparc processor.
These routines are derived from the SPARC Architecture Manual,
version 8,
slightly edited to match the
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, September 22, 2023 8:19 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v2] RISC-V: Refine the code gen for ceil auto vectorization.
LGTM.
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-22 20:16
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Refine the code gen for ceil auto vectorization.
From: Pan Li
We vectorized below ceil code already.
void
test_ceil (float *out,
From: Pan Li
We vectorized below ceil code already.
void
test_ceil (float *out, float *in, int count)
{
for (unsigned i = 0; i < count; i++)
out[i] = __builtin_ceilf (in[i]);
}
Before this patch:
vfmv.v.xv4,fa0 // can be removed
vfabs.v v0,v1
vmv1r.v v2,v1 // can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111531
--- Comment #3 from Paul Haile ---
Fair enough definitely could be intentional. However, In this example
renaming
typedef void (*b_fptr)(B *);
to
typedef void (*b_fptr)(A *);
gets rid of the error.
It seems restricting the binding such
Sure thing, will send V2 for this.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, September 22, 2023 7:26 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Refine the code gen for ceil auto vectorization.
I prefer change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710
--- Comment #8 from Ivan Sorokin ---
> How often these show up, I have no idea.
Perhaps I should have written this in the original message.
The original expression "(x | c) & ~(y | c)" is obviously a reduced version of
what happens in real
On 9/21/23 07:28, waffl3x wrote:
This seems like a reasonable place for it since 'this' is supposed to
precede the decl-specifiers, and since we are parsing initial attributes
here rather than in the caller. You will want to give an error if
found_decl_spec is set. And elsewhere complain about
I prefer change expand_vec_copysign into emit_vec_copysign。
Likewise， emit_fabs. ...etc.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-22 19:19
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Refine the code gen for ceil auto vectorization.
From: Pan Li
We vectorized below ceil code already.
void
test_ceil (float *out, float *in, int count)
{
for (unsigned i = 0; i < count; i++)
out[i] = __builtin_ceilf (in[i]);
}
Before this patch:
vfmv.v.xv4,fa0 // can be removed
vfabs.v v0,v1
vmv1r.v v2,v1 // can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710
--- Comment #7 from Ivan Sorokin ---
(In reply to Andrew Pinski from comment #6)
> Fixed.
Thank you!
From: Kong Lingling
These legacy insn in opcode map0/1 only support GPR16,
and do not have vex/evex counterpart, directly adjust constraints and
add gpr32 attr to patterns.
insn list:
1. xsave/xsave64, xrstor/xrstor64
2. xsaves/xsaves64, xrstors/xrstors64
3. xsavec/xsavec64
4.
From: Kong Lingling
These vex insn may have legacy counterpart that could support EGPR,
but they do not have evex counterpart. Split out its vex part from
patterns and set the vex part to non-EGPR supported by adjusting
constraints and attr_gpr32.
insn list:
1. vmovmskpd/vmovmskps
2. vpmovmskb
For vector move insns like vmovdqa/vmovdqu, their evex counterparts
requrire explicit suffix 64/32/16/8. The usage of these instruction
are prohibited under AVX10_1 or AVX512F, so for we select
vmovaps/vmovups for vector load/store insns that contains EGPR if
ther is no AVX512VL, and keep the
From: Kong Lingling
These legacy insns in opcode map2/3 have vex but no evex
counterpart, disable EGPR for them by adjusting alternatives and
attr_gpr32.
insn list:
1. phaddw/vphaddw, phaddd/vphaddd, phaddsw/vphaddsw
2. phsubw/vphsubw, phsubd/vphsubd, phsubsw/vphsubsw
3. psignb/vpsginb,
From: Kong Lingling
Add backend helper functions to verify if a rtx_insn can adopt EGPR to
its base/index reg of memory operand. The verification rule goes like
1. For asm insn, enable/disable EGPR by ix86_apx_inline_asm_use_gpr32.
2. Disable EGPR for unrecognized insn.
3. If
From: Kong Lingling
The APX enabled hardware should also be AVX10 enabled, thus for map2/3 insns
with evex counterpart, we assume auto promotion to EGPR under APX_F if the
insn uses GPR32. So for below insns, we disabled EGPR usage for their sse
mnenomics, while allowing egpr generation of their
From: Kong Lingling
Extend GENERAL_REGS with extra r16-r31 registers like REX registers,
named as REX2 registers. They will only be enabled under
TARGET_APX_EGPR.
gcc/ChangeLog:
* config/i386/i386-protos.h (x86_extended_rex2reg_mentioned_p):
New function prototype.
*
From: Kong Lingling
Disable EGPR usage for below legacy insns in opcode map2/3 that have vex
but no evex counterpart.
insn list:
1. phminposuw/vphminposuw
2. ptest/vptest
3. roundps/vroundps, roundpd/vroundpd,
roundss/vroundss, roundsd/vroundsd
4. pcmpestri/vpcmpestri, pcmpestrm/vpcmpestrm
From: Kong Lingling
Current reload infrastructure does not support selective base_reg_class
for backend insn. Add new macros with insn parameters to base_reg_class
for lra/reload usage.
gcc/ChangeLog:
* addresses.h (base_reg_class): Add insn argument and new macro
From: Kong Lingling
Add -mapx-features= enumeration to separate subfeatures of APX_F.
-mapxf is treated same as previous ISA flag, while it sets
-mapx-features=apx_all that enables all subfeatures.
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (XSTATE_APX_F): New macro.
From: Kong Lingling
In inline asm, we do not know if the insn can use EGPR, so disable EGPR
usage by default via mapping the common reg/mem constraint to non-EGPR
constraints.
The full list of mapping goes like
"g" -> "jrjmi"
"r" -> "jr"
"m" -> "jm"
"<" -> "j<"
">" -> "j>"
"o" ->
From: Kong Lingling
For APX, as we extended the GENERAL_REG_CLASS, new constraints are
needed to restrict insns that cannot adopt EGPR either in its reg or
memory operands. We added a series of constraints for general/backend
ones that related to GPR usage. All of them are prefixed with "j" to
Like base_reg_class, INDEX_REG_CLASS also does not support backend insn.
Add index_reg_class with insn argument for lra/reload usage.
gcc/ChangeLog:
* addresses.h (index_reg_class): New wrapper function like
base_reg_class.
* doc/tm.texi: Document INSN_INDEX_REG_CLASS.
Hi,
This is a v2 patch for APX support which follows-up previous discussion in
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628904.html
As discussed in previous thread, the inverse approach to extend base/index reg
support with new memory constraints requrires much more effort both in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111471
--- Comment #3 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:b7d2bb488efbdeab42cf047d92cf0f9acdc1c5ec
commit r13-7830-gb7d2bb488efbdeab42cf047d92cf0f9acdc1c5ec
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
Bug ID: 111537
Summary: ICE: in set_cell_span, at text-art/table.cc:148 with D
front-end and -fanalyzer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:1fea14def849dd38b098b0e2d54e64801f9c1f43
commit r14-4225-g1fea14def849dd38b098b0e2d54e64801f9c1f43
Author: Patrick Palka
Date:
1 - 100 of 124 matches
Mail list logo
