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 /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gcc.git~ma

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 not

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

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). libgomp/libgomp.t

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 co

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

[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

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: {,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.

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

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

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 2

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 register_mmxmem_o

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

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 probl

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

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

[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

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

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

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 Me

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 VEC_PER

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 b

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 include/demangle.h

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 overl

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

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

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

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 be

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", >&n

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

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 wh

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 != IDENTIF

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 t

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

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

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

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

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

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 > https://gcc.gnu.org/onlinedocs/libi

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 have

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 @@ stmt_side_effects::stmt_side_effe

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

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

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

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

[COMMITTED] [Ada, build] Rename OSCONS_CC to GCC_FOR_ADA_RTS

Several gnatlib* targets perform, with a subshell and sed, the same GCC_FOR_TARGET pathname transformation that OSCONS_CC performs with make subst macros. Rename OSCONS_CC to a more general name, and use it for gnatlib as well. Tested on x86_64-linux-gnu, checking in. for gcc/ada/ChangeLog

[committed] libgomp: Don't define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC for _aligned_malloc [PR105745]

since apparently _aligned_malloc requires freeing with _aligned_free and: /* Defined if gomp_aligned_alloc doesn't use fallback version and free can be used instead of gomp_aligned_free. */ #define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1 so the second condition isn't satisfied. For uses inside