Re: [PATCH] i386: Mark Xeon Phi ISAs as deprecated

On Wed, Dec 6, 2023 at 3:33 AM Jiang, Haochen wrote: > > > -Original Message- > > From: Jiang, Haochen > > Sent: Friday, December 1, 2023 4:51 PM > > To: Richard Biener > > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ; > > ubiz...@gmail.com > > Subject: RE: [PATCH] i386: Mark Xeon Phi ISAs

Re: [gcc15] nested functions in C

On Tue, Dec 5, 2023 at 10:16 PM Martin Uecker wrote: > > 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

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

On Tue, 5 Dec 2023, Jakub Jelinek wrote: > 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

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

LGTM On Tue, Dec 5, 2023 at 11:16 PM Christoph Müllner wrote: > > 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

[PATCH v3 4/5] LoongArch: New options -mrecip and -mrecip= with ffast-math.

When both the -mrecip and -mfrecipe options are enabled, use approximate reciprocal instructions and approximate reciprocal square root instructions with additional Newton-Raphson steps to implement single precision floating-point division, square root and reciprocal square root operations, for

[PATCH v3 2/5] LoongArch: Use standard pattern name for xvfrsqrt/vfrsqrt instructions.

Rename lasx_xvfrsqrt*/lsx_vfrsqrt* to rsqrt2 to align with standard pattern name. Define function use_rsqrt_p to decide when to use rsqrt optab. gcc/ChangeLog: * config/loongarch/lasx.md (lasx_xvfrsqrt_): Renamed to .. (rsqrt2): .. this. *

[PATCH v3 5/5] LoongArch: Vectorized loop unrolling is disable for divf/sqrtf/rsqrtf when -mrecip is enabled.

Using -mrecip generates a sequence of instructions to replace divf, sqrtf and rsqrtf. The number of generated instructions is close to or exceeds the maximum issue instructions per cycle of the LoongArch, so vectorized loop unrolling is not performed on them. gcc/ChangeLog: *

[PATCH v3 3/5] LoongArch: Redefine pattern for xvfrecip/vfrecip instructions.

Redefine pattern for [x]vfrecip instructions use rtx code instead of unspec, and enable [x]vfrecip instructions to be generated during auto-vectorization. gcc/ChangeLog: * config/loongarch/lasx.md (lasx_xvfrecip_): Renamed to .. (recip3): .. this. *

[PATCH v3 1/5] LoongArch: Add support for LoongArch V1.1 approximate instructions.

This patch adds define_insn/builtins/intrinsics for these instructions, and add option -mfrecipe to control instruction generation. gcc/ChangeLog: * config/loongarch/genopts/isa-evolution.in (fecipe): Add. * config/loongarch/larchintrin.h (__frecipe_s): New intrinsic.

[PATCH v3 0/5] Add support for approximate instructions and optimize divf/sqrtf/rsqrtf operations.

LoongArch V1.1 adds support for approximate instructions, which are utilized along with additional Newton-Raphson steps implement single precision floating-point division, square root and reciprocal square root operations for better throughput. The patches are modifications made based on the

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

On Wed, Dec 6, 2023 at 2:31 AM Hongyu Wang wrote: > > 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,

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

Got it. Committed, thanks juzhe and kito. xu...@eswincomputing.com From: Kito Cheng Date: 2023-12-06 14:45 To: Li Xu CC: gcc-patches; palmer; juzhe.zhong Subject: Re: [PATCH] RISC-V: Remove useless modes You could add [NFC] to the title for this kind of patch to declare its clean up or

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

Do vector crypto instruction demand RATIO ? If no, add them into: ;; It is valid for instruction that require sew/lmul ratio. (define_attr "ratio" "" (cond [(eq_attr "type" "vimov,vfmov,vldux,vldox,vstux,vstox,\ vialu,vshift,vicmp,vimul,vidiv,vsalu,\

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

+if (!((strcmp (instance.base_name, "vghsh") == 0 + || strcmp (instance.base_name, "vgmul") == 0 + || strcmp (instance.base_name, "vaesz") == 0 + || strcmp (instance.base_name, "vsha2ms") == 0 + || strcmp (instance.base_name, "vsha2ch") == 0 + ||

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

You could add [NFC] to the title for this kind of patch to declare its clean up or refactor patch without change any function or feature, that would be easier for reviewer, anyway LGTM as well On Wed, Dec 6, 2023 at 12:50 PM Li Xu wrote: > > From: xuli > > gcc/ChangeLog: > > *

[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

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

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.

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

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

[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

[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

[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

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

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

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

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

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

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

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

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

[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

[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

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 >

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

[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

[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: *

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

[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

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

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

[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

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.

[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

[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

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

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

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

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

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

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

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

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

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,

[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

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

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,

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

[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

[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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

[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

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

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

[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 [[]] [[]];.

[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

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

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

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

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

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

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

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

[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

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

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

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

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

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

  1   2   3   >