Hi,
For PR96866, when printing asm code for modifier "%a", an addressable
operand is required. While the constraint "X" allow any kind of
operand even which is hard to get the address directly. e.g. extern
symbol whose address is in TOC.
An error message would be reported to indicate the invalid
在 2024/07/16 8:28, Jeff Law 写道:
IIRC these fails are dependent upon whether or not the statements turn
into vector stores or not.
So to remove the xfail don't you have to know if vector is
enabled/disabled?
I am not sure, I tried to enable with RVV, but it still pass the test:
https://go
On 7/15/24 9:19 PM, Kewen.Lin wrote:
> on 2024/7/16 04:30, Peter Bergner wrote:
>> On 7/11/24 1:24 AM, Kewen.Lin wrote:
>>> Sorry for the confusion, I meant for most target options when we emit some
>>> error
>>> message meanwhile we also unset it, such as:
>>>
>>> if (TARGET_CRYPTO && !TARGET_A
Hi,
Shall I push this if no objection?
Thanks,
Di Zhao
> -Original Message-
> From: Di Zhao OS
> Sent: Tuesday, June 18, 2024 9:52 AM
> To: Jeff Law
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PING][PATCH] [tree-optimization/110279] fix testcase pr110279-1.c
>
> This is OK for trunk?
>
On Mon, Jul 15, 2024 at 06:57:57PM -0400, Jason Merrill wrote:
> On 7/8/24 12:56 PM, Andi Kleen wrote:
> > diff --git a/gcc/testsuite/g++.dg/musttail10.C
> > b/gcc/testsuite/g++.dg/musttail10.C
> > new file mode 100644
> > index ..9b7043b8a306
> > --- /dev/null
> > +++ b/gcc/testsuite/
On Tue, Jul 16, 2024 at 1:09 AM Christoph Müllner
wrote:
>
> On Mon, Jul 15, 2024 at 11:10 AM Kito Cheng wrote:
> >
> > LGTM, and could you backport this to the GCC 14 branch as well?
>
> Rebased, retested (multilib), fixed an issue related to Zca/Zcd and pushed.
>
> Should the GCC 14 backport be
Bootstrapped andrregtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here we're neglecting to emit a -Wunused-value for eligible ! operator
expressions, and in turn for != operator expressions that are rewritten
as !(x == y), only because we don't call warn_if_unused_value on
Hi Peter,
on 2024/7/16 06:07, Peter Bergner wrote:
> Hi Kewen,
>
> Here's the updated patch per your review comments, minus your suggestion
> to disable the ROP mask which I mentioned isn't needed in my other reply.
>
> This passed bootstrap and regtesting with no regressions on powerpc64le-linu
Hi Haochen,
on 2024/7/15 10:14, HAO CHEN GUI wrote:
> Hi,
> This patch removes FLOAT128_IEEE_P guard when the mode of pattern
> is IEEE128 and FLOAT128_IBM_P when the mode of pattern is IBM128.
> The mode iterators already do the checking. So they're redundant.
>
> Bootstrapped and tested on
Hi Haochen,
on 2024/7/15 10:10, HAO CHEN GUI wrote:
> Hi,
> This patch adds TARGET_FLOAT128_HW into pattern conditions for quad-
> precision insns. Some qp patterns are guarded by TARGET_P9_VECTOR
> originally, so replace it with "TARGET_FLOAT128_HW".
>
> For test case float128-cmp2-runnable.
on 2024/7/16 04:30, Peter Bergner wrote:
> On 7/11/24 1:24 AM, Kewen.Lin wrote:
>> Sorry for the confusion, I meant for most target options when we emit some
>> error
>> message meanwhile we also unset it, such as:
>>
>> if (TARGET_CRYPTO && !TARGET_ALTIVEC)
>> {
>> if (rs6000_isa_flag
On Mon, Jul 15, 2024 at 3:17 PM Max Filippov wrote:
>
> On Mon, Jul 15, 2024 at 10:21:18AM -0700, Ian Lance Taylor wrote:
> > Can you see whether this patch works for FDPIC support? This is based
> > on your patch but has various changes. Thanks.
>
> Yes, it is working.
Thanks for testing. Com
On 7/15/24 6:15 PM, Jiawei wrote:
Update warning test info for RISC-V target, compared on godbolt:
https://godbolt.org/z/Mexd3dfcc
gcc/testsuite/ChangeLog:
* gcc.dg/Wstringop-overflow-47.c: Remove xfail target.
IIRC these fails are dependent upon whether or not the statements turn
So as I've noted before I believe the control flow in ext-dce.cc is
horribly messy. While investigating a fix for 115877 I came across
another problem related to control flow handling.
Specifically, if we have an binary op which implies the 2nd operand is
fully live, then we'd actually fail t
Update warning test info for RISC-V target, compared on godbolt:
https://godbolt.org/z/Mexd3dfcc
gcc/testsuite/ChangeLog:
* gcc.dg/Wstringop-overflow-47.c: Remove xfail target.
---
gcc/testsuite/gcc.dg/Wstringop-overflow-47.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
On 7/15/24 5:43 PM, Carl Love wrote:
> -/* { dg-do run } */
> +/* { dg-do run { target { lp64 } && { int128 } } } */
Why isn't this just:
/* { dg-do run { target int128 } } */
??? The int128 test should disable this on 32-bit systems just fine.
Peter
My change to fix a ubsan issue broke handling propagation of the
carry/sign bit down through a right shift. Thanks to Andreas for the
analysis and proposed fix and Sergei for the testcase.
Bootstrapped and regression tested on x86-64. Pushing to the trunk.
Jeff
commit 94b21f13763638f64e
On 7/8/24 12:56 PM, Andi Kleen wrote:
diff --git a/gcc/testsuite/g++.dg/musttail10.C
b/gcc/testsuite/g++.dg/musttail10.C
new file mode 100644
index ..9b7043b8a306
--- /dev/null
+++ b/gcc/testsuite/g++.dg/musttail10.C
@@ -0,0 +1,34 @@
+/* { dg-do compile { target { tail_call } } } */
GCC maintainers:
The tests:
tests builtins-10-runnable.c
tests builtins-10.c
vec_perm-runnable-i128.c
generate the following errors when run on a 32-bit BE Power system with
GCC configured with multilib enabled.
FAIL: gcc.target/powerpc/builtins-10-runnable.c (test for excess errors)
F
On 7/12/24 1:03 PM, Iain Sandoe wrote:
HI Jason,
On 9 Jul 2024, at 22:55, Jason Merrill wrote:
On 7/9/24 11:52 AM, Iain Sandoe wrote:
Hi Folks
On 8 Jul 2024, at 20:57, Jason Merrill wrote:
On 7/8/24 3:37 PM, Iain Sandoe wrote:
On 8 Jul 2024, at 20:19, Jason Merrill wrote:
On 6/17/24 8:
On Mon, Jul 15, 2024 at 10:21:18AM -0700, Ian Lance Taylor wrote:
> Can you see whether this patch works for FDPIC support? This is based
> on your patch but has various changes. Thanks.
Yes, it is working.
--
Thanks.
-- Max
Hi Kewen,
Here's the updated patch per your review comments, minus your suggestion
to disable the ROP mask which I mentioned isn't needed in my other reply.
This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
Ok for trunk?
Peter
Changes from v1:
* Moved checks for
> On Jul 15, 2024, at 17:41, Martin Uecker wrote:
>
> Am Montag, dem 15.07.2024 um 21:26 + schrieb Qing Zhao:
>> Hi, Martin,
>> I didn’t see your v3 patches attached to the email, did you miss them?
>> (I really want to see them -:).
>
> Sorry, I should have CCed you. It was sent as a s
Am Montag, dem 15.07.2024 um 21:26 + schrieb Qing Zhao:
> Hi, Martin,
> I didn’t see your v3 patches attached to the email, did you miss them?
> (I really want to see them -:).
Sorry, I should have CCed you. It was sent as a series of patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024
> Currently unaligned YMM and ZMM load and store costs are cheaper than
> aligned which causes the vectorizer to purposely mis-align accesses
> by adding an alignment prologue. It looks like the unaligned costs
> were simply left untouched from znver3 where they equate the aligned
> costs when twe
On 7/13/24 9:09 AM, Richard Sandiford wrote:
The asm in the testcase has a memory operand and also clobbers ax.
The clobber means that ax cannot be used to hold inputs, which
extends to the address of the memory.
I think I had an implicit assumption that constrain_operands
would enforce this,
On 7/14/24 1:45 PM, Jørgen Kvalsvik wrote:
lmap was introduced in tcl 8.6, and while it was released in 2012, lmap
does not really make too much of a difference to warrant the friction on
consverative (and relevant) systems.
gcc/testsuite/ChangeLog:
* lib/gcov.exp: Use foreach for tc
Hi, Martin,
I didn’t see your v3 patches attached to the email, did you miss them? (I
really want to see them -:).
> On Jul 15, 2024, at 16:58, Martin Uecker wrote:
>
> Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook:
>> On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote
On 7/12/24 2:53 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/14?
-- >8 --
Here we're prematurely stripping the dependent alias template-id A to
its defining-type-id T when used as a template argument, which in turn
causes us to essentia
On Mon, 15 Jul 2024, Jakub Jelinek wrote:
> > > > for gcc/ChangeLog
> > > >
> > > > PR target/115459
> > > > * config/alpha/alpha.cc (alpha_expand_block_move): Adjust
> > > > MEMs to match inferred alignment.
> > >
> > > LGTM, based on a successful bootstrap/regtest repor
On Mon, 15 Jul 2024, Richard Biener wrote:
> > > > The patch is OK for trunk, thanks. I agree that it's a regression
> > > > from 08a692679fb8. Since it's fixing such a hard-to-diagnose wrong
> > > > code bug, and since it seems very safe, I think it's worth backporting
> > > > to all active bra
Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook:
> On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote:
> > No, there are still two many missing pieces. The following
> > works already
> >
> > int h(int n, int buf[n])
> > {
> > return __builtin_dynamic_object_size(buf, 1);
On 7/11/24 1:24 AM, Kewen.Lin wrote:
> Sorry for the confusion, I meant for most target options when we emit some
> error
> message meanwhile we also unset it, such as:
>
> if (TARGET_CRYPTO && !TARGET_ALTIVEC)
> {
> if (rs6000_isa_flags_explicit & OPTION_MASK_CRYPTO)
> error ("
On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote:
> No, there are still two many missing pieces. The following
> works already
>
> int h(int n, int buf[n])
> {
> return __builtin_dynamic_object_size(buf, 1);
> }
Yeah, this is nice.
There are some interesting things happening aro
Am 15.07.24 um 20:27 schrieb Harald Anlauf:
Replying to myself:
Am 15.07.24 um 19:35 schrieb Harald Anlauf:
For '_len_trim_c_k':
Breakpoint 1, gfc_create_module_variable (sym=0x32af2f0)
at ../../gcc-trunk/gcc/fortran/trans-decl.cc:5515
5515 gcc_assert (sym->ns->proc_name->attr.flavor
Hi Prathamesh!
Am 15.07.24 um 15:07 schrieb Prathamesh Kulkarni:
-Original Message-
From: Harald Anlauf
I agree that it is reasonable to defer the handling of arrays as
components of derived types, and recommend to do the following:
- replace "&& gfc_is_simply_contiguous (expr, true, f
Replying to myself:
Am 15.07.24 um 19:35 schrieb Harald Anlauf:
For '_len_trim_c_k':
Breakpoint 1, gfc_create_module_variable (sym=0x32af2f0)
at ../../gcc-trunk/gcc/fortran/trans-decl.cc:5515
5515 gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE
(gdb) p sym->ns->proc_name->att
> Am 15.07.2024 um 19:08 schrieb Richard Sandiford :
>
> Richard Biener writes:
>> The following adds a new --param for debugging the vectorizers alignment
>> peeling by increasing the cost of aligned stores.
>>
>> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>>
>> This makes th
Hi Paul, Andre,
at the risk of getting stoned to death, here's an example:
module m
implicit none
integer :: c
contains
function f(n) result(z)
integer, intent(in) :: n
character, parameter :: c(3) = ['x', 'y', 'z']
character(len_trim(c(n))) :: z
z = c(n)
end
function
Can you see whether this patch works for FDPIC support? This is based
on your patch but has various changes. Thanks.
Ian
diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index cc36a0a2990..96ffc4cc481 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -388,8 +388,8 @@ struct
Am Montag, dem 15.07.2024 um 09:45 -0700 schrieb Kees Cook:
> On Mon, Jul 15, 2024 at 09:19:49AM +0200, Martin Uecker wrote:
> > The instrumentation is guarded by a new instrumentation flag -fvla-bounds,
> > but runtime overhead should generally be very low as most checks are
> > removed by the
On Jul 12, 2024, Jonathan Wakely wrote:
> On Fri, 12 Jul 2024 at 10:27, Jonathan Wakely wrote:
>>
>> On Fri, 12 Jul 2024 at 09:27, Alexandre Oliva wrote:
>> >
>> > On Jul 11, 2024, Jonathan Wakely wrote:
>> >
>> > > There's no requirement that system_error uses strerror, that's just an
>> > >
On Mon, Jul 15, 2024 at 11:10 AM Kito Cheng wrote:
>
> LGTM, and could you backport this to the GCC 14 branch as well?
Rebased, retested (multilib), fixed an issue related to Zca/Zcd and pushed.
Should the GCC 14 backport be posted for review before pushing?
Thanks,
Christoph
>
> On Tue, Jul 9
Richard Biener writes:
> The following adds a new --param for debugging the vectorizers alignment
> peeling by increasing the cost of aligned stores.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> This makes the PR115843 testcase fail again on trunk (but not on the
> branch), see
On Mon, Jul 15, 2024 at 09:19:49AM +0200, Martin Uecker wrote:
> The instrumentation is guarded by a new instrumentation flag -fvla-bounds,
> but runtime overhead should generally be very low as most checks are
> removed by the optimizer, e.g.
>
> void foo(int x, char (*buf)[x])
> {
> bar(x, buf)
Committed!
Edwin
On 7/12/2024 3:40 PM, Jeff Law wrote:
On 7/12/24 12:37 PM, Edwin Lu wrote:
The following testcase was not properly testing anything due to an
uninitialized variable. As a result, the loop was not iterating through
the testing data, but instead on undefined values which could
Hi All,
I am not sure that I understand why this bug occurs. The regression was
introduced by my patch that had gfc_trans_class_init_assign return
NULL_TREE, when all the components of the default initializer are NULL.
Note that this only afflicts scalar dummy arguments.
With pr115070:
void my_su
On 15/07/2024 16:36, Thomas Schwinge wrote:
Hi!
On 2024-07-15T12:16:30+0100, Andrew Stubbs wrote:
On 15/07/2024 10:29, Thomas Schwinge wrote:
On 2021-11-12T18:58:04+0100, Jakub Jelinek via Gcc-patches
wrote:
And finally here is a third version, [...]
... which became commit 9fa72756d90e0
Hi!
On 2024-07-15T12:16:30+0100, Andrew Stubbs wrote:
> On 15/07/2024 10:29, Thomas Schwinge wrote:
>> On 2021-11-12T18:58:04+0100, Jakub Jelinek via Gcc-patches
>> wrote:
>>> And finally here is a third version, [...]
>>
>> ... which became commit 9fa72756d90e0d9edadf6e6f5f56476029925788
>> "
Both xchg and cmpxchg instructions, in the pseudo-C dialect, do not
expect their memory address operand to be surrounded by parentheses.
For example, it should be output as "w0 =cmpxchg32_32(r8+8,w0,w2)"
instead of "w0 =cmpxchg32_32((r8+8),w0,w2)".
This patch implements an operand modifier 'M' whi
On Sat, Jul 13, 2024 at 5:49 PM Feng Xue OS wrote:
>
> When transforming multiple lane-reducing operations in a loop reduction chain,
> originally, corresponding vectorized statements are generated into def-use
> cycles starting from 0. The def-use cycle with smaller index, would contain
> more st
On Sat, Jul 13, 2024 at 5:48 PM Feng Xue OS wrote:
>
> For lane-reducing operation(dot-prod/widen-sum/sad) in loop reduction, current
> vectorizer could only handle the pattern if the reduction chain does not
> contain other operation, no matter the other is normal or lane-reducing.
>
> This patch
On Sat, Jul 13, 2024 at 5:47 PM Feng Xue OS wrote:
>
> Vector stmts number of an operation is calculated based on output vectype.
> This is over-estimated for lane-reducing operation, which would cause vector
> def/use mismatched when we want to support loop reduction mixed with lane-
> reducing a
On Sat, Jul 13, 2024 at 5:46 PM Feng Xue OS wrote:
>
> Extend original vect_get_num_copies (pure loop-based) to calculate number of
> vector stmts for slp node regarding a generic vect region.
>
> Thanks,
> Feng
> ---
> gcc/
> * tree-vectorizer.h (vect_get_num_copies): New overload functio
On 6/14/24 07:10, user202...@protonmail.com wrote:
This patch was inspired from PR 110137. It reduces the amount of stack spilling
by ensuring that more values are constant across a pure function call.
It does not add any new flag; rather, it makes the optimizer generate more
optimal code.
On Sun, Jul 14, 2024 at 3:08 PM Roger Sayle wrote:
>
>
> Hi Richard,
> Many thanks for the review and recommendation to use nop_convert?.
> This revised patch implements that suggestion, which required a little
> experimentation/tweaking as ranger/EVRP records the ranges on the
> useless type conv
On Sat, Jul 13, 2024 at 7:52 PM Max Filippov wrote:
>
> On Wed, Jul 10, 2024 at 12:49 PM Ian Lance Taylor wrote:
> > On Sun, May 26, 2024 at 11:51 PM Max Filippov wrote:
> > > diff --git a/libbacktrace/internal.h b/libbacktrace/internal.h
> > > index 4fa0af8cb6c9..456911166026 100644
> > > --- a
On Sun, Jul 14, 2024 at 10:15 AM rubin.gerritsen wrote:
>
> Previously only simplifications of the `__st[xrp]cpy_chk`
> were dumped. Now all call replacement simplifications are
> dumped.
>
> Examples of statements with corresponding dumpfile entries:
>
> `printf("mystr\n");`:
> optimized: s
On Mon, 15 Jul 2024, Torbjörn SVENSSON wrote:
> As the test case requires +-Inf and NaN to work and -ffast-math is added
> by default for arm-none-eabi, re-enable non-finite math.
Isn't
/* { dg-add-options ieee } */
the canonical way to handle CPU/testsuite defaults?
> gcc/testsuite/ChangeLog:
The following adds a new --param for debugging the vectorizers alignment
peeling by increasing the cost of aligned stores.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
This makes the PR115843 testcase fail again on trunk (but not on the
branch), seemingly uncovering another backend is
> -Original Message-
> From: Harald Anlauf
> Sent: Saturday, July 13, 2024 1:15 AM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org; fort...@gcc.gnu.org
> Subject: Re: Lower zeroing array assignment to memset for allocatable
> arrays
>
> External email: Use caution opening links or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876#c7
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Linux/x86_64,
a6f551d079de1d151b272bcdd3d42316857c9d4e is the first bad commit
commit a6f551d079de1d151b272bcdd3d42316857c9d4e
Author: Jeff Law
Date: Fri Jul 12 13:11:33 2024 -0600
[PR rtl-optimization/115876] Fix one of two ubsan reported issues in new
ext-dce.cc code
caused
FAIL: g
On 7/15/24 09:04, LIU Hao wrote:
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index 747f74ba1c0..b67a0b524db 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -7805,6 +7805,8 @@ decl_binds_to_current_def_p (const_tree decl)
for all other declaration types. */
if (DECL_WEAK (decl))
r
Hello Richard:
On 13/07/24 8:16 pm, Ajit Agarwal wrote:
> Hello Richard:
>
> On 12/07/24 6:20 pm, Richard Biener wrote:
>> On Fri, Jul 12, 2024 at 12:09 PM Ajit Agarwal wrote:
>>>
>>> Hello Richard:
>>>
>>> On 11/07/24 2:21 pm, Richard Biener wrote:
On Thu, Jul 11, 2024 at 10:30 AM Ajit Aga
On Mon, Jul 15, 2024 at 1:22 PM Tejas Belagod wrote:
>
> On 7/15/24 12:16 PM, Tejas Belagod wrote:
> > On 7/12/24 6:40 PM, Richard Biener wrote:
> >> On Fri, Jul 12, 2024 at 3:05 PM Jakub Jelinek wrote:
> >>>
> >>> On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener wrote:
> Padding is
On Mon, 15 Jul 2024, Maciej W. Rozycki wrote:
> On Sun, 30 Jun 2024, Maciej W. Rozycki wrote:
>
> > > The patch is OK for trunk, thanks. I agree that it's a regression
> > > from 08a692679fb8. Since it's fixing such a hard-to-diagnose wrong
> > > code bug, and since it seems very safe, I think
On Mon, Jul 15, 2024 at 01:09:02PM +0100, Maciej W. Rozycki wrote:
> On Wed, 10 Jul 2024, Uros Bizjak wrote:
>
> > > Before issuing loads or stores for a block move, adjust the MEM
> > > alignments if analysis of the addresses enabled the inference of
> > > stricter alignment. This ensures that t
On Sun, 30 Jun 2024, Maciej W. Rozycki wrote:
> > The patch is OK for trunk, thanks. I agree that it's a regression
> > from 08a692679fb8. Since it's fixing such a hard-to-diagnose wrong
> > code bug, and since it seems very safe, I think it's worth backporting
> > to all active branches, after
On Wed, 10 Jul 2024, Uros Bizjak wrote:
> > Before issuing loads or stores for a block move, adjust the MEM
> > alignments if analysis of the addresses enabled the inference of
> > stricter alignment. This ensures that the MEMs are sufficiently
> > aligned for the corresponding insns, which avoid
When AVX512 uses a fully masked loop and peeling we fail to create the
correct initial loop mask when the mask is composed of multiple
components in some cases. The following fixes this by properly applying
the bias for the component to the shift amount.
Bootstrap and regtest running on x86_64-un
Hi All,
This RFC document covers at a high level how to extend early break support in
GCC to support SLP and how this will be extended in the future to support
full control flow in GCC.
The basic idea in this is based on the paper "All You Need Is Superword-Level
Parallelism: Systematic Control-F
This trivially fixes an incorrectly encoded character in the DejaGnu
scan pattern.
OK for trunk?
--
PA>From 87686fe5589711b90d0b421368747373978f2a39 Mon Sep 17 00:00:00 2001
From: Paul-Antoine Arras
Date: Mon, 15 Jul 2024 13:18:01 +0200
Subject: [PATCH] Fix non-Unicode character
---
gcc/tests
On 7/15/24 12:16 PM, Tejas Belagod wrote:
On 7/12/24 6:40 PM, Richard Biener wrote:
On Fri, Jul 12, 2024 at 3:05 PM Jakub Jelinek wrote:
On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener wrote:
Padding is only an issue for very small vectors - the obvious choice is
to disallow vector
On 15/07/2024 10:29, Thomas Schwinge wrote:
Hi!
On 2021-11-12T18:58:04+0100, Jakub Jelinek via Gcc-patches
wrote:
And finally here is a third version, [...]
... which became commit 9fa72756d90e0d9edadf6e6f5f56476029925788
"libgomp, nvptx: Honor OpenMP 5.1 num_teams lower bound".
Attached h
Currently unaligned YMM and ZMM load and store costs are cheaper than
aligned which causes the vectorizer to purposely mis-align accesses
by adding an alignment prologue. It looks like the unaligned costs
were simply left untouched from znver3 where they equate the aligned
costs when tweaking alig
From: Pan Li
Update in v3:
* Rebase the upstream.
* Adjust asm check.
Original log:
This patch would like to implement the simple .SAT_TRUNC pattern
in the riscv backend. Aka:
Form 1:
#define DEF_SAT_U_TRUC_FMT_1(NT, WT) \
NT __attribute__((noinline)) \
sat_u_truc_##WT##_t
Hi Peter,
> On Jul 12, 2024, at 23:48, Peter Bergner wrote:
>
> René's patch seems to have stalled, so here is an updated version of the
> patch with the requested changes to his patch.
Yes, sorry. Our Linux distribution grew so much in popularity the last
month that I had hard weeks keeping up
Hi Paul,
I tried to "break" your patch, but I failed. (I tried having same function in
both modules with identical signature; but I do not get a symbol collision). So
to me the patch looks fine now. But you may want to give Harald some time for a
look.
Thanks for the patch,
Andre
On Mon,
As the test case requires +-Inf and NaN to work and -ffast-math is added
by default for arm-none-eabi, re-enable non-finite math.
gcc/testsuite/ChangeLog:
PR testsuite/115826
* gcc.dg/vect/tsvc/vect-tsvc-s1281.c: Use -fno-finite-math-only.
Signed-off-by: Torbjörn SVENSSON
---
g
I've done it again! Patch duly added.
Paul
On Mon, 15 Jul 2024 at 09:21, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> Thank you for the review and for the testing to destruction. Both issues
> are fixed in the attached patch. Note the new function 'h', which both
Hi!
On 2021-11-12T18:58:04+0100, Jakub Jelinek via Gcc-patches
wrote:
> And finally here is a third version, [...]
... which became commit 9fa72756d90e0d9edadf6e6f5f56476029925788
"libgomp, nvptx: Honor OpenMP 5.1 num_teams lower bound".
Attached here is "GCN: Honor OpenMP 5.1 'num_teams' lowe
LGTM, and could you backport this to the GCC 14 branch as well?
On Tue, Jul 9, 2024 at 8:50 PM Christoph Müllner
wrote:
>
> The target-arch attribute handling in RISC-V is only a few months old,
> but already saw a rewrite (9941f0295a14), which addressed an important
> issue. This rewrite introd
Ok for trunk and releases/gcc-14?
Changes since v1:
- Fixed a regression for armv8l-unknown-linux-gnueabihf reported by Linaro
TCWG-CI.
--
Overriding the -mpfu and -mfloat-abi might be incompatible with selected
multilib. As a result, verify that the current multilib is compatible
with the eff
--
Best regards,
LIU Hao
From 6a2f0d3fbd443487bb6dd7bc95ed5403cd572ac1 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 15 Jul 2024 16:55:52 +0800
Subject: [PATCH] Do not use caller-saved registers for COMDAT functions
A reference to a COMDAT function may be resolved to another definition
outs
Hi Paul,
I am missing an attachment or is the change to small, that I've overlooked it
:-)
- Andre
On Mon, 15 Jul 2024 09:21:54 +0100
Paul Richard Thomas wrote:
> Hi Harald,
>
> Thank you for the review and for the testing to destruction. Both issues
> are fixed in the attached patch. Note the
On Mon, 15 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 15, 2024 at 09:52:18AM +0200, Richard Biener wrote:
> > > .string "k"
> > > .string ""
> > > .string ""
> > > .string "\375"
> > > .string ""
> > > .string ""
> > > .string ""
> > >
Hi Harald,
Thank you for the review and for the testing to destruction. Both issues
are fixed in the attached patch. Note the new function 'h', which both
tests that the namespace confusion is fixed and that the elemental-ness of
LEN_TRIM is respected.
The patch continues to regtest OK. If I don'
On Mon, Jul 15, 2024 at 09:52:18AM +0200, Richard Biener wrote:
> > .string "k"
> > .string ""
> > .string ""
> > .string "\375"
> > .string ""
> > .string ""
> > .string ""
> > .string ""
> > .string ""
> > .string ""
Applied this small patch that uses existing mode attributes
like instead of GET_MODE_SIZE (mode) etc.
Johann
--
AVR: avr-md - Simplify GET_MODE_[BIT]SIZE (mode).
gcc/
* config/avr/avr.md: Simplify mode usage.
(GET_MODE_SIZE (mode)): Use instead.
(GET_MODE_BITSIZE (mod
在 2024/7/11 下午7:45, Xi Ruoyao 写道:
Doing so can avoid loading FP constants from the memory. It also
partially fixes PR 66462 as fclass does not signal on sNaN.
gcc/ChangeLog:
* config/loongarch/loongarch.md (extendsidi2): Add ("=r", "f")
alternative and use movfr2gr.s for it.
On Mon, 15 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 15, 2024 at 09:16:29AM +0200, Richard Biener wrote:
> > > Nick has implemented a new .base64 directive in gas (to be shipped in
> > > the upcoming binutils 2.43; big thanks for that).
> > > See https://sourceware.org/bugzilla/show_bug.cgi?id=
correct email.
Am Montag, dem 15.07.2024 um 09:19 +0200 schrieb Martin Uecker:
> This is the third revision for my patch series to check bounds
> consistency at run-time when assigning VM types. Relative
> to the last version, mostly the tests were simplified and some
> coding style issues fixe
On Mon, Jul 15, 2024 at 09:16:29AM +0200, Richard Biener wrote:
> > Nick has implemented a new .base64 directive in gas (to be shipped in
> > the upcoming binutils 2.43; big thanks for that).
> > See https://sourceware.org/bugzilla/show_bug.cgi?id=31964
> >
> > The following patch adjusts default_
Support instrumentation of function arguments for functions
called via a declaration. We can support only simple size
expressions without side effects, because the run-time
instrumentation is done before the call, but the expressions
are evaluated in the callee.
gcc/c:
* c-typeck.cc (process_v
Support instrumentation of functions called via pointers. To do so,
record the declaration with the parameter types, so that it can be
retrieved later.
gcc/c:
c-decl.cc (get_parm_info): Record function declaration
for arguments.
c-typeck.cc (process_vm_constraints): Instrument functions
cal
Add warning for the case when a function call can not be instrumented
and add documentation for instrumentation of function calls.
gcc/c-family/:
* c.opt (Wvla-parameter-missing-check): Add warning.
gcc/c/:
* c-typeck.cc (process_vm_constraints): Add warning.
gcc/doc/:
* invoke.texi (Wvla-p
When checking compatibility of types during assignment, collect
all pairs of types where the outermost bound needs to match at
run-time. This list is then processed to add runtime checks for
each bound.
gcc/c-family:
* c-opt (fvla-bounds): New flag.
gcc/c:
* c-typeck.cc (struct instrument_dat
This is the third revision for my patch series to check bounds
consistency at run-time when assigning VM types. Relative
to the last version, mostly the tests were simplified and some
coding style issues fixed.
It adds a new code instrumentation option that inserts
run-time checks to ensure bo
On Mon, Jul 15, 2024 at 12:39:22AM +, Kugan Vivekanandarajah wrote:
> OMP safelen handling is assigning backend provided max as an int even when
> the pragma didn’t provide one. As a result, vectoriser is rejecting SVE modes
> while comparing poly_int with the safelen.
>
> That is, for the
1 - 100 of 101 matches
Mail list logo
