Re: [PATCH][RTL] Fix PR87852

On Fri, 2 Nov 2018, Eric Botcazou wrote: > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > > > OK for trunk? > > > > Thanks, > > Richard. > > > > 2018-11-02 Richard Biener > > > > PR rtl-optimization/87852 > > * fwprop.c (use_killed_between): Only consider singl

[PATCH 3/4] Fix vector memory statistics.

gcc/ChangeLog: 2018-11-02 Martin Liska * mem-stats.h (mem_alloc_description::release_instance_overhead): Return T *. * vec.c (struct vec_usage): Register m_element_size. (vec_prefix::register_overhead): New arguments: elements and element_size.

[PATCH 1/4] Fix string pool statistics.

libcpp/ChangeLog: 2018-11-02 Martin Liska * include/symtab.h (ht_identifier): Make room for ggc flag. * symtab.c (ht_lookup_with_hash): Mark GGC and non-GGC allocated strings. (ht_dump_statistics): Use the information. --- libcpp/include/symtab.h | 4

[PATCH 4/4] Come up with SIZE_AMOUNT and use it in memory statistics and sort stats.

gcc/ChangeLog: 2018-11-02 Martin Liska * alloc-pool.h (struct pool_usage): Use SIZE_AMOUNT. * bitmap.h (struct bitmap_usage): Likewise. * ggc-common.c (SCALE): Remove. (LABEL): Likewise. (struct ggc_usage): Use SIZE_AMOUNT. And update compare me

[PATCH 2/4] Fix GNU coding style.

gcc/ChangeLog: 2018-11-02 Martin Liska * mem-stats.h (mem_alloc_description::get_list): Fix GNU coding style. * vec.c: Likewise. --- gcc/mem-stats.h | 61 + gcc/vec.c | 1 - 2 files changed, 26 insertions(+), 36 d

[PATCH 0/4] Enhance and fix various issues in -fmem-report

Hi. As I discussed with Richi, the patch set fixes few issues in memory report. Apart from that it makes it more readable with usage of k (or M) as units. Survives bootstrap and regression tests on x86_64-linux-gnu. And there are no new warnings on i586-linux-gnu. Martin marxin (4): Fix strin

Re: [PATCH] i386: Remove duplicated AVX2/AVX512 vec_dup patterns

On Sun, Nov 4, 2018 at 9:49 PM H.J. Lu wrote: > > > > Actually, we can achieve the same with pre-reload splitters. Please > > > > see the attached patch for a couple of examples and a fix for > > > > vbroadcastss that accesses the memory in wrong mode. > > > > > > > > > > My patch removes a bunch

Re: [PATCH] newlib/configure.host: Set have_init_fini to no for OpenRISC

On Nov 3 07:00, Stafford Horne wrote: > The new GCC port for OpenRISC will use the init_fini_array only and not > provide the init() and fini() functions. Disable the function usage by > default as its no longer needed. > > Signed-off-by: Stafford Horne > --- > newlib/configure.host | 1 + > 1

[PATCH] Fix -fsanitize=undefined vs. x + y < x (PR sanitizer/87837)

Hi! I wish I had a better fix, but I don't, trying to sanitize signed integer arithmetics in the FEs already before any folding there is complicated by that arithmetics being created just in way too many spots. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-11-05 Jaku

Re: PR83750: CSE erf/erfc pair

On Fri, Nov 2, 2018 at 10:37 AM Prathamesh Kulkarni wrote: > > Hi, > This patch adds two transforms to match.pd to CSE erf/erfc pair. > erfc(x) is canonicalized to 1 - erf(x) and is then reversed to 1 - > erf(x) when canonicalization is disabled and result of erf(x) has > single use within 1 - erf

Re: [PATCH 1/4] Fix string pool statistics.

On Mon, Nov 5, 2018 at 9:07 AM marxin wrote: > > > libcpp/ChangeLog: Hmm, the patch suggests the flag might be instead part of cpp_hash_table instead of each individual ht_identifier? Or the patch is confused when it sets HT_GGC to 1 even in else -HT_STR (node) = (const unsigned char *)

Re: [PATCH 2/4] Fix GNU coding style.

On Mon, Nov 5, 2018 at 9:07 AM marxin wrote: > OK > gcc/ChangeLog: > > 2018-11-02 Martin Liska > > * mem-stats.h (mem_alloc_description::get_list): Fix GNU coding > style. > * vec.c: Likewise. > --- > gcc/mem-stats.h | 61 +-

Re: [PATCH 3/4] Fix vector memory statistics.

On Mon, Nov 5, 2018 at 9:07 AM marxin wrote: > > > gcc/ChangeLog: /* Release PTR pointer of SIZE bytes. If REMOVE_FROM_MAP is set to true, remove the instance from reverse map. */ - void release_instance_overhead (void *ptr, size_t size, - bool remove_fr

[PATCH] Fix store merging wrong-code (PR tree-optimization/87859)

Hi! My recent change for PR86844 broke the following testcases. The problem is that we are processing the stores in the bitpos/bitsize order. The change PR86844 change was about if we try to merge two overlapping stores of INTEGER_CST, we need to go through all other stores that are overlapping

Re: [PATCH] Fix -fsanitize=undefined vs. x + y < x (PR sanitizer/87837)

On Mon, 5 Nov 2018, Jakub Jelinek wrote: > Hi! > > I wish I had a better fix, but I don't, trying to sanitize signed integer > arithmetics in the FEs already before any folding there is complicated by > that arithmetics being created just in way too many spots. I suppose we could play some trick

Re: [PATCH v2] S/390: Allow LARL of literal pool entries

> Am 31.10.2018 um 10:59 schrieb Ulrich Weigand : > > Ilya Leoshkevich wrote: >> Am 30.10.2018 um 18:22 schrieb Ulrich Weigand : >>> This definitely looks wrong. If we haven't annotated the address, >>> it should *not* be found by find_constant_pool_ref, since we are >>> not going to replace i

Re: [PATCH] Fix store merging wrong-code (PR tree-optimization/87859)

On Mon, 5 Nov 2018, Jakub Jelinek wrote: > Hi! > > My recent change for PR86844 broke the following testcases. > > The problem is that we are processing the stores in the bitpos/bitsize > order. The change PR86844 change was about if we try to merge two > overlapping stores of INTEGER_CST, we n

Re: [PATCH] Fix -fsanitize=undefined vs. x + y < x (PR sanitizer/87837)

On Mon, Nov 05, 2018 at 11:03:28AM +0100, Richard Biener wrote: > On Mon, 5 Nov 2018, Jakub Jelinek wrote: > > > Hi! > > > > I wish I had a better fix, but I don't, trying to sanitize signed integer > > arithmetics in the FEs already before any folding there is complicated by > > that arithmetics

Re: [aarch64] disable shrink wrapping when tracking speculative execution

On Fri, Nov 2, 2018 at 3:04 PM Richard Earnshaw (lists) wrote: > > On 02/11/2018 13:53, Richard Biener wrote: > > On Fri, Nov 2, 2018 at 2:38 PM Richard Earnshaw (lists) > > wrote: > >> > >> Although there's no fundamental reason why shrink wrapping and > >> speculation tracking are incompatible,

Re: [aarch64] disable shrink wrapping when tracking speculative execution

On 05/11/2018 10:05, Richard Biener wrote: > On Fri, Nov 2, 2018 at 3:04 PM Richard Earnshaw (lists) > wrote: >> >> On 02/11/2018 13:53, Richard Biener wrote: >>> On Fri, Nov 2, 2018 at 2:38 PM Richard Earnshaw (lists) >>> wrote: Although there's no fundamental reason why shrink wrappin

Re: [PATCH 1/3][GCC] Add new target hook asm_post_cfi_startproc

On 11/05/2018 07:54 AM, Richard Biener wrote: > On Fri, 2 Nov 2018, Sam Tebbs wrote: > >> On 11/02/2018 05:28 PM, Sam Tebbs wrote: >> >>> Hi all, >>> >>> This patch adds a new target hook called "asm_post_cfi_startproc". This >>> hook is >>> intended to be used by the aarch64 backend to emit a d

[PATCH] Rip out SCEV cprop

This rips out SCEV constant propagation, keeping only final value replacement in the scev_cprop pass. There's not a single testcase that shows "SCEV" constant propagation is doing sth useful. This takes us one step closer of removing the pass completely, doing final value replacement only when

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On 04/11/18 09:05, Stafford Horne wrote: > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote: >> On 27/10/18 05:37, Stafford Horne wrote: ... >>> +#undef LINK_SPEC >>> +#define LINK_SPEC "%{h*} \ >>> + %{static:-Bstatic} \ >>> + %{share

[PATCH][GCC] Make DR_TARGET_ALIGNMENT compile time variable

Hi, This patch enables targets to describe DR_TARGET_ALIGNMENT as a compile-time variable. It does so by turning the variable into a 'poly_uint64'. This should not affect the current code-generation for any target. We hope to use this in the near future for SVE using the current_vector_size as

Re: PR83750: CSE erf/erfc pair

On Mon, 5 Nov 2018 at 15:10, Richard Biener wrote: > > On Fri, Nov 2, 2018 at 10:37 AM Prathamesh Kulkarni > wrote: > > > > Hi, > > This patch adds two transforms to match.pd to CSE erf/erfc pair. > > erfc(x) is canonicalized to 1 - erf(x) and is then reversed to 1 - > > erf(x) when canonicalizat

Re: [PATCH 1/4] Fix string pool statistics.

On 11/5/18 10:52 AM, Richard Biener wrote: > On Mon, Nov 5, 2018 at 9:07 AM marxin wrote: >> >> >> libcpp/ChangeLog: > > Hmm, the patch suggests the flag might be instead > part of cpp_hash_table instead of each individual > ht_identifier? Or the patch is confused when it > sets HT_GGC to 1 even

Re: [PATCH 3/4] Fix vector memory statistics.

On 11/5/18 10:56 AM, Richard Biener wrote: > On Mon, Nov 5, 2018 at 9:07 AM marxin wrote: >> >> >> gcc/ChangeLog: > >/* Release PTR pointer of SIZE bytes. If REMOVE_FROM_MAP is set to true, > remove the instance from reverse map. */ > - void release_instance_overhead (void *ptr, size_

Re: [PATCH] combine: Do not combine moves from hard registers

Hi Segher, On 11/03/2018 02:34 AM, Jeff Law wrote: On 11/2/18 5:54 PM, Segher Boessenkool wrote: On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote: The original rtx is generated by expand_builtin_setjmp_receiver to adjust the frame pointer. And later in LRA, it will try to el

Re: [PATCH][GCC] Make DR_TARGET_ALIGNMENT compile time variable

On Mon, Nov 5, 2018 at 1:07 PM Andre Vieira (lists) wrote: > > > Hi, > > This patch enables targets to describe DR_TARGET_ALIGNMENT as a > compile-time variable. It does so by turning the variable into a > 'poly_uint64'. This should not affect the current code-generation for > any target. > > We

Re: PR83750: CSE erf/erfc pair

On Mon, Nov 5, 2018 at 1:11 PM Prathamesh Kulkarni wrote: > > On Mon, 5 Nov 2018 at 15:10, Richard Biener > wrote: > > > > On Fri, Nov 2, 2018 at 10:37 AM Prathamesh Kulkarni > > wrote: > > > > > > Hi, > > > This patch adds two transforms to match.pd to CSE erf/erfc pair. > > > erfc(x) is canon

Re: [PATCH 1/4] Fix string pool statistics.

On Mon, Nov 5, 2018 at 1:17 PM Martin Liška wrote: > > On 11/5/18 10:52 AM, Richard Biener wrote: > > On Mon, Nov 5, 2018 at 9:07 AM marxin wrote: > >> > >> > >> libcpp/ChangeLog: > > > > Hmm, the patch suggests the flag might be instead > > part of cpp_hash_table instead of each individual > > h

Re: [PATCH 3/4] Fix vector memory statistics.

On Mon, Nov 5, 2018 at 1:17 PM Martin Liška wrote: > > On 11/5/18 10:56 AM, Richard Biener wrote: > > On Mon, Nov 5, 2018 at 9:07 AM marxin wrote: > >> > >> > >> gcc/ChangeLog: > > > >/* Release PTR pointer of SIZE bytes. If REMOVE_FROM_MAP is set to true, > > remove the instance from r

Re: [ARM] Implement division using vrecpe, vrecps

Hi Prathamesh, Prathamesh Kulkarni wrote: > Thanks for the suggestions. The last time I benchmarked the patch > (around Jan 2016) > I got following results with the patch for SPEC2006: > > a15: +0.64% overall, 481.wrf: +6.46% > a53: +0.21% overall, 416.gamess: -1.39%, 481.wrf: +6.76% > a57: +0.35%

[committed] Cherry-pick asan fix (PR sanitizer/87860)

Hi. There's a sparc fix that I've just installed in libsanitizer upstream repository. I'm going to install it into GCC's trunk. Martin >From c43ed4eb4d76ec25e42b954a00a1684de09011da Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 5 Nov 2018 14:30:00 +0100 Subject: [PATCH] Fix build on sparc64-l

Fix SPEC gcc micompile with LTO

Hi, this patch fixes the miscompare I introduced to spec2006 GCC benchmark when build with LTO. The problem is that fld_incomplete_type_of builds new pointer type to incomplete type rather than complete but it ends up giving wrong type canonical. This patch also improves TBAA with early opts becau

Re: [PATCH] x86: Update VFIXUPIMM* Intrinsics to align with the latest Intel SDM

On Sun, Nov 4, 2018 at 11:00 PM Uros Bizjak wrote: > > On Mon, Nov 5, 2018 at 6:54 AM Wei Xiao wrote: > > > > > Please also rename these: > > > > > > _mm512_mask_fixupimm_round_pd (__m512d __A, __mmask8 __U, __m512d __B, > > > __m512i __C, const int __imm, const int __R) > >

Re: [ARM] Implement division using vrecpe, vrecps

On 26/10/2018 06:04, Prathamesh Kulkarni wrote: > Hi, > This is a rebased version of patch that adds a pattern to neon.md for > implementing division with multiplication by reciprocal using > vrecpe/vrecps with -funsafe-math-optimizations excluding -Os. > The newly added test-cases are not vectoriz

Re: PR83750: CSE erf/erfc pair

On Mon, 5 Nov 2018 at 18:14, Richard Biener wrote: > > On Mon, Nov 5, 2018 at 1:11 PM Prathamesh Kulkarni > wrote: > > > > On Mon, 5 Nov 2018 at 15:10, Richard Biener > > wrote: > > > > > > On Fri, Nov 2, 2018 at 10:37 AM Prathamesh Kulkarni > > > wrote: > > > > > > > > Hi, > > > > This patch

Backports to 8.3

Hi! I've backported from trunk, bootstrapped/regtested on x86_64-linux and i686-linux and committed to gcc-8-branch the following 6 patches. Jakub 2018-11-05 Jakub Jelinek Backported from mainline 2018-10-19 Jakub Jelinek PR middle-end/85488 PR midd

[PATCH] S/390: Introduce relative_long attribute

In order to properly fix PR87762, we need to distinguish between instructions which support relative addressing and instructions which don't. We could check whether the existing "type" attribute is equal to "larl", but there are notable exceptions (lrl, for example), and changing them makes schedu

Re: V2 [PATCH] i386: Add pass_remove_partial_avx_dependency

> > Did you mean "the nearest common dominator"? If the nearest common dominator appears in the loop while all uses are out of loops, this will result in suboptimal xor placement. In this case you want to split edges out of the loop. In general this is what the LCM framework will do for you if t

[PATCH][OBVIOUS] Fix printf call in symtab.c.

Hi. I'm sending obvious fix that I forgot to adjust. Martin >From 873c7df254f98b27a83272abd9f60adb32741026 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 5 Nov 2018 15:22:20 +0100 Subject: [PATCH] Fix printf call in symtab.c. libcpp/ChangeLog: 2018-11-05 Martin Liska * symtab.c (ht_dump

Re: [PATCH][OBVIOUS] Fix printf call in symtab.c.

One more change is needed. Thanks for understanding, Martin >From 60d59b8b3deea1b59c135705b333ddf2ab6a9ba4 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 5 Nov 2018 15:28:21 +0100 Subject: [PATCH] Do not use %zu format in libcpp. libcpp/ChangeLog: 2018-11-05 Martin Liska * symtab.c (ht_d

Re: [PATCH AutoFDO/2]Treat ZERO as common profile probability/count

diff --git a/gcc/profile-count.h b/gcc/profile-count.h index f4d0c340a0a..4289bc5a004 100644 --- a/gcc/profile-count.h +++ b/gcc/profile-count.h @@ -200,11 +200,11 @@ public: ret.m_quality = profile_guessed; return ret; } - static profile_probability always () + static profile_

[PATCH] S/390: Increase register move costs for CC_REGS

Hi, the attached patch increases the move costs for moves involving the CC register. This saves us some instructions in SPEC CPU2006. Regards Robin -- gcc/ChangeLog: 2018-11-05 Robin Dapp * config/s390/s390.c (s390_register_move_cost): Increase costs for moves involving t

Re: [PATCH AutoFDO/2]Treat ZERO as common profile probability/count

diff --git a/gcc/profile-count.h b/gcc/profile-count.h index 4289bc5a004..2b5e3269250 100644 --- a/gcc/profile-count.h +++ b/gcc/profile-count.h @@ -218,6 +218,11 @@ public: } + /* Return true if value is zero. */ + bool never_p () const +{ + return m_val == 0; +} /* Ret

[PATCH][RTL] Add simplify pattern for bitfield insertion

The PR18041 testcase is about bitfield insertion of the style b->bit |= <...> where the RMW cycle we end up generating contains redundant masking and ORing of the original b->bit value. The following adds a combine pattern in simplify-rtx to specifically match (X & C) | ((X | Y) & ~C) and

Re: Fix SPEC gcc micompile with LTO

On Mon, 5 Nov 2018, Jan Hubicka wrote: > Hi, > this patch fixes the miscompare I introduced to spec2006 GCC benchmark > when build with LTO. > The problem is that fld_incomplete_type_of builds new pointer type to > incomplete type rather than complete but it ends up giving wrong type > canonical.

[PATCH] Fix PR87873

The fragile PHI copying logic in the vectorizer got confused by constants in loop-closed PHI nodes. Fixed like the following. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. >From a965417cbefd54f45ac6f2b6e3d5dc39c307da09 Mon Sep 17 00:00:00 2001 From: Richard G

Re: V2 [PATCH] i386: Add pass_remove_partial_avx_dependency

On 11/5/18 7:21 AM, Jan Hubicka wrote: >> >> Did you mean "the nearest common dominator"? > > If the nearest common dominator appears in the loop while all uses are > out of loops, this will result in suboptimal xor placement. > In this case you want to split edges out of the loop. > > In general

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote: > On 04/11/18 09:05, Stafford Horne wrote: > > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote: > >> On 27/10/18 05:37, Stafford Horne wrote: > ... > >>> +#undef LINK_SPEC > >>> +#define LINK_SPEC "%{h*} \

Re: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

> On Nov 3, 2018, at 10:12 PM, Jeff Law wrote: > > On 11/1/18 1:13 PM, Paul Koning wrote: >> A number of test cases contain declarations like: >> void *memcpy(); >> which currently are silently accepted on most platforms but not on all; >> pdp11 (and possibly some others) generate a "conflic

Re: Fix SPEC gcc micompile with LTO

> Hmm, this _should_ be a no-op. Can you, before that line, add > > gcc_assert (TYPE_CANONICAL (t2) != t2 > && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); > > ? That is, the incomplete variant should share TYPE_CANONICAL with > the pointed-to type and be _not_ the ca

Re: V2 [PATCH] i386: Add pass_remove_partial_avx_dependency

> On 11/5/18 7:21 AM, Jan Hubicka wrote: > >> > >> Did you mean "the nearest common dominator"? > > > > If the nearest common dominator appears in the loop while all uses are > > out of loops, this will result in suboptimal xor placement. > > In this case you want to split edges out of the loop. >

Re: Fix SPEC gcc micompile with LTO

On Mon, 5 Nov 2018, Jan Hubicka wrote: > > Hmm, this _should_ be a no-op. Can you, before that line, add > > > > gcc_assert (TYPE_CANONICAL (t2) != t2 > > && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); > > > > ? That is, the incomplete variant should share TYPE_CANO

Re: Fix SPEC gcc micompile with LTO

> > + gcc_assert (TYPE_CANONICAL (t2) != t2 > > + && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); > > + TYPE_CANONICAL (first) = TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)); > > as said the TYPE_CANONICAL assign should be already done exactly this > way in build_{poit

Re: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

On 11/05/2018 08:12 AM, Paul Koning wrote: On Nov 3, 2018, at 10:12 PM, Jeff Law wrote: On 11/1/18 1:13 PM, Paul Koning wrote: A number of test cases contain declarations like: void *memcpy(); which currently are silently accepted on most platforms but not on all; pdp11 (and possibly some

Re: Fix SPEC gcc micompile with LTO

Hi, this is patch I ended up testing. It ensures that canonical types of copies I create are same as of originals C++ FE has its own refernece type construction (cp_build_reference_type) and it creates additional pointer types with TYPE_REF_IS_RVALUE set and it has different TYPE_CANONICAL. Obvio

Re: Fix SPEC gcc micompile with LTO

> Hi, > this is patch I ended up testing. It ensures that canonical types of > copies I create are same as of originals C++ FE has its own refernece piece of mail got lost rendering the paragraph unreadable. I wanted to say: This is patch I ended up testing. It ensures that canonical types of c

Re: [PATCH], Remove power9 fusion support

On Nov 2, 2018, at 11:37 AM, Michael Meissner wrote: > > As I discussed in my 2018 Cauldron talk, the PowerPC GCC compiler supported a > subset of the original design for fusion in the power9 hardware using > peepholes > to fuse together ADDIS instructions and floating point load/store operation

[PATCH] S/390: Make tests expect column numbers in RTL output

RTL output now includes column numbers in addition to line numbers, like this: "gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c":16:1 This confuses some S/390 tests. gcc/testsuite/ChangeLog: 2018-11-05 Ilya Leoshkevich * gcc.target/s390/md/andc-splitter-1.c: Add colon to

Re: [PATCH] S/390: Make tests expect column numbers in RTL output

On 05.11.18 17:32, Ilya Leoshkevich wrote: > RTL output now includes column numbers in addition to line numbers, > like this: > > "gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c":16:1 > > This confuses some S/390 tests. > > gcc/testsuite/ChangeLog: > > 2018-11-05 Ilya Leoshkevich > >

Re: [PATCH] S/390: Increase register move costs for CC_REGS

On 05.11.18 15:38, Robin Dapp wrote: > Hi, > > the attached patch increases the move costs for moves involving the CC > register. This saves us some instructions in SPEC CPU2006. > > Regards > Robin > > -- > > gcc/ChangeLog: > > 2018-11-05 Robin Dapp > > * config/s390/s390.c (s390_

Re: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

On 11/5/18 8:12 AM, Paul Koning wrote: > > >> On Nov 3, 2018, at 10:12 PM, Jeff Law wrote: >> >> On 11/1/18 1:13 PM, Paul Koning wrote: >>> A number of test cases contain declarations like: >>> void *memcpy(); >>> which currently are silently accepted on most platforms but not on all; >>> pdp1

Re: [PATCH][RTL] Add simplify pattern for bitfield insertion

On 11/5/18 7:44 AM, Richard Biener wrote: > > The PR18041 testcase is about bitfield insertion of the style > > b->bit |= <...> > > where the RMW cycle we end up generating contains redundant > masking and ORing of the original b->bit value. The following > adds a combine pattern in simplify-r

Re: [PATCH 2/4] Fix GNU coding style.

On 11/02/2018 04:37 AM, marxin wrote: gcc/ChangeLog: 2018-11-02 Martin Liska * mem-stats.h (mem_alloc_description::get_list): Fix GNU coding style. * vec.c: Likewise. I have no preference here or even know what the style guide calls for (nor have I been able to fin

[PATCH][rs6000] use index form addresses more often for l[wh]brx/st[wh]brx

This does the same thing for bswap2 that I previously did for bswapdi2. The predicates for bswap2_{load,store} are now indexed_or_indirect_operand, and bswap2 uses rs6000_force_indexed_or_indirect_mem to make sure the address is appropriate for that predicate. Bootstrap/regtest passes on ppc64le

Re: Fix SPEC gcc micompile with LTO

On November 5, 2018 5:11:09 PM GMT+01:00, Jan Hubicka wrote: >> Hi, >> this is patch I ended up testing. It ensures that canonical types of >> copies I create are same as of originals C++ FE has its own refernece >piece of mail got lost rendering the paragraph unreadable. I wanted to >say: > >Th

Re: [PATCH] Verify that last argument of __builtin_expect_with_probability is a real cst (PR c/87811).

On 11/01/2018 07:45 AM, Martin Liška wrote: On 11/1/18 1:15 PM, Jakub Jelinek wrote: On Thu, Nov 01, 2018 at 01:09:16PM +0100, Martin Liška wrote: -range 0.0 to 1.0, inclusive. +range 0.0 to 1.0, inclusive. The @var{probability} argument must be +a compiler time constant. When you say must,

Re: [PATCH libquadmath/PR68686]

On Sat, 3 Nov 2018, Jeff Law wrote: > Note that Joseph's follow-up doesn't touch on the gamma problem AFAICT, > but instead touches on the larger issues around trying to keep the > quadmath implementations between glibc and gcc more in sync. The second version of my patch

Re: [PATCH libquadmath/PR68686]

On Fri, Nov 02, 2018 at 11:43:03PM +, Joseph Myers wrote: > Here's an updated version of the patch that also updates most of the > previously omitted libquadmath/math/ files that are based on glibc sources > (not fmaq.c or rem_pio2q.c), including *gamma*. It adds exp2q and > issignalingq as

Re: [PATCH] combine: Do not combine moves from hard registers

On 11/05/2018 12:35 PM, Renlin Li wrote: Hi Segher, On 11/03/2018 02:34 AM, Jeff Law wrote: On 11/2/18 5:54 PM, Segher Boessenkool wrote: On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote: The original rtx is generated by expand_builtin_setjmp_receiver to adjust the frame

Re: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

> On Nov 5, 2018, at 11:45 AM, Jeff Law wrote: > >>> ... >> >> I can do that, but I'm wondering if some systems have different prototypes >> than the C standard calls for so I'd end up breaking those.I wouldn't worry >> about those. I think the bigger question (thanks > Martin) is whether

Re: [PATCH libquadmath/PR68686]

On Sun, 4 Nov 2018, Ed Smith-Rowland wrote: > I looked in glibc.  Unfortunately, I see how they have the same mistake: > glibc/math/w_tgammal_compat.c: >     long double >     __tgammal(long double x) >     { >         int local_signgam; >         long double y = __ieee754_gammal_r(x,&local_signga

Re: [PATCH libquadmath/PR68686]

On Sun, 4 Nov 2018, Ed Smith-Rowland wrote: > I *do* think a couple tests should be added to test-signgam-*.c to test > alternation of signs: The main tests for results of libm functions are in auto-libm-test-in (from which auto-libm-test-out-* are generated by gen-auto-libm-tests.c) and libm-t

Re: PR83750: CSE erf/erfc pair

On Sun, 4 Nov 2018, Jeff Law wrote: > Don't we have a flag specific to honoring nans? Would that be better to > use than flag_unsafe_math_optimizations? As Uli mentioned, there's That's only relevant for the comparison optimization, of course. Converting erfc to 1-erf is dubious, since the who

Re: PR83750: CSE erf/erfc pair

On 11/5/18 11:27 AM, Joseph Myers wrote: > On Sun, 4 Nov 2018, Jeff Law wrote: > >> Don't we have a flag specific to honoring nans? Would that be better to >> use than flag_unsafe_math_optimizations? As Uli mentioned, there's > > That's only relevant for the comparison optimization, of course.

Re: [PATCH] Come up with htab_hash_string_vptr and use string-specific if possible.

Hi, On Fri, 2 Nov 2018, Martin Liška wrote: > V2 of the patch. > > Thoughts? Whereever the new function belongs it certainly isn't system.h. Also the definition in a header seems excessive. Sure, it enables inlining of it, but that seems premature optimization. It contains a loop, and inli

Re: PR83750: CSE erf/erfc pair

Hi, On Mon, 5 Nov 2018, Jeff Law wrote: > >> Don't we have a flag specific to honoring nans? Would that be better > >> to use than flag_unsafe_math_optimizations? As Uli mentioned, > >> there's > > > > That's only relevant for the comparison optimization, of course. > > > > Converting erfc

[PATCH] gcc: xtensa: don't force PIC for uclinux target

xtensa-uclinux uses bFLT executable file format that cannot relocate fields representing offsets from data to code. C++ objects built as PIC use offsets to encode FDE structures. As a result C++ exception handling doesn't work correctly on xtensa-uclinux. Don't use PIC by default on xtensa-uclinux.

[PATCH v2] gcc: xtensa: don't force PIC for uclinux target

xtensa-uclinux uses bFLT executable file format that cannot relocate fields representing offsets from data to code. C++ objects built as PIC use offsets to encode FDE structures. As a result C++ exception handling doesn't work correctly on xtensa-uclinux. Don't use PIC by default on xtensa-uclinux.

Re: PR83750: CSE erf/erfc pair

> On Nov 5, 2018, at 1:48 PM, Michael Matz wrote: > > Hi, > > On Mon, 5 Nov 2018, Jeff Law wrote: > Don't we have a flag specific to honoring nans? Would that be better to use than flag_unsafe_math_optimizations? As Uli mentioned, there's >>> >>> That's only relevant for

Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On 11/1/18 4:07 PM, Peter Bergner wrote: > On 11/1/18 1:50 PM, Renlin Li wrote: >> Is there any update on this issues? >> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while. > > From the analysis I've done, my commit is just exposing latent issues > in LRA. Can you try th

Re: [PATCH libquadmath/PR68686]

On 11/5/18 1:19 PM, Joseph Myers wrote: On Sun, 4 Nov 2018, Ed Smith-Rowland wrote: I looked in glibc.  Unfortunately, I see how they have the same mistake: glibc/math/w_tgammal_compat.c:     long double     __tgammal(long double x)     {         int local_signgam;         long double y =

Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On 11/5/18 1:20 PM, Jeff Law wrote: > On 11/1/18 4:07 PM, Peter Bergner wrote: >> On 11/1/18 1:50 PM, Renlin Li wrote: >>> Is there any update on this issues? >>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while. >> >> From the analysis I've done, my commit is just exposi

Re: [PATCH, testsuite] add "inf" target attribute

> On Nov 4, 2018, at 2:33 PM, Jeff Law wrote: > > On 11/1/18 1:30 PM, Paul Koning wrote: >> A number of test cases fail on pdp11 because they use the "inf" float value >> which does not exist on that target (nor on VAX). Rainer Orth and Joseph >> Myers suggested adding a new effective-targe

[PATCH 0/9]: C++ P0482R5 char8_t implementation

This series of patches provides an implementation of the core language and library changes for C++ proposal P0482R5 [1]. These changes are believed to be complete with the exception of the proposed mbrtoc8() and c8rtomb() functions (the expectation is that the C library will provide mbrtoc8()

[PATCH 1/9]: C++ P0482R5 char8_t: Documentation updates

This patch adds documentation for new -fchar8_t and -fno-char8_t options. gcc/ChangeLog: 2018-11-04 Tom Honermann * doc/invoke.texi (-fchar8_t): Document new option. Tom. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 57491f1033c..cd3a2a715db 100644 --- a/gcc/doc/invoke.te

[PATCH 2/9]: C++ P0482R5 char8_t: Core language support

This patch adds support for the P0482R5 core language changes. This includes: - The -fchar8_t and -fno_char8_t command line options. - char8_t as a keyword. - The char8_t builtin type as a non-aliasing unsigned integral character type of size 1. - Use of char8_t as a simple type specifier. - u

[PATCH 3/9]: C++ P0482R5 char8_t: New core language tests

This patch adds new tests to exercise new behavior for when support for char8_t is enabled as well as protect against unintended behavioral impact when support for char8_t is not enabled. In some cases, existing tests suffice to exercise existing behavior and such tests have been cloned to val

[PATCH 6/9]: C++ P0482R5 char8_t: A small correction to a common testsuite header file

This patch corrects ambiguous partial specializations of typelist::detail::append_. Previously, neither append_, Typelist_Chain> nor append_ was a better match for append_, null_type>. libstdc++-v3/ChangeLog: 2018-11-04 Tom Honermann * include/ext/typelist.h: Constrained a partial s

[PATCH 5/9]: C++ P0482R5 char8_t: Standard library support

This patch adds support to libstdc++ for the P0482R5 standard library changes. This includes: - New char8_t based specializations: - std::numeric_limits - std::char_traits - std::hash - std::hash - std::hash - std::codecvt - std::codecvt - std::codecvt_byname - std::codecvt_byn

[PATCH 4/9]: C++ P0482R5 char8_t: Updates to existing core language tests

This patch updates existing testing gaps related to support for u8 character and string literals. None of these changes exercise new char8_t functionality; they are intended to guard against regressions in behavior of u8 literals when support for char8_t is not enabled. gcc/testsuite/ChangeLo

[PATCH 8/9]: C++ P0482R5 char8_t: Updates to existing standard library tests

This patch augments existing tests to validate behavior for char8_t. In all cases, added test cases are cloned from existing tests for wchar_t or char16_t. A few tests required updates to line numbers for diagnostic messages. libstdc++-v3/ChangeLog: 2018-11-04 Tom Honermann * testsu

[PATCH 7/9]: C++ P0482R5 char8_t: New standard library tests

This patch adds new tests for char8_t standard library features. Most of these tests were cloned from existing tests that exercise char16_t and adapted for char8_t. Only testsuite/experimental/feat-char8_t.cc and testsuite/ext/char8_t/atomic-1.cc are net new tests. libstdc++-v3/ChangeLog: 2

[PATCH 9/9]: C++ P0482R5 char8_t: Updates to gdb pretty printing support

This patch adds recognition of the u8string and u8string_view type aliases to the gdb pretty printer extension. libstdc++-v3/ChangeLog: 2018-11-04 Tom Honermann * python/libstdcxx/v6/printers.py (register_type_printers): Add type printers for u8string and u8string_view. * tes

Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On 11/5/18 12:36 PM, Peter Bergner wrote: > On 11/5/18 1:20 PM, Jeff Law wrote: >> On 11/1/18 4:07 PM, Peter Bergner wrote: >>> On 11/1/18 1:50 PM, Renlin Li wrote: Is there any update on this issues? arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while. >>> >

[PATCH 2/2] C++: improvements to binary operator diagnostics (PR c++/87504)

The C frontend is able (where expression locations are available) to print problems with binary operators in 3-location form, labelling the types of the expressions: arg_0 op arg_1 ~ ^~ ~ || |arg1 type arg0 type The C++ frontend currently just shows the com

[PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486)

The C++ frontend gained various location wrapper nodes in r256448 (GCC 8). That patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html added wrapper nodes around all nodes with !CAN_HAVE_LOCATION_P for: * arguments at callsites, and for * typeid, alignof, sizeof, and offsetof. This is

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On 11/4/18 9:05 AM, Stafford Horne wrote: > I have had some inqueries into helping > bootstrap some linux nommu machines. For nommu, we'd need to implement an FDPIC ABI. Otherwise, code segments cannot be mapped separately from data segments. I believe that the arm (32bit) port has recently adde

  1   2   >