[PATCH] [PR105665] ivopts: check defs of names in base for undefs

The patch for PR 100810 tested for undefined SSA_NAMEs appearing directly in the base expression of the potential IV candidate, but that's not enough. The testcase for PR105665 shows an undefined SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg in the referenced SSA_NAME.

[pushed] c++: lambda in concept [PR105652]

We currently check satisfaction in the context of the constrained declaration (which may be wrong, see PR104111). When checking C for S, we currently substitute into the lambda in the context of S (rather than S, which seems wrong if the above isn't wrong), so the new closure type thinks its

Re: [committed] d: Merge upstream dmd 60bfa0ee7, druntime 94bd5bcb, phobos 3a1cd9a01.

Excerpts from Rainer Orth's message of Mai 18, 2022 4:40 pm: > Hi Iain, > >> Upstream dmd has now released v2.100.0, this patch merges in the >> latest bug fixes since the last sync-up of the release branch, as well >> as all new feature changes on development branch. > [...] >> D runtime

Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

On 5/26/22 00:29, Yonghong Song wrote: > > > On 5/24/22 10:04 AM, David Faust wrote: >> >> >> On 5/24/22 09:03, Yonghong Song wrote: >>> >>> >>> On 5/24/22 8:53 AM, David Faust wrote: On 5/24/22 04:07, Jose E. Marchesi wrote: > >> On 5/11/22 11:44 AM, David Faust wrote:

Re: [PATCH] Add divide by zero side effect.

On 5/27/22 15:33, Andi Kleen wrote: Andrew MacLeod via Gcc-patches writes: diff --git a/gcc/gimple-range-side-effect.cc b/gcc/gimple-range-side-effect.cc index 2c8c77dc569..548e4bea313 100644 --- a/gcc/gimple-range-side-effect.cc +++ b/gcc/gimple-range-side-effect.cc @@ -116,6 +116,23 @@

Re: [PATCH] Add divide by zero side effect.

Andrew MacLeod via Gcc-patches writes: > > diff --git a/gcc/gimple-range-side-effect.cc b/gcc/gimple-range-side-effect.cc > index 2c8c77dc569..548e4bea313 100644 > --- a/gcc/gimple-range-side-effect.cc > +++ b/gcc/gimple-range-side-effect.cc > @@ -116,6 +116,23 @@

Re: [committed] amdgcn: Remove LLVM 9 assembler/linker support

Hi Andrew! On 2022-05-24T16:27:52+0100, Andrew Stubbs wrote: > I've committed this patch to set the minimum required LLVM version, for > the assembler and linker, to 13.0.1. An upgrade from LLVM 9 is a > prerequisite for the gfx90a support, and 13.0.1 is now the oldest > version not known to

Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches wrote: > > Hi fellow hackers, > > first of all: I'm not sure if this is the correct mailing list for this > question, but I did not found a separate one and > gnu.org/software/libiberty redirects to >

[PATCH] c++: document comp_template_args's default args

In passing, use bool for its return type. gcc/cp/ChangeLog: * cp-tree.h (comp_template_args): Change return type to bool. * pt.cc (comp_template_args): Document default arguments. Change return type to bool and adjust returns accordingly. --- gcc/cp/cp-tree.h | 2 +-

[PATCH] c++: use current_template_constraints more

gcc/cp/ChangeLog: * decl.cc (grokvardecl): Use current_template_constraints. (xref_tag): Likewise. * semantics.cc (finish_template_template_parm): Likewise. --- gcc/cp/decl.cc | 13 +++-- gcc/cp/semantics.cc | 3 +-- 2 files changed, 4 insertions(+), 12

[PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of each template parameter except as necessary for (friend) declaration matching, like we already do for the overall TEMPLATE_PARMS_CONSTRAINTS of a template parameter list. Bootstrapped and regtested on x86_64-pc-linux-gnu, does

Re: [PATCH 1/7] openmp: Add C support for parsing metadirectives

On Fri, Dec 10, 2021 at 05:31:08PM +, Kwok Cheung Yeung wrote: > This patch adds support for parsing metadirectives in the C parser. > > Metadirectives are represented by a OMP_METADIRECTIVE tree node. It has a > single operand (accessed by OMP_METADIRECTIVE_CLAUSES) which contains a I think

Re: [PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

On Fri, May 27, 2022 at 11:52:12AM -0400, Jason Merrill wrote: > On 5/26/22 20:33, Marek Polacek wrote: > > As discussed here: > > , > > type_dependent_expression_p should not be called with a type argument. > > > > I promised

Re: [PATCH] c++: Fix ICE with -Wmismatched-tags [PR105725]

On 5/27/22 11:46, Marek Polacek wrote: Here we ICE with -Wmismatched-tags on something like template bool B>>; Specifically, the "class T::foo" bit. There, class_decl_loc_t::add gets a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking TYPE_BEING_DEFINED will crash. I

Re: [PATCH] c-family: fix attribute constructor ICE [PR90658]

On 5/26/22 20:34, Marek Polacek wrote: Here the C compiler crashes because a FUNCTION_DECL got into get_priority -> default_conversion, and the C FE's version of d_c specifically asserts that it doesn't get a FUNCTION_DECL. All uses of default_conversion in c-attribs.cc are guarded by !=

Re: [PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

On 5/26/22 20:33, Marek Polacek wrote: As discussed here: , type_dependent_expression_p should not be called with a type argument. I promised I'd add an assert so here it is. One place needed adjusting, the comment explains

[PATCH] c++: Fix ICE with -Wmismatched-tags [PR105725]

Here we ICE with -Wmismatched-tags on something like template bool B>>; Specifically, the "class T::foo" bit. There, class_decl_loc_t::add gets a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking TYPE_BEING_DEFINED will crash. I think it's OK to allow a TYPENAME_TYPE to

Re: [Patch] OpenMP/Fortran: Add support for enter clause on declare target (was: [committed] openmp: Add support for enter clause on declare target)

On Fri, May 27, 2022 at 05:20:08PM +0200, Jakub Jelinek wrote: > 2) move the > else if (n->sym->mark) > gfc_error_now ("Variable at %L mentioned multiple times in " >"clauses of the same OMP DECLARE TARGET directive", >

Re: [Patch] OpenMP/Fortran: Add support for enter clause on declare target (was: [committed] openmp: Add support for enter clause on declare target)

On Fri, May 27, 2022 at 04:52:17PM +0200, Tobias Burnus wrote: > This patch adds the Fortran support to the just-committed C/C++ support for > the 'enter' clause. > > The 'TO'/'ENTER' usage is first stored in a linked list – and > then as attribute to the symbol. I am not sure how to handle it

[PATCH] libgfortran: Use `__gthread_t` instead of `pthread_t`

The attached patch addresses a build issue when is not included. Please review. -- Best regards, LIU Hao From 7b573e4cdb7c3b666baac4c38046c64a01b6dcb5 Mon Sep 17 00:00:00 2001 From: LIU Hao Date: Fri, 27 May 2022 23:12:48 +0800 Subject: [PATCH] libgfortran: Use `__gthread_t` instead of

[Patch] OpenMP/Fortran: Add support for enter clause on declare target (was: [committed] openmp: Add support for enter clause on declare target)

This patch adds the Fortran support to the just-committed C/C++ support for the 'enter' clause. The 'TO'/'ENTER' usage is first stored in a linked list – and then as attribute to the symbol. I am not sure how to handle it best. I did went for adding an ENTER_LIST but kept only using the single

[committed] libstdc++: Mark non-exported function always_inline [PR105671]

Tested powerpc64le-linux, pushed to trunk. Backports to gcc-12 and gcc-11 will be done early next month. -- >8 -- This new function was added for gcc 11.1 but is not exported from the shared library. Depending on inlining decisions, its callers might get inlined but an external definition be

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On Thu, 26 May 2022, Patrick Palka wrote: > On Thu, 26 May 2022, Jason Merrill wrote: > > > On 5/26/22 14:57, Patrick Palka wrote: > > > On Thu, 26 May 2022, Patrick Palka wrote: > > > > > > > Here we expect the calls to BaseClass::baseDevice resolve to the second, > > > > third and fourth

Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

On Fri, May 27, 2022 at 12:17 AM Simon Sobisch via Gcc-patches wrote: > > As noted: the first question is: is it reasonable to add support for > GnuCOBOL? It seems fine to me to add support for demangling GnuCOBOL symbol names controlled by a DMGL option (options are defined in

Re: [PATCH 7/7] openmp: Add testcases for metadirectives

On Fri, Dec 10, 2021 at 05:40:36PM +, Kwok Cheung Yeung wrote: > This adds testcases for metadirectives. Let me start with the last patch. > +++ b/gcc/testsuite/c-c++-common/gomp/metadirective-1.c > @@ -0,0 +1,29 @@ > +/* { dg-do compile } */ > + > +#define N 100 > + > +void f (int a[], int

Re: [0/9] [middle-end] Add param to vec_perm_const hook to specify mode of input operand

On Wed, May 25, 2022 at 10:24 PM Prathamesh Kulkarni wrote: > > On Thu, 26 May 2022 at 00:37, Richard Biener > wrote: [...] > > x86 now accepts V4SI V8SI permutes because we don’t ask it correctly and > > thus my naive attempt to use the new function API breaks . Not to mention > > the

Re: [ping][vect-patterns] Refactor widen_plus/widen_minus as internal_fns

On Wed, 25 May 2022, Joel Hutton wrote: > Ping! > > Just checking there is still interest in this. I'm assuming you've been > busy with release. Can you post an updated patch (after the .cc renaming, and code_helper now already moved to tree.h). Thanks, Richard. > Joel > > > -Original

[committed] Fortran: Fix OpenMP clause name in error message

This fix was part of the submitted patch + reviewed with minor comments patch: [PATCH, OpenMP 5.0] More implementation of the requires directive https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563393.html but that never got revised and applied. Committed the most obvious parts as

[PATCH] Avoid shift in get_ref_base_and_extent

This avoids one instance of a shift from bytes to bits in get_ref_base_and_extent by using TYPE_SIZE instead of TYPE_SIZE_UNIT. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * tree-dfa.cc (get_ref_base_and_extent): Avoid shift. --- gcc/tree-dfa.cc | 5 ++--- 1 file

[PING] libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option (was: Proposal to remove '--with-cuda-driver')

Hi! Ping. Grüße Thomas On 2022-05-13T14:29:01+0200, I wrote: > Hi! > > On 2022-04-29T15:48:03+0200, I wrote: >> On 2022-04-06T11:57:57+0200, Tom de Vries wrote: >>> On 4/5/22 17:14, Thomas Schwinge wrote: Regarding [...] > Now, consider doing a GCC/nvptx offloading build with

[committed] openmp: Add support for enter clause on declare target

Hi! OpenMP 5.1 and earlier had 2 different uses of to clause, one for target update construct with one semantics, and one for declare target directive with a different semantics. Under the hood we were using OMP_CLAUSE_TO_DECLARE to represent the latter. OpenMP 5.2 renamed the declare target

Re: [PATCH] ipa: Check cst type when propagating controled uses info (PR 105639)

Hi, On Fri, May 27 2022, Richard Biener wrote: > On Thu, May 26, 2022 at 4:47 PM Martin Jambor wrote: >> >> Hi, >> >> PR 105639 shows that code with type-mismatches can trigger an assert >> after runnning into a branch that was inteded only for references to >> variables - as opposed to

Re: [PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

On 27.05.2022 10:57, Uros Bizjak wrote: > On Fri, May 27, 2022 at 10:05 AM Jan Beulich wrote: >> >> It's pretty clear that the operand numbers in the MEM_P() checks are >> off by one, perhaps due to a copy-and-paste oversight (unlike in most >> other places here we're dealing with two outputs).

Re: [PATCH] fold-const: Fix up -fsanitize=null in C++ [PR105729]

On Fri, 27 May 2022, Jakub Jelinek wrote: > Hi! > > The following testcase triggers a false positive UBSan binding a reference > to null diagnostics. > In the FE we instrument conversions from pointer to reference type > to diagnose at runtime if the operand of such a conversion is 0. > The

Re: [PATCH] Add a bit dislike for separate mem alternative when op is REG_P.

On Wed, 25 May 2022, liuhongt via Gcc-patches wrote: > Rigt now, mem_cost for separate mem alternative is 1 * frequency which > is pretty small and caused the unnecessary SSE spill in the PR, I've tried > to rework backend cost model, but RA still not happy with that(regress > somewhere else). I

Re: [gcc r12-6398] [Ada] Reduce runtime dependencies on stage1

Hi! (Before the GCC 12 release) I had reported that commit r12-6398-ga6eae6a9bbf83ada3aab7f5a2a74e7024889d237 "[Ada] Reduce runtime dependencies on stage1" has broken GCC/Ada build with GCC 4.8. That's unfortunate, as I understand that GCC 4.8 is generally the prerequisite compiler for GCC.

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On 2022/05/27 12:00, Takayuki 'January June' Suwa via Gcc-patches wrote: On 2022/05/27 1:57, Max Filippov wrote: is that something that can be addressed in this patch? seems hard to resolve, because the RTL-generation pass passes only 68 bytes in that case: the culprit is here, but i don't

Re: [PATCH] x86: {,v}psadbw have commutative source operands

On Fri, May 27, 2022 at 10:13 AM Jan Beulich wrote: > > Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the > "absolute difference" aspect of the insns makes their source operands > commutative. You will need to expand via ix86_fixup_binary_operands_no_copy, use

Re: [PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

On Fri, May 27, 2022 at 10:05 AM Jan Beulich wrote: > > It's pretty clear that the operand numbers in the MEM_P() checks are > off by one, perhaps due to a copy-and-paste oversight (unlike in most > other places here we're dealing with two outputs). > --- > What I don't understand is why operand

[PATCH] fold-const: Fix up -fsanitize=null in C++ [PR105729]

Hi! The following testcase triggers a false positive UBSan binding a reference to null diagnostics. In the FE we instrument conversions from pointer to reference type to diagnose at runtime if the operand of such a conversion is 0. The problem is that a GENERIC folding folds ((const struct Bar *)

[PATCH] libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

Hi! The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes after the __VA_OPT__ (in this case there is

[PATCH] x86: {,v}psadbw have commutative source operands

Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the "absolute difference" aspect of the insns makes their source operands commutative. gcc/ 2022-05-XX Jan Beulich * config/i386/mmx.md (mmx_psadbw): Mark as commutative. * config/i386/sse.md (_psadbw): Likewise.

GCC 9 branch is now closed

After the GCC 9.5 release the GCC 9 branch is now closed and the hooks should reject any further pushes to it. Thanks, Richard.

[PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

It's pretty clear that the operand numbers in the MEM_P() checks are off by one, perhaps due to a copy-and-paste oversight (unlike in most other places here we're dealing with two outputs). --- What I don't understand is why operand 2 is "nonimmediate_operand", not "register_operand" (which afaict

Re: [Patch] libgomp.texi: Add more to-be-implemented OpenMP 5.2 features / [wwwdocs] gcc-13/changes.html - Update OpenMP / projects/gomp - add more to-do items

On Fri, May 27, 2022 at 09:41:22AM +0200, Tobias Burnus wrote: > On 25.05.22 17:55, Tobias Burnus wrote: > > I had a look at the OpenMP 5.2 changes and found some more, > > which I think should be listed. Some were rather hidden, two > > were only documented in the deprecate part. > > Fixes:

libatomic: drop redundant all-multi command

./multilib.am already specifies this same command, and make warns about the earlier one being ignored when seeing the later one. All that needs retaining to still satisfy the preceding comment is the extra dependency. libatomic/ 2022-05-XX Jan Beulich * Makefile.am (all-multi): Drop

Re: [Patch] libgomp.texi: Add more to-be-implemented OpenMP 5.2 features / [wwwdocs] gcc-13/changes.html - Update OpenMP / projects/gomp - add more to-do items

On 25.05.22 17:55, Tobias Burnus wrote: I had a look at the OpenMP 5.2 changes and found some more, which I think should be listed. Some were rather hidden, two were only documented in the deprecate part. Fixes: Remove the last two items – they were already in the list (ups).

Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

On Wed, May 25, 2022 at 9:50 PM Gaius Mulley wrote: > > Richard Biener writes: > > > So is there a reason to have the 'scaffold' separate from the object > > of hello.mod? > > Perhaps the major advantage is flexibility? But no we can by default > produce the scaffold within the object of

libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

Hi fellow hackers, first of all: I'm not sure if this is the correct mailing list for this question, but I did not found a separate one and gnu.org/software/libiberty redirects to https://gcc.gnu.org/onlinedocs/libiberty.pdf - so I'm here. If there's a better place for this: please drop a

vec_perm_const hook -- Fix build failure in ARM backend

Hi, I forgot to adjust prototype for arm_vectorize_vec_perm_const, which, resulted in following build error: # 00:05:33 make[3]: [Makefile:1787: armv8l-unknown-linux-gnueabihf/bits/largefile-config.h] Error 1 (ignored) # 00:10:53

Re: [PATCH] ipa: Check cst type when propagating controled uses info (PR 105639)

On Thu, May 26, 2022 at 4:47 PM Martin Jambor wrote: > > Hi, > > PR 105639 shows that code with type-mismatches can trigger an assert > after runnning into a branch that was inteded only for references to > variables - as opposed to references to functions. Fixed by moving > the condition from

[PATCH v3 9/9] RISC-V: Introduce predicate "riscv_sync_memory_operand" [PR 100266]

Atomic instructions require zero-offset memory addresses. If we allow all addresses, the nonzero-offset addresses will be prepared in an extra register in an extra instruction before the actual atomic instruction. This patch introduces the predicate "riscv_sync_memory_operand", which restricts

[PATCH v3 8/9] RISC-V: Add s.ext-consuming INSNs for LR and SC [PR 100266]

The current model of the LR and SC INSNs requires a sign-extension to use the generated SImode value for conditional branches, which only operate on XLEN registers. However, the sign-extension is actually not required in both cases, therefore this patch introduces additional INSNs that consume the

[PATCH v3 7/9] RISC-V: Model INSNs for LR and SC [PR 100266]

In order to emit LR/SC sequences, let's provide INSNs, which take care of memory ordering constraints. gcc/ PR 100266 * config/rsicv/sync.md (UNSPEC_LOAD_RESERVED): New. * config/rsicv/sync.md (UNSPEC_STORE_CONDITIONAL): New. * config/riscv/sync.md

[PATCH v3 6/9] RISC-V: Implement atomic_{load,store} [PR 100265]

A recent commit introduced a mechanism to emit proper fences for RISC-V. Additionally, we already have emit_move_insn (). Let's reuse this code and provide atomic_load and atomic_store for RISC-V (as defined in section "Code Porting and Mapping Guidelines" of the unpriv spec). Note, that this

[PATCH v3 5/9] RISC-V: Emit fences according to chosen memory model [PR 100265]

mem_thread_fence gets the desired memory model as operand. Let's emit fences according to this value (as defined in section "Code Porting and Mapping Guidelines" of the unpriv spec). gcc/ PR 100265 * config/riscv/sync.md (mem_thread_fence): Emit fences according

[PATCH v3 4/9] RISC-V: Use STORE instead of AMOSWAP for atomic stores [PR 100265]

Using AMOSWAP as atomic store does not allow us to do sub-word accesses. Further, it is not consistent with our atomic_load () implementation. The benefit of AMOSWAP is that the resulting code sequence will be smaller (comapred to FENCE+STORE), however, this does not weight out for the lack of

[PATCH v3 3/9] RISC-V: Eliminate %F specifier from riscv_print_operand() [PR 100265]

A previous patch took care, that the proper memory ordering suffixes for AMOs are emitted. Therefore there is no reason to keep the fence generation mechanism for release operations. gcc/ PR 100265 * config/riscv/riscv.c (riscv_memmodel_needs_release_fence): Remove

[PATCH v3 2/9] RISC-V: Emit proper memory ordering suffixes for AMOs [PR 100265]

The ratified A extension supports '.aq', '.rl' and '.aqrl' as memory ordering suffixes. Let's emit them in case we get a '%A' conversion specifier for riscv_print_operand(). As '%A' was already used for a similar, but restricted, purpose (only '.aq' was emitted so far), this does not require any

[PATCH v3 1/9] RISC-V: Simplify memory model code [PR 100265]

We don't have any special treatment of MEMMODEL_SYNC_* values, so let's hide them behind the memmodel_base() function. gcc/ PR 100265 * config/riscv/riscv.c (riscv_memmodel_needs_amo_acquire): Ignore MEMMODEL_SYNC_* values. * config/riscv/riscv.c

[PATCH v3 0/9] [RISC-V] Atomics improvements

This series provides a cleanup of the current atomics implementation of RISC-V (PR100265: Use proper fences for atomic load/store). The first patch could be squashed into the following patches, but I found it easier to understand the chances with it in place. The series has been tested as