[PATCH v4 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the standard 'Zicond' extension are functionally

[PATCH v4 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

PATCH v1: PATCH v2: PATCH v3: Changes: v1 -> v2 * Removed bogus opt2 pattern as pointed

Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

On 2023/09/06 8:01, Max Filippov wrote: > Hi Suwa-san, Hi! > > On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa > wrote: >> >> This patch optimizes the boolean evaluation for equality to 0 in SImode >> using the MINU (Minimum Value Unsigned) machine instruction available >> when

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

On 2023/9/6 8:31, Jeff Law wrote: On 9/3/23 22:49, Lehua Ding wrote: This patch adds a combined pattern for combining vfsqrt.v and vcond_mask. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_): Add sqrt + vcond_mask combine pattern. * config/riscv/autovec.md (2):

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

Reading the manual again, it seems I missed something in the manual before, the MASK syntax already says we can specify Var to select the variable other than target_flags, but I tried that not work when we only declare Mask with Var (e.g. "Mask(VECTOR_ELEN_32) Var(riscv_vector_elen_flags)" still

[pushed] c++: [[no_unique_address]] and cv-qualified type

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were checking for overlap using same_type_p and therefore allocating two Empty subobjects at the same offset because one was cv-qualified. This gives the warning at the location of the class name rather than the member declaration, but

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On Tue, 05 Sep 2023 20:07:16 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On 9/5/23 20:33, Tsukasa OI wrote: Internally we have this as: (TARGET_ZICOND || TARGET_XVENTANACONDOPS) I don't really care, so I'm happy to go with yours. Because XVentanaCondOps instructions are only available

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 9/5/23 20:33, Tsukasa OI wrote: Internally we have this as: (TARGET_ZICOND || TARGET_XVENTANACONDOPS) I don't really care, so I'm happy to go with yours. Because XVentanaCondOps instructions are only available on 64-bit target (I wanted to prevent misuses because we don't reject

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

RISC-V qemu default that to false, which mean stack can't execute anything by default, that's match RISC-V linux kernel behaviour, but the problem is risc-v bare metal toolchain may execute code on stack *without* that tag, that does not cause problems before for running tests on qemu user mode,

[COMMITTED] RISC-V: typo: add closing paren to a comment

From: Tsukasa OI gcc/ChangeLog: * config/riscv/zicond.md: Add closing parent to a comment. --- gcc/config/riscv/zicond.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md index 1721e1011ea8..c28bee5d5709 100644

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 2023/09/06 9:17, Jeff Law wrote: > > > On 9/5/23 06:10, Tsukasa OI wrote: >> From: Tsukasa OI >> >> 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems >> containing two instructions for conditional move and will be supported on >> their Veyron V1 CPU. >> >> And most notably

[PATCH v3] RISC-V:Optimize the MASK opt generation

This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt generation" and add the new explanation in the options.texi. Please check the detail info on the "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html; gcc/ChangeLog: * config/riscv/riscv-opts.h

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

On 2023/09/06 10:22, Jeff Law wrote: > > > On 9/5/23 06:08, Tsukasa OI wrote: >> From: Tsukasa OI >> >> Large constant cons and/or alt will trigger ICEs building GCC target >> libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. >> >> For instance, zicond-ice-2.c (new test

Re: Re: [PATCH 2/2] [RISC-V] Enalble zcmp for -Os

On 2023-09-05 20:02  Kito Cheng wrote: > >> @@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct riscv_frame_info >> *frame) >>  { >>    if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed >>    || cfun->machine->interrupt_handler_p || cfun->machine->varargs_size >>!= 0

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

On 9/5/23 06:08, Tsukasa OI wrote: From: Tsukasa OI Large constant cons and/or alt will trigger ICEs building GCC target libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. For instance, zicond-ice-2.c (new test case in this commit) will cause an ICE when SOME_NUMBER

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Tue, Sep 05, 2023 at 09:31:56PM +0800, Xi Ruoyao wrote: > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > > * Support options for LoongArch SIMD extensions: > >   new configure options --with-simd={none,lsx,lasx}; > >   new compiler option -msimd={none,lsx,lasx}; > >   new driver options

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

On 9/3/23 22:49, Lehua Ding wrote: This patch adds a combined pattern for combining vfsqrt.v and vcond_mask. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_): Add sqrt + vcond_mask combine pattern. * config/riscv/autovec.md (2): Change define_expand to

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 9/5/23 06:10, Tsukasa OI wrote: From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the

Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

Hi Suwa-san, On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa wrote: > > This patch optimizes the boolean evaluation for equality to 0 in SImode > using the MINU (Minimum Value Unsigned) machine instruction available > when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x,

Re: [PATCH] c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

On Tue, 5 Sep 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > Now that _Float{16,32,64,128,32x,64x,128x} and > {f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard, > I think it is undesirable to pedwarn about these for -std=c2x, so this > patch uses pedwarn_c11 instead.

Re: [PATCH 13/12 v2] C _BitInt incremental fixes [PR102989]

On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > On Thu, Aug 10, 2023 at 12:10:07PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Here is an incremental patch which does that: > > Bootstrap/regtest on i686-linux (next to x86_64-linux where it went fine) > revealed I forgot to add {

Re: [PATCH 10/12] C _BitInt support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > This patch adds the C FE support, c-family support, small libcpp change > so that 123wb and 42uwb suffixes are handled plus glimits.h change > to define BITINT_MAXWIDTH macro. > > The previous patches really do nothing without

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

On Tue, Sep 5, 2023 at 2:51 PM Jakub Jelinek wrote: > > On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote: > > > I admit it isn't really clear to me what do you want to achieve by the > > > above build_nonstandard_integer_type. Is it because of BOOLEAN_TYPE > > > or perhaps

Re: [PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

Applied to master. Thanks! Philipp. On Tue, 5 Sept 2023 at 23:57, Jeff Law wrote: > > > On 9/5/23 15:15, Christoph Muellner wrote: > > From: Christoph Müllner > > > > Some constants can be built up using LI+RORI instructions. > > The current implementation requires one of the upper 32-bits > >

Re: [PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

On 9/5/23 15:15, Christoph Muellner wrote: From: Christoph Müllner Some constants can be built up using LI+RORI instructions. The current implementation requires one of the upper 32-bits to be a zero bit, which is not neccesary. Let's drop this requirement in order to be able to synthesize

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

On 9/5/23 15:39, 钟居哲 wrote: - Why don't we use the normal reverse postorder (or postorder) approach of    computing live ranges?  Is that because we don't really need full global    live ranges? Yes. We don't need global live ranges. - Why can't we use existing code i.e. tree-ssa-live?  I

Re: [PATCH 18/12] Handle BITINT_TYPE in build_{, minus_}one_cst [PR102989]

On Tue, Sep 05, 2023 at 02:42:39PM -0700, Andrew Pinski wrote: > On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches > > Recent match.pd changes trigger ICE in build_minus_one_cst, apparently > > I forgot to handle BITINT_TYPE in these (while I've handled it in > > build_zero_cst). > > >

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote: > > I admit it isn't really clear to me what do you want to achieve by the > > above build_nonstandard_integer_type. Is it because of BOOLEAN_TYPE > > or perhaps ENUMERAL_TYPE as well? > > Yes I was worried about types where the

Re: [PATCH 18/12] Handle BITINT_TYPE in build_{, minus_}one_cst [PR102989]

On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > Recent match.pd changes trigger ICE in build_minus_one_cst, apparently > I forgot to handle BITINT_TYPE in these (while I've handled it in > build_zero_cst). > > Will commit as obvious together with the rest of the

[committed] RISC-V: Expose bswapsi for TARGET_64BIT

Various bswapsi tests are failing for rv64. More importantly, we're generating crappy code. Let's take the first test from bswapsi-1.c as an example. typedef unsigned int uint32_t; #define __const_swab32(x) ((uint32_t)(\ (((uint32_t)(x) &

Re: Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

- Why don't we use the normal reverse postorder (or postorder) approach of computing live ranges? Is that because we don't really need full global live ranges? Yes. We don't need global live ranges. - Why can't we use existing code i.e. tree-ssa-live? I suspect I already know the

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

On Tue, Sep 5, 2023 at 12:28 AM Jakub Jelinek via Gcc-patches wrote: > > On Wed, Aug 09, 2023 at 12:19:54PM -0700, Andrew Pinski via Gcc-patches wrote: > > PR tree-optimization/110937 > > PR tree-optimization/100798 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -6460,6 +6460,20

[PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

From: Christoph Müllner Some constants can be built up using LI+RORI instructions. The current implementation requires one of the upper 32-bits to be a zero bit, which is not neccesary. Let's drop this requirement in order to be able to synthesize a constant like 0x00ffL. The tests

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

Hi Juzhe, I think the general approach makes sense and it doesn't need to be perfect from the beginning as we can always iterate on it. Before continuing with a more detailed review (hopefully tomorrow) some high-level questions upfront. It would help to document some of these choices so it's

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

On Tue, Sep 5, 2023 at 5:14 AM Kito Cheng via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > committed, thanks :) > > On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches > wrote: > > > > > > > > On 8/31/23 03:05, Kito Cheng wrote: > > > We only emit that on linux target before, that not

Re: [PATCH] c++: Additional warning for name-hiding [PR12341]

On 9/4/23 13:18, priour...@gmail.com wrote: From: benjamin priour Hi, This patch was the first I wrote and had been at that time returned to me because ill-formatted. Getting busy with other things, I forgot about it. I've now fixed the formatting. Succesfully regstrapped on

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On 9/5/23 15:59, Marek Polacek wrote: On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: On 9/1/23 13:23, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In the review of P2564:

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: > On 9/1/23 13:23, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > > > In the review of P2564: > > > > it

[PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support

This patch implements "omp declare mapper" functionality for Fortran, following the equivalent support for C and C++. This version of the patch is based on the version posted for the og13 branch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623357.html and contains some significant

[PATCH 7/8] OpenMP, Fortran: Split out OMP clause checking

This patch breaks out two helper functions from openmp.cc:resolve_omp_clauses, so those parts can be reused in order to improve diagnostics (duplicate clause checking, etc.) after "declare mapper" instantiation in the patch later in this series. This is pretty mechanical -- most previous lines

[PATCH 6/8] OpenMP, Fortran: Per-directive control for gfc_trans_omp_clauses

Some of the processing done by gfc_trans_omp_clauses depends on the directive that that clause is attached to. This patch refactors two booleans and one gfc_exec_op parameter for gfc_trans_omp_clauses into a single parameter of (new) enumerated type 'toc_directive'. The same parameter is also

[PATCH 5/8] OpenMP, Fortran: Pass list number to gfc_free_omp_namelist

This is a cleanup to avoid passing an ever-longer list of boolean arguments to gfc_free_omp_namelist, in support of the Fortran "declare mapper" implementation further along this patch series. This patch isn't intended to cause any behavioural changes. 2023-09-05 Julian Brown gcc/fortran/

[PATCH 4/8] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C

This patch adds support for "declare mapper" directives (and the "mapper" modifier on "map" clauses) for C. It was previously posted for mainline here: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609041.html and for the og13 branch here:

[PATCH 3/8] OpenMP: C++ "declare mapper" support

This patch adds support for OpenMP 5.0 "declare mapper" functionality for C++. This is based on the version of the patch posted for the og13 branch here: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623353.html The following follow up patches/fixes have also been incorporated into this

[PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C)

This patch adds support for parsing general lvalues ("locator list item types") for OpenMP "map", "to" and "from" clauses to the C front-end, similar to the previously-posted patch for C++. Such syntax is permitted for OpenMP 5.0 and above. It was previously posted for mainline here:

[PATCH 0/8] OpenMP: lvalue parsing and "declare mapper" support

This series implements "lvalue" parsing for C and C++ map/to/from clauses, and "declare mapper" support for C, C++ and Fortran. This is the latter part of the series that was previously posted for mainline here: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609031.html and is

Re: [Committed] RISC-V: Add Types to Un-Typed Risc-v Instructions:

On 9/1/2023 11:02 AM, Jeff Law wrote: On 8/31/23 11:32, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the riscv instructions to ensure that no insn is left without a type attribute. Added

Re: [Committed] Add Types to Un-Typed Pic Instructions:

On 9/1/2023 6:15 AM, Jeff Law wrote: On 8/31/23 17:01, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the pic instructions to ensure that no insn is left without a type attribute. Tested

Re: [PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

Applied to master. Thanks! Philipp. On Tue, 5 Sept 2023 at 18:10, Jeff Law wrote: > > > On 9/5/23 09:42, Christoph Muellner wrote: > > From: Christoph Müllner > > > > Some constants can be built up using rotate-right instructions. > > The code that enables this can be found in

Re: [PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

On 9/5/23 09:42, Christoph Muellner wrote: From: Christoph Müllner Some constants can be built up using rotate-right instructions. The code that enables this can be found in riscv_build_integer_1(). However, this functionality is only available for Zbb, which includes the rori instruction.

[PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

From: Christoph Müllner Some constants can be built up using rotate-right instructions. The code that enables this can be found in riscv_build_integer_1(). However, this functionality is only available for Zbb, which includes the rori instruction. This patch enables this also for XTheadBb,

Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

Tobias Burnus writes: > Attached an old patch. See attached patch for the current one. > > Difference is one line: the warning that is shown in the example output > below. Python-wise, the changes seem fine. Unsure if it does the right thing, though, since I'm not familiar with the full

[Committed] RISC-V: zicond: Fix opt2 pattern

Fixes: 1d5bc3285e8a ("[committed][RISC-V] Fix 20010221-1.c with zicond") This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since in failing case, pattern semantics were not matching with asm czero.nez We start with the following src code snippet: if (a == 0) return 0;

Re: [PATCH 10/11] aarch64: Fix branch-protection error message tests

Szabolcs Nagy writes: > Update tests for the new branch-protection parser errors. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/branch-protection-attr.c: Update. > * gcc.target/aarch64/branch-protection-option.c: Update. OK, thanks. (And I agree these are better messages.

Re: [PATCH] c++: improve verify_constant diagnostic [PR91483]

On 9/1/23 20:00, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- When verify_constant complains, it's pretty terse. Consider void test () { constexpr int i = 42; constexpr const int *p = } where it says "'& i' is not a constant

Re: [PATCH 07/11] aarch64: Disable branch-protection for pcs tests

Szabolcs Nagy writes: > The tests manipulate the return address in abitest-2.h and thus not > compatible with -mbranch-protection=pac-ret+leaf or > -mbranch-protection=gcs. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/aapcs64/func-ret-1.c: Disable branch-protection. > *

Re: [PATCH 06/11] aarch64: Fix pac-ret eh_return tests

Szabolcs Nagy writes: > This is needed since eh_return no longer prevents pac-ret in the > normal return path. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/return_address_sign_1.c: Move func4 to ... > * gcc.target/aarch64/return_address_sign_2.c: ... here and fix the >

[committed] OpenMP: Avoid ICE in c_parser_omp_clause_allocate with invalid expr

I encountered an ICE when playing around. As allocate clauses are a bit separate from the allocate directive, I decided to fix it separately. Note: The check also handles alignment expression (no testcases) and C++ already checked for error_mark_node, i.e. it wasn't affected. Committed as Rev.

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On 9/1/23 13:23, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In the review of P2564: it turned out that in order to correctly handle an example in the paper, we should stop doing

Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

Attached an old patch. See attached patch for the current one. Difference is one line: the warning that is shown in the example output below. On 05.09.23 16:37, Tobias Burnus wrote: That's based on the fail https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html and on the discussion on IRC.

Re: [PATCH 05/11] aarch64: Add eh_return compile tests

Szabolcs Nagy writes: > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/eh_return-2.c: New test. > * gcc.target/aarch64/eh_return-3.c: New test. OK. I wonder if it's worth using check-function-bodies for -3.c though. It would then be easy to verify that the autiasp only occurs on

[Patch] contrib/gcc-changelog: Check whether revert-commit exists

That's based on the fail https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html and on the discussion on IRC. The problem in for the cron job was that r14-3661-g084a7cf9fb2d9cb98dfbe7d91602c840ec50b002 referenced a commit that did not exist. This was temporarily fixed by Jakub, but it

Re: [PATCH 04/11] aarch64: Do not force a stack frame for EH returns

Szabolcs Nagy writes: > EH returns no longer rely on clobbering the return address on the stack > so forcing a stack frame is not necessary. > > This does not actually change the code gen for the unwinder since there > are calls before the EH return. > > gcc/ChangeLog: > > *

Re: [PATCH 01/11] aarch64: AARCH64_ISA_RCPC was defined twice

Szabolcs Nagy writes: > gcc/ChangeLog: > > * config/aarch64/aarch64.h (AARCH64_ISA_RCPC): Remove dup. OK, thanks. Richard > --- > gcc/config/aarch64/aarch64.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h > index

Re: testsuite: Port 'check-function-bodies' to nvptx

Thomas Schwinge writes: > Hi! > > On 2023-09-04T23:05:05+0200, I wrote: >> On 2019-07-16T15:04:49+0100, Richard Sandiford >> wrote: >>> This patch therefore adds a new check-function-bodies dg-final test > >>> The regexps in parse_function_bodies are fairly general, but might >>> still need to

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even in compound-stmt of function-try-block [PR52953]

On 9/1/23 09:24, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 03:52:22PM -0400, Jason Merrill wrote: On 8/31/23 03:20, Jakub Jelinek wrote: As the following testcase shows, while check_local_shadow diagnoses most of the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]

On 9/1/23 09:34, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 05:46:28PM -0400, Jason Merrill wrote: I've suggested this to Core. Thanks. So, I'm not really sure what to do. Intuitively the patch seems right because even block externs redeclare stuff and change meaning of the identifiers

[PATCH] c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

Hi! Now that _Float{16,32,64,128,32x,64x,128x} and {f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard, I think it is undesirable to pedwarn about these for -std=c2x, so this patch uses pedwarn_c11 instead. In c-family/, we don't have that function and am not sure it would be

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > * Support options for LoongArch SIMD extensions: >   new configure options --with-simd={none,lsx,lasx}; >   new compiler option -msimd={none,lsx,lasx}; >   new driver options -m[no]-l[a]sx. Hmm... In my build (a cross compiler configured with

Re: [PATCH V2] Emit funcall external declarations only if actually used.

ping^ > ping > >> [Differences from V1: >> - Prototype for call_from_call_insn moved before comment block. >> - Reuse the `call' flag for SYMBOL_REF_LIBCALL. >> - Fallback to check REG_CALL_DECL in non-direct calls. >> - New test to check correct behavior for non-direct calls.] >> >> There are

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

在 2023/9/5 下午8:17, Xi Ruoyao 写道: On Tue, 2023-09-05 at 20:01 +0800, chenglulu wrote: 在 2023/9/5 下午7:51, Xi Ruoyao 写道: On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:   /* Note: optimize_size may vary across functions, while -m[no]-memcpy imposes a global constraint.  */   

testsuite: Port 'check-function-bodies' to nvptx (was: Add dg test for matching function bodies)

Hi! On 2023-09-04T23:05:05+0200, I wrote: > On 2019-07-16T15:04:49+0100, Richard Sandiford > wrote: >> This patch therefore adds a new check-function-bodies dg-final test >> The regexps in parse_function_bodies are fairly general, but might >> still need to be extended in future for targets

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Tue, 2023-09-05 at 20:01 +0800, chenglulu wrote: > > 在 2023/9/5 下午7:51, Xi Ruoyao 写道: > > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > > >   /* Note: optimize_size may vary across functions, > > > while -m[no]-memcpy imposes a global constraint.  */ > > >   #define

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

committed, thanks :) On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches wrote: > > > > On 8/31/23 03:05, Kito Cheng wrote: > > We only emit that on linux target before, that not problem before, > > however Qemu has fix a bug to make qemu user mode honor PT_GNU_STACK[1], > > that will cause

RE: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Tuesday, September 5, 2023 7:14 PM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode LGTM

[PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the standard 'Zicond' extension are functionally

[PATCH v3 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

PATCH v1: PATCH v2: Changes: v1 -> v2 * Removed bogus opt2 pattern as pointed out in:

[PATCH v2] RISC-V: Fix Zicond ICE on large constants

From: Tsukasa OI Large constant cons and/or alt will trigger ICEs building GCC target libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. For instance, zicond-ice-2.c (new test case in this commit) will cause an ICE when SOME_NUMBER is 0x1000 or larger. While opposite

Re: [PATCH 2/2] [RISC-V] Enalble zcmp for -Os

> @@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct riscv_frame_info > *frame) > { >if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed >|| cfun->machine->interrupt_handler_p || cfun->machine->varargs_size > != 0 > - || crtl->args.pretend_args_size != 0

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

在 2023/9/5 下午7:51, Xi Ruoyao 写道: On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:  /* Note: optimize_size may vary across functions,     while -m[no]-memcpy imposes a global constraint.  */  #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P loongarch_do_optimize_block_move_p() -#ifndef

Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote: > Hi, > > The second patch of this serie. > Regstrapped on x86_64-linux-gnu off trunk > a7d052b3200c7928d903a0242b8cfd75d131e374. Thanks for the patch. Overall, looks like great work, but there are a few nitpicks to be fixed, see

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: >  /* Note: optimize_size may vary across functions, >     while -m[no]-memcpy imposes a global constraint.  */ >  #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P  > loongarch_do_optimize_block_move_p() >   > -#ifndef HAVE_AS_EXPLICIT_RELOCS > -#define

Re: [PATCH v2] RISC-V: Optimize the MASK opt generation

Hi Feng: Thanks for the simplification, that reduces the effort of adding a new extension! Functional part looks good, but I think we may document that new syntax at gcc/gcc/doc/options.texi On Thu, Aug 31, 2023 at 11:32 AM Feng Wang wrote: > > This patch rebases the change of "[PATCH] RISC-V:

Re:[pushed] [PATCH v6 0/4] Add Loongson SX/ASX instruction support to LoongArch target.

Pushed to r14-3700. 在 2023/8/31 下午5:08, Chenghui Pan 写道: This is an update of: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628303.html Changes since last version of patch set: - "dg-skip-if"-related Changes of the g++.dg/torture/vshuf* testcases are reverted. (Replaced by

Re: [PING][PATCH] LoongArch: initial ada support on linux

Yujie Yang writes: > Hi Marc, > > Thank you for the review! > > We added -gnatea and -gnatez to CC1_SPECS for correct multilib handling, > and I believe this is currently specific to LoongArch. > > LoongArch relies on the GCC driver (via self_specs rules) to generate a > canonicalized tuple of

[COMMITTED] ada: Elide the copy in extended returns for nonlimited by-reference types

From: Eric Botcazou gcc/ada/ * gcc-interface/trans.cc (gnat_to_gnu): Really test Storage_Pool on the simple return statement. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/gcc-interface/trans.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[COMMITTED] ada: Fix spurious warning emissions

From: Ronan Desplanques Before this patch, warnings handled by `Sem_Warn.Check_References` were erroneously emitted in some cases. Here is an example of a program that, when compiled with the `-gnatwu` switch, triggered the bug: procedure Main is package T is A : Integer;

Re: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-09-05 18:32 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode From: Pan Li This patch would like to allow the VLS mode autovec for the floating-point binary

[COMMITTED] ada: Support setting task affinity on QNX

From: Johannes Kliemann QNX does not support setting the thread affinity via a POSIX API. This implementation uses QNX's native Thread_Ctl API to set the thread affinity for Ada tasks. gcc/ada/ * libgnarl/s-taprop__qnx.adb: Implement Set_Task_Affinity. Tested on x86_64-pc-linux-gnu,

[COMMITTED] ada: building_executable_programs_with_gnat.rst: fix -gnatw.x index

From: Ghjuvan Lacambre The index for this paragraph was wrong. gcc/ada/ * doc/gnat_ugn/building_executable_programs_with_gnat.rst: Fix index. * gnat_ugn.texi: Regenerate. Tested on x86_64-pc-linux-gnu, committed on master. ---

[COMMITTED] ada: Remove redundant protection against empty list

From: Piotr Trojanek Calls to First on No_List intentionally return Empty, so explicit guards against No_List are unnecessary. Code cleanup; semantics is unaffected. gcc/ada/ * sem_type.adb (Interface_Present_In_Ancestor): Remove guard against no list of interfaces; fix style

[COMMITTED] ada: Fix problematic secondary stack management in protected entry

From: Eric Botcazou The secondary stack mark goes formally out of scope before the finalizer reads it to reclaim the storage. gcc/ada/ * exp_ch9.adb (Build_Protected_Entry): Move the At_End procedure from the entry body to the inner block statement. Tested on

[COMMITTED] ada: Preserve capability validity in address arithmetic

From: Daniel King On CHERI targets where System.Address is a capability, arithmetic on addresses should avoid converting to integers and instead use the operations defined in System.Storage_Elements to perform the arithmetic directly on the System.Address object. This preserves the capability's

[COMMITTED] ada: Add guard before querying the type for its interfaces

From: Piotr Trojanek Fix crash on illegal code, when routine Iface_Present_In_Ancestor is called on the predefined String type and attempts to examine the list of interfaces. gcc/ada/ * sem_type.adb (Iface_Present_In_Ancestor): Only look at the list of interfaces for types that

[COMMITTED] ada: Fix DWARF for certain arrays

From: Tom Tromey An array whose index type is a nonstandard enum will be marked as "packed", but should not emit DW_AT_bit_stride unless it is also bit-packed. gcc/ada/ * gcc-interface/decl.cc (gnat_to_gnu_entity): Set bit-packed for constrained and unconstrained array types.

[COMMITTED] ada: Remove TBC comment, no more needed

From: Liaiss Merzougue gcc/ada/ * libgnat/s-imguti.adb: Remove comment. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/libgnat/s-imguti.adb | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/ada/libgnat/s-imguti.adb b/gcc/ada/libgnat/s-imguti.adb index

[COMMITTED] ada: Fix internal error on instantiation with private component type

From: Eric Botcazou First, this fixes an internal error on the instantiation of a nested generic package taking an array type whose component type is a private type declared in the parent package as formal type parameter. In the body of the instance, the full view of the private type is visible

[COMMITTED] ada: Remove redundant guard against an empty list of interfaces

From: Piotr Trojanek Code cleanup; semantics is unaffected. gcc/ada/ * sem_type.adb (Iface_Present_In_Ancestor): Remove guard for empty list of interfaces; the following loop will work just fine without it. Tested on x86_64-pc-linux-gnu, committed on master. ---

[COMMITTED] ada: Crash on creation of extra formals on type extension

From: Javier Miranda The compiler blows up processing an overriding dispatching function of a derived tagged type that returns a private tagged type that has an access type discriminant. gcc/ada/ * accessibility.ads (Needs_Result_Accessibility_Extra_Formal): New subprogram.

[COMMITTED] ada: Handle GNATcheck violations

From: Sheri Bernstein For the GNATcheck rule "Improper_Returns", either use pragma Annotate to exempt the violation with the rationale "early returns for performance", or refactor the code by replacing multiple returns by a single return statement with a conditional expression; this is more

  1   2   >