On Tue, Mar 19, 2024 at 12:38:34PM -0400, David Malcolm wrote:
> On Tue, 2024-03-19 at 16:10 +0100, Stefan Schulze Frielinghaus wrote:
> > On s390 pr94688.c is failing due to excess error
> >
> > pr94688.c:6:5: warning: allocated buffer size is not a multiple of
> > the pointee's size [CWE-131] [-
Hi!
The Knuth's division algorithm relies on the number of dividend limbs
to be greater ore equal to number of divisor limbs, which is why
I've added a special case for un < vn at the start of __divmodbitint4.
Unfortunately, my assumption that it then implies abs(v) > abs(u) and
so quotient must b
wi::from_mpz doesn't take a sign argument, we want it to be wrapped
instead of saturation, so pass utype and true to it, and it fixes the
bug.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk and backport to gcc13?
gcc/ChangeLog:
PR tree-optimization/114396
On Thu, 21 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The Knuth's division algorithm relies on the number of dividend limbs
> to be greater ore equal to number of divisor limbs, which is why
> I've added a special case for un < vn at the start of __divmodbitint4.
> Unfortunately, my assumption that
On Thu, Mar 21, 2024 at 9:35 AM liuhongt wrote:
>
> wi::from_mpz doesn't take a sign argument, we want it to be wrapped
> instead of saturation, so pass utype and true to it, and it fixes the
> bug.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk and backport to gcc13?
The following more thoroughly avoids address sanitizing accesses
to non-generic address-spaces.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
PR tree-optimization/111736
* asan.cc (instrument_derefs): Do not instrument accesses
to non-generic
Two avx512cd tests FAIL to assemble with the Solaris/x86 assembler:
FAIL: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c compilation failed to
produce executable
FAIL: gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c (tes
On Thu, Mar 21, 2024 at 10:25:24AM +0100, Richard Biener wrote:
> The following more thoroughly avoids address sanitizing accesses
> to non-generic address-spaces.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> PR tree-optimization/111736
>
gcc.dg/vect/bb-slp-32.c currently XPASSes on 32 and 64-bit Solaris/SPARC:
XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects scan-tree-dump slp2
"vectorization is not profitable"
XPASS: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2 "vectorization is not
profitable"
At least on SPARC, the cur
On Thu, 21 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 21, 2024 at 10:25:24AM +0100, Richard Biener wrote:
> > The following more thoroughly avoids address sanitizing accesses
> > to non-generic address-spaces.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> > Th
On Thu, Mar 21, 2024 at 10:50:04AM +0100, Richard Biener wrote:
> Fixed and pushed. I suppose for address-spaces nested within the
> generic address space we could instrument the address converted to
> the generic address space value.
Unlike TLS, we don't know if address-spaces are nested within
On Thu, 21 Mar 2024, Rainer Orth wrote:
> gcc.dg/vect/bb-slp-32.c currently XPASSes on 32 and 64-bit Solaris/SPARC:
>
> XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects scan-tree-dump slp2
> "vectorization is not profitable"
> XPASS: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2 "vectorizat
On Thursday, March 7, 2024 9:48 PM
Evgeny Karpov wrote:
> > Changes from v1 to v2:
> > Adjust the target name to aarch64-*-mingw* to exclude the big-endian
> > target from support.
> > Exclude 64-bit ISA.
> > Update commit descriptions to follow standard style.
> > Rebase from 4th March 2024.
>
On Thu, 21 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 21, 2024 at 10:50:04AM +0100, Richard Biener wrote:
> > Fixed and pushed. I suppose for address-spaces nested within the
> > generic address space we could instrument the address converted to
> > the generic address space value.
>
> Unlike
Hi!
On 2024-01-12T15:02:35+0100, I wrote:
> OK to push the attached
> "GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'"?
Ping. (Or is that not what you'd expect to see for GCN? I haven't
checked the actual back end code...)
> ("The relevant test cases are all-PASS with
Hi!
OK to push the attached "GCN: Enable effective-target 'vect_long_mult'"?
(Or is that not what you'd expect to see for GCN? I haven't checked the
actual back end code...)
Grüße
Thomas
>From e0e58dfc350581ed0519420ad02adcc01e645eae Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed,
Hi!
OK to push the attached
"GCN: Enable effective-target 'vect_hw_misalign'"? (Or is that not what
you'd expect to see for GCN? I haven't checked the actual back end
code...)
Grüße
Thomas
>From dad0686e179e9395408a39ccfbf760bc30acffc9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: W
On 21/03/2024 10:41, Thomas Schwinge wrote:
Hi!
On 2024-01-12T15:02:35+0100, I wrote:
OK to push the attached
"GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'"?
Ping. (Or is that not what you'd expect to see for GCN? I haven't
checked the actual back end code...)
So
Hi!
On 2024-02-16T10:48:53-0800, Mike Stump wrote:
> On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>>
>> There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
>> target. I think claiming for it that it is a lra target is strange (even
>> though it effectively returns t
LGTM, thanks :)
On Wed, Mar 20, 2024 at 2:07 PM wrote:
>
> From: Pan Li
>
> This patch depends on below ICE fix.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647915.html
>
> The function target attribute should be on a per-function basis.
> For example, we have 3 function as below:
>
LGTM too :)
On Mon, Mar 18, 2024 at 11:35 PM Robin Dapp wrote:
>
> LGTM as well.
>
> Regards
> Robin
>
> +
> + /* Make sure the implied or combined extension is included after add
> + a new std extension to subset list. For exmaple as below,
> +
> + void __attribute__((target("arch=+v"))) func () with -march=rv64gc.
> +
> + The implied zvl128b and zve64d of the std v should be included
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
PTImode assists in generating even/odd register pairs on 128 bits. When the
user
specifies PTImode as an attribute, it breaks because there is no internal type
to handle this mode. To address this, we have cr
Le 20/03/2024 à 21:24, Harald Anlauf a écrit :
Hi Mikael, all,
here's now the third version of the patch that implements the following
scheme:
On 3/15/24 20:29, Mikael Morin wrote:
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
OK, that sounds interesting. To clarify the options:
- for ordi
There are some stability issues in the ROC runtime or drivers when we
run too many tests in quick succession. I was hoping this patch might
fix it, but no; still good to fix the omissions though.
Committed to mainline.
gcc/ChangeLog:
* config/gcn/gcn-run.cc (main): Add an hsa_memory_fre
> For the vint*m*_t below operations are allowed.
> * The sizeof.
> * The global variable(s).
> * The element of union and struct.
> * The cast to other equalities.
> * CMP: >, <, ==, !=, <=, >=
The result of comparison should be vbool* rather than v[u]int*.
> * ALU: +, -, *, /, %, &, |, ^, >>, <
Hi Stefan:
I admit that's kinda bad practice here, the spec should appear before
implementation or at least come together, however we have long
discussion on the RISC-V gcc community on this, and we give a waiver
for this feature due to the clang compatibility, and this features
also used on some
The location of the marker was changed, but the comment wasn't updated.
Fixed now.
Committed to mainline
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_expand_builtin_1): Comment correction.
---
gcc/config/gcn/gcn.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/c
CUmode "on" is the setting for compatibility with GCN and CDNA devices.
Committed to mainline.
gcc/ChangeLog:
* config/gcn/gcn-hsa.h (ASM_SPEC): Pass -mattr=+cumode.
---
gcc/config/gcn/gcn-hsa.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config/gcn/gcn-hsa.h b/gcc/config/gc
On Thu, 2024-03-21 at 10:14 +0800, Jie Mei wrote:
> diff --git a/gcc/testsuite/gcc.target/mips/mips-minmax.c
> b/gcc/testsuite/gcc.target/mips/mips-minmax.c
> new file mode 100644
> index 000..2d234ac4b1d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/mips/mips-minmax.c
> @@ -0,0 +1,40 @
Thanks Kito, will commit it after the ICE fix.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, March 21, 2024 8:33 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Bugfix function target attribute pollution
LGT
Thanks Kito, will send v2 for this change.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, March 21, 2024 8:39 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))
>
> The result of comparison should be vbool* rather than v[u]int*.
> The result of comparison should be vbool* rather than vfloat*,
> otherwise all 1 is not really meanful for floating point value.
> But I know clang generates the same strange/wrong code here...
I see, will update the test cases a
> > &, ^, | has supported on clang, so I think we should support that as well
>
> Looks gcc lack of such operation right now, so mark the TYPE_INDIVISIBLE_P
> (type) = 0 as aarch64 did.
> I have a try but I am afraid we need separated patch to take care of it for
> risk control consideration.
Ye
My previous patch to fix this problem with xor was rejected because we
want to fix these issues only at the point of use. That patch produced
slightly better code, in this example, but this works too
These patches fix up a failure in testcase vect/tsvc/vect-tsvc-s278.c when
configured to use
On 3/18/24 21:41, Jeff Law wrote:
>
> On 3/16/24 11:35 AM, Vineet Gupta wrote:
>> Hi,
>>
>> This set of patches (for gcc-15) help improve stack/array accesses
>> by improving constant materialization. Details are in respective
>> patches.
>>
>> The first patch is the main change which improves S
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/abs-4.c: On s390 we also have a copysign optab
for long double. Thus, scan 3 instead of 2 times for it.
---
Ok for mainline?
gcc/testsuite/gcc.dg/tree-ssa/abs-4.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
On 3/21/24 8:36 AM, Vineet Gupta wrote:
On 3/18/24 21:41, Jeff Law wrote:
On 3/16/24 11:35 AM, Vineet Gupta wrote:
Hi,
This set of patches (for gcc-15) help improve stack/array accesses
by improving constant materialization. Details are in respective
patches.
The first patch is the main
On Thu, Mar 21, 2024 at 3:23 PM Andrew Stubbs wrote:
>
> My previous patch to fix this problem with xor was rejected because we
> want to fix these issues only at the point of use. That patch produced
> slightly better code, in this example, but this works too
>
> These patches fix up a failu
On 21/03/2024 15:18, Richard Biener wrote:
On Thu, Mar 21, 2024 at 3:23 PM Andrew Stubbs wrote:
My previous patch to fix this problem with xor was rejected because we
want to fix these issues only at the point of use. That patch produced
slightly better code, in this example, but this works t
Hello,
here is a fix for an ICE caused by dangling pointers to ISO_C_BINDING's
C_PTR symbol in the global intrinsic symbol for C_LOC.
I tried to fix it by making the intrinsic symbol use its own copy of
C_PTR, but it regressed heavily.
Instead, I propose this which is based on a patch I attached
Use dg_add_options riscv_a to add atomic extension when running compile
tests on non-a targets.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add
dg_add_options riscv_a
* gcc.target/riscv/amo-table-ztso-amo-add-2.c: Ditto.
* gcc.target/r
On 3/21/24 15:41, Stefan Schulze Frielinghaus wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/abs-4.c: On s390 we also have a copysign optab
> for long double. Thus, scan 3 instead of 2 times for it.
> ---
> Ok for mainline?
Ok. Thanks!
Andreas
On 3/21/24 07:45, Jeff Law wrote:
The first patch is the main change which improves SPEC cactu by 10%.
>>> Just to confirm. Yup, 10% reduction in icounts and about a 3.5%
>>> improvement in cycles on our target. Which is great!
>>>
>>> This also makes me wonder if cactu is the benchmark t
On 3/21/24 11:19 AM, Vineet Gupta wrote:
So if we go back to Robin's observation that scheduling dramatically
increases the instruction count, perhaps we try a run with
-fno-schedule-insns -fno-schedule-insns2 and see how the instruction
counts compare.
Oh yeah ! Robin hinted to this in Tu
On Wed, Mar 20, 2024 at 09:21:02PM -0400, Jason Merrill wrote:
> On 3/1/24 19:58, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't
> > claim that this has to go to 14 though.
> >
> > -- >8 --
> > ...from another array in a mem-initializer should not be
Hi Mikael,
this looks all good to me. I wouldn't mind the minor side-effects of
better error recovery, as you are (successfully) trying hard to keep
the namespaces sane. So OK for mainline.
Thanks for the patch!
Harald
On 3/21/24 17:27, Mikael Morin wrote:
Hello,
here is a fix for an ICE
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong;
we're dealing with a noexcept-spec there, not a noexcept-expr, so
setting cp_noexcept_operand et al is incorrect. Back to the drawing
board then.
To fix noexcept
On Fri, Mar 15, 2024 at 12:12:49PM -0400, Patrick Palka wrote:
> On Fri, 15 Mar 2024, Marek Polacek wrote:
>
> > On Fri, Mar 15, 2024 at 10:35:07AM -0400, Patrick Palka wrote:
> > > On Tue, 5 Mar 2024, Marek Polacek wrote:
> > >
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
On 3/21/24 17:01, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong;
we're dealing with a noexcept-spec there, not a noexcept-expr, so
setting cp_noexcept_operand et al is incorrect. Back to
On 3/21/24 16:48, Marek Polacek wrote:
On Wed, Mar 20, 2024 at 09:21:02PM -0400, Jason Merrill wrote:
On 3/1/24 19:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't
claim that this has to go to 14 though.
-- >8 --
...from another array in a mem-init
On Thu, Mar 21, 2024 at 10:26 AM Rainer Orth
wrote:
>
> Two avx512cd tests FAIL to assemble with the Solaris/x86 assembler:
>
> FAIL: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c compilation failed
> to produce ex
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9600-g7a5a4a4467b2e1.
gcc/analyzer/ChangeLog:
PR analyzer/113619
* region-model.cc (region_model::eval_condition): Fix
int test(int a) {
return a * 4 + 3;
}
In the example above, since Xtensa has instructions to add register value
scaled by 2, 4 or 8 (and corresponding define_insns), we would expect them
to be used but not, because it is transformed before reaching the RTL
generation pass as below:
int tes
The expansion of `memset` (via expand_builtin_memset_args())
uses clear_by_pieces() and store_by_pieces() to avoid calls
to the C runtime. To check if a type can be used for that purpose
the function by_pieces_mode_supported_p() tests if a `mov` and
a `vec_duplicate` INSN can be expaned by the back
On 2024-03-20 16:34, rep.dot@gmail.com wrote:
> On 19 March 2024 18:27:13 CET, Kaz Kylheku wrote:
>>On 2024-03-18 00:30, Jonathan Wakely wrote:
>>> I don't have an opinion on the implementation, or the proposal itself,
>>> except that the implementation seems susprisingly simple, which is
>>>
On 3/21/24 12:56, Jeff Law wrote:
>
> On 3/21/24 11:19 AM, Vineet Gupta wrote:
>
>>> So if we go back to Robin's observation that scheduling dramatically
>>> increases the instruction count, perhaps we try a run with
>>> -fno-schedule-insns -fno-schedule-insns2 and see how the instruction
>>> co
From: Pan Li
This patch would like to fix one ICE for __attribute__((target("arch=+v"))
and likewise extension(s). Given we have sample code as below:
void __attribute__((target("arch=+v")))
test_2 (int *a, int *b, int *out, unsigned count)
{
unsigned i;
for (i = 0; i < count; i++)
out[i]
Sorry for disturbing, kindly ping for this ICE.
Pan
-Original Message-
From: Li, Pan2
Sent: Tuesday, March 12, 2024 10:09 AM
To: Jeff Law ; Robin Dapp ;
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
Wang, Yanzhang ; Liu, Hongtao
S
LGTM.
juzhe.zh...@rivai.ai
From: Christoph Müllner
Date: 2024-03-22 07:45
To: gcc-patches; Kito Cheng; Palmer Dabbelt; Andrew Waterman; Philipp Tomsich;
Camel Coder; Bruce Hoult; Juzhe-Zhong; Jun Sha; Xianmiao Qu; Jin Ma
CC: Christoph Müllner
Subject: [PATCH] RISC-V: Don't add fractional LMUL
On Thu, Mar 21, 2024, 17:20 Kaz Kylheku wrote:
> On 2024-03-20 16:34, rep.dot@gmail.com wrote:
> > On 19 March 2024 18:27:13 CET, Kaz Kylheku wrote:
> >>On 2024-03-18 00:30, Jonathan Wakely wrote:
> >>> I don't have an opinion on the implementation, or the proposal itself,
> >>> except that
Also fixed a typo in the testcase.
Commit as an obvious fix.
gcc/testsuite/ChangeLog:
PR tree-optimization/114396
* gcc.target/i386/pr114396.c: Move to...
* gcc.c-torture/execute/pr114396.c: ...here.
---
.../{gcc.target/i386 => gcc.c-torture/execute}/pr114396.c | 6 +++
LGTM, thanks :)
On Fri, Mar 22, 2024 at 9:13 AM wrote:
>
> From: Pan Li
>
> This patch would like to fix one ICE for __attribute__((target("arch=+v"))
> and likewise extension(s). Given we have sample code as below:
>
> void __attribute__((target("arch=+v")))
> test_2 (int *a, int *b, int *out,
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Friday, March 22, 2024 10:24 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v2] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))
LGTM, thanks :)
On F
As some of you know, Raphael has been working on stack-clash support for
the RISC-V port. A little while ago Florian reached out to us with an
issue where glibc was failing its smoke test due to referencing an
unallocated stack slot.
Without diving into the code in detail I (incorrectly) co
> The effect is demonstrated by a new test case that shows
that the by-pieces framework now emits `sb` instructions
instead of triggering an ICE
So these small memset() now don't use RVV at all if xtheadvector is enabled?
I don't have evidence whether the use of RVV (whether V or
xtheadvector) fo
This another one of these ICE after error issues with the
gimplifier and a fallout from r12-3278-g823685221de986af.
This case happens when we are trying to fold memcpy/memmove.
There is already code to try to catch ERROR_MARKs as arguments
to the builtins so just need to change them to use error_op
On 2024-03-21 18:40, Andrew Pinski wrote:
On Thu, Mar 21, 2024, 17:20 Kaz Kylheku wrote: For instance,
suppose we have a macro that expands to some block
of code in which there is an internal goto. If we have it
#define MAC(...) { ... goto _label; ... __label: ; }
then this cannot be used tw
From: Pan Li
This patch would like to introduce one new gcc attribute for RVV.
This attribute is used to define fixed-length variants of one
existing sizeless RVV types.
This attribute is valid if and only if the mrvv-vector-bits=zvl, the only
one args should be the integer constant and its' val
69 matches
Mail list logo
