[PATCH] testsuite/108985 - missing vect_simd_clones target requirement on test

Added. Pushed. PR testsuite/108985 * gcc.dg/vect/pr108950.c: Require vect_simd_clones. --- gcc/testsuite/gcc.dg/vect/pr108950.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/testsuite/gcc.dg/vect/pr108950.c b/gcc/testsuite/gcc.dg/vect/pr108950.c index 2163866dfa7..ecf0

[committed] openmp: Fix up error recovery for invalid structured bindings in OpenMP range for loops [PR105839]

Hi! The PR108503 temporary DECL_HAS_VALUE_EXPR_P clearing code can ICE during recovery, because cp_finish_decomp when it detects errors and reports them clears DECL_HAS_VALUE_EXPR_P, clears DECL_VALUE_EXPR and sets TREE_TYPE of the structured binding vars to error_mark_node. The PR108503 code had

Re: [PATCH 2/2] gcov: Fix incorrect gimple line LOCATION [PR97923]

On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches wrote: > > For case like belowi test.c: > > 1:int foo(char c) > 2:{ > 3: return ((c >= 'A' && c <= 'Z') > 4: || (c >= 'a' && c <= 'z') > 5: || (c >= '0' && c <='0'));} > > the generated line number is incorrect for condition c

[PATCH] fold-const: Ignore padding bits in native_interpret_expr REAL_CST reverse verification [PR108934]

Hi! In the following testcase we try to std::bit_cast a (pair of) integral value(s) which has some non-zero bits in the place of x86 long double (for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw, for 32-bit 12 byte) and starting with my PR104522 change we reject that as native_in

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

On Thu, 2 Mar 2023, juzhe.zh...@rivai.ai wrote: > >> Does the eventual value set by ADJUST_BYTESIZE equal the real number of > >> bytes loaded by vlm.v and stored by vstm.v (after the appropriate vsetvl)? > >> Or is the GCC size larger in some cases than the number of bytes > >> loaded and stored?

Re: [PATCH] fold-const: Ignore padding bits in native_interpret_expr REAL_CST reverse verification [PR108934]

On Thu, 2 Mar 2023, Jakub Jelinek wrote: > Hi! > > In the following testcase we try to std::bit_cast a (pair of) integral > value(s) which has some non-zero bits in the place of x86 long double > (for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw, > for 32-bit 12 byte) and starti

[PATCH v4 0/9] RISC-V: Add XThead* extension support

From: Christoph Müllner This series introduces support for the T-Head specific RISC-V ISA extensions which are available e.g. on the T-Head XuanTie C906. The ISA spec can be found here: https://github.com/T-head-Semi/thead-extension-spec This series adds support for the following XThead* exte

[PATCH v4 1/9] riscv: Add basic XThead* vendor extension support

From: Christoph Müllner This patch add basic support for the following XThead* ISA extensions: * XTheadBa * XTheadBb * XTheadBs * XTheadCmo * XTheadCondMov * XTheadFMemIdx * XTheadFmv * XTheadInt * XTheadMac * XTheadMemIdx * XTheadMemPair * XTheadSync The extensions are just recognized by the c

[PATCH v4 2/9] riscv: riscv-cores.def: Add T-Head XuanTie C906

From: Christoph Müllner This adds T-Head's XuanTie C906 to the list of known cores as "thead-c906". The C906 is shipped for quite some time (it is the core of the Allwinner D1). Note, that the tuning struct for the C906 is already part of GCC (it is also name "thead-c906"). gcc/ChangeLog:

[PATCH v4 4/9] riscv: thead: Add support for the XTheadBs ISA extension

From: Christoph Müllner This patch adds support for the XTheadBs ISA extension. The new INSN pattern is defined in a new file to separate this vendor extension from the standard extensions. The cost model adjustment reuses the xbs:bext cost. gcc/ChangeLog: * config/riscv/riscv.cc (riscv

[PATCH v4 3/9] riscv: thead: Add support for the XTheadBa ISA extension

From: Christoph Müllner This patch adds support for the XTheadBa ISA extension. The new INSN pattern is defined in a new file to separate this vendor extension from the standard extensions. gcc/ChangeLog: * config/riscv/riscv.md: Include thead.md * config/riscv/thead.md: New fil

[PATCH v4 5/9] riscv: thead: Add support for the XTheadBb ISA extension

From: Christoph Müllner This patch adds support for the XTheadBb ISA extension. Thus, there is a functional overlap of the new instructions with existing Bitmanip instruction, which allows a good amount of code sharing. However, the vendor extensions are cleanly separated from the standard extens

[PATCH v4 6/9] riscv: thead: Add support for the XTheadCondMov ISA extensions

From: Christoph Müllner This patch adds support for XTheadCondMov ISA extension. The extension brings a one-sided conditional move (no else-assignment). Given that GCC has a great if-conversion pass, we don't need to do much, besides properly expanding movcc accordingly and adjust the cost model.

[PATCH v4 8/9] riscv: thead: Add support for the XTheadFmv ISA extension

From: Christoph Müllner The XTheadFmv ISA extension provides instructions to move data between 32-bit GP registers and 64-bit FP registers. gcc/ChangeLog: * config/riscv/constraints.md (TARGET_XTHEADFMV ? FP_REGS : NO_REGS) New constraint "th_f_fmv". (TARGET_XTHEADFMV ?

[PATCH v4 7/9] riscv: thead: Add support for the XTheadMac ISA extension

From: Christoph Müllner The XTheadMac ISA extension provides multiply-accumulate/subtract instructions: * mula/mulaw/mulah * muls/mulsw/mulsh To benefit from middle-end passes, we expand the following named patterns in riscv.md (as they are not T-Head-specific): * maddhisi4 * msubhisi4 gcc/Chan

[PATCH v4 9/9] riscv: thead: Add support for the XTheadMemPair ISA extension

From: Christoph Müllner The XTheadMemPair ISA extension allows to pair two loads or stores: * th.ldd (2x LD) * th.lwd (2x LW) * th.lwud (2x LWU) * th.sdd (2x SD) * th.swd (2x SW) The displacement of these instructions is quite limited: * Displacement := imm2 << shamt * imm2 is a 2-bit unsigned v

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Fortunately, we won't have aggregates, arrays of vbool*_t in the future. I think it's not an issue. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-03-02 16:25 To: juzhe.zhong CC: richard.sandiford; pan2.li; gcc-patches; Pan Li; kito.cheng Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bo

Re: [PATCH 1/2] gcov: Fix "do-while" structure in case statement leads to incorrect code coverage [PR93680]

On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches wrote: > > When spliting edge with self loop, the split edge should be placed just next > to > the edge_in->src, otherwise it may generate different position latch bbs for > two consecutive self loops. For details, please refer to: > htt

Re: [PATCH] libiberty: fix memory leak in pex-win32.c and refactor

I forgot to mention that: 1) The CreateProcess documentation https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa doesn't mention anything about taking ownership of this or any other buffer passed to it. 2) The cmdline buffer gets created by

Ping: [PATCH V4] Use reg mode to move sub blocks for parameters and returns

Hi, Ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609394.html Thanks for any comments and suggestions! BR, Jeff (Jiufu) Jiufu Guo writes: > Hi, > > When assigning a parameter to a variable, or assigning a variable to > return value with struct type, "block move" ma

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Thanks for the explanation about the sizes. "juzhe.zh...@rivai.ai" writes: > Fortunately, we won't have aggregates, arrays of vbool*_t in the future. > I think it's not an issue. But isn't it possible to allocate a char/byte array and construct vbool*_ts at addresses calculated by intrinsics? E

Re: [PATCH v2] RISC-V: Bugfix for rvv bool mode precision adjustment

pan2...@intel.com writes: > From: Pan Li > > Fix the bug of the rvv bool mode precision with the adjustment. > The bits size of vbool*_t will be adjusted to > [1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The > adjusted mode precison of vbool*_t will help unde

Re: [PATCH 2/2] gcov: Fix incorrect gimple line LOCATION [PR97923]

On 2023/3/2 16:16, Richard Biener wrote: On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches wrote: For case like belowi test.c: 1:int foo(char c) 2:{ 3: return ((c >= 'A' && c <= 'Z') 4: || (c >= 'a' && c <= 'z') 5: || (c >= '0' && c <='0'));} the generated line numbe

Ping: [PATCH V2] extract DF/SF/SI/HI/QI subreg from parameter word on stack

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609396.html Thanks for comments and suggestions! I'm thinking that we may use these patches to fix some of the issues on parm and returns. Sorry for the late ping for this patch to ask if this is acceptable. BR, Jeff (Jiu

Re: [PATCH 2/2] gcov: Fix incorrect gimple line LOCATION [PR97923]

On Thu, 2 Mar 2023, Xionghu Luo wrote: > > > On 2023/3/2 16:16, Richard Biener wrote: > > On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches > > wrote: > >> > >> For case like belowi test.c: > >> > >> 1:int foo(char c) > >> 2:{ > >> 3: return ((c >= 'A' && c <= 'Z') > >> 4: || (c

Re: [PATCH] simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

Hey both, Sorry about that, don't know how I missed those. Just running a test on that now and will commit when it's done. I assume the comment and 0 -> byte change can be seen as obvious, especially since it was supposed to be in my original patch... On 27/02/2023 15:46, Richard Sandiford w

Re: [PATCH] libiberty: fix memory leak in pex-win32.c and refactor

On Thu, Mar 2, 2023 at 10:21 AM Costas Argyris wrote: > > I forgot to mention that: > > 1) The CreateProcess documentation > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa > > doesn't mention anything about taking ownership of this or an

Re: [PATCH] simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

"Andre Vieira (lists)" writes: > Hey both, > > Sorry about that, don't know how I missed those. Just running a test on > that now and will commit when it's done. I assume the comment and 0 -> > byte change can be seen as obvious, especially since it was supposed to > be in my original patch...

[PATCH] vect: Fix voluntarily-masked negative conditionals [PR108430]

vectorizable_condition checks whether a COND_EXPR condition is used elsewhere with a loop mask. If so, it applies the loop mask to the COND_EXPR too, to reduce the number of live masks and to increase the chance of combining the AND with the comparison. There is also code to do this for inverted

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

>> I realise it's a corner case. But I don't think making GET_MODE_SIZE >>bigger than the real size is conservatively correct. I don't understand which corner case will riscks wrong code. Would you mind giving me some examples? VNx8BI ABI size is the same as machine size. The only inconsistency

[PATCH] Avoid creating (const (reg ...)) [PR108603]

convert_memory_address_addr_space_1 has two modes: one in which it tries to create a self-contained RTL expression (which might fail) and one in which it can emit new instructions where necessary. When handling a CONST, the function recurses into the CONST's operand and then constifies the result.

Re: [PATCH 1/2] gcov: Fix "do-while" structure in case statement leads to incorrect code coverage [PR93680]

On 2023/3/2 16:41, Richard Biener wrote: On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches wrote: When spliting edge with self loop, the split edge should be placed just next to the edge_in->src, otherwise it may generate different position latch bbs for two consecutive self loops.

Re: [PATCH] vect: Fix voluntarily-masked negative conditionals [PR108430]

On Thu, Mar 2, 2023 at 11:19 AM Richard Sandiford via Gcc-patches wrote: > > vectorizable_condition checks whether a COND_EXPR condition is used > elsewhere with a loop mask. If so, it applies the loop mask to the > COND_EXPR too, to reduce the number of live masks and to increase the > chance of

Re: [PATCH 0/8] aarch64: testsuite: Fix test failures with --enable-default-pie or --enable-default-ssp

Xi Ruoyao writes: > Hi, > > This patch series fixes a lot of test failures with --enable-default-pie > or --enable-default-ssp for AArch64 target. Only test files are changed > to disable PIE or SSP to satisify the expectation of the developer who > programmed the test. > > Bootstrapped and regte

Re: [PATCH] Avoid creating (const (reg ...)) [PR108603]

On Thu, Mar 2, 2023 at 11:21 AM Richard Sandiford via Gcc-patches wrote: > > convert_memory_address_addr_space_1 has two modes: one in which it > tries to create a self-contained RTL expression (which might fail) > and one in which it can emit new instructions where necessary. > > When handling a

[wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

Hi! On Fri, Feb 10, 2023 at 10:06:03AM +0100, Gerald Pfeifer wrote: > Yes, thank you! Two minor suggestions/questions below: > > > --- a/htdocs/gcc-13/changes.html > > +++ b/htdocs/gcc-13/changes.html > > + -fexcess-precision=fast. The option affects mainly > > Here I'd say "mainly affects

Re: [PATCH v2] MIPS: Add buildtime option to set msa default

"Junxian Zhu" writes: > From: Junxian Zhu > > Add buildtime option to decide whether will compiler build with `-mmsa` > option default. > > gcc/ChangeLog: > * config.gcc: add -with-{no-}msa build option. > * config/mips/mips.h: Likewise. > * doc/install.texi: Likewise. Thanks,

Re: [PATCH] MIPS: Bugfix for fix Dejagnu issues with RTL checking enabled.

"Xin Liu" writes: > From: Robert Suchanek > > gcc/ChangeLog: > >* config/mips/mips.cc (mips_set_text_contents_type): Modified parameter >* config/mips/mips-protos.h (mips_set_text_contents_type): Likewise > > Signed-off-by: Xin Liu Thanks, pushed to trunk. I guess this is a regression

Re: [PATCH] libstdc++: Limit allocations in _Rb_tree 2/2

On Thu, 2 Mar 2023 at 05:40, François Dumont via Libstdc++ wrote: > > Just forget about this patch, bad idea. > > The key_type might have additional data not used for the comparison. > This data would not be preserved if we were inserting the already stored > equivalent key instead of the user pro

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

Jonathan Yong via Gcc-patches writes: > On 2/28/23 03:06, Hans-Peter Nilsson wrote: >> >> On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote: >> >>> This test is for LP64 only, exclude LLP64 too. >>> Patch OK? >> >> I may be confused, but you're not making use of the "llp64" >> effective

Re: [PATCH 1/2] gcov: Fix "do-while" structure in case statement leads to incorrect code coverage [PR93680]

On Thu, Mar 2, 2023 at 11:22 AM Xionghu Luo wrote: > > > > On 2023/3/2 16:41, Richard Biener wrote: > > On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches > > wrote: > >> > >> When spliting edge with self loop, the split edge should be placed just > >> next to > >> the edge_in->src, othe

Re: [Patch] gcc.dg/memchr-3.c: fix for LLP64

Jonathan Yong <10wa...@gmail.com> writes: > On 2/27/23 16:55, Richard Sandiford wrote: >> Jonathan Yong via Gcc-patches writes: >>> Attached patch OK? >>> >>> gcc.dg/memchr-3.c: fix for LLP64 >>> >>> gcc/testsuite/ChangeLog: >>> >>> PR middle-end/97956 >>>

[PATCH] c++, v3: Emit fundamental tinfos for _Float16/decltype(0.0bf16) types on ia32 with -mno-sse2 [PR108883]

Hi! On Wed, Mar 01, 2023 at 05:50:47PM -0500, Jason Merrill wrote: > > And then there is a question whether we want to emit rtti for > > _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless > > of whether the target supports them at all or not. > > Emitting them always would h

[PATCH] wwwdocs: Document several further C++23 changes

Hi! Tobias mentioned on IRC that assume attribute wasn't mentioned in changes.html. The P1774R8 entry was missing for C++, so I went through projects/cxx-status.html#cxx23 and filled in all the missing papers which have been implemented newly in GCC 13, plus a small note for C family about assume

Re: [wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

On 3/2/23 11:32, Jakub Jelinek wrote: > Hi! > > On Fri, Feb 10, 2023 at 10:06:03AM +0100, Gerald Pfeifer wrote: >> Yes, thank you! Two minor suggestions/questions below: >> >>> --- a/htdocs/gcc-13/changes.html >>> +++ b/htdocs/gcc-13/changes.html >>> + -fexcess-precision=fast. The option aff

Re: [PATCH] debug/108772 - ICE with late debug generated with -flto

On 3/2/23 02:43, Richard Biener wrote: On Wed, 1 Mar 2023, Jason Merrill wrote: On 3/1/23 08:09, Jakub Jelinek wrote: On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote: When combining -g1 with -flto we run into the DIE location annotation machinery for globals calling dwarf2out_l

[PATCH] target/108738 - limit STV chain discovery

The following puts a hard limit on the inherently quadratic STV chain discovery. Without a limit for the compiler.i testcase in PR26854 we see at -O2 machine dep reorg : 574.45 ( 53%) with release checking while with the proposed limit it's machine dep reorg

Re: [PATCH] wwwdocs: Document several further C++23 changes

On Thu, Mar 02, 2023 at 12:46:42PM +0100, Jakub Jelinek wrote: > Hi! > > Tobias mentioned on IRC that assume attribute wasn't mentioned in > changes.html. The P1774R8 entry was missing for C++, so I went through > projects/cxx-status.html#cxx23 and filled in all the missing papers > which have be

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

On 3/2/23 10:44, Richard Sandiford wrote: diff --git a/gcc/testsuite/gcc.dg/overflow-warn-9.c b/gcc/testsuite/gcc.dg/overflow-warn-9.c index 57c0f17bc91..ae588bd8491 100644 --- a/gcc/testsuite/gcc.dg/overflow-warn-9.c +++ b/gcc/testsuite/gcc.dg/overflow-warn-9.c @@ -59,7 +59,8 @@ const struct Ty

Re: [Patch] gcc.dg/memchr-3.c: fix for LLP64

On 3/2/23 10:46, Richard Sandiford wrote: diff --git a/gcc/testsuite/gcc.dg/memchr-3.c b/gcc/testsuite/gcc.dg/memchr-3.c index c38d9cf3349..af1b26ef3ae 100644 --- a/gcc/testsuite/gcc.dg/memchr-3.c +++ b/gcc/testsuite/gcc.dg/memchr-3.c @@ -6,7 +6,7 @@ typedef __INT8_TYPE__ int8_t; typedef __I

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

Jonathan Yong <10wa...@gmail.com> writes: > On 3/2/23 10:44, Richard Sandiford wrote: >>> diff --git a/gcc/testsuite/gcc.dg/overflow-warn-9.c >>> b/gcc/testsuite/gcc.dg/overflow-warn-9.c >>> index 57c0f17bc91..ae588bd8491 100644 >>> --- a/gcc/testsuite/gcc.dg/overflow-warn-9.c >>> +++ b/gcc/testsu

Re: [PATCH] libiberty: fix memory leak in pex-win32.c and refactor

Thanks for the review. What is the next step please? Thanks, Costas On Thu, 2 Mar 2023 at 10:08, Richard Biener wrote: > On Thu, Mar 2, 2023 at 10:21 AM Costas Argyris > wrote: > > > > I forgot to mention that: > > > > 1) The CreateProcess documentation > > > > > https://learn.microsoft.com/e

Re: [PATCH] simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

Committed attached patch. On 02/03/2023 10:13, Richard Sandiford wrote: "Andre Vieira (lists)" writes: Hey both, Sorry about that, don't know how I missed those. Just running a test on that now and will commit when it's done. I assume the comment and 0 -> byte change can be seen as obvious, e

[PATCH] vect: Don't apply masks to operations on invariants [PR108979]

The loop body in the testcase contains an operation on invariants. SLP detects this and can hoist/schedule the operation outside of the loop. However, after the fix for PR96373, we would try to apply a loop mask to this operation, even though the mask is defined in the loop. The patch does what R

RE: [PATCH v2] RISC-V: Bugfix for rvv bool mode precision adjustment

Oops, looks I missed that part for assertion. Thank you for coaching. Added and tested the below changes at the end of emit_mode_adjustments already but looks we may have other problems about the size, the precision and the C types. Looks like I need to hold this PATCH for a while until we have

Re: [PATCH] amdgcn: Enable SIMD vectorization of math functions

Hello I've made the suggested changes. Should I hold off on committing this until GCC 13 has been branched off? Kwok On 01/03/2023 10:01 am, Andrew Stubbs wrote: On 28/02/2023 23:01, Kwok Cheung Yeung wrote: Hello This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION targ

[PATCH] s390: libatomic: Fix 16 byte atomic {cas,load,store}

This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413 introducing a runtime check for alignment for 16 byte atomic compare-exchange, load, and store. Bootstrapped and regtested on s390. Ok for mainline and gcc-{12,11,10}? libatomic/ChangeLog: * config/s390/cas_n.c: New f

Re: [PATCH] vect: Don't apply masks to operations on invariants [PR108979]

> Am 02.03.2023 um 15:28 schrieb Richard Sandiford via Gcc-patches > : > > The loop body in the testcase contains an operation on invariants. > SLP detects this and can hoist/schedule the operation outside of > the loop. However, after the fix for PR96373, we would try to > apply a loop mask

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

On 3/1/23 17:33, Marek Polacek wrote: On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote: On 3/1/23 16:40, Marek Polacek wrote: On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote: On 3/1/23 15:33, Marek Polacek wrote: -Wmismatched-tags warns about the (harmless) struct/c

[PATCH] LoongArch: Stop -mfpu from silently breaking ABI

In the toolchain convention, we describe -mfpu= as: "Selects the allowed set of basic floating-point instructions and registers. This option should not change the FP calling convention unless it's necessary." Though not explicitly stated, the rationale of this rule is to allow combinations like "

Re: [PATCH] c++, v3: Emit fundamental tinfos for _Float16/decltype(0.0bf16) types on ia32 with -mno-sse2 [PR108883]

On 3/2/23 06:20, Jakub Jelinek wrote: Hi! On Wed, Mar 01, 2023 at 05:50:47PM -0500, Jason Merrill wrote: And then there is a question whether we want to emit rtti for _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless of whether the target supports them at all or not. Emi

Re: [PATCH] c++: constant non-copy-init is manifestly constant [PR108243]

On 2/21/23 15:18, Patrick Palka wrote: On Mon, 20 Feb 2023, Patrick Palka wrote: According to [basic.start.static]/2 and [expr.const]/2, a variable with static storage duration initialized with a constant initializer has constant initialization, and such an initializer is manifestly constant-ev

Re: [PATCH] c++: more mce_false folding from cp_fully_fold_init [PR108243]

On 2/21/23 14:10, Patrick Palka wrote: We should also fold the overall initializer passed to cp_fully_fold_init with mce_false, which enables folding of the copy-initialization of 'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR). Unfortunately this doesn't help with direct-

Re: [PATCH] c++: Don't defer local statics initialized with constant expressions [PR108702]

On 2/9/23 11:14, Jakub Jelinek wrote: Hi! The stmtexpr19.C testcase used to be rejected as it has a static variable in statement expression in constexpr context, but as that static variable is initialized by constant expression, when P2647R1 was implemented we agreed to make it valid. Now, as r

Re: [PATCH] c++, debug: Fix up locus of DW_TAG_imported_module [PR108716]

On 2/9/23 03:41, Jakub Jelinek wrote: Hi! Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that change we haven't emitted it at all for a while and after some time started emitting incorrect locus,

Re: [PATCH] amdgcn: Add instruction patterns for conditional min/max operations

On 01/03/2023 16:56, Paul-Antoine Arras wrote: This patch introduces instruction patterns for conditional min and max operations (cond_{f|s|u}{max|min}) in the GCN machine description. It also allows the exec register to be saved in SGPRs to avoid spilling to memory. Tested on GCN3 Fiji gfx803

Re: [PATCH] amdgcn: Enable SIMD vectorization of math functions

On 02/03/2023 15:07, Kwok Cheung Yeung wrote: Hello I've made the suggested changes. Should I hold off on committing this until GCC 13 has been branched off? No need, amdgcn is not a primary target and this stuff won't affect anyone else. Please go ahead and commit. Andrew

Re: [PATCH v2] RISC-V: Bugfix for rvv bool mode precision adjustment

"Li, Pan2" writes: > Oops, looks I missed that part for assertion. Thank you for coaching. > Added and tested the below changes at the end of emit_mode_adjustments > already but looks we may have other problems about the size, the precision > and the C types. > > Looks like I need to hold this P

Re: Ping: [PATCH] testsuite: Tweak gcc.dg/attr-aligned.c for CRIS

On Feb 27, 2023, at 5:54 PM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ping... Ok. > >> From: Hans-Peter Nilsson >> Date: Thu, 16 Feb 2023 21:05:29 +0100 > >> Asking for the lines outside the "#if __CRIS__" part. >> Ok to commit? >> >> -- >8 -- >> tm.texi says for BIGGEST_ALIGNMENT (fr

[PATCH] s390: Fix ifcvt test cases

Hi, we seem to flip flop between the "high" and "not low" variants of load on condition. Accept both in the affected test cases. Going to commit this as obvious. Regards Robin -- gcc/testsuite/ChangeLog: * gcc.target/s390/ifcvt-two-insns-bool.c: Allow "high" and "not low or

[PATCH] s390: Use arch14 instead of z16 for -march=native.

Hi, When compiling on a system where binutils do not yet support the 'z16' name assembling fails with -march=native which we currently interpret as -march=z16 (on a z16 machine). This patch uses -march=arch14 instead. Is it OK? Regards Robin -- gcc/ChangeLog: * config/s390/driver-na

[PATCH] testsuite: Do not expect partial vectorization for s390.

Hi, this patch changes SLP test expectations. As we only vectorize when no more than one rgroup is present, no vectorization is performed. I was also considering using a separate target selector (something like vect_partial_vectors_bias_m1) but as the number of testcases is limited that would pr

[pushed] analyzer: fix uninit false +ves reading from DECL_HARD_REGISTER [PR108968]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-6420-g20bd258d0fa098. gcc/analyzer/ChangeLog: PR analyzer/108968 * region-model.cc (region_model::get_rvalue_1): Handle VAR_DECLs with a DECL_HARD_REGISTER by returning UNKNOWN. gcc/tests

[PATCH] driver: Treat include path args the same way between cpp_unique_options and asm_options. [PR71850]

This is a proposal to fix PR71850 by applying the existing logic for passing include paths to cc1 to as. Thanks, Costas From 393aff0d006ee9372cc8b9321c612c2dfb4b0a31 Mon Sep 17 00:00:00 2001 From: Costas Argyris Date: Thu, 2 Mar 2023 18:27:22 + Subject: [PATCH] driver: Treat include path args

Re: [PATCH] libgccjit: Fix a failing test

Ping David. Le lun. 16 janv. 2023 à 15:08, Guillaume Gomez a écrit : > Ping David. > > Le jeu. 5 janv. 2023 à 23:37, Guillaume Gomez > a écrit : > >> Ping David. >> >> Le sam. 24 déc. 2022 à 21:01, Guillaume Gomez >> a écrit : >> >>> Ping David >>> >>> Le jeu. 15 déc. 2022 à 11:34, Guillaume G

Re: [PATCH, V3] PR 107299, GCC does not build on PowerPC when long double is IEEE 128-bit

Hi! On Wed, Dec 14, 2022 at 03:29:02PM -0500, Michael Meissner wrote: > These 3 patches fix the problems with building GCC on PowerPC systems when > long > double is configured to use the IEEE 128-bit format. If you are strictly trying to fix a bootstrap problem, you should say so: it should be

[wwwdocs] Document allocator_traits::rebind_alloc assertion with GCC 13

Pushed to wwwdocs. --- htdocs/gcc-13/porting_to.html | 60 +++ 1 file changed, 60 insertions(+) diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html index 5cbeefb6..f0ccef69 100644 --- a/htdocs/gcc-13/porting_to.html +++ b/htdocs/gcc-13/porti

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote: > > @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t) > >const int& y = (f(1), 42); // NULL_TREE > >const int& z = f(f(1)); // f(f(1)) > > - EXPR is the initializer. */ > > + EXPR is the initializer. If ARG_P i

Re: [PATCH] libgccjit: Fix a failing test

On Thu, 2022-12-15 at 08:34 +0100, Guillaume Gomez via Jit wrote: > Forgot it indeed, thanks for notifying me! > > I modified the commit message to add it and added it into this email. Sorry about the delay in reviewing this; for some reason I didn't see the mail. The patch looks good for trunk,

[PATCH] Fortran: fix CLASS attribute handling [PR106856]

Dear all, the attached patch fixes a long-standing issue with CLASS attributes when a declaration is scattered over multiple statements. The major part ("draft") of the patch is by Tobias, which I took up before it started to bit-rot too much, see PR. It is mainly about a proper updating and boo

Re: [PATCH] libgccjit: Fix a failing test

No problem, thanks for the explanations. I joined the patch with the fixed commit message. Le jeu. 2 mars 2023 à 22:58, David Malcolm a écrit : > On Thu, 2022-12-15 at 08:34 +0100, Guillaume Gomez via Jit wrote: > > Forgot it indeed, thanks for notifying me! > > > > I modified the commit messag

[pushed][PR90706] IRA: Use minimal cost for hard register movement

The following patch is for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 The patch was successfully bootstrapped and tested on i686, x86-64, aarch64, ppc64le. commit 23661e39df76e07fb4ce1ea015379c7601d947ef Author: Vladimir N. Makarov Date: Thu Mar 2 16:29:05 2023 -0500 IRA: Use

Re: [PATCH] libgccjit: Fix a failing test

Just realized I used whitespace and not a tab. Sorry about that. Here's the fixed version... Le jeu. 2 mars 2023 à 23:19, Guillaume Gomez a écrit : > No problem, thanks for the explanations. > > I joined the patch with the fixed commit message. > > Le jeu. 2 mars 2023 à 22:58, David Malcolm a é

Re: [PATCH] libgccjit: Fix a failing test

On Thu, 2023-03-02 at 23:29 +0100, Guillaume Gomez wrote: > Just realized I used whitespace and not a tab. Sorry about that. > Here's the > fixed version... Looks great. Do you have push rights, or do you want me to push this? Thanks Dave > > Le jeu. 2 mars 2023 à 23:19, Guillaume Gomez > a >

Re: [PATCH] libgccjit: Fix a failing test

I don't have push rights so if you could push it, it'd be super appreciated! Le jeu. 2 mars 2023 à 23:33, David Malcolm a écrit : > On Thu, 2023-03-02 at 23:29 +0100, Guillaume Gomez wrote: > > Just realized I used whitespace and not a tab. Sorry about that. > > Here's the > > fixed version... >

Ping: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

This is the most important patch. It is needed to allow the boostrap to work again when long double is IEEE 128-bit. | Date: Fri, 3 Feb 2023 00:49:12 -0500 | From: Michael Meissner | Subject: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit | Message-ID: -- Mich

Ping: [PATCH 2/2] Rework 128-bit complex multiply and divide.

This patch is second in importance after the first patch in the series. It is needed to allow complex IBM 128-bit multiply/divide when long double is IEEE 128-bit. | Date: Fri, 3 Feb 2023 00:53:05 -0500 | From: Michael Meissner | Subject: [PATCH 2/2] Rework 128-bit complex multiply and divide. |

Re: [PATCH] libgccjit: Fix a failing test

On Thu, 2023-03-02 at 23:35 +0100, Guillaume Gomez wrote: > I don't have push rights so if you could push it, it'd be super > appreciated! Done, as r13-6425-g6b432c0f777ab9; I took the liberty of slightly tweaking the subject line to add a "jit, testsuite: " prefix. Thanks again for the patch Dav

[r13-6414 Regression] FAIL: gcc.dg/memchr-3.c target llp64 (test for warnings, line 9) on Linux/x86_64

On Linux/x86_64, 62a8d31ecc07041af4a81353c2d57d9845c4b771 is the first bad commit commit 62a8d31ecc07041af4a81353c2d57d9845c4b771 Author: Jonathan Yong <10wa...@gmail.com> Date: Mon Feb 27 10:02:32 2023 + gcc.dg/memchr-3.c: Account for LLP64 warnings caused FAIL: gcc.dg/memchr-3.c ta

Re: [wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

On Thu, 2 Mar 2023, Jakub Jelinek wrote: > + > +#include Oops, in HTML we need to spell "<" as "<" and ">" as "> - otherwise the above would be seen as a tag by the name of stdlib.h. ;-) I pushed the follow-up patch below. Gerald commit 935fcdebfb2fb4dcd89edb51ebed5f1be0fb41e5 Author: Gerald

Re: [wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

On Fri, Mar 03, 2023 at 12:05:09AM +0100, Gerald Pfeifer wrote: > On Thu, 2 Mar 2023, Jakub Jelinek wrote: > > + > > +#include > > Oops, in HTML we need to spell "<" as "<" and ">" as "> - otherwise > the above would be seen as a tag by the name of stdlib.h. ;-) > > I pushed the follow-up patch

[PATCH v2] libcpp: Handle extended characters in user-defined literal suffix [PR103902]

The PR complains that we do not handle UTF-8 in the suffix for a user-defined literal, such as: bool operator ""_π (unsigned long long); In fact we don't handle any extended identifier characters there, whether UTF-8, UCNs, or the $ sign. We do handle it fine if the optional space after the "" to

[committed] testsuite: Fix up memchr-3.c test [PR108991]

On Thu, Mar 02, 2023 at 01:43:30PM +, Jonathan Yong via Gcc-patches wrote: > On 3/2/23 10:46, Richard Sandiford wrote: > > > diff --git a/gcc/testsuite/gcc.dg/memchr-3.c > > > b/gcc/testsuite/gcc.dg/memchr-3.c > > > index c38d9cf3349..af1b26ef3ae 100644 > > > --- a/gcc/testsuite/gcc.dg/memchr-

Re: [V4][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

Ping Qing > On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote: > > Hi, Joseph and Richard, > > Could you please review this patch and let me know whether it’s ready > for committing into GCC13? > > The fix to Bug PR101832 is an important patch for kernel security > purpose. it's better to be put i

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

Ping. Qing > On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote: > > GCC extension accepts the case when a struct with a C99 flexible array member > is embedded into another struct or union (possibly recursively). > __builtin_object_size should treat such struct as flexible size. > > gcc/c/ChangeLog

Re: [V4][PATCH 2/2] Update documentation to clarify a GCC extension

Ping. Qing > On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote: > > on a structure with a C99 flexible array member being nested in > another structure. > > "GCC extension accepts a structure containing an ISO C99 "flexible array > member", or a union containing such a structure (possibly recursive

[committed] d: Add test for PR d/108167 to the testsuite [PR108167]

Hi, This patch adds the test for checking PR108167. The D front-end implementation got fixed in upstream, add test to the gdc testsuite to check we don't regress on it. Regression tested on x86_64-linux-gnu/-m32, and committed to mainline. Regards, Iain. --- PR d/108167 gcc/testsuite/

[committed] d: Allow vectors to be compared for identity (PR108946)

Hi, Vector equality and comparisons are now accepted by the language implementation, but identity wasn't. This patch implements it as an extra integer comparison of the bit-casted bitmask. Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and committed to mainline. Regards, Iain. --

[committed] d: Fix ICE on explicit immutable struct import [PR10887]

Hi, This patch fixes an ICE in the D front-end when importing an immutable struct. Const and immutable types are built as variants of the type they are derived from, and TYPE_STUB_DECL is not set for these variants. Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed to mainli

[committed] d: vector float comparison doesn't result in 0 or -1 [PR108945]

Hi, When comparing two vectors, the type of vector was used as the result of the condition result. This meant that for floating point comparisons, each value would either be `0.0' or `-1.0' reinterpreted as an integer, not the expected integral bitmask values `0' and `-1'. Instead, use the compa

  1   2   >