[PATCH v5] RISC-V: Implement TLS Descriptors.

This implements TLS Descriptors (TLSDESC) as specified in [1]. The 4-instruction sequence is implemented as a single RTX insn for simplicity, but this can be revisited later if instruction scheduling or more flexible RA is desired. The default remains to be the traditional TLS model, but can be

Re: [PATCH] mips: Fix C23 (...) functions returning large aggregates [PR114175]

Xi Ruoyao 于2024年3月20日周三 15:12写道： > > We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named > arguments and there is nothing to advance, but that is not the case > for (...) functions returning by hidden reference which have one such > artificial argument. This is causing

[COMMITTED] Use fatal_error instead of internal_error for when ZSTD is not enabled

This changes an internal error to be a fatal error for when the ZSTD is not enabled but the section was compressed as ZSTD. Committed as approved after bootstrap/test on x86_64-linux-gnu. gcc/ChangeLog: * lto-compress.cc (lto_end_uncompression): Use fatal_error instead of

[PATCH] c++: Keep DECL_SAVED_TREE of destructor instantiations in modules [PR104040]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- A template instantiation still needs to have its DECL_SAVED_TREE so that its definition is emitted into the CMI. This way it can be emitted in the object file of any importers that use it, in case it doesn't end up getting

Re: [PATCH] LoongArch: Increase division costs

在 2024/3/27 下午8:42, Xi Ruoyao 写道: On Wed, 2024-03-27 at 18:39 +0800, Xi Ruoyao wrote: On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote: 在 2024/3/26 下午5:48, Xi Ruoyao 写道: The latency of LA464 and LA664 division instructions depends on the input.  When I updated the costs in r14-6642, I

Ping: [PATCH] mips: Fix C23 (...) functions returning large aggregates [PR114175]

Ping. On Wed, 2024-03-20 at 15:10 +0800, Xi Ruoyao wrote: > We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named > arguments and there is nothing to advance, but that is not the case > for (...) functions returning by hidden reference which have one such > artificial argument.  This

[committed] Provide suitable output template for zero_extendqihi2 on H8

Segher's recent combine change, quite unexpectedly, triggered a regression on the H8 port. It failed to build newlib. The zero_extendqihi2 pattern provided two alternatives. One where the source and destination matched. That turns into a suitable instruction trivially. The second

[PATCH] Allow `gcc_jit_type_get_size` to work with pointers

Hi, Here's a little fix to allow the `gcc_jit_type_get_size` function to work on pointer types as well. Cordially. From 21e6e2d5ea897fc74d0e3194973093c58157e6fa Mon Sep 17 00:00:00 2001 From: Guillaume Gomez Date: Tue, 26 Mar 2024 17:56:36 +0100 Subject: [PATCH] [PATH] Allow

Re: [Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization

Hi Paul, Am 28.03.24 um 16:39 schrieb Paul Richard Thomas: Hi All, The attached patch has two elements: (i) A fix for gimplifier ICEs with derived type having no components. The reporter himself suggested (thanks Kirill!): - if (derived && derived->attr.zero_comp) + if (derived &&

Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]

On Thu, Mar 28, 2024 at 3:15 PM Дилян Палаузов wrote: > > Hello Ian, > > when I add in gcc/go/config-lang.in the line > boot_language=yes > > then on stage3 x86_64-pc-linux-gnu/libbacktrace is compiled before > x86_64-pc-linux-gnu/libgo and this error is gone. > > But then Makefile.def has >

Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]

Hello Ian, when I add in gcc/go/config-lang.in the line boot_language=yes then on stage3 x86_64-pc-linux-gnu/libbacktrace is compiled before x86_64-pc-linux-gnu/libgo and this error is gone. But then Makefile.def has target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };

[PATCH] Fortran: fix NULL pointer dereference on overlapping initialization [PR50410]

Dear all, the attached simple, obvious and ancient patch from the PR fixes a NULL pointer dereference that occurs on overlapping initializations of derived types/DT components in DATA statements. Gfortran currently does not detect or report overlapping initializations in such cases, and some

[PATCH] Prettify output of debug_dwarf_die

When debugging gcc, I tried calling debug_dwarf_die and I saw this output: DW_AT_location: location descriptor: (0x7fffe9c2e870) DW_OP_dup 0, 0 (0x7fffe9c2e8c0) DW_OP_bra location descriptor (0x7fffe9c2e640) , 0 (0x7fffe9c2e820) DW_OP_lit4 4, 0

[committed] Fix failure of c-c++-common/analyzer/stdarg-pr111289-int.c on hpux

Fixes conflicting declarations of mode_t. Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Committed to trunk. Dave --- Fix failure of c-c++-common/analyzer/stdarg-pr111289-int.c on hpux 2024-03-28 John David Anglin gcc/testsuite/ChangeLog: PR analyzer/111289 *

[PATCH] c++: __is_constructible ref binding [PR100667]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The requirement that a type argument be complete is excessive in the case of direct reference binding to the same type, which does not rely on any properties of the type. This is LWG 2939. PR c++/100667 gcc/cp/ChangeLog:

[oops pushed] aarch64: Fix vld1/st1_x4 intrinsic definitions

Gah. As mentioned on irc, I'd written this patch to fix PR114521. The bug was fixed properly by Jonathan's struct rework in GCC 12, but that's much too invasive to backport. The attached patch therefore deals with the bug directly. Since it's new work, and since there's only one GCC 11 release

[COMMITTED] RISC-V: testsuite: ensure vtype is call clobbered

Per classic Vector calling convention ABI, vtype is call clobbered, so ensure gcc regenerates a VSETVLI in following cases: - after a function call. - after an inline asm fragment which clobbers vtype. ATM gcc seems to be doing the right thing, but a test can never hurt.

[Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization

Hi All, The attached patch has two elements: (i) A fix for gimplifier ICEs with derived type having no components. The reporter himself suggested (thanks Kirill!): - if (derived && derived->attr.zero_comp) + if (derived && (derived->components == NULL)) As far as I can tell, this is the

Re: [PATCH] ipa: Avoid duplicate replacements in IPA-SRA transformation phase

Hello, and ping, please. (In my copy I have fixed the formatting issue spotted by Jakub.) Martin On Fri, Mar 15 2024, Martin Jambor wrote: > Hi, > > when the analysis part of IPA-SRA figures out that it would split out > a scalar part of an aggregate which is known by IPA-CP to contain a >

Re: [PATCHv2 2/2] aarch64: Add support for _BitInt

Jakub Jelinek writes: > On Thu, Mar 28, 2024 at 03:00:46PM +, Richard Sandiford wrote: >> >* gcc.target/aarch64/bitint-alignments.c: New test. >> >* gcc.target/aarch64/bitint-args.c: New test. >> >* gcc.target/aarch64/bitint-sizes.c: New test. >> >*

Re: [PATCHv2 2/2] aarch64: Add support for _BitInt

On Thu, Mar 28, 2024 at 03:00:46PM +, Richard Sandiford wrote: > > * gcc.target/aarch64/bitint-alignments.c: New test. > > * gcc.target/aarch64/bitint-args.c: New test. > > * gcc.target/aarch64/bitint-sizes.c: New test. > > * gcc.target/aarch64/bitfield-bitint-abi.h: New

Re: [PATCHv2 2/2] aarch64: Add support for _BitInt

"Andre Vieira (lists)" writes: > This patch adds support for C23's _BitInt for the AArch64 port when > compiling for little endianness. Big Endianness requires further > target-agnostic support and we therefor disable it for now. > > The tests expose some suboptimal codegen for which I'll

Re: [PATCH] libstdc++: add ARM SVE support to std::experimental::simd

On Mittwoch, 27. März 2024 14:34:52 CET Richard Sandiford wrote: > Matthias Kretz writes: > > The big issue here is that, IIUC, a user (and the simd library) cannot do > > the right thing at the moment. There simply isn't enough context > > information available when parsing the header. I.e. > >

Re: [PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model

On 3/28/24 4:31 AM, demin.han wrote: The adjacent_dr_p is sufficient and unnecessary condition for contiguous access. So unnecessary live-ranges are added and result in spill. This patch uses MEMORY_ACCESS_TYPE as condition and constrains segment load/store. Tested on RV64 and no

[committed] predict: Fix comment typo

Hi! I've noticed a typo in a comment. Fixed thusly, committed to trunk as obvious. 2024-03-28 Jakub Jelinek * predict.cc (estimate_bb_frequencies): Fix comment typo, scalling -> scaling. --- gcc/predict.cc.jj 2024-01-18 08:44:33.593917768 +0100 +++ gcc/predict.cc

Re: [PATCH] profile-count: Avoid overflows into uninitialized [PR112303]

Hi, so what goes wrong with the testcase is the fact that after recursive inliing we have large loop nest and consequently invalid profile since every loop is predicted to iterate quite a lot. Rebuild_frequences should take care of the problem, but it doesn't since there is: if (freq_max <

Re: [PATCH] RISC-V: testsuite: ensure vtype is call clobbered

On 3/27/24 4:14 PM, Vineet Gupta wrote: Per classic Vector calling convention ABI, vtype is call clobbered, so ensure gcc generates fresh a VSETVLI after a function call or an inline asm which clobbers vtype. ATM gcc seems to be doing the right thing, but a test can never be harmful.

Re: [PATCH] profile-count: Avoid overflows into uninitialized [PR112303]

> __attribute__((noipa)) void > bar (void) > { > __builtin_exit (0); > } > > __attribute__((noipa)) void > foo (void) > { > for (int i = 0; i < 1000; ++i) > for (int j = 0; j < 1000; ++j) > for (int k = 0; k < 1000; ++k) > for (int l = 0; l < 1000; ++l) > for (int m = 0; m < 1000;

Re: [PATCHv2 1/2] aarch64: Do not give ABI change diagnostics for _BitInt(N)

"Andre Vieira (lists)" writes: > This patch makes sure we do not give ABI change diagnostics for the ABI > breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that > type did not exist before this GCC version. > > ChangeLog: > > * config/aarch64/aarch64.cc

[PATCH] c++/modules: Prefer partition indexes when installing imported entities [PR99377]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- The testcase in comment 15 of the linked PR is caused because the following assumption in depset::hash::make_dependency doesn't hold: if (DECL_LANG_SPECIFIC (not_tmpl) && DECL_MODULE_IMPORT_P (not_tmpl)) {

RE: RE: [PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model

OK，I will spilt them. Thanks. From: juzhe.zh...@rivai.ai Sent: 2024年3月28日 19:11 To: Demin Han ; gcc-patches Cc: kito.cheng ; pan2.li ; jeffreyalaw ; Robin Dapp Subject: 回复: RE: [PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model OK. It's an obvious fix but it

[PATCH 1/1] [RISCV] Add support for _Bfloat16

1 At point , BF16 has already been completed "post public review". 2 LLVM has also added support for RISCV BF16 in and . 3 According to the discussion

[PATCH 0/1] [RISCV] Add support for _Bfloat16

Hi all RISC-V folks: This patch completes the support for the bf16 data type in the riscv architecture.On this basis, there will be a series of patches in the future to strengthen support for BF16. It is recommended to first review this patch from the testcases, where detailed explanations have

回复: RE: [PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model

OK. It's an obvious fix but it seems to be unrelated to the PR. Could you split it 2 separate patches ? Thanks. juzhe.zh...@rivai.ai 发件人： Demin Han 发送时间： 2024-03-28 19:06 收件人： juzhe.zh...@rivai.ai; gcc-patches 抄送： kito.cheng; pan2.li; jeffreyalaw; Robin Dapp 主题： RE: [PATCH] RISC-V: Refine

RE: [PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model

Hi, the point starts from 1. the max_point should equal to length(); Should I prepare an individual patch for this? From: juzhe.zh...@rivai.ai Sent: 2024年3月28日 18:45 To: Demin Han ; gcc-patches Cc: kito.cheng ; pan2.li ; jeffreyalaw ; Robin Dapp Subject: Re: [PATCH] RISC-V: Refine the

[committed] testsuite: Add testcase for already fixed PR [PR109925]

Hi! This testcase was made latent by r14-4089 and got fixed both on the trunk and 13 branch with PR113372 fix. Adding testcase to the testsuite and will close the PR as a dup. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2024-03-28 Jakub Jelinek

[PATCH] profile-count: Avoid overflows into uninitialized [PR112303]

Hi! The testcase in the patch ICEs with --- gcc/tree-scalar-evolution.cc +++ gcc/tree-scalar-evolution.cc @@ -3881,7 +3881,7 @@ final_value_replacement_loop (class loop *loop) /* Propagate constants immediately, but leave an unused initialization around to avoid invalidating the

Re: [PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model

Thanks a lot for trying to optimize the dynamic LMUL cost model. The need_additional_vector_vars_p looks good to me. But - = (*program_points_per_bb.get (bb)).length () - 1; + = (*program_points_per_bb.get (bb)).length (); I wonder why you remove - 1?

[PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model

The adjacent_dr_p is sufficient and unnecessary condition for contiguous access. So unnecessary live-ranges are added and result in spill. This patch uses MEMORY_ACCESS_TYPE as condition and constrains segment load/store. Tested on RV64 and no regression. PR target/114506

Re: [PATCH] middle-end/114480 - IDF compute is slow

On Wed, 27 Mar 2024, Michael Matz wrote: > Hey, > > On Wed, 27 Mar 2024, Jakub Jelinek wrote: > > > > @@ -1712,12 +1711,9 @@ compute_idf (bitmap def_blocks, bitmap_head *dfs) > > >gcc_checking_assert (bb_index > > > < (unsigned) last_basic_block_for_fn (cfun)); > >

RE: [PATCH v1] RISC-V: Allow RVV intrinsic for more function target

I see. This failure comes from that we have zve32x (TARGET_VECTOR is true) in command line, and then we don't do the reinit in riscv_pragma_intrinsic in v1. As I understand, we need something like below, no matter TARGET_VECTOR is true or false. Int flags_backup = flags; Int new_flags = flags

RE: [PATCH v1] RISC-V: Allow RVV intrinsic for more function target

Thanks kito, looks missed this part in test, let me check it out. Pan -Original Message- From: Kito Cheng Sent: Thursday, March 28, 2024 2:44 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Allow RVV intrinsic for

Re: [committed] amdgcn: Prefer V32 on RDNA devices

Hi Andrew! On 2024-03-22T15:54:48+, Andrew Stubbs wrote: > This patch alters the default (preferred) vector size to 32 on RDNA devices to > better match the actual hardware. 64-lane vectors will continue to be > used where they are hard-coded (such as function prologues). > > We run these

Re: [PATCH v1] RISC-V: Allow RVV intrinsic for more function target

Just tried something interesting: $ riscv64-unknown-linux-gnu-gcc -march=rv64gc -O target_attribute_v_with_intrinsic-9.c -S # Work $ riscv64-unknown-linux-gnu-gcc -march=rv64gc_zve32x -O target_attribute_v_with_intrinsic-9.c -S # Not work Also I guess all zvk* and zvbb may also need to be added

Re: [PATCH] RISC-V: Add vxsat as a register

LGTM, and committed to trunk :) On Thu, Mar 28, 2024 at 5:37 AM Palmer Dabbelt wrote: > > We aren't doing anything with vxsat right now, but I'd like to add it as > an accepted register to the clobber list. If we get this into GCC-14 > then we'll avoid some preprocessor-based twiddling if we