[PATCH] asan: Mark instrumented vars addressable [PR102656]

Hi! We ICE on the following testcase, because the asan1 pass decides to instrument .x = 0; and does that by _13 = &.x; .ASAN_CHECK (7, _13, 4, 4); .x = 0; and later sanopt pass turns that into: _39 = (unsigned long) &.x; _40 = _39 >> 3; _41 = _40 + 2147450880; _42 = (signed char *)

Re: [PATCH] asan: Mark instrumented vars addressable [PR102656]

On Fri, 18 Feb 2022, Jakub Jelinek wrote: > Hi! > > We ICE on the following testcase, because the asan1 pass decides to > instrument > .x = 0; > and does that by > _13 = &.x; > .ASAN_CHECK (7, _13, 4, 4); > .x = 0; > and later sanopt pass turns that into: > _39 = (unsigned long) &.x; >

[PATCH 1/3] tree-optimization/104582 - Simplify vectorizer cost API and fixes

This simplifies the vectorizer cost API by providing overloads to add_stmt_cost and record_stmt_cost suitable for scalar stmt and branch stmt costing which do not need information like a vector type or alignment. It also fixes two mistakes where costs for versioning tests were recorded as vector s

[PATCH 2/3] tree-optimization/104582 - make SLP node available in vector cost hook

This adjusts the vectorizer costing API to allow passing down the SLP node the vector stmt is created from. Bootstrapped and tested on x86_64-unknown-linux-gnu, I've built aarch64 and rs6000 cc1 crosses. OK? Thanks, Richard. 2022-02-18 Richard Biener PR tree-optimization/104582

[PATCH 3/3] target/99881 - x86 vector cost of CTOR from integer regs

This uses the now passed SLP node to the vectorizer costing hook to adjust vector construction costs for the cost of moving an integer component from a GPR to a vector register when that's required for building a vector from components. A cruical difference here is whether the component is loaded

[committed] rs6000: Fix up posix_memalign call in _mm_malloc [PR104598]

On Wed, Feb 16, 2022 at 09:09:27PM -0600, Paul A. Clarke wrote: > I see a couple of issues in my commit message, which I'll fix up before > merging... The uglification changes went in one spot too far and uglified also the anem of function, posix_memalign should be called like that and not a non-e

Re: [committed] d: Merge upstream dmd 52844d4b1, druntime dbd0c874, phobos 896b1d0e1.

Excerpts from Rainer Orth's message of Februar 16, 2022 11:45 pm: > Hi Iain, > >> This patch merges the D front-end implementation with upstream dmd >> 52844d4b1, as well as the D runtime libraries with druntime dbd0c874, >> and phobos 896b1d0e1, including the latest features and bug-fixes ahead o

[PATCH] PR middle-end/65855: Scalar evolution for quadratic chrecs

This patch improves GCC's scalar evolution and final value replacement optimizations by supporting triangular/quadratic/trapezoid chrecs which resolves both PR middle-end/65855 and PR c/80852, but alas not (yet) PR tree-optimization/46186. I've listed Richard Biener as co-author, as this solution

[r12-7293 Regression] FAIL: gcc.target/i386/pieces-memset-21.c scan-assembler-not vzeroupper on Linux/x86_64

On Linux/x86_64, fe79d652c96b53384ddfa43e312cb0010251391b is the first bad commit commit fe79d652c96b53384ddfa43e312cb0010251391b Author: Richard Biener Date: Thu Feb 17 14:40:16 2022 +0100 target/104581 - compile-time regression in mode-switching caused FAIL: gcc.target/i386/pieces-mems

[PATCH] pieces-memset-21.c: Expect vzeroupper for ia32

On Thu, Feb 17, 2022 at 6:32 PM Hongtao Liu via Gcc-patches wrote: > > On Thu, Feb 17, 2022 at 9:47 PM Richard Biener via Gcc-patches > wrote: > > > > The x86 backend piggy-backs on mode-switching for insertion of > > vzeroupper. A recent improvement there was implemented in a way > > to walk po

[PATCH 0/8] OpenMP 5.0: C++ "declare mapper" support (plus struct rework, etc.)

Hi, This patch contains rebased/slightly bug-fixed versions of the patches previously posted in the series: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585439.html plus a new implementation of "declare mapper" support for C++. This can't be committed now, but posting now so others (m

[PATCH 1/8] OpenMP 5.0: Clause ordering for OpenMP 5.0 (topological sorting by base pointer)

This patch reimplements the omp_target_reorder_clauses function in anticipation of supporting "deeper" struct mappings (that is, with several structure dereference operators, or similar). The idea is that in place of the (possibly quadratic) algorithm in omp_target_reorder_clauses that greedily mo

[PATCH 2/8] Remove omp_target_reorder_clauses

This patch has been split out from the previous one to avoid a confusingly-interleaved diff. The two patches should probably be committed squashed together. 2021-10-01 Julian Brown gcc/ * gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete. --- gcc/gimplify.cc | 207 ---

[PATCH 3/8] OpenMP/OpenACC struct sibling list gimplification extension and rework

This patch is a combination of several previously-posted patches, rebased and squashed together, and with a couple of additional bugfixes: "Rewrite GOMP_MAP_ATTACH_DETACH mappings unconditionally" https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585440.html "OpenMP/OpenACC: Move array_ref/

[PATCH 4/8] OpenMP: Add inspector class to unify mapped address analysis

Several places in the C and C++ front-ends dig through OpenMP addresses from "map" clauses (etc.) in order to determine whether they are component accesses that need "attach" operations, check duplicate mapping clauses, and so on. When we're extending support for more kinds of lvalues in map claus

[PATCH 5/8] OpenMP: lvalue parsing for map clauses (C++)

This patch changes parsing for OpenMP map clauses in C++ to use the generic expression parser, hence adds support for parsing general lvalues (as required by OpenMP 5.0+). So far only a few new types of expression are actually supported throughout compilation (including everything in the testsuite

[PATCH 7/8] Use OMP_ARRAY_SECTION instead of TREE_LIST in C++ FE

This patch changes the representation of OMP array sections in the C++ front end to use the new OMP_ARRAY_SECTION tree code instead of a TREE_LIST. This is important for "declare mapper" support, because the array section representation may stick around longer (in "declare mapper" definitions), an

[PATCH 6/8] OpenMP: lvalue parsing for map clauses (C)

This patch adds support for parsing general lvalues for OpenMP "map" clauses to the C front-end, similar to the previous patch for C++. This version of the patch fixes several omissions regarding non-DECL_P root terms in map clauses (i.e. "*foo" in "(*foo)->ptr->arr[:N]") -- similar to the cp/sema

[PATCH 8/8] OpenMP 5.0 "declare mapper" support for C++

This patch implements OpenMP 5.0 "declare mapper" support for C++ -- except for arrays of structs with mappers, which are TBD. I've taken cues from the existing "declare reduction" support where appropriate, though obviously the details of implementation differ somewhat (in particular, "declare map

Re: [PATCH] rs6000: Workaround for new ifcvt behavior [PR104335]

On 2/17/22 1:04 PM, Robin Dapp via Gcc-patches wrote: >> Please send patches as plain text, not as base64. > > It seems like Thunderbird does not support this anymore since later > versions, grml. Probably need to look for another mail client. I use Thunderbird with no problems. I use the Quick

[PATCH] openmp: Improve handling of nested OpenMP metadirectives in C and C++ (was: Re: [PATCH 1/7] openmp: Add C support for parsing metadirectives)

This patch (to be applied on top of the metadirective patch series) addresses issues found in the C/C++ parsers when nested metadirectives are used. analyze_metadirective_body when encountering code like: #pragma omp metadirective when {set={...}: A) #pragma omp metadirective when (set={...}

libgo patch committed: Update to Go1.18rc1 release

This patch updates libgo to the Go1.18rc1 release. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian patch.txt.bz2 Description: application/bzip

[og11][committed] openmp: Improve handling of nested OpenMP metadirectives in C and C++

This patch has been committed to the devel/omp/gcc-11 development branch: 249df772b70f7b9f50f68030d4ea9c25624cc578 openmp: Improve handling of nested OpenMP metadirectives in C and C++ Kwok

[PATCH] c: [PR104506] Fix ICE after error due to change of type to error_mark_node

From: Andrew Pinski The problem here is we end up with an error_mark_node when calling useless_type_conversion_p and that ICEs. STRIP_NOPS/tree_nop_conversion has had a check for the inner type being an error_mark_node since g9a6bb3f78c96 (2000). This just adds the check also to tree_ssa_useless_

Re: [PATCH] PR c/104506: Tolerate error_mark_node in useless_type_conversion_p.

On Mon, Feb 14, 2022 at 11:39 PM Andrew Pinski wrote: > > On Mon, Feb 14, 2022 at 11:33 PM Richard Biener > wrote: > > > > On Tue, Feb 15, 2022 at 12:58 AM Andrew Pinski via Gcc-patches > > wrote: > > > > > > On Mon, Feb 14, 2022 at 4:54 AM Roger Sayle > > > wrote: > > > > > > > > > > > > > >

[PATCH] Add a restriction on allocate clause (OpenMP 5.0)

An allocate clause in target region must specify an allocator unless the compilation unit has requires construct with dynamic_allocators clause. Current implementation of the allocate clause did not check for this restriction. This patch fills that gap. gcc/ChangeLog: * omp-low.cc (omp_m

Re: [PR103302] skip multi-word pre-move clobber during lra

On Dec 15, 2021, Jeff Law wrote: >> * expr.c (emit_move_complex_parts): Skip clobbers during lra. > OK for the next cycle. Thanks, but having looked into PR 104121, I withdraw this patch and also the already-installed patch for PR 103302. As I found out, LRA does worse without the clobbers for

libgo patch committed: Update hurd support

This libgo patch based on patches by Svante Signell updates the hurd support in libgo. This is for GCC PR 104290. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian fa59861178df32a1f1271be6f763b71d2bb5ecab diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofronten

Contents of PO file 'cpplib-12.1-b20220213.ru.po'

cpplib-12.1-b20220213.ru.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

New Russian PO file for 'cpplib' (version 12.1-b20220213)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Russian team of translators. The file is available at: https://translationproject.org/latest/cpplib/ru.po (This file, 'cpplib-12.1-b202202