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
On Linux/x86_64,
a9a425df628ab80374cc6a132d39e470bc78c8bc is the first bad commit
commit a9a425df628ab80374cc6a132d39e470bc78c8bc
Author: Richard Biener
Date: Fri Feb 23 16:06:05 2024 +0100
middle-end/114070 - folding breaking VEC_COND expansion
caused
FAIL: gcc.dg/tree-ssa/andnot-2.c
On Fri, Mar 22, 2024 at 2:18 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM.
Pushed.
Thanks!
>
>
> 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
For machines that satisfy ISA_HAS_LSX && !TARGET_64BIT, we will not support
them now
and in the future, so this patch removes these unused code.
This patch also adds sign/zero-extend operations to vpickve2gr.d to match
the actual
instruction behavior, and integrates the template definition of
On Fri, 22 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes some bugs in the handling of stores to large/huge
> _BitInt bitfields.
>
> In the first 2 hunks we are processing the most significant limb of the
> actual type (not necessarily limb in the storage), and so we know it
Hi!
The middle-end warns about the ANNOTATE_EXPR added for while/for loops
if they declare a var inside of the loop condition.
This is because the assumption is that ANNOTATE_EXPR argument is used
immediately in a COND_EXPR (later GIMPLE_COND), but simplify_loop_decl_cond
wraps the ANNOTATE_EXPR
On Fri, 22 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> On x86 and avr some address spaces allow 0 pointers (on avr actually
> even generic as, but libsanitizer isn't ported to it and
> I'm not convinced we should completely kill -fsanitize=null in that
> case).
> The following patch makes sure
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'
Hello All:
When using FlexiBLAS with OpenBLAS we noticed corruption of
the parameters passed to OpenBLAS functions. FlexiBLAS
basically provides a BLAS interface where each function
is a stub that forwards the arguments to a real BLAS lib,
like OpenBLAS.
Fixes the corruption of caller frame
On Fri, Mar 22, 2024 at 4:43 AM Bruce Hoult wrote:
>
> > 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?
Yes, but
Hi!
On x86 and avr some address spaces allow 0 pointers (on avr actually
even generic as, but libsanitizer isn't ported to it and
I'm not convinced we should completely kill -fsanitize=null in that
case).
The following patch makes sure those aren't diagnosed for -fsanitize=null,
though they are
On Fri, Mar 22, 2024 at 01:00:21PM +0530, Ajit Agarwal wrote:
> When using FlexiBLAS with OpenBLAS we noticed corruption of
> the parameters passed to OpenBLAS functions. FlexiBLAS
> basically provides a BLAS interface where each function
> is a stub that forwards the arguments to a real BLAS lib,
Hi!
The following patch fixes some bugs in the handling of stores to large/huge
_BitInt bitfields.
In the first 2 hunks we are processing the most significant limb of the
actual type (not necessarily limb in the storage), and so we know it is
either partial or full limb, so [1, limb_prec] bits
On Thu, Mar 21, 2024 at 8:56 PM 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
Hi Richard,
> 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
Hello Jakub:
Addressed the below comments and sent version 1 of the patch
for review.
Thanks & Regards
Ajit
On 22/03/24 1:15 pm, Jakub Jelinek wrote:
> On Fri, Mar 22, 2024 at 01:00:21PM +0530, Ajit Agarwal wrote:
>> When using FlexiBLAS with OpenBLAS we noticed corruption of
>> the parameters
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/backprop-6.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/backprop-6.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
On 3/22/24 10:49, Stefan Schulze Frielinghaus wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/backprop-6.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 Thu, Mar 21, 2024 at 5:07 PM Andrew Stubbs wrote:
>
> 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.
On Fri, Mar 22, 2024 at 5:20 AM Andrew Pinski wrote:
>
> 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
Hi!
I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for warnings,
line 15)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for warnings,
line 37)
PASS: c-c++-common/gomp/depobj-3.c
Hi Jakub,
> I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
> PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for
> warnings, line 15)
> FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for
> warnings, line 37)
> PASS:
Hello Jakub:
When using FlexiBLAS with OpenBLAS we noticed corruption of
the parameters passed to OpenBLAS functions. FlexiBLAS
basically provides a BLAS interface where each function
is a stub that forwards the arguments to a real BLAS lib,
like OpenBLAS.
Fixes the corruption of caller frame
On Fri, Mar 22, 2024 at 02:55:43PM +0530, Ajit Agarwal wrote:
> rs6000: Stackoverflow in optimized code on PPC [PR100799]
>
> When using FlexiBLAS with OpenBLAS we noticed corruption of
> the parameters passed to OpenBLAS functions. FlexiBLAS
> basically provides a BLAS interface where each
Hi!
While I've posted a patch to handle EXCESS_PRECISION_EXPR in C/C++
pretty printing, still we'd need to handle
(a + (float)5)
and
(float)(((long double)a) + (long double)5)
and possibly
(float)(((double)a) + (double)5)
too for s390?, so the following patch just uses -fexcess-precision=fast,
so
LGTM, thanks :)
On Fri, Mar 22, 2024 at 2:55 PM wrote:
>
> 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
Hello All:
This is version-2 of the patch with review comments addressed.
When using FlexiBLAS with OpenBLAS we noticed corruption of
the parameters passed to OpenBLAS functions. FlexiBLAS
basically provides a BLAS interface where each function
is a stub that forwards the arguments to a real
Hello Jakub:
Thanks for review. Addressed below review comments and sent
version 2 of the patch for review.
Thanks & Regards
Ajit
On 22/03/24 3:06 pm, Jakub Jelinek wrote:
> On Fri, Mar 22, 2024 at 02:55:43PM +0530, Ajit Agarwal wrote:
>> rs6000: Stackoverflow in optimized code on PPC
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Friday, March 22, 2024 6:06 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
; rdapp@gmail.com; vine...@rivosinc.com;
pal...@rivosinc.com
Subject: Re: [PATCH v4] RISC-V:
On 3/15/24 4:29 AM, Thomas Neumann wrote:
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Given that this is a regression, is this okay for gcc 13 and mainline?
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup
On 22/03/2024 08:43, Richard Biener wrote:
I'll note that we don't pass 'val' there and
'val' is unfortunately
not documented - what's it supposed to be? I think I placed the original fix in
do_compare_and_jump because we have the full into available there. So
what's the
On Thu, 21 Mar 2024 10:00:24 PDT (-0700), Patrick O'Neill wrote:
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
*
On 3/22/24 2:47 AM, Richard Biener wrote:
On Thu, Mar 21, 2024 at 8:56 PM 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
The RDNA devices have different cache architectures to the CDNA devices, and
the differences go deeper than just the assembler mnemonics, so we
probably need to generate different code to maintain coherency across
the whole device.
I believe this patch is correct according to the documentation in
Hi Andrew!
On 2024-03-21T13:39:53+, Andrew Stubbs wrote:
> CUmode "on" is the setting for compatibility with GCN and CDNA devices.
> --- a/gcc/config/gcn/gcn-hsa.h
> +++ b/gcc/config/gcn/gcn-hsa.h
> @@ -107,6 +107,7 @@ extern unsigned int gcn_local_sym_hash (const char *name);
>
On 3/15/24 4:29 AM, Thomas Neumann wrote:
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Given that this is a regression, is this okay for gcc 13 and mainline?
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup
Another followup to r14-6057-g12b67d1e13b3cf to make it easier to debug
the analyzer.
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-9624-gd475a4571ef310.
gcc/analyzer/ChangeLog:
*
PR analyzer/112974 and PR analyzer/112975 record false positives
from the analyzer's taint detection where sanitization of the form
if (VALUE CMP VALUE-OF-WIDER-TYPE)
happens, but wasn't being "noticed" by the taint checker, due to the
test being:
(WIDER_TYPE)VALUE CMP VALUE-OF-WIDER-TYPE
This patch alters the default (preferred) vector size to 32 on RDNA devices to
better match the actual hardware. 64-lane vectors will continue to be
used where they are hard-coded (such as function prologues).
We run these devices in wavefrontsize64 for compatibility, but they actually
only have
On 22/03/2024 11:56, Thomas Schwinge wrote:
Hi Andrew!
On 2024-03-21T13:39:53+, Andrew Stubbs wrote:
CUmode "on" is the setting for compatibility with GCN and CDNA devices.
--- a/gcc/config/gcn/gcn-hsa.h
+++ b/gcc/config/gcn/gcn-hsa.h
@@ -107,6 +107,7 @@ extern unsigned int
On Fri, 22 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
> PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for
> warnings, line 15)
> FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for
>
libgcc/ChangeLog:
PR libgcc/111731
* unwind-dw2-fde.c: Split unwind ranges if they contain the
unwind table.
And what I'd suggest is committing to the trunk now, then waiting a week
or two before backporting to gcc-13.
I will do that, thanks for looking at the patch.
Best
This patch adds support for the gfx1103 RDNA3 APU integrated graphics
devices. The ROCm documentation warns that these may not be supported,
but it seems to work at least partially.
This device should be considered "Experimental" at this point, although
so far it seems to be at least as
Tested aarch64-linux. Pushed to trunk.
This should be backported to all branches, as the failure to destroy the
allocators in the re-inserted nodes results in potential resource leaks.
-- >8 --
The allocator objects in container node handles were not being destroyed
after the node was
On 3/22/24 5:15 AM, Ajit Agarwal wrote:
> When using FlexiBLAS with OpenBLAS we noticed corruption of
> the parameters passed to OpenBLAS functions. FlexiBLAS
> basically provides a BLAS interface where each function
> is a stub that forwards the arguments to a real BLAS lib,
> like OpenBLAS.
>
>
Thanks Jeff for comments.
> As Richi noted using validate_subreg here isn't great. Does it work to
> factor out this code from extract_low_bits
>
>> if (!int_mode_for_mode (src_mode).exists (_int_mode)
>> || !int_mode_for_mode (mode).exists (_mode))
>> return NULL_RTX;
>>
>> if
On 3/22/24 12:24 PM, Jakub Jelinek wrote:
On Fri, Mar 22, 2024 at 12:17:03PM -0600, Jeff Law wrote:
I'd just make target_lra return false for nvptx rather than creating a new
The lra effective target currently though doesn't check if asm goto can have
outputs, but rather if the target is
Tested aarch64-linux. Pushed to trunk.
-- >8 --
Put the C++23 generator and tuple_like ones before the C++26 ones.
libstdc++-v3/ChangeLog:
* include/bits/version.def (generator, tuple_like): Move earlier
in the file.
* include/bits/version.h: Regenerate.
---
On Thu, Mar 21, 2024 at 4:36 PM Takayuki 'January June' Suwa
wrote:
>
> 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,
Pushed to trunk. Backport to gcc-13 needed too, as the changes to use
concepts for std::pair constructors are on that branch.
On Tue, 19 Mar 2024 at 15:59, Jonathan Wakely wrote:
>
> This fixes the problem in the PR, which is revealed by the new
> concept-based constraints on std::pair
This another one of these ICE after error issues with the
gimplifier and a fallout from r12-3278-g823685221de986af.
The problem here is that STRIP_USELESS_TYPE_CONVERSION will
leave around a NON_LVALUE_EXPR which is an error mark node.
Since the gimplifier assumes non-lvalue expressions has been
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The preprocessor checks for __cplusplus in should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.
For the latter, we want to check the compiler macro not
Tested aarch64-linux. Pushed to trunk.
-- >8 --
Replace std::result_of with std::invoke_result, as specified in the
standard since C++17, to avoid deprecated warnings for std::result_of.
We don't have __invoke_result_t in C++11 mode, so add it as an alias
template for __invoke_result<>::type
And this replaces an existing custom dg-require- directive with a use of
the new one that checks for a standard feature test macro. I didn't see
any other existing dg-require-xxx directives that can be replaced like
this.
-- >8 --
Remove the dejagnu code for checking whether std::stacktrace is
Thoughts? There are only a few uses for this presently, but I can see it
being useful often in future. The library exposes which features it
supports in a standardized way, so we can use those in tests to skip
tests for features that aren't available on all targets.
The obvious downside is that
Applied this patchlet for a more precise diagnostic.
Johann
--
AVR: Adjust message for SIGNAL and INTERRUPT usage
gcc/
* config/avr/avr.cc (avr_set_current_function): Adjust diagnostic
for deprecated SIGNAL and INTERRUPT usage without respective header.
diff --git
On 3/22/24 05:29, Jeff Law wrote:
>> Another option is to enable -fsched-pressure which should help with
>> this issue.
> In theory we're already using that by default -- it's part of what makes
> me so curious to understand what's going on.
We are actually using it in practice :-)
Its the
On 3/22/24 07:22, Palmer Dabbelt wrote:
On Thu, 21 Mar 2024 10:00:24 PDT (-0700), Patrick O'Neill wrote:
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
On Fri, Mar 22, 2024 at 12:17:03PM -0600, Jeff Law wrote:
> I'd just make target_lra return false for nvptx rather than creating a new
The lra effective target currently though doesn't check if asm goto can have
outputs, but rather if the target is using lra.
> selector -- I'm not aware of any
I added a note about gfx1103 to the existing text for gfx1100.
Andrew
---
htdocs/gcc-14/changes.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index d88fbc96..880b9195 100644
---
Dear all,
here's a simple and obvious patch for a rejects-valid case when
we pass a NULL() actual to an optional dummy for variants where
there is no MOLD argument and it is also not required.
The testcase is an extended version of PR55978 comment#16
and cross-checked with Intel and NAG.
> "Andrew" == Andrew Burgess writes:
Andrew> Thanks, that would be great, and would certainly fix the build problems
Andrew> I see.
I'm going to check it in to binutils-gdb in a minute.
For those reading on gcc-patches, please consider this a ping of the
patch.
thanks,
Tom
On 3/9/24 2:11 AM, Alexandre Oliva wrote:
ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes report errors.
Skip this pass if errors were seen.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
On 3/4/24 11:22 PM, Li, Pan2 wrote:
Thanks Jeff for comments.
But in the case of a vector modes, we can usually reinterpret the
underlying bits in whatever mode we want and do any of the usual
operations on those bits.
Yes, I think that is why we can allow vector mode in get_stored_val if
libgcc/
* unwind-arm-common.inc (__gnu_personality_sigframe_fdpic): Cast
last argument of _Unwind_VRS_Set to void *.
---
libgcc/unwind-arm-common.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc
On Thu, Mar 21, 2024 at 05:27:37PM -0400, Jason Merrill wrote:
> 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
On 3/21/24 5:20 AM, Thomas Schwinge wrote:
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
On 3/1/24 8:07 AM, Robin Dapp wrote:
+ /* Segment load/store permute cost. */
+ const int segment_permute_2;
+ const int segment_permute_4;
+ const int segment_permute_8;
Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8
No idea why I posted that (wrong) version, I used
68 matches
Mail list logo
