[PATCH v5 4/5] LoongArch: Added support for loading __get_tls_addr symbol address using call36.

gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_call_tls_get_addr): Add support for call36. gcc/testsuite/ChangeLog: * gcc.target/loongarch/explicit-relocs-medium-call36-auto-tls-ld-gd.c: New test. --- gcc/config/loongarch/loongarch.cc | 22 +++

[PATCH v5 0/5] When cmodel=extreme, add macro implementation and fix problems with explicit relos implementation.

When cmodel=extreme, since the symbol address is obtained through four instructions, errors may occur in some cases during linking. Xi Ruoyao fixes this problem. https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc#extreme-code-model v4 -> v5: 1. Modify code format. 2. Add the i

[PATCH v5 2/5] LoongArch: Add the macro implementation of mcmodel=extreme.

gcc/ChangeLog: * config/loongarch/loongarch-protos.h (loongarch_symbol_extreme_p): Add function declaration. * config/loongarch/loongarch.cc (loongarch_symbolic_constant_p): For SYMBOL_PCREL64, non-zero addend of "la.local $rd,$rt,sym+addend" is not allowed

[PATCH v5 3/5] LoongArch: Enable explicit reloc for extreme TLS GD/LD with -mexplicit-relocs=auto.

Binutils does not support relaxation using four instructions to obtain symbol addresses gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_explicit_relocs_p): When the code model of the symbol is extreme and -mexplicit-relocs=auto, the macro instruction loading symb

[PATCH v5 5/5] LoongArch: Don't split the instructions containing relocs for extreme code model.

From: Xi Ruoyao The ABI mandates the pcalau12i/addi.d/lu32i.d/lu52i.d instructions for addressing a symbol to be adjacent. So model them as "one large instruction", i.e. define_insn, with two output registers. The real address is the sum of these two registers. The advantage of this approach i

[PATCH] tree-ssa-strlen: Fix pdata->maxlen computation [PR110603]

Hi! On the following testcase we emit an invalid range of [2, 1] due to UB in the source. Older VRP code silently swapped the boundaries and made [1, 2] range out of it, but newer code just ICEs on it. The reason for pdata->minlen 2 is that we see a memcpy in this case setting both elements of t

[PATCH v5 1/5] LoongArch: Merge template got_load_tls_{ld/gd/le/ie}.

gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_load_tls): Load all types of tls symbols through one function. (loongarch_got_load_tls_gd): Delete. (loongarch_got_load_tls_ld): Delete. (loongarch_got_load_tls_ie): Delete. (loongarch_got_loa

Re: [PATCH] tree-ssa-strlen: Fix pdata->maxlen computation [PR110603]

On Mon, 29 Jan 2024, Jakub Jelinek wrote: > Hi! > > On the following testcase we emit an invalid range of [2, 1] due to > UB in the source. Older VRP code silently swapped the boundaries and > made [1, 2] range out of it, but newer code just ICEs on it. > > The reason for pdata->minlen 2 is tha

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

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 iteration of the loop. In practice

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

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: Assembler messages: Error: improper immediate val

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

On Mon, Jan 29, 2024 at 1:21 AM Jin Ma wrote: > > 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 compil

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

>On Mon, Jan 29, 2024 at 1:21=E2=80=AFAM Jin Ma wr= >ote: >> >> 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 occur

Re: [patch][v2] gcn/mkoffload.cc: Fix SRAM_ECC and XNACK handling [PR111966]

On 25/01/2024 15:11, Tobias Burnus wrote: Updated patch enclosed. Tobias Burnus wrote: I have now run the attached script and the result running yesterday's build with both my patch and your patch applied. (And the now committed gcn-hsa.h patch) Now the result with the testscript is: * fiji

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

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: Assembler messages: Error: improper immediate val

Re: [patch] install.texi: For gcn, recommend LLVM 15, unless gfx1100 is disabled

On 26/01/2024 16:45, Tobias Burnus wrote: Hi, Thomas Schwinge wrote: amdgcn: config.gcc - enable gfx1030 and gfx1100 multilib; add them to the docs ... Further down in that file, we state: @anchor{amdgcn-x-amdhsa} @heading amdgcn-*-amdhsa AMD GCN GPU target. Instead o

[committed] libgomp.c/declare-variant-4.h: Fix used variant function for gfx1030/gfx1100

This fixes an obvious and stupid copy'n'paste bug of mine in the OpenMP declare variant used for two testcases, fixing: FAIL: libgomp.c/declare-variant-4-gfx1030.c scan-amdgcn-amdhsa-offload-tree-dump optimized "= gfx1030 \\(\\);" FAIL: libgomp.c/declare-variant-4-gfx1100.c scan-amdgcn-amdhsa-o

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

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. > > gcc/ > > PR target/38534 > * config/i386/i386.

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

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 fndecl) > > > function is marked as noreturn in the IR output,

Re: [PATCH] vect: Tighten vect_determine_precisions_from_range [PR113281]

On Sat, Jan 27, 2024 at 4:44 PM Richard Sandiford wrote: > > This was another PR caused by the way that > vect_determine_precisions_from_range handle shifts. We tried to > narrow 32768 >> x to a 16-bit shift based on range information for > the inputs and outputs, with vect_recog_over_widening_pa

Re: [wwwdocs][patch] gcc-14/changes.html (amdgcn): Update for gfx1030/gfx1100

On 26/01/2024 17:06, Tobias Burnus wrote: Mention that gfx1030/gfx1100 are now supported. As noted in another thread, LLVM 15's assembler is now required, before LLVM 13.0.1 would do. (Alternatively, disabling gfx1100 support would do.) Hence, the added link to the install documentation. Com

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

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 some ICEs later and create better code. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK? Thanks, Richard.

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

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 also confirm manually that it fixes the ICE I

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

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 some ICEs later and create > better code. > > Bootstr

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

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 relocated read-only data section associated with the > function D

Re: [PATCH] jit: Ensure ssize_t is defined.

Hi David, I guess the solution here depends on the scope over which we expect the header to be used. > On 28 Jan 2024, at 23:13, Iain Sandoe wrote: >> On 28 Jan 2024, at 21:25, Eric Gallager wrote: >> On Sun, Jan 28, 2024 at 6:45 AM Iain Sandoe wrote: >>> >>> Tested on i686, x86_64 Darwin, x8

[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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

[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

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

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

[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

[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

[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

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

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

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

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

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

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

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

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

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

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

  1   2   >