[PATCH v2] LoongArch: Modify the address calculation logic for obtaining array element values through fp.

Modify address calculation logic from (((a x C) + fp) + offset) to ((fp + offset) + a x C). Thereby modifying the register dependencies and optimizing the code. The value of C is 2 4 or 8. The following is the assembly code before and after a loop modification in spec2006 401.bzip:

[PATCH] LoongArch: Modify the address calculation logic for obtaining array element values through fp.

Modify address calculation logic from (((a x C) + fp) + offset) to ((fp + offset) + a x C). Thereby modifying the register dependencies and optimizing the code. The value of C is 2 4 or 8. The following is the assembly code before and after a loop modification in spec2006 401.bzip:

Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

On Tue, Jan 30, 2024 at 4:35 AM Alexandre Oliva wrote: > > On Jan 19, 2024, Alexandre Oliva wrote: > > > On Jan 18, 2024, "Kewen.Lin" wrote: > >> Not sure if I missed something in the testing, could you > >> kindly double check if those test cases started to fail from r14-6275 on > >> your > >>

[tree-ssa PATCH] PR target/113560: Enhance is_widening_mult_rhs_p.

This patch resolves PR113560, a code quality regression from GCC12 affecting x86_64, by enhancing the middle-end's tree-ssa-math-opts.cc to recognize more instances of widening multiplications. The widening multiplication perception code identifies cases like: _1 = (unsigned __int128) x;

Re: [PATCH]AArch64: relax cbranch tests to accepted inverted branches [PR113502]

On Mon, Jan 29, 2024 at 5:00 PM Richard Sandiford wrote: > > Tamar Christina writes: > > Hi All, > > > > Recently something in the midend had started inverting the branches by > > inverting > > the condition and the branches. > > > > While this is fine, it makes it hard to actually test. In RTL

Re: [PATCH v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.

On Mon, Jan 29, 2024 at 1:32 PM Kito Cheng wrote: > > LGTM I've rebased, retested (rv64+rv32) and merged this patch. Thanks! > > Jin Ma 於 2024年1月29日 週一 17:57 寫道： >> >> When using '%ld' to print 'long long int' variable, 'fprintf' will >> produce messy output on a 32-bit system, in an incorrec

Re: [PATCH] strub: drop nonaliased parm from build_ref_type_for [PR113394]

> Am 30.01.2024 um 03:31 schrieb Alexandre Oliva : > >  > Variant type copies can't have their own alias sets any more, and it's > not like setting them affected the pointed-to objects anyway. > > Regstrapped on x86_64-linux-gnu; also bootstrapped with -fstrub=internal > enabled by default.

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, Jan 29, 2024 at 10:45:23PM +, Qing Zhao wrote: > There are two things here. > > 1. The value of the “counted-by” is 0; (which is easy to be understood) > 2. The result of the _builtin_object_size when see a “counted-by” 0. > > For 1, it’s simple, if we see a counted-by value <= 0, t

[PATCH] Fix some of vect-avg-*.c testcases

The vect-avg-*.c testcases are trying to make sure the AVG internal function are used and not doing promotion to `vector unsigned short` but when V4QI is implemented, `vector(2) unsigned short` shows up in the detail dump file and causes the failure. To fix this checking the optimized dump instead

Ping PATCH: testcase for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

Ping for the xfailed testsuite patch below the review (actual constexpr.cc patch to be handled separately): > From: Hans-Peter Nilsson > Date: Tue, 23 Jan 2024 05:55:00 +0100 > > > Date: Mon, 22 Jan 2024 14:33:59 -0500 > > From: Marek Polacek > > > The problem seems to be more about conversion

Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

On Jan 19, 2024, Alexandre Oliva wrote: > On Jan 18, 2024, "Kewen.Lin" wrote: >> Not sure if I missed something in the testing, could you >> kindly double check if those test cases started to fail from r14-6275 on your >> env? > My guess is that they started to fail when David attempted to bypa

Re: [PATCH] c++/modules: Handle error header names in modules [PR107594]

On 1/27/24 15:51, Nathaniel Shead wrote: I don't provide a new test because this error only happens when there are no include paths at all, and I haven't worked out a way to get this to happen within DejaGNU (as it adds a number of `-B` and `-I` flags). Bootstrapped and regtested on x86_64-pc-li

[PATCH] strub: drop nonaliased parm from build_ref_type_for [PR113394]

Variant type copies can't have their own alias sets any more, and it's not like setting them affected the pointed-to objects anyway. Regstrapped on x86_64-linux-gnu; also bootstrapped with -fstrub=internal enabled by default. Ok to install? for gcc/ChangeLog PR debug/113394

[PATCH] x86: Limit -mcmodel=large tests to lp64 target

-mcmodel=large is only supported for lp64 targets. Limit -mcmodel=large tests of libcall-1.c and pr107057.c to lp64 target. * gcc.target/i386/libcall-1.c: Limit to lp64 target. * gcc.target/i386/pr107057.c: Likewise. --- gcc/testsuite/gcc.target/i386/libcall-1.c | 2 +- gcc/tests

[PATCH] LoongArch: libsanitizer: Enable build lsan and tsan for loongarch64.

From: chenguoqi libsanitizer/ChangeLog: * configure.tgt: Enable tsan and lsan for loongarch64. * tsan/Makefile.am: Add tsan_rtl_loongarch64.S to EXTRA_libtsan_la_SOURCES. * tsan/Makefile.in: Regenerate. --- libsanitizer/configure.tgt| 5 + libsanitizer/tsan/Make

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 3:12 PM H.J. Lu wrote: > > On Mon, Jan 29, 2024 at 2:51 PM Jakub Jelinek wrote: > > > > On Mon, Jan 29, 2024 at 11:29:22PM +0100, Jakub Jelinek wrote: > > > On Mon, Jan 29, 2024 at 11:22:44PM +0100, Jakub Jelinek wrote: > > > > On Mon, Jan 29, 2024 at 02:01:56PM -0800, H.J

[Committed] RISC-V: Fix regression

Due to recent middle-end loop vectorizer changes, these tests have regression and the changes are reasonable. Adapt test to fix the regression. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c: Adapt test. * gcc.target/riscv/rvv/autovec/binop/shift-rv

Re: [PATCH] c++: unifying INTEGER_CST parm with type-dep arg [PR113644]

On 1/29/24 15:53, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Here when trying to unify P=42 A=T::value we ICE due to the latter's empty type, which same_type_p dislikes. If the argument has empty type then it can't be an

Re: [PATCH] aarch64: Check the ldp/stp policy model correctly when mem ops are reversed.

Applied to master, thanks! --Philipp. On Wed, 24 Jan 2024 at 12:43, Richard Sandiford wrote: > Manos Anagnostakis writes: > > The current ldp/stp policy framework implementation was missing cases, > where > > the memory operands were reversed. Therefore the call to the framework > function > >

[Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[I was torn towards asking gcc@ only, individual i386 maintainers in private or bluntly asking for help on gcc-patches or re-iterate through ABI, so in an attempt to cut off years of latency i hereby ask all and everybody for assistance. Stage4 means any chances are low, i know.. hence stage 1 mate

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 2:51 PM Jakub Jelinek wrote: > > On Mon, Jan 29, 2024 at 11:29:22PM +0100, Jakub Jelinek wrote: > > On Mon, Jan 29, 2024 at 11:22:44PM +0100, Jakub Jelinek wrote: > > > On Mon, Jan 29, 2024 at 02:01:56PM -0800, H.J. Lu wrote: > > > > > A function accesses a function symbol

[PATCH] Handle COMDAT function symbol reference in readonly data section

For a COMDAT function symbol reference in readonly data section, instead of putting it in .data.rel.ro or .rodata.cst section, call function_rodata_section to get the read-only or relocated read-only data section associated with the function DECL so that the COMDAT section will be used for the COMD

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 11:29:22PM +0100, Jakub Jelinek wrote: > On Mon, Jan 29, 2024 at 11:22:44PM +0100, Jakub Jelinek wrote: > > On Mon, Jan 29, 2024 at 02:01:56PM -0800, H.J. Lu wrote: > > > > A function accesses a function symbol defined in a comdat group. > > > > If the function symbol is pub

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Jan 29, 2024, at 3:19 PM, Kees Cook wrote: > > On Mon, Jan 29, 2024 at 07:32:06PM +, Qing Zhao wrote: >> >> >>> On Jan 29, 2024, at 12:25 PM, Kees Cook wrote: >>> >>> On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote: An update on the kernel building with my version 4

Re: [PATCH] c++: problematic assert in reference_binding [PR113141]

On Mon, 29 Jan 2024, Patrick Palka wrote: > On Fri, 26 Jan 2024, Jason Merrill wrote: > > > On 1/26/24 17:11, Jason Merrill wrote: > > > On 1/26/24 16:52, Jason Merrill wrote: > > > > On 1/25/24 14:18, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this loo

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 11:22:44PM +0100, Jakub Jelinek wrote: > On Mon, Jan 29, 2024 at 02:01:56PM -0800, H.J. Lu wrote: > > > A function accesses a function symbol defined in a comdat group. > > > If the function symbol is public, any comdat definition of the same group > > > signature should pro

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 02:01:56PM -0800, H.J. Lu wrote: > > A function accesses a function symbol defined in a comdat group. > > If the function symbol is public, any comdat definition of the same group > > signature should provide the function definition. If the function symbol > > is private to

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Jan 29, 2024, at 3:35 PM, Joseph Myers wrote: > > On Mon, 29 Jan 2024, Qing Zhao wrote: > >> Thank you! >> >> Joseph and Richard, could you also comment on this? > > I think Martin's suggestions are reasonable. Okay, I will update the patches based on this approach. Thanks a lot fo

Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800]

On 29 January 2024 22:06:04 CET, Harald Anlauf wrote: >Am 29.01.24 um 21:45 schrieb Bernhard Reutner-Fischer: >> On Wed, 17 Nov 2021 21:32:14 +0100 >> Harald Anlauf wrote: >> >>> Do you have testcases/reproducers demonstrating that the patch actually >>> fixes the issues you're describing? >> >

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 2:01 PM H.J. Lu wrote: > > On Mon, Jan 29, 2024 at 1:42 PM H.J. Lu wrote: > > > > On Mon, Jan 29, 2024 at 1:22 PM H.J. Lu wrote: > > > > > > On Mon, Jan 29, 2024 at 1:00 PM H.J. Lu wrote: > > > > > > > > On Mon, Jan 29, 2024 at 9:34 AM H.J. Lu wrote: > > > > > > > > > >

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 1:42 PM H.J. Lu wrote: > > On Mon, Jan 29, 2024 at 1:22 PM H.J. Lu wrote: > > > > On Mon, Jan 29, 2024 at 1:00 PM H.J. Lu wrote: > > > > > > On Mon, Jan 29, 2024 at 9:34 AM H.J. Lu wrote: > > > > > > > > On Mon, Jan 29, 2024 at 9:00 AM Jakub Jelinek wrote: > > > > > > >

[PATCH v3] x86: Generate REG_CFA_UNDEFINED for unsaved callee-saved registers

Changes in v3: 1. Fix a typo in REG_CFA_UNDEFINED note comment. 2. Replace assemble with compile in tests and remove -save-temps since ".cfi_undefined regno" is generated now. Changes in v2: 1. Add REG_CFA_UNDEFINED notes to a frame-related instruction in prologue. 2. Add comments for add_cfi_un

Re: [PATCH][libsanitizer]: Sync fixes for asan interceptors from upstream [PR112644]

On Mon, Jan 29, 2024 at 7:04 AM Tamar Christina wrote: > > Hi All, > > This cherry-picks and squashes the differences between commits > > d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63 > from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the changes relev

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 1:22 PM H.J. Lu wrote: > > On Mon, Jan 29, 2024 at 1:00 PM H.J. Lu wrote: > > > > On Mon, Jan 29, 2024 at 9:34 AM H.J. Lu wrote: > > > > > > On Mon, Jan 29, 2024 at 9:00 AM Jakub Jelinek wrote: > > > > > > > > On Mon, Jan 29, 2024 at 08:45:45AM -0800, H.J. Lu wrote: > >

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 1:00 PM H.J. Lu wrote: > > On Mon, Jan 29, 2024 at 9:34 AM H.J. Lu wrote: > > > > On Mon, Jan 29, 2024 at 9:00 AM Jakub Jelinek wrote: > > > > > > On Mon, Jan 29, 2024 at 08:45:45AM -0800, H.J. Lu wrote: > > > > In this case, these are internal to the same comdat group: >

Re: [PATCH] aarch64: enforce lane checking for intrinsics

Alexandre Oliva writes: > On Jan 23, 2024, Richard Sandiford wrote: > >> Performing the check in expand is itself wrong > > *nod* > >> So I think we should enforce the immediate range within the frontend >> instead, via TARGET_CHECK_BUILTIN_CALL. > > Sounds good. Can that accommodate the existin

Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800]

Am 29.01.24 um 21:45 schrieb Bernhard Reutner-Fischer: On Wed, 17 Nov 2021 21:32:14 +0100 Harald Anlauf wrote: Do you have testcases/reproducers demonstrating that the patch actually fixes the issues you're describing? I believe that marking artificial symbols as such is obvious and i did us

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 9:34 AM H.J. Lu wrote: > > On Mon, Jan 29, 2024 at 9:00 AM Jakub Jelinek wrote: > > > > On Mon, Jan 29, 2024 at 08:45:45AM -0800, H.J. Lu wrote: > > > In this case, these are internal to the same comdat group: > > > > But that is only by accident, no? > > This may be by lu

[PATCH] c++: unifying INTEGER_CST parm with type-dep arg [PR113644]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here when trying to unify P=42 A=T::value we ICE due to the latter's empty type, which same_type_p dislikes. If the argument has empty type then it can't be an INTEGER_CST, so unification should fail.

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

Am 29.01.24 um 18:25 schrieb Harald Anlauf: I was talking about the generated format strings of runtime error messages. program p   implicit none   type t real :: zzz(10) = 42   end type t   class(t), allocatable :: xx(:)   integer :: j   j = 0   allocate (t :: xx(1))   print *, xx

Re: [PATCH] c++: problematic assert in reference_binding [PR113141]

On Fri, 26 Jan 2024, Jason Merrill wrote: > On 1/26/24 17:11, Jason Merrill wrote: > > On 1/26/24 16:52, Jason Merrill wrote: > > > On 1/25/24 14:18, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > > OK for trunk/13?  This isn't a very satisfact

Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800]

On Wed, 17 Nov 2021 21:32:14 +0100 Harald Anlauf wrote: > Do you have testcases/reproducers demonstrating that the patch actually > fixes the issues you're describing? I believe that marking artificial symbols as such is obvious and i did use the existing tests to verify that the changes do not

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, 29 Jan 2024, Qing Zhao wrote: > Thank you! > > Joseph and Richard, could you also comment on this? I think Martin's suggestions are reasonable. -- Joseph S. Myers josmy...@redhat.com

Re: Fix ICE with -g and -std=c23 when forming composite types [PR113438]

On Sat, 27 Jan 2024, Martin Uecker wrote: > Debug output ICEs when we do not set TYPE_STUB_DECL, fix this. > > > Fix ICE with -g and -std=c23 when forming composite types [PR113438] > > Set TYPE_STUB_DECL to an artificial decl when creating a new structure > as a composite type.

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, Jan 29, 2024 at 07:32:06PM +, Qing Zhao wrote: > > > > On Jan 29, 2024, at 12:25 PM, Kees Cook wrote: > > > > On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote: > >> An update on the kernel building with my version 4 patch. > >> > >> Kees reported two FE issues with the cur

[PATCH v2] x86: Generate REG_CFA_UNDEFINED for unsaved callee-saved registers

Changes in v2: 1. Add REG_CFA_UNDEFINED notes to a frame-related instruction in prologue. 2. Add comments for add_cfi_undefined. --- Attach REG_CFA_UNDEFINED notes for unsaved callee-saved registers which have been used in the function to a frame-related instruction in prologue. gcc/ PR

Re: [PATCH] x86: Generate REG_CFA_UNDEFINED for unsaved callee-saved registers

On Mon, Jan 29, 2024 at 8:30 AM Jakub Jelinek wrote: > > On Mon, Jan 29, 2024 at 08:00:26AM -0800, H.J. Lu wrote: > > Attach REG_CFA_UNDEFINED notes for unsaved callee-saved registers which > > have been used in the function to an instruction in prologue. > > > > gcc/ > > > > PR target/38534

[PATCH] RISC-V: Fix rvv intrinsic pragma tests dejagnu selector

Adding rvv related flags (i.e. --param=riscv-autovec-preference) to non vector targets bypassed the dejagnu skip test directive. Change the target selector to skip if rvv is enabled gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/abi-1.c: change selector * gcc.target/riscv/rv

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Jan 29, 2024, at 12:25 PM, Kees Cook wrote: > > On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote: >> An update on the kernel building with my version 4 patch. >> >> Kees reported two FE issues with the current version 4 patch: >> >> 1. The operator “typeof” cannot return correct

Re: _GLIBCXX_DEBUG_BACKTRACE broken

On Mon, 29 Jan 2024 at 18:30, François Dumont wrote: > > I had missed it, thanks. > > Here is a patch to fix debug mode doc then. > > libstdc++: Fix _GLIBCXX_DEBUG_BACKTRACE macro documentation > > libstdc++-v3/ChangeLog: > > * doc/xml/manual/debug_mode.xml: Link against libstdc++exp.a to use

Re: [PATCH] aarch64: enforce lane checking for intrinsics

On Jan 23, 2024, Richard Sandiford wrote: > Performing the check in expand is itself wrong *nod* > So I think we should enforce the immediate range within the frontend > instead, via TARGET_CHECK_BUILTIN_CALL. Sounds good. Can that accommodate the existing uses in always_inline wrappers? > U

Re: _GLIBCXX_DEBUG_BACKTRACE broken

I had missed it, thanks. Here is a patch to fix debug mode doc then. libstdc++: Fix _GLIBCXX_DEBUG_BACKTRACE macro documentation libstdc++-v3/ChangeLog:     * doc/xml/manual/debug_mode.xml: Link against libstdc++exp.a to use     _GLIBCXX_DEBUG_BACKTRACE macro. Ok to commit ? François On 29/

Re: [PATCH] testsuite: no dfp run without dfprt

On Jan 24, 2024, Jeff Law wrote: > OK Thanks. FTR, there were typos (s/ṕ/p/g) and a missing entry for builtin-snan-1.c in the ChangeLog entries, that the ChangeLog checker kindly pointed out. Fixed below, just pushed along with the otherwise-unchanged patch as r14-8505. for gcc/testsuite/Cha

[COMMITTED] bpf: emit empty epilogues in naked functions

This patch fixes the BPF backend to not generate `exit' (return) instructions in epilogues of functions that are declared as naked via the corresponding compiler attribute. Having extra exit instructions upsets the kernel BPF verifier. Tested in bpf-unknown-none target in x86_64-linux-gnu host.

[Committed] RISC-V: Add require-effective-target to pr113429 testcase

Committed. Thanks for catching this. Patrick On 1/28/24 19:41, juzhe.zh...@rivai.ai wrote: ok juzhe.zh...@rivai.ai *From:* Patrick O'Neill *Date:* 2024-01-27 10:50 *To:* gcc-pat

[PATCH v2] openmp: Change to using a hashtab to lookup offload target addresses for indirect function calls

Can you please akso update the comments to talk about hashtab instead of splay? Hello This version has the comments updated and removes a stray 'volatile' in the #ifdefed out code. Thanks KwokFrom 5737298f4f5e5471667b05e207b22c9c91b94ca0 Mon Sep 17 00:00:00 2001 From: Kwok Cheung Yeung Da

[pushed] c++: local class in generic lambda [PR113544]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- My earlier commit r14-278-gd60cbbfaa9a3ad was a start toward better handling of local classes in generic lambdas, but isn't actually useful by itself and breaks this testcase, so let's revert it for now. PR c++/113544 gcc/cp/Change

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 9:00 AM Jakub Jelinek wrote: > > On Mon, Jan 29, 2024 at 08:45:45AM -0800, H.J. Lu wrote: > > In this case, these are internal to the same comdat group: > > But that is only by accident, no? This may be by luck. I don't know if gcc checks it when generating such reference

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

Am 28.01.24 um 22:43 schrieb Steve Kargl: On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote: Am 28.01.24 um 12:39 schrieb Mikael Morin: Le 24/01/2024 à 22:39, Harald Anlauf a écrit : Dear all, this patch is actually only a followup fix to generate the proper name of an array refe

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote: > An update on the kernel building with my version 4 patch. > > Kees reported two FE issues with the current version 4 patch: > > 1. The operator “typeof” cannot return correct type for a->array; > 2. The operator “&” cannot return correc

Re: [v2][patch] plugin/plugin-nvptx.c: Fix fini_device call when already shutdown [PR113513]

Hi Thomas, Thomas Schwinge wrote: On 2024-01-23T10:55:16+0100, Tobias Burnus wrote: plugin/plugin-nvptx.c: Fix fini_device call when already shutdown [PR113513] The following issue was found when running libgomp.c/target-52.c with nvptx offloading when the dg-set-target-env-var was honored.

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 08:45:45AM -0800, H.J. Lu wrote: > In this case, these are internal to the same comdat group: But that is only by accident, no? I mean, if you need to refer to such a symbol from non-comdat function or comdat function in a different comdat group and RA decides it wants the

[committed] MAINTAINERS: Update my email address

I have committed this to update my work email address in MAINTAINERS (but forgot to change my git user.mail first - oops!). Thanks Kwok Yeung From f3fdaa3eecd155dbdc78c1ec9a259dfa4e379ea4 Mon Sep 17 00:00:00 2001 From: Kwok Cheung Yeung Date: Mon, 29 Jan 2024 16:40:49 + Subject: [PATCH] MA

Re: [PATCH] Handle function symbol reference in readonly data section

> _ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxx10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE > - .ident &

Re: [PATCH] Handle function symbol reference in readonly data section

ldLinksExxP12vtkCellArray,comdat .align 8 .LC0: .quad _ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxx10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE - .ident "GCC: (GNU) 14.0.1 20240127 (experimental)" + .ident "GCC: (GNU) 14.0.1 20240129 (experimental)" .section.note.GNU-stack,"",@progbits Jakub

Re: [PATCH] x86: Generate REG_CFA_UNDEFINED for unsaved callee-saved registers

On Mon, Jan 29, 2024 at 08:00:26AM -0800, H.J. Lu wrote: > Attach REG_CFA_UNDEFINED notes for unsaved callee-saved registers which > have been used in the function to an instruction in prologue. > > gcc/ > > PR target/38534 > * dwarf2cfi.cc (add_cfi_undefined): New. > (dwarf2out

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 8:03 AM Jakub Jelinek wrote: > > On Mon, Jan 29, 2024 at 06:36:47AM -0800, H.J. Lu wrote: > > TARGET_ASM_SELECT_RTX_SECTION is for constant in RTL. > > It should have a non-public label reference which can't be used > > by other TUs. The same section can contain other cons

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Jan 29, 2024, at 10:50 AM, Martin Uecker wrote: > > Am Montag, dem 29.01.2024 um 15:09 + schrieb Qing Zhao: >> Thank you! >> >> Joseph and Richard, could you also comment on this? >> >>> On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote: >>> >>> Am Freitag, dem 26.01.2024 um 14:33

Re: [PATCH] x86: Generate .cfi_undefined for unsaved callee-saved registers

On Mon, Jan 29, 2024 at 2:08 AM Jakub Jelinek wrote: > > On Sat, Jan 27, 2024 at 12:41:24PM -0800, H.J. Lu wrote: > > When assembler directives for DWARF frame unwind is enabled, generate > > the .cfi_undefined directive for unsaved callee-saved registers which > > have been used in the function.

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 06:36:47AM -0800, H.J. Lu wrote: > TARGET_ASM_SELECT_RTX_SECTION is for constant in RTL. > It should have a non-public label reference which can't be used > by other TUs. The same section can contain other constants. > If there is a COMAT issue, linker will catch it. Let m

Re: [PATCH][GCC][Arm] Add pattern for bswap + rotate -> rev16 [Bug 108933]

On 29/01/2024 14:14, Matthieu Longo wrote: Hi Richard, Please find below the new patch where I addressed your comments and updated the changelog. rev16 pattern was not recognised anymore as a change in the bswap tree pass was introducing a new GIMPLE form, not recognized by the assembly final

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

An update on the kernel building with my version 4 patch. Kees reported two FE issues with the current version 4 patch: 1. The operator “typeof” cannot return correct type for a->array; 2. The operator “&” cannot return correct address for a->array; I fixed both in my local repository. With th

[PATCH] x86: Generate REG_CFA_UNDEFINED for unsaved callee-saved registers

Attach REG_CFA_UNDEFINED notes for unsaved callee-saved registers which have been used in the function to an instruction in prologue. gcc/ PR target/38534 * dwarf2cfi.cc (add_cfi_undefined): New. (dwarf2out_frame_debug_cfa_undefined): Likewise. (dwarf2out_frame_deb

Re: [PATCH]AArch64: relax cbranch tests to accepted inverted branches [PR113502]

Tamar Christina writes: > Hi All, > > Recently something in the midend had started inverting the branches by > inverting > the condition and the branches. > > While this is fine, it makes it hard to actually test. In RTL I disable > scheduling and BB reordering to prevent this. But in GIMPLE th

Re: [v2][patch] plugin/plugin-nvptx.c: Fix fini_device call when already shutdown [PR113513]

Hi Tobias! On 2024-01-23T10:55:16+0100, Tobias Burnus wrote: > Slightly changed patch: > > nvptx_attach_host_thread_to_device now fails again with an error for > CUDA_ERROR_DEINITIALIZED, except for GOMP_OFFLOAD_fini_device. > > I think it makes more sense that way. Agreed. > Tobias Burnus wro

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Montag, dem 29.01.2024 um 15:09 + schrieb Qing Zhao: > Thank you! > > Joseph and Richard, could you also comment on this? > > > On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote: > > > > Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao: > > > > > > > On Jan 26, 2024, at 3:04

Re: [patch] gcn/gcn-valu.md: Disable fold_left_plus for TARGET_RDNA2_PLUS [PR113615]

On 29/01/2024 12:50, Tobias Burnus wrote: Andrew Stubbs wrote: /tmp/ccrsHfVQ.mkoffload.2.s:788736:27: error: value out of range    .amdhsa_next_free_vgpr    516 ^~~ [Obviously, likewise forlibgomp.c++/.. Hmm, supposedly there are 768 register

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Thank you! Joseph and Richard, could you also comment on this? > On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote: > > Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao: >> >>> On Jan 26, 2024, at 3:04 AM, Martin Uecker wrote: >>> >>> >>> I haven't looked at the patch, but it sou

Re: [PATCH][libsanitizer]: Sync fixes for asan interceptors from upstream [PR112644]

On Mon, Jan 29, 2024 at 03:03:46PM +, Tamar Christina wrote: > Hi All, > > This cherry-picks and squashes the differences between commits > > d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63 > from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the chan

[PATCH]middle-end: check memory accesses in the destination block [PR113588].

Hi All, When analyzing loads for early break it was always the intention that for the exit where things get moved to we only check the loads that can be reached from the condition. However the main loop checks all loads and we skip the destination BB. As such we never actually check the loads re

[PATCH]AArch64: relax cbranch tests to accepted inverted branches [PR113502]

Hi All, Recently something in the midend had started inverting the branches by inverting the condition and the branches. While this is fine, it makes it hard to actually test. In RTL I disable scheduling and BB reordering to prevent this. But in GIMPLE there seems to be nothing I can do. __bui

[PATCH][libsanitizer]: Sync fixes for asan interceptors from upstream [PR112644]

Hi All, This cherry-picks and squashes the differences between commits d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63 from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the changes relevant for GCC. This is required to fix the linked PR. As mentioned i

Re: [PATCH] Handle function symbol reference in readonly data section

On Mon, Jan 29, 2024 at 3:03 AM Jakub Jelinek wrote: > > On Sat, Jan 27, 2024 at 07:10:55AM -0800, H.J. Lu wrote: > > For function symbol reference in readonly data section, instead of putting > > it in .data.rel.ro or .rodata.cst section, call function_rodata_section to > > get the read-only or r

Re: [PATCH][GCC][Arm] Add pattern for bswap + rotate -> rev16 [Bug 108933]

Hi Richard, Please find below the new patch where I addressed your comments and updated the changelog. rev16 pattern was not recognised anymore as a change in the bswap tree pass was introducing a new GIMPLE form, not recognized by the assembly final transformation pass. More details in https

Re: [PATCH] x86: Save callee-saved registers in noreturn functions for -O0/-Og

On Mon, Jan 29, 2024 at 2:11 AM Jakub Jelinek wrote: > > On Sat, Jan 27, 2024 at 07:00:03AM -0800, H.J. Lu wrote: > > On Sat, Jan 27, 2024 at 6:09 AM Jakub Jelinek wrote: > > > > > > On Sat, Jan 27, 2024 at 05:52:34AM -0800, H.J. Lu wrote: > > > > @@ -3391,7 +3392,9 @@ ix86_set_func_type (tree fn

Re: [PATCH v3] x86: Save callee-saved registers in noreturn functions for -O0/-Og

On Mon, Jan 29, 2024 at 05:26:05AM -0800, H.J. Lu wrote: > Changes in v3: > > 1. Add the TREE_THIS_VOLATILE check to minimize noreturn attribute lookup. > > Changes in v2: > > 1. Lookup noreturn attribute first. > 2. Use __attribute__((noreturn, optimize("-Og"))) in pr38534-6.c. > > > Save

[PATCH v3] x86: Save callee-saved registers in noreturn functions for -O0/-Og

Changes in v3: 1. Add the TREE_THIS_VOLATILE check to minimize noreturn attribute lookup. Changes in v2: 1. Lookup noreturn attribute first. 2. Use __attribute__((noreturn, optimize("-Og"))) in pr38534-6.c. Save callee-saved registers in noreturn functions for -O0/-Og so that debugger can

Re: [PATCH v1] RISC-V: Bugfix for vls integer mode calling convention

> @@ -4868,6 +4968,63 @@ riscv_pass_fpr_pair (machine_mode mode, unsigned > regno1, >GEN_INT (offset2; > } > > +static rtx > +riscv_pass_vls_aggregate_in_gpr_or_fpr (struct riscv_arg_info *info, > + machine_mode mode, u

Re: [aarch64] PR112950: gcc.target/aarch64/sve/acle/general/dupq_5.c fails on aarch64_be-linux-gnu

Prathamesh Kulkarni writes: > On Sat, 27 Jan 2024 at 21:19, Richard Sandiford > wrote: >> >> Prathamesh Kulkarni writes: >> > Hi, >> > The test passes -mlittle-endian option but doesn't have target check >> > for aarch64_little_endian and thus fails to compile on >> > aarch64_be-linux-gnu. The p

Re: [PATCH] aarch64: Ensure iterator validity when updating debug uses [PR113616]

Alex Coplan writes: > Hi, > > The fix for PR113089 introduced range-based for loops over the > debug_insn_uses of an RTL-SSA set_info, but in the case that we reset a > debug insn, the use would get removed from the use list, and thus we > would end up using an invalidated iterator in the next ite

Re: [patch] gcn/gcn-valu.md: Disable fold_left_plus for TARGET_RDNA2_PLUS [PR113615]

Andrew Stubbs wrote: /tmp/ccrsHfVQ.mkoffload.2.s:788736:27: error: value out of range    .amdhsa_next_free_vgpr    516 ^~~ [Obviously, likewise forlibgomp.c++/.. Hmm, supposedly there are 768 registers allocated in groups of 12, on gfx1100 (8

Re: [aarch64] PR112950: gcc.target/aarch64/sve/acle/general/dupq_5.c fails on aarch64_be-linux-gnu

On Sat, 27 Jan 2024 at 21:19, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > Hi, > > The test passes -mlittle-endian option but doesn't have target check > > for aarch64_little_endian and thus fails to compile on > > aarch64_be-linux-gnu. The patch adds the missing aarch64_little_en

Re: [patch] gcn/gcn-valu.md: Disable fold_left_plus for TARGET_RDNA2_PLUS [PR113615]

On 29/01/2024 10:34, Tobias Burnus wrote: Andrew wrote off list:   "Vector reductions don't work on RDNA, as is, but they're    supposed to be disabled by the insn condition" This patch disables "fold_left_plus_", which is about vectorization and in the code path shown in the backtrace. I can

Re: [PATCH v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.

LGTM Jin Ma 於 2024年1月29日 週一 17:57 寫道： > When using '%ld' to print 'long long int' variable, 'fprintf' will > produce messy output on a 32-bit system, in an incorrect instruction > being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the > following error occurred during compilation: >

Re: [PATCH] middle-end/113622 - handle store with variable index to register

On Mon, Jan 29, 2024 at 01:17:16PM +0100, Jakub Jelinek wrote: > On Mon, Jan 29, 2024 at 01:05:51PM +0100, Richard Biener wrote: > > The following implements storing to a non-MEM_P with a variable > > offset. We usually avoid this by forcing expansion to memory but > > this doesn't work for hard r

Re: [PATCH] middle-end/113622 - handle store with variable index to register

On Mon, Jan 29, 2024 at 01:05:51PM +0100, Richard Biener wrote: > The following implements storing to a non-MEM_P with a variable > offset. We usually avoid this by forcing expansion to memory but > this doesn't work for hard register variables. The solution is > to spill and operate on the stack

[PATCH] middle-end/113622 - handle store with variable index to register

The following implements storing to a non-MEM_P with a variable offset. We usually avoid this by forcing expansion to memory but this doesn't work for hard register variables. The solution is to spill and operate on the stack. Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? I realize t

Re: [PATCH] middle-end/113622 - allow .VEC_SET and .VEC_EXTRACT for global hard regs

On Mon, 29 Jan 2024, Jakub Jelinek wrote: > On Mon, Jan 29, 2024 at 11:24:58AM +0100, Richard Biener wrote: > > The following expands .VEC_SET and .VEC_EXTRACT instruction selection > > to global hard registers, not only automatic variables (possibly) > > promoted to registers. This can avoid som

Re: [patch] nvptx.opt: Add sm_89 and sm_90a to -march-map=

Hi Tobias! On 2024-01-20T10:57:29+0100, Tobias Burnus wrote: > Stumbled over this as we recently got a sm_89 card. > > -march-map= is mostly a future proof method for user to ensure to use > always the best code gen for a specific card - without needing to know > which GCC version added support

[PATCH] RISC-V: Fix VSETLV PASS compile-time issue

The compile time issue was discovered in SPEC 2017 wrf: Use time and -ftime-report to analyze the profile data of SPEC 2017 wrf compilation . Before this patch (Lazy vsetvl): scheduling : 121.89 ( 15%) 0.53 ( 11%) 122.72 ( 15%) 13M ( 1%) machine dep reorg

  1   2   >