The following properly guards the simplifications that move
operations into VEC_CONDs, in particular when that changes the
type constraints on this operation.
This needed a genmatch fix which was recording spurious implicit fors
when tcc_comparison is used in a C expression.
Bootstrapped and test
> validate_subreg is a can of worms, can you try to fix the issue in DSE
> by avoiding to form the subreg in the first place?
Sure thing, will have a try in v2.
Pan
-Original Message-
From: Richard Biener
Sent: Monday, February 26, 2024 3:38 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org
On Mon, Feb 26, 2024 at 4:26 AM wrote:
>
> From: Pan Li
>
> We allowed vector type for get_stored_val when read is less than or
> equal to store in previous. Unfortunately, we missed to adjust the
> validate_subreg part accordingly. For vector type, we don't need to
> restrict the mode size is
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 1dbe1115da4..6303d82d959 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11521,7 +11521,8 @@ vectorizable_load (vec_info *vinfo,
- (vec_num * j + i) * nunits);
Hi!
These 2 patterns are incorrect on floating point, or for -fwrapv, or
for -ftrapv, or the first one for unsigned types (the second one is
mathematically correct, but we ought to just fold that to 0 instead).
So, the following patch properly guards this.
I think we don't need && !TYPE_OVERFLOW
Hi!
In the following testcase we infinitely recurse during BIT_IOR_EXPR
reassociation.
One operand is (unsigned _BitInt(31)) a << 4 and another operand
2147483647 >> 1 | 80 where both the right shift and the | 80
trees have TREE_CONSTANT set, but weren't folded because of delayed
folding, where so
On Fri, Feb 23, 2024 at 3:48 AM Palmer Dabbelt wrote:
>
> On Wed, 21 Feb 2024 16:02:50 PST (-0800), Kito Cheng wrote:
> > Palmer Dabbelt 於 2024年2月22日 週四 07:42 寫道：
> >
> >> On Wed, 21 Feb 2024 15:34:32 PST (-0800), Kito Cheng wrote:
> >> > LGTM for the patch
> >> >
> >> > Li, Pan2 於 2024年2月21日 週三
Hi!
In my r14-8214 changes I apparently forgot one \n at the end of an instruction.
The corresponding AT&T line looks like:
"1:\tcall\t*%s@GOTPCREL(%%rip)\n"
but the Intel variant was
"1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]"
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
com
Got it, we need to combine that together up to point.
Thanks Tamar for the explanation. Help a lot and will have a try in v3.
Pan
-Original Message-
From: Tamar Christina
Sent: Sunday, February 25, 2024 5:02 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzh
Add proper hints for implicit declaration of strerror.
The results could be confusing depending on the other included headers.
These example messages are from compiling a trivial program to print the
string for an errno value. It only includes stdio.h (cstdio for C++).
Before:
$ /tmp/gcc-master/b
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
There is no immediate value splatting instruction in powerpc. Currently that
needs to be stored in a register or memory. For addressing this I have updated
the predicate for the second operand in vsx_splat to sp
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
PR110040 exposes an issue concerning moves from vector registers to GPRs.
There are two moves, one for upper 64 bits and the other for the lower
64 bits. In the problematic test case, we are only interested in
On Mon, Feb 26, 2024 at 11:42 AM Li, Pan2 wrote:
>
> > Be Careful, It may regresses some other backend.
>
> Thanks Hongtao, how about take INNER_MODE here for regsize. Currently it will
> be the whole vector register when comparation.
>
> poly_uint64 regsize = REGMODE_NATURAL_SIZE (imode);
>
> Pa
Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.
gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_load_lanes,
vec_mask_len_store_lanes):
Predicate with TARGE
The specification of crc/crcc instructions is clear that the output is
sign-extended to GRLEN. Add a define_insn to tell the compiler this
fact and allow it to remove the unneeded sign extension on crc/crcc
output. As crc/crcc instructions are usually used in a tight loop,
this should produce a s
Introduce an iterator for UNSPEC_CRC and UNSPEC_CRCC to make the next
change easier.
gcc/ChangeLog:
* config/loongarch/loongarch.md (CRC): New define_int_iterator.
(crc): New define_int_attr.
(loongarch_crc_w__w, loongarch_crcc_w__w): Unify
into ...
(loonga
On Sun, Feb 25, 2024 at 7:03 PM Hongtao Liu wrote:
>
> On Mon, Feb 26, 2024 at 10:37 AM H.J. Lu wrote:
> >
> > On Sun, Feb 25, 2024 at 6:03 PM Hongtao Liu wrote:
> > >
> > > On Mon, Feb 26, 2024 at 5:11 AM H.J. Lu wrote:
> > > >
> > > > ldtilecfg and sttilecfg take a 512-byte memory block. Wit
> Be Careful, It may regresses some other backend.
Thanks Hongtao, how about take INNER_MODE here for regsize. Currently it will
be the whole vector register when comparation.
poly_uint64 regsize = REGMODE_NATURAL_SIZE (imode);
Pan
-Original Message-
From: Hongtao Liu
Sent: Monday, F
On Mon, Feb 26, 2024 at 11:26 AM wrote:
>
> From: Pan Li
>
> We allowed vector type for get_stored_val when read is less than or
> equal to store in previous. Unfortunately, we missed to adjust the
> validate_subreg part accordingly. For vector type, we don't need to
> restrict the mode size is
Hi,
This patch tries to fix a potential problem which is raised by the patch
for PR111267. The volatile asm operand tries to be propagated to a single
set insn with the patch for PR111267. It has potential risk as the behavior
is wrong. Currently set_src_cost comparison can reject such propagatio
From: Pan Li
We allowed vector type for get_stored_val when read is less than or
equal to store in previous. Unfortunately, we missed to adjust the
validate_subreg part accordingly. For vector type, we don't need to
restrict the mode size is greater than the vector register size.
Thus, for exa
On Mon, Feb 26, 2024 at 10:37 AM H.J. Lu wrote:
>
> On Sun, Feb 25, 2024 at 6:03 PM Hongtao Liu wrote:
> >
> > On Mon, Feb 26, 2024 at 5:11 AM H.J. Lu wrote:
> > >
> > > ldtilecfg and sttilecfg take a 512-byte memory block. With
> > > _tile_loadconfig implemented as
> > >
> > > extern __inline
On Sun, Feb 25, 2024 at 6:03 PM Hongtao Liu wrote:
>
> On Mon, Feb 26, 2024 at 5:11 AM H.J. Lu wrote:
> >
> > ldtilecfg and sttilecfg take a 512-byte memory block. With
> > _tile_loadconfig implemented as
> >
> > extern __inline void
> > __attribute__((__gnu_inline__, __always_inline__, __artifi
Hi,
This patch enables overlap memory store for block memory clear which
saves the number of store instructions. The expander calls
widest_fixed_size_mode_for_block_clear to get the mode for looped block
clear and calls widest_fixed_size_mode_for_block_clear to get the mode
for last overlapped cl
> Date: Fri, 16 Feb 2024 11:16:22 +0100
> From: Jakub Jelinek
> Given the recent discussions on IRC started with Andrew P. mentioning that
> an asm goto outputs test should have { target lra } and the lra effective
> target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
> we
On Mon, Feb 26, 2024 at 5:11 AM H.J. Lu wrote:
>
> ldtilecfg and sttilecfg take a 512-byte memory block. With
> _tile_loadconfig implemented as
>
> extern __inline void
> __attribute__((__gnu_inline__, __always_inline__, __artificial__))
> _tile_loadconfig (const void *__config)
> {
> __asm__ v
On Wed, Feb 7, 2024 at 4:23 AM Matteo Italia wrote:
>
> Il 06/02/24 10:17, Jonathan Yong ha scritto:
> > On 2/6/24 05:31, NightStrike wrote:
> >> On Mon, Feb 5, 2024, 06:53 Matteo Italia wrote:
> >>
> >>> Il 31/01/24 04:24, LIU Hao ha scritto:
> 在 2024-01-31 08:08, Jonathan Yong 写道:
> >
On Wed, Feb 21, 2024 at 12:48 PM Evgeny Karpov
wrote:
>
> Hello,
>
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three plann
Thanks for fixing this! Didn't notice that the pointer conversion can
cause this issue...
Was it possible to use local array like
char a[64] = (char *)p
__asm__ volatile ("ldtilecfg\t%X0" :: "m" (a)));
If not, for the two patterns we can use "m" instead of "jm" as APX
supports EGPR extension for
On 2/25/24 12:26 PM, Harald Anlauf wrote:
Dear all,
the attached simple patch fixes an issue where we evaluated
polymorphic functions twice in assignments: once for the _data
component, and once for the _vptr. Using save_expr prevents
the double evaluation.
Regtested on x86_64-pc-linux-gnu. O
Hi,
This patch merges the D front-end and runtime library with upstream dmd
ceff48bf7d, and the standard library with phobos dcbfbd43a.
D front-end changes:
- Import latest fixes from dmd v2.107.1-rc.1.
D runtime changes:
- Import latest fixes from druntime v2.107.1-rc.1.
On 2/25/24 12:34 PM, Harald Anlauf wrote:
Hi Jerry,
On 2/22/24 20:11, Jerry D wrote:
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable manually
On 23/2/24 17:54, Andrew Pinski wrote:
There is arm64ec ABI defined for aarch64 windows which is a different
ABI from the standard windows aarch64 ABI, though I am not sure if it
supported with the patches here.
It is documented at
https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-c
ix86_set_func_type checks noreturn attribute to avoid incompatible
attribute error in LTO1 on interrupt functions. Since TREE_THIS_VOLATILE
is set also for _Noreturn without noreturn attribute, check interrupt
attribute for interrupt functions instead.
gcc/
PR target/114097
* con
On 22/2/24 11:11, Richard Earnshaw (lists) wrote:
Most of the free world has left COFF behind since several decades, so I won't
comment on that. YMMV.
This isn't helpful. Windows platforms use (a derivative of) COFF, so that's
what the tools need to use when targetting that platform.
Also,
ldtilecfg and sttilecfg take a 512-byte memory block. With
_tile_loadconfig implemented as
extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_tile_loadconfig (const void *__config)
{
__asm__ volatile ("ldtilecfg\t%X0" :: "m" (*((const void **)__config)));
}
Dear all,
just like last year, I would like to commit the changes that took place
over at GNAT for GCC v14. The patch is attached to the email. Hopefully
it is good enough to just be added to master. If you see something wrong
or if you would like to add anything to it, feel free :) Feedback is
Harald,
Thank you for reviewing my code. I've been doing research and debugging to
investigate the error thrown by Intel and NAG for the deferred parameter in
the dummy variable declaration. I found where the problem was and added the
fix as part of my patch. I've attached the patch as a file, whi
Hi Jerry,
On 2/22/24 20:11, Jerry D wrote:
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable manually before
returning to the parent READ.
the
Dear all,
the attached simple patch fixes an issue where we evaluated
polymorphic functions twice in assignments: once for the _data
component, and once for the _vptr. Using save_expr prevents
the double evaluation.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
And a backport to 13-branch
Hi Mike, Joseph,
On Sun, Feb 25, 2024 at 10:10:09AM -0800, Mike Stump wrote:
> On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote:
> >
> > Warn about the following:
> >
> >char s[3] = "foo";
>
> No ObjC specific impact here, so no need for ObjC review.
>
> As a member of the peanut gall
The target will be adjusted to aarch64-*-mingw* in config.gcc. This
change will ensure consistency with the target in libgcc.
Regards,
Evgeny
-Original Message-
Thursday, February 22, 2024 2:36 PM
Richard Earnshaw (lists) wrote:
>
+aarch64-*-mingw*)
This doesn't match the glob pattern
Thank you for the historical information regarding the introduction
of the features. I can confirm that removing the HAVE_GAS_WEAK check
and setting HAVE_GAS_ALIGNED_COMM to 1 by default works well.
These changes will be included in v2.
Regards,
Evgeny
-Original Message-
Thursday, Febru
On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote:
>
> Warn about the following:
>
>char s[3] = "foo";
No ObjC specific impact here, so no need for ObjC review.
As a member of the peanut gallery, I like the patch.
Joseph, this is been submitted 5 times over the past year. Any thoughts
On Sun, Feb 25, 2024 at 8:54 AM Uros Bizjak wrote:
>
> On Sun, Feb 25, 2024 at 5:01 PM H.J. Lu wrote:
> >
> > ix86_set_func_type checks noreturn attribute to avoid incompatible
> > attribute error in LTO1 on interrupt functions. Since TREE_THIS_VOLATILE
> > is set also for _Noreturn without nore
On Sun, Feb 25, 2024 at 5:01 PM H.J. Lu wrote:
>
> ix86_set_func_type checks noreturn attribute to avoid incompatible
> attribute error in LTO1 on interrupt functions. Since TREE_THIS_VOLATILE
> is set also for _Noreturn without noreturn attribute, check interrupt
> attribute for interrupt functi
ix86_set_func_type checks noreturn attribute to avoid incompatible
attribute error in LTO1 on interrupt functions. Since TREE_THIS_VOLATILE
is set also for _Noreturn without noreturn attribute, check interrupt
attribute for interrupt functions instead.
gcc/
PR target/114097
* con
Hi All,
The testcase shows an interesting case where we have multiple loops sharing a
live value and have an early exit that go to the same location. The additional
complication is that on x86_64 with -mavx we seem to also do prologue peeling
on the loops.
We correctly identify which BB we need
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-14.1-b20240218.sv.po'
Hi Pan,
> From: Pan Li
>
> Hi Richard & Tamar,
>
> Try the DEF_INTERNAL_INT_EXT_FN as your suggestion. By mapping
> us_plus$a3 to the RTL representation (us_plus:m x y) in optabs.def.
> And then expand_US_PLUS in internal-fn.cc. Not very sure if my
> understanding is correct for DEF_INTERNAL_
50 matches
Mail list logo
