Re: AW: [PATCH] m68k architecture: support ccmode + lra

Am 2019-12-08 01:54, schrieb Oleg Endo: On Tue, 2019-11-26 at 07:38 +0100, ste...@franke.ms wrote: > On 11/21/19 10:30 AM, ste...@franke.ms wrote: > > Hi there, > > > > here is mc68k's patch to switch the m68k architecture over to ccmode > > and > > lra. See https://github.com/mc68kghost/gcc 68k

[PATCH] V10 patch #12, Test to make sure we don't generate prefixed pre-modify load/stores for -mcpu=future

Patch V10 #12 is a slight reworking of patch V8 #3 (making sure we don't try to generate the non-existant PLWZU and PSTWU pre-modify instructions). This test passes when I run make check. Can I check this in when patch V10 #9 is installed? 2019-12-11 Michael Meissner * gcc.target/pow

[PATCH] V10 patch #11, Add test for generating prefixed load/store when the offset is not valid for DS/DQ instructions

Patch V10 #11 is a slight reworking of patch V8 #2 (testing whether we generate a prefixed instruction when the offset would be invalid for DS and DQ instruction formats). This test passes when I run make check. Can I check this in when patch V10 #9 is checked in? 2019-12-11 Michael Meissner

Re: introduce -fcallgraph-info option

On Dec 9, 2019, Richard Biener wrote: > On Tue, 3 Dec 2019, Alexandre Oliva wrote: >> I'm considering rejecting command lines that specify both an explicit >> -dumpdir and -save-temps=cwd, and in the absence of an explicit >> -dumpdir, arranging for -save-temps=cwd or -save-temps=obj to overrid

[PATCH] V10 patch #10, Add PADDI/PLI tests for -mcpu=future

Patch V10 #10 is a modification of patch V8 #1. I renamed the files from paddi-?.c to prefixed-*.c so that there isn't a false match due to the .ident directive. This test passes when I do a make check. One patch V10 #9 is checked in can I commit this patch? 2019-12-11 Michael Meissner

[PATCH] V10 patch #9, Add new effective targets for the testsuite

Patch V10 #9 is patch V7 #5 that was redone. This patch adds new effective target options for PowerPC. I have changed this patch to look at the code generated by the compiler to see if prefixed adddressing or PC-relative addressing is used for -mcpu=future. This patch needs patch V10 #8 installe

[PATCH] V10 patch #8, Enable -mpcrel and -mprefixed-addr for -mcpu=future on 64-bit little endian Linux systems

This patch enables -mpcrel and -mprefixed-addr when -mcpu=future is used on a 64-bit little endian Linux system, but it does not enable those options on other systems. It is a slight reworking of patch V7 #7 taking into account the comments you made. In particular, I changed the macros used by th

[PATCH] V10 patch #7, Improve vector_extract code of a PC-relative address with a constant offset for -mcpu=future

This patch improves the code of vector_extract when the vector is addressed with a PC-relative address, and the element number is constant. I.e. #include static vector double vd[10]; vector double *p = &vd[0]; double get (void) { return vector_

[PATCH] V10 patch #6, Use prefixed load/stores for vector extract with large offsets

This patch optimizes vector extracts where the vector is pointed to by an address with an offset larger than 16-bits to fold the add into the final address. I.e. #include double get (vector double *p, unsigned int h) { return vec_extract (p[5], 1);

[PATCH] V10 patch #5, Fix codegen bug with vector extracts using a variable offset & PC-relative address

This patch fixes a bug with vector extracts using a PC-relative address and a variable offset with using -mcpu=future. Consider the code: #include static vector double vd; vector double *p = &vd; double get (unsigned int n) { return vec_extract

[PATCH] V10 patch #4, Add new prefixed/non-prefixed memory constraints

Add new constraints to match whether a memory is not prefixed (em constraint) or prefixed (ep constraint). This is one of 4 parts aimed at reworking the vector extract code in patch V7 #6. This patch just adds the new constraints, but these constraints will not be used until the next patch. Orig

[PATCH] V10 patch #3, Use PADDI to add large constants if -mcpu=future is used

This patch adds an alternative to use PADDI to add large SImode and DImode constants if -mcpu=future is used. It is a slight reworking of patch V7 #3. I have done bootstraps and make check on a power8 little endian system and there were no regressions. Can I check this patch in? 2019-12-09 Mic

[PATCH] V10 patch #2, use PLI to load up large SImode constants if -mcpu=future

This patch adds an alternative to use PLI to load up large SImode constants if -mcpu=future is used. It is a slight reworking of patch V7 #2 after reformating the movsi_interal1 insn. I have done bootstraps and make check on a power8 little endian system and there were no regressions. Can I chec

[PATCH] V10 patch #1, Use PLI to load up large DImode constants if -mcpu=future

This patch adds an alternative to use PLI to load up large DImode constants if -mcpu=future is used. It is a slight reworking of patch V7 #1 after reformating the movdi_interal64 insn. I have done bootstraps and make check on a power8 little endian system and there were no regressions. Can I che

PowerPC V10 Patches for -mcpu=future

This set of patches is an attempt to address the issues raised in the previous sets of patches: The V7 patches were for important functionality The V8 patches were for tests The V9 patches were for the PCREL_OPT support As I write this there are 12 patches. There will be more patches

[committed] Fix OpenMP fortran atomic swap with casts (PR fortran/92899)

Hi! My PR77500 fix apparently broke the following testcase, while atomic swaps are handled in many ways similarly to atomic writes, in this conditional which is the first one in atomic swap we actually need to look through the conversions. Fixed thusly, bootstrapped/regtested on x86_64-linux and

[committed] Small -ftree-loop-distribute-patterns fixes

Hi! When looking at the hash table memset -> loop patch, I was looking at when -ftree-loop-distribute-patterns is enabled and noticed since r271595 / PR88440 it is actually enabled at -O2+ rather than -O3+. This patch moves it to the proper section, so that OPT_LEVELS_2_PLUS are together, and upda

[PATCH] Fix simplify-rtx.c handling of avx512 vector comparisons (PR target/92908)

Hi! The AVX512{F,VL} vector comparisons that set %kN registers are represented in RTL as comparisons with vector mode operands and scalar integral result, where at runtime the scalar integer is filled with a bitmask. Unfortunately, simplify_relational_operation would fold e.g. (eq:SI (reg:V32HI x)

Re: [PING 3][PATCH] track dynamic allocation in strlen (PR 91582)

Jeff's buildbot exposed a bug in the patch that caused false positives in cases involving negative offsets into destinations involving pointers pointing into multiple regions of the same object. The attached revision fixes that bug, plus makes a few minor other fixes pointed out in PR 92868. On

Re: C++ PATCH for c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr

On Fri, Nov 22, 2019 at 04:11:53PM -0500, Jason Merrill wrote: > On 11/8/19 4:24 PM, Marek Polacek wrote: > > After much weeping and gnashing of teeth, here's a patch to handle > > dynamic_cast > > in constexpr evaluation. While the change in the standard is trivial (see > >

Re: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157

On Wed, Dec 11, 2019 at 11:24:35PM +0100, Harald Anlauf wrote: > > > Gesendet: Dienstag, 10. Dezember 2019 um 23:34 Uhr > > Von: "Thomas Koenig" > > An: "Harald Anlauf" , gfortran , > > gcc-patches > > Betreff: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in > > gfc_check_is_contiguous

Aw: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157

Hi Thomas, > Gesendet: Dienstag, 10. Dezember 2019 um 23:34 Uhr > Von: "Thomas Koenig" > An: "Harald Anlauf" , gfortran , > gcc-patches > Betreff: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in > gfc_check_is_contiguous, at fortran/check.c:7157 > > Hello Harald, > > > Index: gcc/fortr

Re: [PATCH] Fix gnu-versioned-namespace build

On 11/12/19 22:28 +0100, François Dumont wrote: On 12/11/19 9:44 PM, Jonathan Wakely wrote: On 11/12/19 21:23 +0100, François Dumont wrote: On 12/11/19 12:16 PM, Jonathan Wakely wrote: On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just

Re: [PATCH] Fix gnu-versioned-namespace build

On 12/11/19 9:44 PM, Jonathan Wakely wrote: On 11/12/19 21:23 +0100, François Dumont wrote: On 12/11/19 12:16 PM, Jonathan Wakely wrote: On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERSION_

Re: [PATCH 47/49] analyzer: new files: diagnostic-manager.{cc|h}

On Wed, 2019-12-11 at 13:42 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > > This patch adds diagnostic_manager and related support classes for > > saving, deduplicating, and emitting analyzer diagnostics. > > > > gcc/ChangeLog: > > * analyzer/diagnostic-man

Re: [PATCH] Fix gnu-versioned-namespace tr1 declaration

On 11/12/19 21:25 +0100, François Dumont wrote: On 12/11/19 12:22 PM, Jonathan Wakely wrote: On 11/12/19 11:16 +, Jonathan Wakely wrote: On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERS

Re: [PATCH][RFC] Add new ipa-reorder pass

Martin Liška writes: > > Notes and limitations: > - The call-chain-clustering algorithm requires to fit as many as possible > functions into page size (4K). > Based on my measurements that should correspond to ~1000 GIMPLE statements > (IPA inliner size). I can > make it a param in the futur

Re: [PATCH 46/49] analyzer: new files: checker-path.{cc|h}

On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > This patch adds a family of classes for representing paths of events > for analyzer diagnostics. > > gcc/ChangeLog: > * analyzer/checker-path.cc: New file. > * analyzer/checker-path.h: New file. > > No significant concerns her

Re: [PATCH] Fix gnu-versioned-namespace build

On 11/12/19 21:23 +0100, François Dumont wrote: On 12/11/19 12:16 PM, Jonathan Wakely wrote: On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace us

Re: [PATCH 47/49] analyzer: new files: diagnostic-manager.{cc|h}

On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > This patch adds diagnostic_manager and related support classes for > saving, deduplicating, and emitting analyzer diagnostics. > > gcc/ChangeLog: > * analyzer/diagnostic-manager.cc: New file. > * analyzer/diagnostic-manager.h: N

[PATCH] Fix gnu-versioned-namespace tr1 declaration

On 12/11/19 12:22 PM, Jonathan Wakely wrote: On 11/12/19 11:16 +, Jonathan Wakely wrote: On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace us

Re: [PATCH] Fix gnu-versioned-namespace build

On 12/11/19 12:16 PM, Jonathan Wakely wrote: On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace usage outside std namespace. Let me know if it was

Re: [PATCH 00/49] RFC: Add a static analysis framework to GCC

On Mon, 2019-12-09 at 09:10 +0100, Richard Biener wrote: > On Fri, Dec 6, 2019 at 11:31 PM Jeff Law wrote: > > On Wed, 2019-12-04 at 12:55 -0700, Martin Sebor wrote: > > > On 11/15/19 6:22 PM, David Malcolm wrote: > > > > This patch kit introduces a static analysis pass for GCC that > > > > can >

Re: [PATCH 44/49] analyzer: new files: state-purge.{cc|h}

On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > This patch adds classes for tracking what state can be safely purged > at any given point in the program. > > gcc/ChangeLog: > * analyzer/state-purge.cc: New file. > * analyzer/state-purge.h: New file. > --- > gcc/analyzer/stat

Re: [PATCH 43/49] analyzer: new file: exploded-graph.h

On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > This patch adds exploded_graph and related classes, for managing > exploring paths through the user's code as a directed graph > of pairs. > > gcc/ChangeLog: > * analyzer/exploded-graph.h: New file. > --- > gcc/analyzer/exploded-gra

Re: [PATCH 41/49] analyzer: new files: program-point.{cc|h}

On Wed, 2019-12-11 at 12:54 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > > This patch introduces function_point and program_point, classes > > for tracking locations within the program (the latter adding > > a call_string for tracking interprocedural location).

Re: [PATCH 41/49] analyzer: new files: program-point.{cc|h}

On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > This patch introduces function_point and program_point, classes > for tracking locations within the program (the latter adding > a call_string for tracking interprocedural location). > > gcc/ChangeLog: > * analyzer/program-point.cc: N

Re: [PATCH] include size and offset in -Wstringop-overflow

On 12/5/19 4:37 PM, Martin Sebor wrote: If yes, since I don't think I have the time for it for GCC 10 I need to decide whether to drop just this improvement or all of the buffer overflow checks that depend on it. Let me know which you prefer. As I mentioned in my previous message, I think we've

Re: [PATCH 28/49] analyzer: new files: analyzer.{cc|h}

On Sat, 2019-12-07 at 08:01 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: [...] > > diff --git a/gcc/analyzer/analyzer.cc b/gcc/analyzer/analyzer.cc > > new file mode 100644 > > index 000..399925c > > --- /dev/null > > +++ b/gcc/analyzer/analyzer.cc [...] > >

Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches

On 12/11/19 11:27 AM, Jason Merrill wrote: On 12/11/19 2:03 AM, Sandra Loosemore wrote: [snip] Anyway, I'm no longer expecting to get this front end patch into GCC 10, but it would be helpful to get some guidance on how to proceed for resubmission when stage 1 re-opens.  E.g. from where I'm

[Committed] PR fortran/92897 -- remove invalid assert()

Committed as obvious. 2019-12-11 Steven G. Kargl PR fortran/92897 * array.c (gfc_set_array_spec): Remove invalid assert() triggered by invalid Fortran code. 2019-12-11 Steven G. Kargl PR fortran/92897 * gfortran.dg/pr92897.f90: New test. -- Steve

Re: [PATCH 40/49] analyzer: new files: call-string.{cc|h}

On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > This patch adds call_string, a class for representing the > call stacks at a program_point, so that we can ensure that > paths through the code are interprocedurally valid. > > gcc/ChangeLog: > * analyzer/call-string.cc: New file. >

Re: [PATCH 33/49] analyzer: new files: sm.{cc|h}

On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > This patch adds a "state_machine" base class for describing > API checkers in terms of state machine transitions. Followup > patches use this to add specific API checkers. > > gcc/ChangeLog: > * analyzer/sm.cc: New file. > * an

Re: [PATCH] [ARC] Use hardware support for double-precision compare instructions.

On Mon, 2019-12-09 at 11:52 +0200, Claudiu Zissulescu wrote: > Although the FDCMP (the double precision floating point compare > instruction) is added to the compiler, it is not properly used via > cstoredi pattern. Fix it. > > OK to apply? > Claudidu > > -xx-xx Claudiu Zissulescu > >

Re: [patch] factor out common files for compare_exclusions

On Wed, 2019-12-11 at 01:35 +0100, Matthias Klose wrote: > the toplevel configure.ac repeats common exclusion files for specific > targets. > Just factor those out. Maybe not required, but gm2 is adding more > files to be > ignored on every target, so make it easy to only have these files > mentio

Re: [PATCH v2][MSP430] -Add fno-exceptions multilib

On Wed, 2019-11-27 at 19:53 +, Jozef Lawrynowicz wrote: > From b74f34e5ae7f649296f7f6bcce35b75c34a2b0fd Mon Sep 17 00:00:00 2001 > From: Jozef Lawrynowicz > Date: Mon, 25 Nov 2019 12:07:24 + > Subject: [PATCH] MSP430: Add fno-exceptions multilib > > ChangeLog: > > 2019-11-27 Jozef Lawry

Re: [PATCH v2][MSP430] Add msp430-elfbare target

On Wed, 2019-12-11 at 12:21 +, Jozef Lawrynowicz wrote: > On Wed, 11 Dec 2019 12:19:41 + > Jozef Lawrynowicz wrote: > > > On Mon, 9 Dec 2019 15:28:25 + > > Jozef Lawrynowicz wrote: > > > > > On Sat, 07 Dec 2019 11:40:33 -0700 > > > Jeff Law wrote: > > > > > > > On Fri, 2019-11-2

Re: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE

On Wed, 2019-12-11 at 11:49 +, Jozef Lawrynowicz wrote: > On Mon, 9 Dec 2019 13:05:22 + > Jozef Lawrynowicz wrote: > > > On Sat, 07 Dec 2019 11:27:54 -0700 > > Jeff Law wrote: > > > > > On Wed, 2019-11-06 at 16:19 +, Jozef Lawrynowicz wrote: > > > > From 7bc0971d2936ebe71e7b7d3d80

Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches

On Wed, 2019-12-11 at 00:03 -0700, Sandra Loosemore wrote: > On 12/6/19 3:41 PM, Jeff Law wrote: > > On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote: > > > I bootstrapped and regression-tested this on x86_64-linux- > > > gnu. There > > > are a few regressions involving these tests: > > >

Re: [C++ PATCH] Fix -std=c++17 and earlier handling of CLASSTYPE_NON_AGGREGATE (PR c++/92869)

On 12/10/19 3:47 PM, Jakub Jelinek wrote: Hi! In C++20, types with user-declared constructors are not aggregate types, while in C++17 only types with user-provided or explicit constructors. In check_bases_and_members we handle it properly: CLASSTYPE_NON_AGGREGATE (t) |= ((cxx_dialect < c

Re: [C++ PATCH] c++/92878 - Parenthesized init of aggregates in new-expression.

On 12/10/19 2:13 PM, Marek Polacek wrote: Ville pointed out that our paren init of aggregates doesn't work for auto a = new A(1, 2, 3); and I think it should: A new-expression that creates an object of type T initializes that object as follows: ... -- Otherwise, the new-initializer is inter

Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches

On 12/11/19 2:03 AM, Sandra Loosemore wrote: On 12/6/19 3:41 PM, Jeff Law wrote: On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote: I bootstrapped and regression-tested this on x86_64-linux-gnu.  There are a few regressions involving these tests: gcc.dg/tree-ssa/pr77445-2.c I believe

Re: [PATCH] Fix vect rotate pattern recog (PR target/92723)

Jakub Jelinek writes: > On Wed, Dec 11, 2019 at 04:52:30PM +, Richard Sandiford wrote: >> WDYT about instead having: >> >> if (dt != vect_internal_def || TYPE_MODE (TREE_TYPE (oprnd1)) == mode) >> >> and removing the ext_def stuff? I'd have expected keeping the original >> operand to alwa

Re: [PATCH, GCC/ARM, 2/2] Add support for ASRL(imm), LSLL(imm) and LSRL(imm) instructions for Armv8.1-M Mainline

Hi Mihail, On 11/14/19 1:54 PM, Mihail Ionescu wrote: Hi, This is part of a series of patches where I am trying to add new instructions for Armv8.1-M Mainline to the arm backend. This patch is adding the following instructions: ASRL (imm) LSLL (imm) LSRL (imm) ChangeLog entry are as follow:

Re: [PATCH, GCC/ARM, 1/2] Add support for ASRL(reg) and LSLL(reg) instructions for Armv8.1-M Mainline

Hi Mihail, On 11/14/19 1:54 PM, Mihail Ionescu wrote: Hi, This patch adds the new scalar shift instructions for Armv8.1-M Mainline to the arm backend. This patch is adding the following instructions: ASRL (reg) LSLL (reg) Sorry for the delay, very busy time for GCC development :( Change

Re: [PATCH] Fix vect rotate pattern recog (PR target/92723)

On Wed, Dec 11, 2019 at 04:52:30PM +, Richard Sandiford wrote: > WDYT about instead having: > > if (dt != vect_internal_def || TYPE_MODE (TREE_TYPE (oprnd1)) == mode) > > and removing the ext_def stuff? I'd have expected keeping the original > operand to always be best for vect_external_de

[PR92843] [OpenACC] Fix dynamic reference counting for structured 'REFCOUNT_INFINITY'

Hi! See attached "[PR92843] [OpenACC] Fix dynamic reference counting for structured 'REFCOUNT_INFINITY'"; committed to trunk in r279234. Grüße Thomas From 7c8ffaf54af2c8acb77f82349aac4dd68d47ad9d Mon Sep 17 00:00:00 2001 From: tschwinge Date: Wed, 11 Dec 2019 16:49:27 + Subject: [PATCH]

Re: [PATCH] OpenACC reference count overhaul

Hi! On 2019-10-29T12:15:01+, Julian Brown wrote: > On Mon, 21 Oct 2019 16:14:11 +0200 > Thomas Schwinge wrote: >> On 2019-10-03T09:35:04-0700, Julian Brown >> wrote: >> > void >> > -gomp_acc_remove_pointer (void *h, size_t s, bool force_copyfrom, >> > int async, >> > - in

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

Ping? Le jeu. 5 déc. 2019 à 11:13, Christophe Lyon a écrit : > ping? > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01667.html > > Kyrill approved the previous version modulo a typo fix, but Richard > wanted a better name for a variable. > Is that version OK? > > Thanks, > > Christophe > > > On

[OpenACC] Consolidate 'async'/'wait' code in 'libgomp/oacc-async.c'

Hi! As a preparational patch/general refactoring, see attached "[OpenACC] Consolidate 'async'/'wait' code in 'libgomp/oacc-async.c'"; committed to trunk in r279232. Grüße Thomas From 2b04bb7b4c9a13b6eadc7d9723245dd58f0f4f04 Mon Sep 17 00:00:00 2001 From: tschwinge Date: Wed, 11 Dec 2019 16:4

[PR92854] Add 'libgomp.oacc-c-c++-common/acc_map_data-device_already-*.c', 'libgomp.oacc-c-c++-common/acc_map_data-host_already-*.c'

Hi! See attached "[PR92854] Add 'libgomp.oacc-c-c++-common/acc_map_data-device_already-*.c', 'libgomp.oacc-c-c++-common/acc_map_data-host_already-*.c'", committed to trunk in r279231, "to document the status quo", which does match my understanding of the OpenACC 2.6 semantics. The TODO in 'libgom

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

Hi! On 2018-06-19T10:01:20-0700, Cesar Philippidis wrote: > This patch implements the OpenACC 2.5 data clause semantics in libgomp. > --- a/libgomp/libgomp.h > +++ b/libgomp/libgomp.h > @@ -853,6 +853,8 @@ struct splay_tree_key_s { >uintptr_t tgt_offset; >/* Reference count. */ >uin

Re: [PATCH] PR90838: Support ctz idioms

Hi Richard, >> +(match (ctz_table_index @1 @2 @3) >> +  (rshift (mult (bit_and (negate @1) @1) INTEGER_CST@2) INTEGER_CST@3)) > > You need a :c on the bit_and Fixed. > +  unsigned HOST_WIDE_INT val = tree_to_uhwi (mulc); > +  unsigned shiftval = tree_to_uhwi (tshift); > +  unsigned input_bits =

Re: [PATCH] Fix vect rotate pattern recog (PR target/92723)

Jakub Jelinek writes: > Hi! > > Unlike x86, where the last operand of vector by scalar shift is DImode for > V[248]DImode shifts, on aarch64 they seem to be SImode. > vect_recog_rotate_pattern when the rotate amount is not constant casts the > amount to the element type of the vector, so for V[248

[C++ PATCH] PR c++/92105 - decltype(decltype) error cascade.

The primary change here is to do the CPP_DECLTYPE replacement even when we get an error, so we don't keep trying and giving the same parse error each time. We also commit to the tentative firewall parse more often, leading to better diagnostics. Tested x86_64-pc-linux-gnu, applying to trunk.

[C++ PATCH] PR c++/57082 - new X{} and private destructor.

build_new_1 already passes tf_no_cleanup to build_value_init, but in this testcase we end up calling build_value_init by way of build_special_member_call, so we need to pass it to that function as well. Tested x86_64-pc-linux-gnu, applying to trunk. * init.c (build_new_1): Also pass tf_no

[C++ PATCH] PR c++/92774 - ICE with implicitly deleted operator<=>.

Missing error-recovery code. While I was poking at this I also figured we don't need to iterate over the members of a union. Tested x86_64-pc-linux-gnu, applying to trunk. * method.c (comp_info::~comp_info): Factor out of... (build_comparison_op): Here. Handle error return from

Re: [PATCH] Fix gnu-versioned-namespace build

On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace usage outside std namespace. Let me know if it was intentional.     * src/c++11/random.cc: Add

[C++ PATCH] PR c++/92446 - deduction of class NTTP.

Another place we need to look through the VIEW_CONVERT_EXPR we add to make a use of a class NTTP have const type. Tested x86_64-pc-linux-gnu, applying to trunk. * pt.c (deducible_expression): Look through VIEW_CONVERT_EXPR. --- gcc/cp/pt.c | 2 +- gcc/te

[C++ PATCH] PR c++/92859 - ADL and bit-field.

We also need unlowered_expr_type when considering associated types for ADL. Tested x86_64-pc-linux-gnu, applying to trunk. * name-lookup.c: Use unlowered_expr_type. --- gcc/cp/name-lookup.c | 2 +- gcc/testsuite/g++.dg/overload/bit-field1.C | 18 ++

Re: [PATCH] hash-table.h: support non-zero empty values in empty_slow

On Wed, Dec 11, 2019 at 10:44:58AM -0500, David Malcolm wrote: > Is it OK for a hash_map key to have a "empty" value that isn't > all-zeroes (and thus the same for a hash_table entry)? > > Is the following patch OK for trunk? I'd say that it is important to analyze the generated code for the comm

[PATCH] hash-table.h: support non-zero empty values in empty_slow

On Tue, 2019-12-10 at 16:00 -0700, Martin Sebor wrote: > On 12/10/19 3:07 PM, David Malcolm wrote: > > On Tue, 2019-12-03 at 15:41 -0700, Martin Sebor wrote: > > > After allocating a new chunk of memory hash_table::expand() copy- > > > assigns elements from the current array over the newly allocate

Re: [PATCH, rs6000] Adjust vectorization cost for scalar COND_EXPR

On Wed, Dec 11, 2019 at 07:39:38AM -0600, Bill Schmidt wrote: > I can't approve this, but for what it's worth it looks fine to me. But I can :-) Thanks for looking Bill! The patch is okay for trunk. Thanks Ke Wen! Segher > >2019-12-11 Kewen Lin > > > > * config/rs6000/rs6000.c (adjus

Re: [PATCH, rs6000] Adjust vectorization cost for scalar COND_EXPR

Hi! I can't approve this, but for what it's worth it looks fine to me. Bill On 12/11/19 6:31 AM, Kewen.Lin wrote: Hi, We found that the vectorization cost modeling on scalar COND_EXPR is a bit off on rs6000. One typical case is 548.exchange2_r, -Ofast -mcpu=power9 -mrecip -fvect-cost-model=u

[patch] libgomp/openacc.f90 – clean-up public/private attributes

This patch cleans up the public/private handling in libgomp/openacc.f90: * module openacc_kinds marked symbols explicitly as public and private (but default is public). Make this explicit by a 'PUBLIC' and remove the (redundant) explicit 'public :: ' lines. * 'module openacc' had a bunch of '

[PATCH, rs6000] Adjust vectorization cost for scalar COND_EXPR

Hi, We found that the vectorization cost modeling on scalar COND_EXPR is a bit off on rs6000. One typical case is 548.exchange2_r, -Ofast -mcpu=power9 -mrecip -fvect-cost-model=unlimited is better than -Ofast -mcpu=power9 -mrecip (the default is -fvect-cost-model=dynamic) by 1.94%. Scalar COND_E

Re: [PATCH v2][MSP430] Add msp430-elfbare target

On Wed, 11 Dec 2019 12:19:41 + Jozef Lawrynowicz wrote: > On Mon, 9 Dec 2019 15:28:25 + > Jozef Lawrynowicz wrote: > > > On Sat, 07 Dec 2019 11:40:33 -0700 > > Jeff Law wrote: > > > > > On Fri, 2019-11-29 at 21:00 +, Jozef Lawrynowicz wrote: > > > > The attached patch consol

Re: [PATCH v2][MSP430] Add msp430-elfbare target

On Mon, 9 Dec 2019 15:28:25 + Jozef Lawrynowicz wrote: > On Sat, 07 Dec 2019 11:40:33 -0700 > Jeff Law wrote: > > > On Fri, 2019-11-29 at 21:00 +, Jozef Lawrynowicz wrote: > > > The attached patch consolidates some configuration tweaks I > > > previously submitted > > > as modificatio

Re: [testsuite][arm] Remove xfail for vect-epilogues test

On December 11, 2019 12:27:31 PM GMT+01:00, "Andre Vieira (lists)" wrote: >Hi, > >We can now vectorize an epilogue for this loop for arm too, so removing > >xfail. > >Is this OK for trunk? Wasn't entirely sure whether I could commit this >under obvious. Sure. Richard. >gcc/testsuite/ChangeL

arm: Fix an incorrect warning when -mcpu=cortex-a55 is used with -mfloat-abi=soft

When a CPU such as cortex-a55 is used with the soft-float ABI variant, the compiler is incorrectly issuing a warning about a mismatch between the architecture (generated internally) and the CPU. This is not expected or intended. The problem stems from the fact that we generate (correctly) an

Re: [Patch, committed] libgomp – spelling fixes, incl. omp_lib.h.in

On Wed, Dec 11, 2019 at 12:48:10PM +0100, Tobias Burnus wrote: > --- libgomp/ChangeLog (revision 279217) > +++ libgomp/ChangeLog (revision 279218) > @@ -1,5 +1,25 @@ > 2019-12-11 Tobias Burnus > > + * omp_lib.h.in: Fix spelling of function declaration > + omp_get_cancell(l)ation. > -

Re: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE

On Mon, 9 Dec 2019 13:05:22 + Jozef Lawrynowicz wrote: > On Sat, 07 Dec 2019 11:27:54 -0700 > Jeff Law wrote: > > > On Wed, 2019-11-06 at 16:19 +, Jozef Lawrynowicz wrote: > > > From 7bc0971d2936ebe71e7b7d3d805cf1bbf9f9f5af Mon Sep 17 00:00:00 2001 > > > From: Jozef Lawrynowicz > > >

[Patch, committed] libgomp – spelling fixes, incl. omp_lib.h.in

This patch fixes various comment typos – and: * omp_lib.h.in (Fortran): omp_get_cancell(l)ation – this typo could break user code; the test suite has 'use omp_lib' (i.e. the module) and not the #include file; hence, it didn't fail there. * libgomp.texi: This one is also user visible. Committ

[testsuite][arm] Remove xfail for vect-epilogues test

Hi, We can now vectorize an epilogue for this loop for arm too, so removing xfail. Is this OK for trunk? Wasn't entirely sure whether I could commit this under obvious. gcc/testsuite/ChangeLog: 2019-12-11 Andre Vieira * gcc.dg/vect/vect-epilogues.c: Remove xfail for arm. diff --

Re: [PATCH] Fix gnu-versioned-namespace build

On 11/12/19 11:16 +, Jonathan Wakely wrote: On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace usage outside std namespace. Let me know if it w

Re: [PATCH] Fix gnu-versioned-namespace build

On 11/12/19 08:29 +0100, François Dumont wrote: I plan to commit this tomorrow. Note that rather than just adding the missing _GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace usage outside std namespace. Let me know if it was intentional. It was intentional, why move it

Re: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments

Hi Thomas, [Attached patch committed as Rev. 279217] [One OpenMP (+OpenACC) patch and one OpenACC-only patch pending review are linked below.] On 12/7/19 3:49 PM, Thomas Schwinge wrote: I'm seeing: [-PASS:-]{+FAIL:+} libgomp.fortran/use_device_addr-3.f90 -O1 execution test Whether

Re: [PATCH] Rename condition_variable_any::wait_on_* methods

On 10/12/19 22:38 -0800, Thomas Rodgers wrote: User-agent: mu4e 1.3.4; emacs 26.2 * include/std/condition_variable (condition_variable_any::wait_on(_Lock&, stop_token, _Predicate): Rename to match current draft standard. (condition_variable_any::wait_on_until(_Lock

Re: Ping: [GCC][PATCH] Add ARM-specific Bfloat format support to middle-end

Hi all, On 12/11/19 9:41 AM, Stam Markianos-Wright wrote: On 12/11/19 3:48 AM, Jeff Law wrote: > On Mon, 2019-12-09 at 13:40 +, Stam Markianos-Wright wrote: >> >> On 12/3/19 10:31 AM, Stam Markianos-Wright wrote: >>> >>> On 12/2/19 9:27 PM, Joseph Myers wrote: On Mon, 2 Dec 2019, Jeff

Re: [PATCH]Add tune option for integer mask cmov, enable this tune for m_CORE_AVX512

On Wed, Dec 11, 2019 at 06:18:31PM +0800, Hongtao Liu wrote: > Hi: > This patch is about to add tune option for integer mask cmov, for > some targets has both integer mask register and sse mask register, > this tune indicates to use integer one. Currently it's default on for > m_CORE_AVX512. > >

[PATCH]Add tune option for integer mask cmov, enable this tune for m_CORE_AVX512

Hi: This patch is about to add tune option for integer mask cmov, for some targets has both integer mask register and sse mask register, this tune indicates to use integer one. Currently it's default on for m_CORE_AVX512. Bootstrap is ok, regression test on i386/x86_64 backends is ok. ok for

Re: Ping: [GCC][PATCH] Add ARM-specific Bfloat format support to middle-end

On 12/11/19 3:48 AM, Jeff Law wrote: > On Mon, 2019-12-09 at 13:40 +, Stam Markianos-Wright wrote: >> >> On 12/3/19 10:31 AM, Stam Markianos-Wright wrote: >>> >>> On 12/2/19 9:27 PM, Joseph Myers wrote: On Mon, 2 Dec 2019, Jeff Law wrote: >> 2019-11-13 Stam Markianos-Wright <

[PATCH, committed] Fix PR92901: Change test expectation for C++ in OpenACC test clause-locations.c

Hi, I have committed the attached trivial patch to trunk as r279215. The columns of the clause locations are reported differently by the C and C++ front-end and hence we need different test expectations for both languages. Best regards, Frederik --