[PATCH] Another ICE after conflicting types of redeclaration [PR109619]

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

Re: [PATCH] RISC-V: Don't add fractional LMUL types to V_VLS for XTheadVector

> 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)

[committed] Fix RISC-V missing stack tie

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)

RE: [PATCH v2] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))

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

Re: [PATCH v2] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))

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,

[PATCH] Move pr114396.c from gcc.target/i386 to gcc.c-torture/execute.

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

Re: [PATCH] cpp: new built-in __EXP_COUNTER__

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

Re: [PATCH] RISC-V: Don't add fractional LMUL types to V_VLS for XTheadVector

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

RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

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

[PATCH v2] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))

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++)

Re: scheduler queue flush

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 >>>

Re: [PATCH] cpp: new built-in __EXP_COUNTER__

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 >>>

[PATCH] RISC-V: Don't add fractional LMUL types to V_VLS for XTheadVector

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

[PATCH] xtensa: Add supplementary split pattern for "*addsubx"

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

[pushed] analyzer: fix ignored constraints involving casts [PR113619]

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

Re: [PATCH] testsuite: i386: Skip gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. with Solaris as [PR114150]

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

Re: [PATCH v2] c++: direct-init of an array of class type [PR59465]

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

Re: [PATCH] c++: ICE with noexcept and local specialization, again [PR114349]

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

Re: [PATCH] c++: ICE with noexcept and local specialization [PR114114]

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

[PATCH] c++: ICE with noexcept and local specialization, again [PR114349]

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

Re: [PATCH] fortran: Ignore use statements on error [PR107426]

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

[PATCH v2] c++: direct-init of an array of class type [PR59465]

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

Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

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

Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

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

Re: [PATCH] s390: testsuite: Fix abs-4.c

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

[PATCH] RISC-V: Require a extension for ztso testcases with atomic insns

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. *

[PATCH] fortran: Ignore use statements on error [PR107426]

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

Re: [PATCH] vect: more oversized bitmask fixups

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

Re: [PATCH] vect: more oversized bitmask fixups

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

Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

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

[PATCH] s390: testsuite: Fix abs-4.c

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

scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

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

[PATCH] vect: more oversized bitmask fixups

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

Re: [PATCH v3] RISC-V: Introduce gcc attribute riscv_rvv_vector_bits for RVV

> > &, ^, | 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.

RE: [PATCH v3] RISC-V: Introduce gcc attribute riscv_rvv_vector_bits for RVV

> 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

RE: [PATCH v1] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))

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"))

RE: [PATCH v1] RISC-V: Bugfix function target attribute pollution

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

Re: [PATCH] MIPS: Add MIN/MAX.fmt instructions support for MIPS R6

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

[committed] amdgcn: Ensure gfx11 is running in cumode

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

[commmitted] amdgcn: Comment correction

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

Re: [PATCH v3] RISC-V: Introduce gcc attribute riscv_rvv_vector_bits for RVV

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

Re: [PATCH v3] RISC-V: Introduce gcc attribute riscv_rvv_vector_bits for RVV

> 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: +, -, *, /, %, &, |, ^, >>,

[committed] amdgcn: Clean up device memory in gcn-run

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

Re: [PATCH, v3] Fortran: improve array component description in runtime error message [PR30802]

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

[PATCH v2] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]

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

Re: [PATCH v1] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))

> + > + /* 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

Re: [PATCH v2] RISC-V: Introduce option -mrvv-max-lmul for RVV autovec

LGTM too :) On Mon, Mar 18, 2024 at 11:35 PM Robin Dapp wrote: > > LGTM as well. > > Regards > Robin >

Re: [PATCH v1] RISC-V: Bugfix function target attribute pollution

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:

New effective-target 'asm_goto_with_outputs' (was: [PATCH] testsuite: Fix up lra effective target)

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

Re: GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

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...)

GCN: Enable effective-target 'vect_hw_misalign'

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:

GCN: Enable effective-target 'vect_long_mult'

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:

GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

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

Re: [PATCH] tree-optimization/111736 - avoid address sanitizing of __seg_gs

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

[PING][PATCH v2 00/13] Add aarch64-w64-mingw32 target

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. >

Re: [PATCH] testsuite: vect: Don't xfail scan-tree-dump in gcc.dg/vect/bb-slp-32.c [PR96147]

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

Re: [PATCH] tree-optimization/111736 - avoid address sanitizing of __seg_gs

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

Re: [PATCH] tree-optimization/111736 - avoid address sanitizing of __seg_gs

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? > > > >

[PATCH] testsuite: vect: Don't xfail scan-tree-dump in gcc.dg/vect/bb-slp-32.c [PR96147]

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

Re: [PATCH] tree-optimization/111736 - avoid address sanitizing of __seg_gs

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 >

[PATCH] testsuite: i386: Skip gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. with Solaris as [PR114150]

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

[PATCH] tree-optimization/111736 - avoid address sanitizing of __seg_gs

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

Re: [PATCH] Fix runtime error for nonlinear iv vectorization(step_mult).

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

Re: [PATCH] libgcc: Fix up bitint division [PR114397]

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

[PATCH] Fix runtime error for nonlinear iv vectorization(step_mult).

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

[PATCH] libgcc: Fix up bitint division [PR114397]

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

Re: [PATCH] analyzer: Bail out on function pointer for -Wanalyzer-allocation-size

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]

Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

On Wed, 20 Mar 2024 at 18:11, François Dumont wrote: > > As proposed below I also updated gcc-13 branch. Great, thanks. > > libstdc++: [_GLIBCXX_DEBUG] Define __cpp_lib_null_iterators > > _GLIBCXX_DEBUG has now fully N3344 compliant iterator checks, we > can define >