Re: Re: [PATCH] RISC-V: Block VLSmodes according to TARGET_MAX_LMUL and BITS_PER_RISCV_VECTOR

Hi, Robin. >> Wouldn't maybe_gt on the mode precision already suffice? I.e. do we need >> the ordered_p and the exclusion for masks? (Sure, masks never exceed >> one register anyway.) Currently, I don't see mask mode cause assertion ICE. >> Couldn't we exclude all VLS modes that exceed our min

Re: [PATCH] RISC-V: Block VLSmodes according to TARGET_MAX_LMUL and BITS_PER_RISCV_VECTOR

> I think the VLS modes are excluded exactly meet we expected. > For example, when zvl128b, LMUL = 1. > We allow allow VLS modes <= 128bit, exclude VLS modes > 128bits. > We have the same behavior as ARM SVE. I just found the ordered_p a bit unintuitive here at first sight. But when thinking about

Re: [PATCH] Restore build with GCC 4.8 to GCC 5 (was Re: [PATCH] Workaround array_slice constructor portability issues (with older g++).)

On Mon, Dec 04, 2023 at 01:19:21PM +, Richard Sandiford wrote: > >> (that takes a size) explicitly, rather than rely on template resolution. > >> In the example above this looks like: > >> > >> array_slice t (table, 3); > >> > >> or equivalently > >> > >> array_slice t = array_slice(table, 3);

Re: [PATCH] c++: Further #pragma GCC unroll C++ fix [PR112795]

On 12/5/23 01:55, Jakub Jelinek wrote: Hi! When committing the #pragma GCC unroll patch, I found I forgot one spot for diagnosting the invalid unrolls - if #pragma GCC unroll argument is dependent and the pragma is before a range for loop, the unroll tree (now, before one converted form ushort)

[PATCH v3] aarch64: Implement the ACLE instruction/data prefetch functions.

Key changes in v3: * Implement the `require_const_argument' function to ensure the nth argument in EXP represents a const-type argument in the valid range given by [minval, maxval), forgoing expansion altogether when an invalid argument is detected early on. * Whereas in the previous iter

Re: [PATCH v3 1/3] RISC-V: Add support for XCVelw extension in CV32E40P

LGTM On Tue, Nov 28, 2023 at 9:17 PM Mary Bennett wrote: > > Spec: > github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md > > Contributors: > Mary Bennett > Nandni Jamnadas > Pietra Ferreira > Charlie Keaney > Jessica Mills > Craig Blackmore > Simon

Re: [PATCH v3 2/3] RISC-V: Update XCValu constraints to match other vendors

LGTM On Tue, Nov 28, 2023 at 9:17 PM Mary Bennett wrote: > > gcc/ChangeLog: > * config/riscv/constraints.md: CVP2 -> CV_alu_pow2. > * config/riscv/corev.md: Likewise. > --- > gcc/config/riscv/constraints.md | 15 --- > gcc/config/riscv/corev.md | 4 ++-- > 2 fi

[PATCH] RISC-V: Add vec_init expander for masks [PR112854].

Hi, PR112854 shows a problem on rv32 with zvl1024b. During the course of expand_constructor we try to overlay/subreg a 64-element mask by a scalar (Pmode) register. This works for zvle512b and its maximum of 32 elements but fails for rv32 and 64 elements. To circumvent this this patch adds a ve

[PATCH v2 10/11] aarch64: Add new load/store pair fusion pass.

Hi, This is a v4 of the aarch64 load/store pair fusion pass. This addresses feedback from the review of v3 here: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637756.html I've attached the incremental change in reply to the review above. Bootstrapped/regtested as a series on aarch64-l

[PATCH] RISC-V: xtheadfmemidx: Disable if xtheadmemidx is not available

XTheadMemIdx provides register-register offsets for GP register loads/stores. XTheadFMemIdx does the same for FP registers. We've observed an issue with XTheadFMemIdx-only builds, where FP registers have been promoted to GP registers: (insn 26 22 51 (set (reg:DF 15 a5 [orig:136 ] [136])

[PATCH] RISC-V: xtheadmemidx: Document inline asm issue with memory constraint

The XTheadMemIdx support relies on the fact that memory operands that can be expressed by XTheadMemIdx instructions, will only appear as operands of such instructions. For internal instruction generation this is guaranteed by the implemenation. However, in case of inline assembly, this guarantee

Re: [PATCH] c++: Further #pragma GCC unroll C++ fix [PR112795]

On Tue, Dec 05, 2023 at 10:21:18AM -0500, Marek Polacek wrote: > On Tue, Dec 05, 2023 at 07:55:37AM +0100, Jakub Jelinek wrote: > > Hi! > > > > When committing the #pragma GCC unroll patch, I found I forgot one spot > > for diagnosting the invalid unrolls - if #pragma GCC unroll argument is > > de

Re: [PATCH v3 3/3] RISC-V: Add support for XCVbi extension in CV32E40P

On Tue, Nov 28, 2023 at 9:17 PM Mary Bennett wrote: > > Spec: > github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md > > Contributors: > Mary Bennett > Nandni Jamnadas > Pietra Ferreira > Charlie Keaney > Jessica Mills > Craig Blackmore > Simon Cook

Re: [PATCH] c++: Further #pragma GCC unroll C++ fix [PR112795]

On Tue, Dec 05, 2023 at 07:55:37AM +0100, Jakub Jelinek wrote: > Hi! > > When committing the #pragma GCC unroll patch, I found I forgot one spot > for diagnosting the invalid unrolls - if #pragma GCC unroll argument is > dependent and the pragma is before a range for loop, the unroll tree (now, >

Re: [PATCH 1/1] RISC-V: Add support for XCVbitmanip extension in CV32E40P

> index 7d7b952d817..e7d4ad1760c 100644 > --- a/gcc/config/riscv/corev.md > +++ b/gcc/config/riscv/corev.md > @@ -27,6 +27,25 @@ > >;;CORE-V EVENT LOAD >UNSPECV_CV_ELW > + > + ;;CORE-V BITMANIP > + UNSPEC_CV_BITMANIP_EXTRACT > + UNSPEC_CV_BITMANIP_EXTRACT_INSN > + UNSPEC_CV_BITMANIP_EXT

Re: [PATCH] tree-optimization/112843 - update_stmt doing wrong things

On 12/5/23 03:27, Richard Biener wrote: The following removes range_query::update_stmt and its single invocation from update_stmt_operands. That function is not supposed to look beyond the raw stmt contents of the passed stmt since there's no guarantee about the rest of the IL. I've successfull

Re: [PATCH v3 1/3] libgomp, nvptx: low-latency memory allocator

On 04/12/2023 16:04, Tobias Burnus wrote: On 03.12.23 01:32, Andrew Stubbs wrote: This patch adds support for allocating low-latency ".shared" memory on NVPTX GPU device, via the omp_low_lat_mem_space and omp_alloc.  The memory can be allocated, reallocated, and freed using a basic but fast al

Re: [PATCH] libstdc++: Add test for LWG Issue 3897

On Mon, 4 Dec 2023 at 16:42, Will Hawkins wrote: > > Hello! > > Thank you, as always, for the great work that you do on libstdc++. The > inout_ptr implementation properly handles the issue raised in LWG 3897 > but it seems like having an explicit test might be a good idea. Thanks, Will, we should

Re: [PATCH] libstdc++: Add test for LWG Issue 3897

On Tue, Dec 5, 2023 at 10:46 AM Jonathan Wakely wrote: > > On Mon, 4 Dec 2023 at 16:42, Will Hawkins wrote: > > > > Hello! > > > > Thank you, as always, for the great work that you do on libstdc++. The > > inout_ptr implementation properly handles the issue raised in LWG 3897 > > but it seems like

Re: [PATCH] c++: Implement C++ DR 2262 - Attributes for asm-definition [PR110734]

On 12/5/23 02:40, Jakub Jelinek wrote: Hi! Seems in 2017 attribute-specifier-seq[opt] was added to asm-declaration and the change was voted in as a DR. The following patch implements it by parsing the attributes and warning about them. I found one attribute parsing bug I'll send a fix for mome

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

Alex, This patch broke bootstrap on AIX. The stage1 compiler is not able to build a program and stage2 configure fails. Thanks, David

[PATCH] c++, v2: Further #pragma GCC unroll C++ fix [PR112795]

On Tue, Dec 05, 2023 at 10:07:19AM -0500, Jason Merrill wrote: > Please. Maybe check_pragma_unroll? check_unroll_factor? So like this (assuming it passes bootstrap/regtest, so far passed just GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ RUNTESTFLAGS="dg.exp='unroll*'" )? 2023-12-05 J

Re: [PATCH 1/1] RISC-V: Add support for XCVsimd extension in CV32E40P

There are few formatting issues, but I think this is generally OK for intrinsic support only, but one question before I formally say LGTM for this patch: are you interested in making it able to code gen with GNU vector and also for auto vectorization stuff? If so, I can spend more time on reviewing

Re: [PATCH v2 06/11] aarch64: Fix up aarch64_print_operand xzr/wzr case

Alex Coplan writes: > Hi, > > This is a v2 of: > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637612.html > > v1 was approved as-is, but this version pulls out the test into a helper > function which is used by later patches in the series. > > Bootstrapped/regtested as a series on aar

Re: [PATCH v5] aarch64: New RTL optimization pass avoid-store-forwarding.

Manos Anagnostakis writes: > This is an RTL pass that detects store forwarding from stores to larger loads > (load pairs). > > This optimization is SPEC2017-driven and was found to be beneficial for some > benchmarks, > through testing on ampere1/ampere1a machines. > > For example, it can transf

Re: [PATCH] libstdc++: Add test for LWG Issue 3897

On Tue, 5 Dec 2023 at 15:57, Will Hawkins wrote: > > On Tue, Dec 5, 2023 at 10:46 AM Jonathan Wakely wrote: > > > > On Mon, 4 Dec 2023 at 16:42, Will Hawkins wrote: > > > > > > Hello! > > > > > > Thank you, as always, for the great work that you do on libstdc++. The > > > inout_ptr implementation

[PATCH] remove qmtest-related Makefile targets

On GitHub, Joseph Myers (@jsm28 there) says in MentorEmbedded/qmtest#1 that the qmtest-related targets should have been removed long ago. This patch does so. Ref: https://github.com/MentorEmbedded/qmtest/issues/1 gcc/ChangeLog: * Makefile.in: Remove qmtest-related targets. --- gcc/Makef

Re: [PATCH] c++, v2: Further #pragma GCC unroll C++ fix [PR112795]

On 12/5/23 11:03, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 10:07:19AM -0500, Jason Merrill wrote: Please. Maybe check_pragma_unroll? check_unroll_factor? So like this (assuming it passes bootstrap/regtest, so far passed just GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ RUNTESTF

Re: [PATCH v3] RISC-V: Implement TLS Descriptors.

> On Nov 21, 2023, at 15:59, Fangrui Song wrote: > > On Mon, Nov 20, 2023 at 6:20 AM Tatsuyuki Ishi > wrote: >> >> This implements TLS Descriptors (TLSDESC) as specified in [1]. >> >> The 4-instruction sequence is implemented as a single RTX insn for >> simplici

[committed] libstdc++: Disable std::formatter::set_debug_format [PR112832]

Tested x86_64-linux. Pushed to trunk. Will backport to gcc-13 too. -- >8 -- All set_debug_format member functions should be guarded by the __cpp_lib_formatting_ranges macro (which is not defined yet). libstdc++-v3/ChangeLog: PR libstdc++/112832 * include/std/format (formatter::s

[PATCH] c++, v2: Fix parsing [[]][[]];

On Tue, Dec 05, 2023 at 09:45:32AM -0500, Marek Polacek wrote: > > When working on the previous patch I put [[]] [[]] asm (""); into a > > testcase, but was surprised it wasn't parsed. > > By wasn't parsed you mean we gave an error, right? I only see an error > with block-scope [[]] [[]];. Yeah.

Re: [PATCH RFC] c++: mangle function template constraints

On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely wrote: > > On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote: > > > > Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I > > push this? > > The library parts are OK. > > The variable template is_trivially_copyable_v just uses

Re: [PATCH v3 1/3] libgomp, nvptx: low-latency memory allocator

On 05.12.23 16:39, Andrew Stubbs wrote: Hence, mentioning in this section in addition that omp_low_lat_mem_space is honored on devices seems to be the better location. How about this? LGTM – Thanks! Tobias --- a/libgomp/libgomp.texi +++ b/libgomp/libgomp.texi @@ -3012,9 +3012,9 @@ value.

Re: [PATCH] c++, v2: Fix parsing [[]][[]];

On Tue, Dec 05, 2023 at 06:00:31PM +0100, Jakub Jelinek wrote: > On Tue, Dec 05, 2023 at 09:45:32AM -0500, Marek Polacek wrote: > > > When working on the previous patch I put [[]] [[]] asm (""); into a > > > testcase, but was surprised it wasn't parsed. > > > > By wasn't parsed you mean we gave an

[Patch] tsystem.h: Declare calloc/realloc #ifdef inhibit_libc

Crossref, there is are -Wbuiltin-declaration-mismatch warnings in libgcc/emutls.c, cf. https://gcc.gnu.org/PR109289 I decided to leave this to Thomas and Florian and just fix the build issue with the attached patch. That build issue was also mentioned in PR libgcc/109289. An alternative would b

Re: [Patch] tsystem.h: Declare calloc/realloc #ifdef inhibit_libc

On Tue, Dec 05, 2023 at 06:29:10PM +0100, Tobias Burnus wrote: > Crossref, there is are -Wbuiltin-declaration-mismatch warnings in > libgcc/emutls.c, > cf. https://gcc.gnu.org/PR109289 > > I decided to leave this to Thomas and Florian and just fix the build issue > with > the attached patch. Tha

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

On 05/12/2023 10:59, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote: On 05/12/2023 10:51, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote: The following patch makes libgfortran build on i686-linux after hacking up

Re: [PATCH v2] rs6000: Add new pass for replacement of contiguous addresses vector load lxv with lxvp

Hello Kewen: On 05/12/23 7:13 pm, Ajit Agarwal wrote: > Hello Kewen: > > On 04/12/23 7:31 am, Kewen.Lin wrote: >> Hi Ajit, >> >> on 2023/12/1 17:10, Ajit Agarwal wrote: >>> Hello Kewen: >>> >>> On 24/11/23 3:01 pm, Kewen.Lin wrote: Hi Ajit, Don't forget to CC David (CC-ed) :), som

[PATCH] build: unbreak bootstrap on uclinux targets [PR112762]

Tested with .../configure --target=c6x-uclinux [...] && make all-gcc, ok for trunk? -- >8 -- Currently, cross-compiling with --target=c6x-uclinux (and several other) fails due to: ../../src/gcc/config/linux.h:221:45: error: 'linux_fortify_source_default_level' was not declared in this scope #de

[PATCH] aarch64: Add missing driver-aarch64 dependencies

Ok for master? gcc/ChangeLog: * config/aarch64/x-aarch64: Add missing dependencies. diff --git a/gcc/config/aarch64/x-aarch64 b/gcc/config/aarch64/x-aarch64 index 3cf701a0a01ab00eaaafdfad14bd90ebbb1d498f..6fd638faaab7cb5bb2309d36d6dea2adf1fb8d32 100644 --- a/gcc/config/aarch64/x-aarch

aarch64 testsuite: Check entire .arch string

Add a terminating newline to various tests, and add missing extensions to some test strings. Obvious change, so I'll push it once my other option handling patches are approved (if noone objects). gcc/testsuite/ChangeLog: * gcc.target/aarch64/cpunative/native_cpu_18.c: Add \+nopauth\n

aarch64: Fix +nocrypto handling

Additionally, replace all checks for the AARCH64_FL_CRYPTO bit with checks for (AARCH64_FL_AES | AARCH64_FL_SHA2) instead. The value of the AARCH64_FL_CRYPTO bit within isa_flags is now ignored, but it is retained because removing it would make processing the data in option-extensions.def signific

aarch64: Fix +nopredres, +nols64 and +nomops

For native cpu feature detection, certain features have no entry in /proc/cpuinfo, so have to be assumed to be present whenever the detected cpu is supposed to support that feature. However, the logic for this was mistakenly implemented by excluding these features from part of aarch64_get_extensio

[PATCH] c++: fix ICE with sizeof in a template [PR112869]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CO

Re: [gcc15] nested functions in C

On Mon, 4 Dec 2023, Martin Uecker wrote: > > The key feature of lambdas (which failed to make it into C23) for this > > purpose is that you can't convert them to function pointers, which > > eliminates any need for trampolines. > > And also makes them useful only for template-like macro program

Re: [gcc15] nested functions in C

Am Dienstag, dem 05.12.2023 um 21:08 + schrieb Joseph Myers: > On Mon, 4 Dec 2023, Martin Uecker wrote: > > > > The key feature of lambdas (which failed to make it into C23) for this > > > purpose is that you can't convert them to function pointers, which > > > eliminates any need for trampo

Re: [PATCH] btf: avoid wrong DATASEC entries for extern vars [PR112849]

On 12/4/23 15:47, David Faust wrote: The process of creating BTF_KIND_DATASEC records involves iterating through variable declarations, determining which section they will be placed in, and creating an entry in the appropriate DATASEC record accordingly. For variables without e.g. an explicit __

[[PATCH][GCC13] 0/2] Fix combined tree build of GCC 13 with Binutils 2.41

Hello, To resolve the issue of combined Binutils (2.41) + GCC (13) failing to install (https://sourceware.org/bugzilla/show_bug.cgi?id=31108), we will need some backports. This specific issue is with using --enable-shared in the combined tree build; it arises due to missing install-* dependencies

[[PATCH][GCC13] 1/2] bfd: linker: merge .sframe sections

The linker merges all the input .sframe sections. When merging, the linker verifies that all the input .sframe sections have the same abi/arch. The linker uses libsframe library to perform key actions on the .sframe sections - decode, read, and create output data. This implies buildsystem change

[[PATCH][GCC13] 2/2] toplevel: Makefile.def: add install-strip dependency on libsframe

As noted in PR libsframe/30014 - FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe, the install time dependencies of libbfd need to be updated. ChangeLog: * Makefile.def: Reflect that libsframe needs to installed before libbfd. Reorder a bit to better

Re: [[PATCH][GCC13] 0/2] Fix combined tree build of GCC 13 with Binutils 2.41

On Tue, Dec 05, 2023 at 01:36:30PM -0800, Indu Bhagat wrote: > To resolve the issue of combined Binutils (2.41) + GCC (13) failing to > install (https://sourceware.org/bugzilla/show_bug.cgi?id=31108), we will > need some backports. This specific issue is with using --enable-shared > in the combine

[PATCH] libiberty: Fix build with GCC < 7

Hi! Tobias reported on IRC that the linker fails to build with GCC 4.8.5. In configure I've tried to use everything actually used in the sha1.c x86 hw implementation, but unfortunately I forgot about implicit function declarations. GCC before 7 did have header and bit_SHA define and __get_cpuid

Re: [PATCH] btf: avoid wrong DATASEC entries for extern vars [PR112849]

On 12/5/23 13:28, Indu Bhagat wrote: > On 12/4/23 15:47, David Faust wrote: >> The process of creating BTF_KIND_DATASEC records involves iterating >> through variable declarations, determining which section they will be >> placed in, and creating an entry in the appropriate DATASEC record >> acc

[PATCH] lower-bitint: Fix arithmetics followed by extension by many bits [PR112809]

Hi! A zero or sign extension from result of some upwards_2limb operation is implemented in lower_mergeable_stmt as an extra loop which fills in the extra bits with 0s or 1s. If the delta of extended vs. unextended bit count is small, the code doesn't use a loop and emits up to a couple of stores t

[PATCH] i386: Move vzeroupper pass from after reload pass to after postreload_cse [PR112760]

Hi! Regardless of the outcome of the REG_UNUSED discussions, I think it is a good idea to move the vzeroupper pass one pass later. As can be seen in the multiple PRs and as postreload.cc documents, reload/LRA is known to create dead statements quite often, which is the reason why we have postreloa

Re: [PATCH] libiberty: Fix build with GCC < 7

On Tue, Dec 5, 2023 at 2:06 PM Jakub Jelinek wrote: > > Ok for trunk (both gcc and binutils)? > > 2023-12-05 Jakub Jelinek > > * configure.ac (HAVE_X86_SHA1_HW_SUPPORT): Verify __get_cpuid and > __get_cpuid_count are not implicitly declared. > * configure: Regenerated.

Re: Modula-2: Support '-isysroot [...]'

Thomas Schwinge writes: > Hi! > > OK to push the attached "Modula-2: Support '-isysroot [...]'"? > > This greatly improves test results for the cross configurations I've > tested, but I don't know if any real handling needs to be implemented, or > this should be done differently altogether? > > >

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

The error is: ld: 0711-317 ERROR: Undefined symbol: __cxa_thread_atexit_impl from the new, weak reference. Also, earlier in atexit_thread.cc, there is another definition protected by _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL not utilized by the new reference. Thanks, David On Tue, Dec 5, 2

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

On Tue, Dec 5, 2023 at 3:15 PM David Edelsohn wrote: > > The error is: > > ld: 0711-317 ERROR: Undefined symbol: __cxa_thread_atexit_impl > > > from the new, weak reference. By the way this seems like the same issue on nvptx too. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858 which has a

[committed] libstdc++: Redefine __glibcxx_assert to work in C++23 constexpr

Tested x86_64-linux. Pushed to trunk. Might be worth backporting too, but it can wait. -- >8 -- The changes in r14-5979 to support unknown references in constant expressions caused some test regressions. The way that __glibcxx_assert is defined for constant evaluation no longer works when _GLIBCX

Re: [PATCH] libstdc++: Implement LGW 4016 for std::ranges::to

On Thu, 30 Nov 2023 at 15:53, Jonathan Wakely wrote: > > Before pushing I'll fix the summary to say "LWG" instead of "LGW" (the > airport code for London Gatwick!) Pushed to trunk now. > > On Thu, 30 Nov 2023 at 15:51, Jonathan Wakely wrote: > > > > This hasn't been finally approved by LWG yet, b

Re: [PATCH] libstdc++: Add workaround to std::ranges::subrange [PR111948]

On Thu, 30 Nov 2023 at 15:52, Jonathan Wakely wrote: > > I think I'll push this to work around the compiler bug. We can revert it > later if the front end gets fixed. > > Tested x86_64-linux. Needed on trunk and gcc-13. Pushed to trunk now. > > -- >8 -- > > libstdc++-v3/ChangeLog: > > PR

Re: [[PATCH][GCC13] 0/2] Fix combined tree build of GCC 13 with Binutils 2.41

On 12/5/23 13:45, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 01:36:30PM -0800, Indu Bhagat wrote: To resolve the issue of combined Binutils (2.41) + GCC (13) failing to install (https://sourceware.org/bugzilla/show_bug.cgi?id=31108), we will need some backports. This specific issue is with us

Re: [PATCH] libstdc++: implement std::generator

On Sat, 18 Nov 2023 at 19:50, Arsen Arsenović wrote: > > libstdc++-v3/ChangeLog: > > * include/Makefile.am: Install std/generator, bits/elements_of.h > as freestanding. > * include/Makefile.in: Regenerate. > * include/bits/version.def: Add __cpp_lib_generator. >

[PATCH] RISC-V: Remove xfail from ssa-fre-3.c testcase

Ran the test case at 122e7b4f9d0c2d54d865272463a1d812002d0a5c where the xfail was introduced. The test did pass at that hash and has continued to pass since then. Remove the xfail gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/ssa-fre-3.c: Remove xfail Signed-off-by: Edwin Lu --- gcc/test

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

Hello, David, On Dec 5, 2023, David Edelsohn wrote: > This patch broke bootstrap on AIX. The stage1 compiler is not able to > build a program and stage2 configure fails. Thanks for the report. sorry about the breakage. If the patch makes any difference, this suggests that __GXX_WEAK__ is def

Re: [PATCH v5] Introduce strub: machine-independent stack scrubbing

On Dec 5, 2023, Alexandre Oliva wrote: > I intend to install this as part of the monster patch upthread. I tweaked it a little further, so that exceptions don't mess with the pattern counts, and extending the same anti-vrp measure to the other strub-const tests, even though they weren't affecte

Re: [PATCH] RISC-V: Add vec_init expander for masks [PR112854].

LGTM. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-12-05 23:13 To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai CC: rdapp.gcc Subject: [PATCH] RISC-V: Add vec_init expander for masks [PR112854]. Hi, PR112854 shows a problem on rv32 with zvl1024b. During the course

Re: [PATCH] i386: Move vzeroupper pass from after reload pass to after postreload_cse [PR112760]

On Wed, Dec 6, 2023 at 6:23 AM Jakub Jelinek wrote: > > Hi! > > Regardless of the outcome of the REG_UNUSED discussions, I think > it is a good idea to move the vzeroupper pass one pass later. > As can be seen in the multiple PRs and as postreload.cc documents, > reload/LRA is known to create dead

Re: [PATCH 02/17] [APX NDD] Restrict TImode register usage when NDD enabled

Uros Bizjak 于2023年12月5日周二 18:46写道： > > On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote: > > > > Under APX NDD, previous TImode allocation will have issue that it was > > originally allocated using continuous pair, like rax:rdi, rdi:rdx. > > > > This will cause issue for all TImode NDD patterns.

[PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 There are two related issues here really, a regression since GCC 11 where we can ICE after restoring a PCH, and a deeper issue with bogus locations assigned to macros that were defined prior to restoring a PCH. This patch fixes the ICE r

[PATCH v8] Introduce attribute sym_alias

Here's an improved version that fixes some cases of making static local names visible through sym_alias, detection of symbol name clashes when sym_alias is registered before a clashing definition ("sym name" attributes are now introduced to enable sym_alias-created declarations to be identified),

Re: [PATCH] Don't vectorize when vector stmts are only vec_contruct and stores

On Mon, Dec 4, 2023 at 10:10 PM Richard Biener wrote: > > On Mon, Dec 4, 2023 at 6:32 AM liuhongt wrote: > > > > .i.e. for below cases. > >a[0] = b1; > >a[1] = b2; > >.. > >a[n] = bn; > > > > There're extra dependences when contructing the vector, but not for > > scalar store. Acc

[PATCH RFA (libstdc++)] c++: partial ordering of object parameter [PR53499]

Tested x86_64-pc-linux-gnu. Are the library test changes OK? A reduced example of the issue is at https://godbolt.org/z/cPxrcnKjG -- 8< -- Looks like we implemented option 1 (skip the object parameter) for CWG532 before the issue was resolved, and never updated to the final resolution of option

Re: [PATCH v2] rs6000: Add new pass for replacement of contiguous addresses vector load lxv with lxvp

on 2023/12/6 02:01, Ajit Agarwal wrote: > Hello Kewen: > > > On 05/12/23 7:13 pm, Ajit Agarwal wrote: >> Hello Kewen: >> >> On 04/12/23 7:31 am, Kewen.Lin wrote: >>> Hi Ajit, >>> >>> on 2023/12/1 17:10, Ajit Agarwal wrote: Hello Kewen: On 24/11/23 3:01 pm, Kewen.Lin wrote: > Hi

Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg

On Nov 19, 2023, Alexandre Oliva wrote: > On arm-eabi targets, c23 stdarg execution tests that pass arguments to > (...) functions (without any named argument), the caller passes > everything on the stack, but the callee expects arguments in > registers. Ping? This slightly modified patch only

[PATCH] testsuite: Adjust for the new permerror -Wincompatible-pointer-types

r14-6037 turned -Wincompatible-pointer-types into a permerror, which causes the following tests to fail. gcc/testsuite/ChangeLog: * gcc.dg/fixed-point/composite-type.c: replace dg-warning with dg-error. --- .../gcc.dg/fixed-point/composite-type.c | 64 +-- 1 file ch

[PATCH 1/4] RISC-V: Add crypto vector implied ISA info.

Due to the crypto vector entension is depend on the Vector extension, so the "v" info is added into implied ISA info with the corresponding crypto vector extension. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Add "v" into implied ISA info. --- gcc/common/config/riscv/riscv-comm

[PATCH 2/4] RISC-V: Add crypto vector builtin function.

This patch add the intrinsic funtions of crypto vector based on the intrinsic doc(https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob /eopc/vector-crypto/auto-generated/vector-crypto/intrinsic_funcs.md). Co-Authored by: Songhe Zhu Co-Authored by: Ciyan Pan gcc/ChangeLog: * config/r

[PATCH 3/4] RISC-V: Add crypto vector machine descriptions

This patch add the crypto machine descriptions(vector-crypto.md) and some new iterators which are used by crypto vector ext. Co-Authored by: Songhe Zhu Co-Authored by: Ciyan Pan gcc/ChangeLog: * config/riscv/iterators.md: Add rotate insn name. * config/riscv/riscv.md: Add new i

Re: [PATCH 1/4] RISC-V: Add crypto vector implied ISA info.

On 2023/12/06 11:45, Feng Wang wrote: > Due to the crypto vector entension is depend on the Vector extension, > so the "v" info is added into implied ISA info with the corresponding > crypto vector extension. Hi Feng, It's true that vector crypto extensions are based on the vector extension but i

RE: [PATCH 13/21]middle-end: Update loop form analysis to support early break

ping > -Original Message- > From: Tamar Christina > Sent: Monday, November 27, 2023 10:48 PM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: RE: [PATCH 13/21]middle-end: Update loop form analysis to support > early > break >

[PATCH]middle-end: correct loop bounds for early breaks and peeled vector loops

Hi All, While waiting for reviews I've continued to run more test. In this case this was one found running 32-bit systems. While we calculate the right latch count for the epilog, the vectorizer overrides SCEV and so unrolling goes wrong. This updates the bounds for the case where we've peeled a

[PATCH]middle-end: Fix peeled vect loop IV values.

Hi All, While waiting for reviews I found this case where both loop exit needs to go to epilogue loop, but there was an IV related variable that was used in the scalar iteration as well. vect_update_ivs_after_vectorizer then blew the value away and replaced it with the value if it took the normal

RE: [PATCH 10/21]middle-end: implement relevancy analysis support for control flow

> > > + && LOOP_VINFO_LOOP_IV_COND (loop_vinfo) != cond) > > > + *relevant = vect_used_in_scope; > > but why not simply mark all gconds as vect_used_in_scope? > We break outer-loop vectorization since doing so would pull the inner loop's exit into scope for the outerloop. Also we can't force

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

> > > is the exit edge you are looking for without iterating over all loop > > > exits. > > > > > > > + gimple *tmp_vec_stmt = vec_stmt; > > > > + tree tmp_vec_lhs = vec_lhs; > > > > + tree tmp_bitstart = bitstart; > > > > + /* For early exit

Re: [PATCH RFA (libstdc++)] c++: partial ordering of object parameter [PR53499]

Does CWG2834 effect this weird edge case? I couldn't quite grasp the standardese so I'm not really sure. These are a few cases from a test that I finalized last night. I ran this by jwakely and he agreed that the behavior as shown is correct by the standard. I'll also add that this is also the curr

Re: [PATCH RFA (libstdc++)] c++: partial ordering of object parameter [PR53499]

On 12/5/23 23:23, waffl3x wrote: Does CWG2834 effect this weird edge case? 2834 affects all partial ordering with explicit object member functions; currently the working draft says that they get an additional fake object parameter, which is clearly wrong. I couldn't quite grasp the standar

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> > > + > > > + tree truth_type = truth_type_for (vectype_op); machine_mode mode = > > > + TYPE_MODE (truth_type); int ncopies; > > > + > > more line break issues ... (also below, check yourself) > > shouldn't STMT_VINFO_VECTYPE already match truth_type here? If not > it looks to be set wrong

[PATCH] RISC-V: Remove useless modes

From: xuli gcc/ChangeLog: * config/riscv/riscv.md: Remove. --- gcc/config/riscv/riscv.md | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md index a98918dfd43..0db659acfbe 100644 --- a/gcc/config/riscv/riscv.md +++ b/gcc/config/riscv/

Re: [PATCH v2] rs6000: Add new pass for replacement of contiguous addresses vector load lxv with lxvp

On Wed, Dec 06, 2023 at 10:22:57AM +0800, Kewen.Lin wrote: > I'd expect you use UNSPEC_MMA_EXTRACT to extract V16QI from the result of > lxvp, > the current define_insn_and_split "*vsx_disassemble_pair" should be able to > take > care of it further (eg: reg and regoff). > > BR, > Kewen With Pet

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

On Dec 5, 2023, David Edelsohn wrote: > The error is: > ld: 0711-317 ERROR: Undefined symbol: __cxa_thread_atexit_impl > from the new, weak reference. Thanks. > Also, earlier in atexit_thread.cc, there is another definition protected by > _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL > not utilized

[PATCH V3 1/3]rs6000: update num_insns_constant for 2 insns

Hi, Trunk gcc supports more constants to be built via two instructions: e.g. "li/lis; xori/xoris/rldicl/rldicr/rldic". And then num_insns_constant should also be updated. Function "rs6000_emit_set_long_const" is used to build complicated constants; and "num_insns_constant_gpr" is used to compute

[PATCH V3 2/3] Using pli for constant splitting

Hi, For constant building e.g. r120=0x, which does not fit 'li or lis', 'pli' is used to build this constant via 'emit_move_insn'. While for a complicated constant, e.g. 0xULL, when using 'rs6000_emit_set_long_const' to split the constant recursively, it fails to use 'pli'

[PATCH V3 3/3] split complicate constant to memory

Hi, Sometimes, a complicated constant is built via 3(or more) instructions to build. Generally speaking, it would not be as fast as loading it from the constant pool (as a few discussions in PR63281): * "ld" is one instruction. If consider "address/toc" adjust, we may count it as 2 instructions

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

On Dec 5, 2023, Alexandre Oliva wrote: > Maybe we should narrow it down to targets in which weak undefined > symbols are available with the expected semantics, and where the symbol > is known to have ever been defined in libc. On it... This patch reintroduces the weak symbol reference only on

Re: [PATCH RFA (libstdc++)] c++: partial ordering of object parameter [PR53499]

On Tuesday, December 5th, 2023 at 9:36 PM, Jason Merrill wrote: > > > On 12/5/23 23:23, waffl3x wrote: > > > Does CWG2834 effect this weird edge case? > > > 2834 affects all partial ordering with explicit object member functions; Both in relation to each other, and to iobj and static m

Re: [PATCH] analyzer: deal with -fshort-enums

On Nov 22, 2023, Alexandre Oliva wrote: > Ah, nice, that's a great idea, I wish I'd thought of that! Will do. Sorry it took me so long, here it is. I added two tests, so that, regardless of the defaults, we get both circumstances tested, without repetition. Regstrapped on x86_64-linux-gnu. A

Re: [PATCH] RISC-V: Remove useless modes

LGTM. juzhe.zh...@rivai.ai From: Li Xu Date: 2023-12-06 12:49 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; xuli Subject: [PATCH] RISC-V: Remove useless modes From: xuli gcc/ChangeLog: * config/riscv/riscv.md: Remove. --- gcc/config/riscv/riscv.md | 1 - 1 file changed, 1 deletion(-

[PATCH v2] LoongArch: Fix eh_return epilogue for normal returns

On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved and restored in the function prologue and epilogue if the given function calls __builtin_eh_return. This causes the return value to be overwritten on normal return paths and breaks a rare case of libgcc's _Unwind_RaiseExce

<    1   2   3   >