Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

On 4/3/20 4:07 PM, Patrick Palka wrote: On Fri, 3 Apr 2020, Jason Merrill wrote: On 4/2/20 7:40 PM, Patrick Palka wrote: + /* Prefer the outermost matching object, but don't cross + CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors. */ + if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY

Re: [PATCH] debug: Improve debug info of c++14 deduced return type [PR94459]

On 4/3/20 6:47 PM, Jakub Jelinek wrote: Hi! On the following testcase, in gdb ptype S::m1 prints long as return type, but all the other methods show void instead. PR53756 added code to add_type_attribute if the return type is auto/decltype(auto), but we actually should look through references,

Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On 4/3/20 9:08 PM, Marek Polacek wrote: On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote: On 3/30/20 4:28 PM, Marek Polacek wrote: Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't expect null indexes for a constructor: /* ??? Here's

Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

On 4/3/20 4:57 PM, Patrick Palka wrote: On Fri, 3 Apr 2020, Patrick Palka wrote: On Fri, 3 Apr 2020, Jason Merrill wrote: On 4/2/20 2:19 PM, Patrick Palka wrote: On Thu, 2 Apr 2020, Patrick Palka wrote: This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do not

Re: [PATCH v2] c++: Fix further protected_set_expr_location related -fcompare-debug issues [PR94441]

On 4/3/20 4:12 PM, Jakub Jelinek wrote: On Fri, Apr 03, 2020 at 03:02:58PM -0400, Jason Merrill via Gcc-patches wrote: Or do we want a further wrapper, perhaps C++ FE only, that would do this protected_set_expr_location_if_unset (stmt, locus)? That sounds good to me. So like this if it

[Committed] S/390 zTPF: Handle skip trace addresses when unwinding

From: Jim Johnston Check for and handle new skip trace addresses when unwinding on zTPF. libgcc/ChangeLog: 2020-04-03 Jim Johnston * config/s390/tpf-unwind.h (MIN_PATRANGE, MAX_PATRANGE) (TPFRA_OFFSET): Macros removed. (CP_CNF, cinfc_fast, CINFC_CMRESET,

[PATCH v2] gcc/config/rs6000: Add link with libc128 with -mlong-double-128 for AIX

Description: * AIX applications using 128-bit long double must be linked with libc128.a, in order to have 128-bit compatible routines. Tests: * AIX 7.2, 7.1, 6.1: Build/Tests: OK Changelog: 2020-04-03 Clément Chigot * config/rs6000/aix61.h (LIB_SPEC): Add -lc128 with -mlong-double-128. *

Re: [PATCH] ICF: compare type attributes for gimple_call_fntypes.

On 4/2/20 7:17 PM, Christophe Lyon wrote: On Thu, 2 Apr 2020 at 17:16, Martin Liška wrote: Hi. The patch compares type attributes for gimple_call_fntypes in IPA ICF. Note that we were unable to find a generic function attribute that can be used on a function type definition. For a one which

Re: [PATCH] ICF: compare type attributes for gimple_call_fntypes.

On Thu, Apr 2, 2020 at 5:16 PM Martin Liška wrote: > > Hi. > > The patch compares type attributes for gimple_call_fntypes in IPA ICF. > Note that we were unable to find a generic function attribute that > can be used on a function type definition. > > For a one which is allowed assume_aligned(16)

Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

On 2020/4/3 06:16, Segher Boessenkool wrote: > Hi! > > On Mon, Mar 30, 2020 at 11:59:57AM +0800, luoxhu wrote: >>> Do we want something later in the RTL pipeline to make "addi"s etc. again? > > (This would be a good thing to consider -- maybe a define_insn_and_split > will work. But see

[PATCH 1/3] Do locking for __gcov_dump and __gcov_reset as well.

libgcc/ChangeLog: 2020-04-03 Martin Liska PR gcov-profile/93623 * Makefile.in: Add _gcov_lock_unlock to LIBGCOV_INTERFACE. * libgcov-interface.c (ALIAS_void_fn): Remove. (__gcov_lock): New. (__gcov_unlock): New. (__gcov_flush): Use __gcov_lock

[stage1][PATCH 0/3] __gcov_dump improvements

Hi. The following mini patch series improves: - gcov run-time locking is used for user accessible __gcov_dump and __gcov_reset functions - do not run __gcov_flush in fork, only __gcov_reset is called in child process - gcov exec* wrappers dump counters and reset only if execv* fails Patch can

[PATCH 2/3] Use __gcov_dump and __gcov_reset in execv and fork context.

libgcc/ChangeLog: 2020-04-03 Martin Liska PR gcov-profile/93623 * libgcov-interface.c (__gcov_fork): Do not flush and reset only in child process. (__gcov_execl): Dump counters only and reset them only if exec* fails. (__gcov_execlp): Likewise.

[PATCH 3/3] Remove __gcov_flush.

gcc/ChangeLog: 2020-04-03 Martin Liska PR gcov-profile/93623 * tree-cfg.c (stmt_can_terminate_bb_p): Update comment to reflect reality. libgcc/ChangeLog: 2020-04-03 Martin Liska PR gcov-profile/93623 * Makefile.in: Remove __gcov_flush. *

Revert "[nvptx, libgomp] Update pr85381-{2, 4}.c test-cases" [PR89713, PR94392] (was: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++)

Hi! On 2020-04-02T11:12:48+0200, Richard Biener wrote: > On Wed, 1 Apr 2020, Jason Merrill wrote: > >> On 4/1/20 9:36 AM, Richard Biener wrote: >> > This does away with enabling -ffinite-loops at -O2+ for all languages >> > and instead enables it selectively for C++ only. > I'm retesting the

Re: [PATCH] Fix PR94443 with gsi_insert_seq_before

On Thu, Apr 2, 2020 at 12:43 PM Kewen.Lin wrote: > > on 2020/4/2 上午6:51, H.J. Lu wrote: > > > > This caused: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449 > > > > Thanks for reporting this. The attached patch is to fix the stupid > mistake by using gsi_insert_seq_before instead of

Re: [PATCH] gcc-9 sra: Cap number of sub-access propagations with a param (PR 93435)

On Thu, 2 Apr 2020, Martin Jambor wrote: > Hi, > > This is non-trivial but rather straightforward backport of > 29f23ed79b60949fc60f6fdbbd931bd58090b241 from master. See > https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542390.html for > more information. > > Bootstrapped and tested on

Re: [PATCH] Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3

On Thu, 2020-04-02 at 20:36 -0400, Michael Meissner via Gcc-patches wrote: > Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3 > Hi, > This patch changes the default for -mcpu=future to be -mpcrel (i.e. > use > PC-relative addressing) if the ABI allows PC-relative relocations and > the

Re: [Patch] omp-grid.c – add cast to silence different enumeration types warning

On Fri, Apr 03, 2020 at 11:02:13AM +0200, Tobias Burnus wrote: > Those are all for the same switch statement; > > gomp_for contains 'tree clauses' and this clauses's '->code' is used > to handle store 'enum omp_clauses_code' values in in gimple.{h,c}. > > I think adding this cast (and only this

Re: [PATCH] Improve svn-rev to search for pattern at line beginning.

On Fri, Apr 03, 2020 at 11:13:17AM +0200, Martin Liška wrote: > 2020-04-03 Martin Liska > > * gcc-git-customization.sh: Search for the pattern > at line beginning only. Ok, thanks. > diff --git a/contrib/gcc-git-customization.sh > b/contrib/gcc-git-customization.sh > index

[Patch] HSA: omp-grid.c – access proper clause code (was: Re: [Patch] omp-grid.c – add cast to silence different enumeration types warning)

Hi Jakub, hi Martin, I think I misread some bits – after more code reading, I think it correctly sets '(NODE)->omp_clause.code' alias OMP_CLAUSE_CODE; Hence, using OMP_CLAUSE_CODE in the switch statement makes sense for the actual code usage (and, of course, also semantically). As I don't have

[PATCH] Improve svn-rev to search for pattern at line beginning.

Hi. It's a small fix that removes the first commit from the following command: $ git svn-rev 279550 commit bcf3fa7cf5a3d024b507f68ffdfab037f4820781 Author: Andre Vieira Date: Wed Jan 29 14:23:22 2020 + IRA: Revert 11b8091fb to fix PR 93221 A previous change to simplify LRA

Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu via Gcc-patches wrote: > Seems PR94393? Yes, rs6000_emit_set_const calls rs6000_emit_set_long_const > for DImode. > I tried unsigned long like 0xabcd87654321, 0xabcd87654321 and > 0xc000ULL, > All of them are outside of loop even

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote: > This is attacking case 3 of PR 94174. > > In v2, I unify the various subtract-with-borrow and add-with-carry > patterns that also output flags with unspecs. As suggested by > Richard Sandiford during review of v1. It does seem

[committed] libstdc++: Fix std::to_address for debug iterators (PR 93960)

It should be valid to use std::to_address on a past-the-end iterator, but the debug mode iterators do a check for dereferenceable in their operator->(). That check is generally useful, so rather than remove it this changes std::__to_address to identify a debug mode iterator and use

Re: Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713, PR94392] (was: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++)

On Fri, Apr 03, 2020 at 11:36:29AM +0200, Richard Biener wrote: > Note there's now also the opportunity to set the loop flag for > OpenACC/OpenMP annotated loops if any of that guarantees finiteness. > (for GCC11 only please) Dunno about OpenACC, but OpenMP loops guarantee finiteness, as the

Re: GCC 9 backports

Hi. There's one more I've tested. Martin >From 3b64f64f036c03e74fc4b55327cc07dc1dc21116 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Fri, 3 Apr 2020 09:39:10 +0200 Subject: [PATCH] Backport 55a7380213a5c16120d5c674fb42b38a3d796b57 gcc/ChangeLog: 2020-04-03 Martin Liska PR ipa/94445

Re: GCC 8 backports

Hi. There's one more I've tested. Martin >From 3b64f64f036c03e74fc4b55327cc07dc1dc21116 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Fri, 3 Apr 2020 09:39:10 +0200 Subject: [PATCH] Backport 55a7380213a5c16120d5c674fb42b38a3d796b57 gcc/ChangeLog: 2020-04-03 Martin Liska PR ipa/94445

Re: [PATCH][GCC][AArch64] opt: Fix options canonization for assembler

On 02/04/2020 17:52, Tamar Christina wrote: > Hi All, > > It is currently impossible to use fp16 on any architecture higher than > Armv8.3-a > due to a bug in options canonization. This bug results in the fp16 flag not > being emitted in the assembly when it should have been. > > This is

[Patch] omp-grid.c – add cast to silence different enumeration types warning

Hi, that's based on https://users.suse.com/~mliska/clang-warnings.txt which has for omp-grid.c: /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/omp-grid.c:1070:7: warning: comparison of two values with different enumeration types in switch statement ('enum tree_code' and

Re: Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713, PR94392] (was: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++)

On Fri, 3 Apr 2020, Thomas Schwinge wrote: > Hi! > > On 2020-04-02T11:12:48+0200, Richard Biener wrote: > > On Wed, 1 Apr 2020, Jason Merrill wrote: > > > >> On 4/1/20 9:36 AM, Richard Biener wrote: > >> > This does away with enabling -ffinite-loops at -O2+ for all languages > >> > and instead

Re: [committed] libstdc++: Move "free books" list from fsf.org to gnu.org

On 01/04/20 22:47 +0200, Gerald Pfeifer wrote: The fsf.org server now has a redirect to the gnu.org server; let's follow that. This is my first commit to libstdc++ using git, my first squashing (since I had a follow tweak to the ChangeLog), and my first --amend. Please advise if I can/should

[PATCH] middle-end/94465 - handle released SSA names in array_ref_low_bound

array_ref_low_bound is used in dumping ARRAY_REFs which in turn is called when basic blocks are deleted. cleanup_control_flow_pre consciously decides to remove unreachable basic-blocks in arbitrary order so the following makes array_ref_low_bound forgiving in the case the SSA name with the index

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

"Richard Earnshaw (lists)" writes: > On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote: >> This is attacking case 3 of PR 94174. >> >> In v2, I unify the various subtract-with-borrow and add-with-carry >> patterns that also output flags with unspecs. As suggested by >> Richard

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

On 03/04/2020 13:27, Richard Sandiford wrote: > "Richard Earnshaw (lists)" writes: >> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote: >>> This is attacking case 3 of PR 94174. >>> >>> In v2, I unify the various subtract-with-borrow and add-with-carry >>> patterns that also output

[committed][GCC][Arm]: MVE: Fix unintended change to tests

When committing my last patch I accidentally removed -mfpu=auto from the following tests. This puts it back. 2020-04-03  Andre Vieira      * gcc.target/arm/mve/intrinsics/mve_vector_float.c: Put -mfpu=auto back.     * gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise.  

[committed] c++: Add test for PR c++/93211

The fix for PR c++/90711 also fixed this PR. gcc/testsuite/ChangeLog: PR c++/93211 PR c++/90711 * g++.dg/template/koenig11.C: New test. --- gcc/testsuite/g++.dg/template/koenig11.C | 11 +++ 1 file changed, 11 insertions(+) create mode 100644

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

Hi, and this is the streaming fix diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c index e4077b58890..dd9645723c1 100644 --- a/gcc/tree-ssa-dce.c +++ b/gcc/tree-ssa-dce.c @@ -646,6 +647,19 @@ degenerate_phi_p (gimple *phi) return true; } +/* Return true if C1 and C2 are matching

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

> On 3/31/20 2:29 PM, Jan Hubicka wrote: > > Well, I basically went through all pointers and tried to get rid of as > > many of them as possible. CONTEXT pointers do increase size of SCCs > > that increases chance they will not get merged and also processing time > > of merging algorithm. I

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

"Richard Earnshaw (lists)" writes: > On 03/04/2020 13:27, Richard Sandiford wrote: >> "Richard Earnshaw (lists)" writes: >>> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote: This is attacking case 3 of PR 94174. In v2, I unify the various subtract-with-borrow and

Re: [PATCH] Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3

Hi! On Thu, Apr 02, 2020 at 08:36:59PM -0400, Michael Meissner wrote: > I have changed the spelling of the macro to PCREL_SUPPORTED_BY_ABI (from > PCREL_SUPPORTED_BY_OS) since you pointed out it is more properly a function of > the particular ABI, rather than just an OS choice. No, I did not,

[PATCH] i386: Fix vph{add,subs?}[wd] 256-bit AVX2 RTL patterns [PR94460]

Hi! The following testcase is miscompiled, because the AVX2 patterns don't describe correctly what the insn does. E.g. vphaddd with %ymm* operands (the second pattern) instruction as per: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi32=2941 does { a0+a1,

Re: [PATCH] i386: Fix up handling of OPTION_MASK_ISA_MMX builtins [PR94461]

On Fri, Apr 3, 2020 at 7:30 PM Jakub Jelinek wrote: > > Hi! > > In https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00576.html the builtin > handling was changed so that OPTION_MASK_ISA_MMX | OPTION_MASK_ISA_SSE > etc. in i386-builtin.def means we require both mmx and sse, not just one of > those,

[PATCH] x86: Mark scratch operand in ssse3_pshufbv8qi3 as earlyclobber

commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979 Author: H.J. Lu Date: Wed May 15 15:26:19 2019 + i386: Emulate MMX pshufb with SSE version has +(define_insn_and_split "ssse3_pshufbv8qi3" + [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv") + (unspec:V8QI [(match_operand:V8QI

[PATCH] cselib: Don't consider SP_DERIVED_VALUE_P values as useless [PR94468]

Hi! The following testcase ICEs, because at one point we see the SP_DERIVED_VALUE_P VALUE as useless (not PRESERVED_VALUE_P and no locs) and so expect it to be discarded as useless. But, later on we are adding some new VALUE that is equivalent to it, and when adding the equivalency that that new

Re: [PATCH] Improve svn-rev to search for pattern at line beginning.

Thanks, this matches the commit hook (which only rejects From-SVN: at start of line, not elsewhere in a commit message). -- Joseph S. Myers jos...@codesourcery.com

[PATCH] i386: Fix up handling of OPTION_MASK_ISA_MMX builtins [PR94461]

Hi! In https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00576.html the builtin handling was changed so that OPTION_MASK_ISA_MMX | OPTION_MASK_ISA_SSE etc. in i386-builtin.def means we require both mmx and sse, not just one of those, and later on for other option combinations very similar rule has

Ping: [PATCH] testsuite: Tweak check-function-bodies interface

Ping for the doc/sourcebuild.texi and lib/scanasm.exp parts. Richard Sandiford writes: > In g:2171a9207f51bc486ed9c502cb4da706f594615e I'd tried to fix > various ILP32 testsuite failures by restricting some tests to LP64. > Unfortunately, I messed up the check-function-bodies syntax and passed >

Re: [PATCH] x86: Mark scratch operand in ssse3_pshufbv8qi3 as earlyclobber

On Fri, Apr 3, 2020 at 6:51 PM H.J. Lu wrote: > > commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979 > Author: H.J. Lu > Date: Wed May 15 15:26:19 2019 + > > i386: Emulate MMX pshufb with SSE version > > has > > +(define_insn_and_split "ssse3_pshufbv8qi3" > + [(set (match_operand:V8QI 0

Re: [PATCH] i386: Fix vph{add, subs?}[wd] 256-bit AVX2 RTL patterns [PR94460]

On Fri, Apr 3, 2020 at 7:06 PM Jakub Jelinek wrote: > > Hi! > > The following testcase is miscompiled, because the AVX2 patterns don't > describe correctly what the insn does. E.g. vphaddd with %ymm* operands > (the second pattern) instruction as per: >

[pushed] c++: alias template and parameter packs (PR91966).

In this testcase, when we do a pack expansion of count_better_mins, nums appears both in the definition of count_better_mins and as its template argument. The intent is that we get a expansion over pairs of elements of the pack, i.e. less<2,2>, less<2,7>, less<7,2>, But if we substitute

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

On 3/18/20 10:05 AM, Martin Liška wrote: On 3/17/20 7:43 PM, Egeyar Bagcioglu wrote: Hi Martin, I like the patch. It definitely serves our purposes at Oracle and provides another way to do what my previous patches did as well. 1) It keeps the backwards compatibility regarding

Re: [PATCH] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On 3/30/20 4:28 PM, Marek Polacek wrote: Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't expect null indexes for a constructor: /* ??? Here's to hoping the front end fills in all of the indices, so we don't have to figure out what's missing ourselves.

[PATCH v2] c++: Fix further protected_set_expr_location related -fcompare-debug issues [PR94441]

On Fri, Apr 03, 2020 at 03:02:58PM -0400, Jason Merrill via Gcc-patches wrote: > > Or do we want a further wrapper, perhaps C++ FE only, that would do this > > protected_set_expr_location_if_unset (stmt, locus)? > > That sounds good to me. So like this if it passes bootstrap/regtest? 2020-04-03

Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

On 4/2/20 7:40 PM, Patrick Palka wrote: + /* Prefer the outermost matching object, but don't cross + CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors. */ + if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ctx->ctor)) +if (tree parent_ob = lookup_placeholder (ctx->parent, lval, type))

[committed] Fix m32r target bug exposed by Jakub's cselib.c changes

va-arg-22.c started failing on the m32r target (-O1 only) after Jakub's recent cselib changes. The m32r port has this pattern: (define_insn "cpymemsi_internal" [(set (mem:BLK (match_operand:SI 0 "register_operand" "r")) ;; destination (mem:BLK (match_operand:SI 1 "register_operand"

[PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, David and Jakub, Per the discussion we had for PR94230: provide an option to change the size limitation for -Wmisleading-indent https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 I come up with the following simple patch per David’s

Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

On 4/2/20 2:19 PM, Patrick Palka wrote: On Thu, 2 Apr 2020, Patrick Palka wrote: This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do not anticipate that a constructor element's initializer could mutate the underlying CONSTRUCTOR. Evaluation of the initializer could

Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

On Fri, 3 Apr 2020, Jason Merrill wrote: > On 4/2/20 7:40 PM, Patrick Palka wrote: > > + /* Prefer the outermost matching object, but don't cross > > + CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors. */ > > + if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ctx->ctor)) > > +if (tree

Re: [PATCH] c++: Fix further protected_set_expr_location related -fcompare-debug issues [PR94441]

On 4/2/20 3:48 AM, Jakub Jelinek wrote: Hi! My recent protected_set_expr_location changes work well when that function is called unconditionally, but as the testcase shows, the C++ FE has a few spots that do: if (!EXPR_HAS_LOCATION (stmt)) protected_set_expr_location (stmt, locus); or

Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

On Fri, 3 Apr 2020, Patrick Palka wrote: > On Fri, 3 Apr 2020, Jason Merrill wrote: > > > On 4/2/20 2:19 PM, Patrick Palka wrote: > > > On Thu, 2 Apr 2020, Patrick Palka wrote: > > > > > > > This PR reveals that cxx_eval_bare_aggregate and > > > > cxx_eval_store_expression > > > > do > > > >

Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

Hi! On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu wrote: > Currently 286r.split2 will split "12:%9:DI=0x87654321" to lis+ori by > rs6000_emit_set_const of define_split, do you mean add new > define_insn_and_split > to do the split? Another patch to do this after this one goes upstream in >

Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote: > On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu via Gcc-patches wrote: > > Seems PR94393? Yes, rs6000_emit_set_const calls rs6000_emit_set_long_const > > for DImode. > > I tried unsigned long like 0xabcd87654321, 0xabcd87654321

[PATCH] Fix some incorrect Changelog dates

Hello, It seems that some dates in gcc/ChangeLog-2019 and gcc/testsuite/ChangeLog-2019 are incorrect. diff --git a/gcc/ChangeLog-2019 b/gcc/ChangeLog-2019 index 9f5782fd458..1acf57d49b9 100644 --- a/gcc/ChangeLog-2019 +++ b/gcc/ChangeLog-2019 @@ -1,10 +1,10 @@ -2020-12-31 Richard Sandiford

Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

On Fri, 3 Apr 2020, Jason Merrill wrote: > On 4/2/20 2:19 PM, Patrick Palka wrote: > > On Thu, 2 Apr 2020, Patrick Palka wrote: > > > > > This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression > > > do > > > not anticipate that a constructor element's initializer could mutate

libgcc patch committed: Avoid hooks in split-stack code

The split-stack code invokes mmap and munmap with a limited amount of stack space. That is fine when the functions just make a system call, but it's not fine when programs use LD_PRELOAD or linker tricks to add hooks to mmap/munmap. Those hooks may use too much stack space, leading to an obscure

Re: [PATCH] Fix some incorrect Changelog dates

On Fri, Apr 03, 2020 at 03:53:47PM -0600, Zackery Spytz via Gcc-patches wrote: > Hello, > > It seems that some dates in gcc/ChangeLog-2019 and > gcc/testsuite/ChangeLog-2019 are incorrect. If we want to fix these, there are many more suspect cases. I guess we'd need to look at each of those,

[committed] openmp: Fix ICE on #pragma omp parallel master in template [PR94477]

Hi! The following testcase ICEs, because for parallel combined with some other construct we initialize the omp_parallel_combined_clauses pointer and expect the construct combined with it to clear it after it no longer needs it, but OMP_MASTER didn't do that. Bootstrapped/regtested on

Re: [PATCH] cselib: Don't consider SP_DERIVED_VALUE_P values as useless [PR94468]

On Fri, Apr 03, 2020 at 07:42:10PM +0200, Jakub Jelinek via Gcc-patches wrote: > Or, to avoid the repetitive code, should I introduce > static bool > cselib_useless_value_p (cselib_val *v) > { > return (v->locs == 0 > && !PRESERVED_VALUE_P (v->val_rtx) > && !SP_DERIVED_VALUE_P

[PATCH] i386: Simplify {,v}ph{add,sub{,s}{w,d} insn patterns [PR94460]

Hi! As mentioned in the previous PR94460 patch, the RTL patterns look too large/complicated, we can simplify them by just performing two 2 arg permutations to move the arguments into the right spots and then just doing the plus/minus (or signed saturation version thereof). Bootstrapped/regtested

Re: [PATCH] debug: Improve debug info of c++14 deduced return type [PR94459]

Am Samstag, 4. April 2020, 00:47:27 MESZ hat Jakub Jelinek via Gcc-patches Folgendes geschrieben: > Hi! > > On the following testcase, in gdb ptype S::m1 prints long as return > type, but all the other methods show void instead. > PR53756 added code to add_type_attribute if the return type is

[PATCH] gcc/gcc.c: add outfiles spec

Commit 0b7fb27b698d (Fix and document -r option) broke building of VxWorks modules, at least for our version of VxWorks. A VxWorks module is a relocatable ELF file - the final link is done when the file is linked in to the running kernel. So building with -r is necessary. However, the module also

[committed] Fix xstormy16 fallout from Jakub's cselib changes

This fixes more fallout from Jakub's cselib changes. This shows up as an ICE building stdarg-3 from the testsuite after Jakub's changes. However, a reduced testcase will fail miserably all the way back to gcc-7 (as far back as I tested). The xstormy port only allows a subset of the

[PATCH] debug: Improve debug info of c++14 deduced return type [PR94459]

Hi! On the following testcase, in gdb ptype S::m1 prints long as return type, but all the other methods show void instead. PR53756 added code to add_type_attribute if the return type is auto/decltype(auto), but we actually should look through references, pointers and qualifiers. Haven't included

[PATCH libffi 2/4] Use a documented way to pass $compiler_vendor to DejaGNU

Use Autoconf substitution in the template used for extra DejaGNU site configuration, which is a documented supported way to pass information from the `configure' script, rather than resorting to a hack with extracting an undocumented internal setting from `config.log' to pass the compiler

[PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU

Use an Autoconf template rather an inline piece of scriptery to set DejaGNU's $CC_FOR_TARGET and $CXX_FOR_TARGET variables from $CC and $CXX respectively, making it easier to maintain and making it take advantage of Automake's dependency and rule generation. Relocate the generated `local.exp'

[PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET

Update code in `libffi-init' to use $CC_FOR_TARGET in determining the value of $ld_library_path, as using a different compiler location from one actually used in testing may have odd consequences. As this obviously loses the setting of $gccdir provide a replacement way to determine the

[PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite

Hi, In the course of a discussion at one of the GCC mailing lists here: I have realised that some parts related to libffi testing have not been merged to GCC, and they are needed to choose the right compiler in a

[PATCH libffi 4/4] Correct indentation throughout `libffi-init'

--- testsuite/lib/libffi.exp |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) libffi-init-whitespace.diff Index: libffi/testsuite/lib/libffi.exp === --- libffi.orig/testsuite/lib/libffi.exp +++

[PATCH v4 1/5] libatomic/test: Fix compilation for build sysroot

Fix a problem with the libatomic testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the lack of a suitable `--sysroot=' option where the `--with-build-sysroot='

[PATCH v4 0/5] Fix library testsuite compilation for build sysroot

Hi, This is v4 of patch series, originally posted here: v2

[PATCH v4 GCC 3/5] libffi/test: Make `libffi-init' use $CC_FOR_TARGET

Update code in `libffi-init' to use $CC_FOR_TARGET in determining the value of $ld_library_path, as using a different compiler location from one actually used in testing may have odd consequences. As this obviously loses the setting of $gccdir provide a replacement way to determine the

[PATCH v4 4/5] libgo/test: Complement compilation fix for build sysroot

Complement commit b72813a68c94 ("libgo: fix DejaGNU testsuite compiler when using build sysroot") and move testsuite/libgo-test-support.exp.in to testsuite/libgo-site-extra.exp.in. Update testsuite/lib/libgo.exp to handle the `--tool_exec' option to `runtest' as with other top-level GCC

[PATCH v4 5/5] libgomp/test: Remove a build sysroot fix regression

Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation for build sysroot") that caused a regression in some standalone test environments where testsuite/libgomp-test-support.exp is used, but the compiler is expected to be determined by `[find_gcc]', and set the GCC_UNDER_TEST

[PATCH v4 GCC 2/5] libffi/test: Fix compilation for build sysroot

Fix a problem with the libffi testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the inability to actually choose any compiler at all in a cross-compilation

Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

On Fri, Apr 03, 2020 at 04:11:32PM -0500, Segher Boessenkool wrote: > On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote: > > Segher probably meant the part I'm working on and haven't posted yet, > > fixing lots of problems with rs6000_rtx_costs. > > I meant PR94393 in fact, but yeah,

Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote: > On 3/30/20 4:28 PM, Marek Polacek wrote: > > Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't > > expect null indexes for a constructor: > > > >/* ??? Here's to hoping the front end

[RFA] skip gcc.target/arm/div64-unwinding.c on vxworks_kernel targets

Hello, This test verifies, by using a weak reference to _Unwind_RaiseException, that performing division by zero does not cause that symbol to get indirectly pulled into our closure. The testing methodology unfortunately does not work on VxWorks targets when building in kernel mode. This is