Re: [C++ PATCH] Improve location of CALL_EXPRs (PR c++/60862)

On 09/12/2014 04:52 PM, Marek Polacek wrote: + protected_set_expr_location (postfix_expression, loc); Let's use the location of the (, which should just be token->location at this point. So column 17 instead of 13 in the new test. OK with that change. In some cases postfix_expre

Re: [PATCH] Work around miscompilation with 4.8.1

On Fri, Sep 12, 2014 at 3:27 PM, Andi Kleen wrote: > From: Andi Kleen > > When compiling on opensuse 13.1, with a 4.8.1 based host compiler > and --disable-bootstrap, the generated compiler always ICEs while > compiling __builtin_cpu_supports in the cilk runtime library. > > The problem is fixed

Re: [PATCH] gcc parallel make check

On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote: > curious, when I run atomic.exp=stdatom\*.c: > > gcc.dg/atomic/atomic.exp completed in 30 seconds. > > atomic.exp=c\*.c takes 522 seconds with 3, 2, 5 and 4 being the worst > offenders. That's the @if [ -z "$(filter-out --ta

Re: [PATCH] gcc parallel make check

On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote: > Here is my latest version of the patch. I did a timing test: Before: real0m57.198s user1m24.736s sys 0m19.816s after: real0m28.224s user1m27.823s sys 0m22.374s This is a -j70 run on a 64 core power7 of check-objc, I

[GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions

This patch addresses issues when running gcov-tool after performing COMDAT fixup during dyn-ipa. Functions that were previously all zero counts are marked, and the counts are discarded when being read in by gcov-tool before recalculating module groups and summary info. While here, cleaned up the g

Re: [Ping] Port of VTV for Cygwin and MinGW

First attempt to send this failed. On Fri, Sep 12, 2014 at 3:41 PM, Caroline Tice wrote: > > Hi Patrick, > > Mostly your patch looks OK to me, though there are a couple of serious issues > (mentioned below). Most of my comments are for formatting stuff. Once you > have fixed these issues, le

[PATCH] Work around miscompilation with 4.8.1

From: Andi Kleen When compiling on opensuse 13.1, with a 4.8.1 based host compiler and --disable-bootstrap, the generated compiler always ICEs while compiling __builtin_cpu_supports in the cilk runtime library. The problem is fixed with later 4.8 releases, but at least still happens with the ope

Re: Remove LIBGCC2_HAS_?F_MODE target macros

On Fri, 12 Sep 2014, paul_kon...@dell.com wrote: > > * SFmode would always have been supported in libgcc (the condition was > > BITS_PER_UNIT == 8, true for all current targets), but pdp11 > > defaults to 64-bit float, and in that case SFmode would fail > > scalar_mode_supported_p. I don't kno

Re: [PATCH 2/2] add static typed insn_deleted_p

On 09/11/14 16:49, tsaund...@mozilla.com wrote: From: Trevor Saunders Hi, This changes all callers of INSN_DELETED_P to use one of insn->deleted () insn->set_deleted () or insn->set_undeleted () depending on what they're doing (set_deleted / set_undeleted seem somewhat clearer to me than = 0

Re: [PATCH 1/2] use rtx_insn * more

On 09/11/14 16:48, tsaund...@mozilla.com wrote: From: Trevor Saunders Hi, pretty trivial, but not quiet just changing the types of variables. bootstrapped + regtested on x86_64-unknown-linux-gnu, and run through config-list.mk with a couple other patches. ok? Trev gcc/ChangeLog: 2014-09-11

Re: [PATCH 2/2] add static typed insn_deleted_p

On 09/11/14 19:17, Trevor Saunders wrote: On Thu, Sep 11, 2014 at 08:06:02PM -0400, David Malcolm wrote: On Thu, 2014-09-11 at 18:49 -0400, tsaund...@mozilla.com wrote: From: Trevor Saunders Hi, This changes all callers of INSN_DELETED_P to use one of insn->deleted () insn->set_deleted () o

Re: [PATCH 4/4] Instruction attributes take an rtx_insn *

On 09/12/14 14:38, David Malcolm wrote: This patch strengthens the params of the all of the various generated get_attr_* functions from rtx to rtx_insn *, along with various other functions relating to instruction attributes and scheduling. As well as the changes to genattr.c, genattrtab.c and g

Re: [PATCH 3/4] The various TARGET_ASM_..._MAX_SKIP hooks take an insn

On 09/12/14 14:38, David Malcolm wrote: gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_loop_align_max_skip): Strengthen param "label" from rtx to rtx_insn *. * config/rx/rx.c (rx_max_skip_for_label): Likewise for param "lab" and local "op". * doc/tm.texi (

Re: [PATCH 2/4] The TARGET_CAN_FOLLOW_JUMP hook takes insns

On 09/12/14 14:38, David Malcolm wrote: gcc/ChangeLog: * config/arc/arc.c (arc_can_follow_jump): Strengthen both params from const_rtx to const rtx_insn *. Update union members from rtx to rtx_insn *. * doc/tm.texi (TARGET_CAN_FOLLOW_JUMP): Autogenerated change.

Re: [PATCH 1/4] deps_start_bb takes an insn

On 09/12/14 14:38, David Malcolm wrote: gcc/ChangeLog: * sched-deps.c (deps_start_bb): Strengthen param "head" and local "insn" from rtx to rtx_insn *. * sched-int.h (deps_start_bb): Likewise for 2nd param. OK. jeff

Re: [PATCH] Tiny cleanup for protected_set_expr_location

On 09/12/14 14:52, Marek Polacek wrote: This is rather obvious. CAN_HAVE_LOCATION_P checks that the node is non-null, so no need to check for it in protected_set_expr_location too. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2014-09-12 Marek Polacek * tree.c (protected_se

Re: RFA: Add a destructor to target_ira_int

On 09/12/14 01:25, Richard Sandiford wrote: Jeff Law writes: On 09/08/14 09:26, Richard Sandiford wrote: This patch adds a destructor to target_ira_int, so that the data structures it points to are freed when the parent target_globals is freed. It fixes a memory leak with non-default subtarge

[C++ PATCH] Improve location of CALL_EXPRs (PR c++/60862)

Today I've been playing again with locations in the C++ FE, but of CALL_EXPRs only this time. It seems that it's simplest to just set the location after finish_call_expr does its work rather than to add many new parameters here and there and pass the location all the way down to build_cxx_call. T

[PATCH] Tiny cleanup for protected_set_expr_location

This is rather obvious. CAN_HAVE_LOCATION_P checks that the node is non-null, so no need to check for it in protected_set_expr_location too. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2014-09-12 Marek Polacek * tree.c (protected_set_expr_location): Don't check whether T is

[PATCH 4/4] Instruction attributes take an rtx_insn *

This patch strengthens the params of the all of the various generated get_attr_* functions from rtx to rtx_insn *, along with various other functions relating to instruction attributes and scheduling. As well as the changes to genattr.c, genattrtab.c and genautomata.c, the bulk of the patch makes

[PATCH 2/4] The TARGET_CAN_FOLLOW_JUMP hook takes insns

gcc/ChangeLog: * config/arc/arc.c (arc_can_follow_jump): Strengthen both params from const_rtx to const rtx_insn *. Update union members from rtx to rtx_insn *. * doc/tm.texi (TARGET_CAN_FOLLOW_JUMP): Autogenerated change. * hooks.c (hook_bool_const_rtx_cons

[PATCH 3/4] The various TARGET_ASM_..._MAX_SKIP hooks take an insn

gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_loop_align_max_skip): Strengthen param "label" from rtx to rtx_insn *. * config/rx/rx.c (rx_max_skip_for_label): Likewise for param "lab" and local "op". * doc/tm.texi (TARGET_ASM_JUMP_ALIGN_MAX_SKIP): Autogener

[PATCH 0/4] Use rtx_insn * for instruction attributes

This patch series strengthens more things from rtx to rtx_insn *, eliminating checked casts. Patches 1-3 are fairly trivial, but patch 4 is substantial, strengthening the params of all of the various generated get_attr_* functions from rtx to rtx_insn * (when they're not constant and thus void), a

[PATCH 1/4] deps_start_bb takes an insn

gcc/ChangeLog: * sched-deps.c (deps_start_bb): Strengthen param "head" and local "insn" from rtx to rtx_insn *. * sched-int.h (deps_start_bb): Likewise for 2nd param. --- gcc/sched-deps.c | 4 ++-- gcc/sched-int.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) d

RE: [PATCH] gcc parallel make check

> So, I’d love to see the numbers for 5 and 20 to double check that 10 is the > right number to pick. This sort of refinement is trivial post checkin. So, some timings with the patch, I think this is great. Doing the testing you suggest, changing the variable doesn't influence things much (at

Re: [msp430] fix RLAM opcodes

> This fixes cases where negative indices are used for array offsets. > Committed. > > * config/msp430/msp430.md (extendhipsi2): Use 20-bit form of RLAM/RRAM. > (extend_and_shift1_hipsi2): Likewise. > (extend_and_shift2_hipsi2): Likewise. Committed to 4.9 branch too.

[msp430] fix RLAM opcodes

This fixes cases where negative indices are used for array offsets. Committed. * config/msp430/msp430.md (extendhipsi2): Use 20-bit form of RLAM/RRAM. (extend_and_shift1_hipsi2): Likewise. (extend_and_shift2_hipsi2): Likewise. Index: gcc/config/msp430/msp430.md ==

Re: [debug-early] reuse variable DIEs and fix their context

On 09/12/2014 01:48 PM, Aldy Hernandez wrote: Unless I'm misunderstanding something, validate_phases() verifies that the numbers add up by looking at the actual string name of the phase, irregardless of if you timevar_push/pop'ed it: Yes, but why wouldn't the numbers add up? The comment for t

Re: [RFA 2/2]: --enable-explicit-exception-frame-registration compatibility option

Ping! > From: Hans-Peter Nilsson > Date: Thu, 4 Sep 2014 23:42:28 +0200 > This adds an option to allow programs and libraries built > *without* inhibit_libc to stay compatible with system libraries > (really: libgcc_s.so.1) built *with* i

Ping: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

Ping! > From: Hans-Peter Nilsson > Date: Thu, 4 Sep 2014 23:40:40 +0200 > The directory at $target_header_dir is already inspected in > gcc/configure, for e.g. glibc version and stack protector > support, but not for setting inhibit_libc.

Re: [debug-early] reuse variable DIEs and fix their context

On 09/12/14 10:33, Jason Merrill wrote: On 09/12/2014 01:10 PM, Aldy Hernandez wrote: TV_PHASE_DEFERRED, on the other hand, is a bit problematic because it was originally wrapping the code inside LANG_HOOKS_WRITE_GLOBALS, which will now reside inside the parser (and is thus included in TV_PHASE_

Re: [PATCH] gcc parallel make check

On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote: > Here is my latest version of the patch. > > With this patch I get identical test_summary output on make -k check > (completely serial testing) and make -j48 -k check from toplevel directory. > > Major changes since last version: > 1) I've chang

Re: [debug-early] reuse variable DIEs and fix their context

On 09/12/2014 01:10 PM, Aldy Hernandez wrote: TV_PHASE_DEFERRED, on the other hand, is a bit problematic because it was originally wrapping the code inside LANG_HOOKS_WRITE_GLOBALS, which will now reside inside the parser (and is thus included in TV_PHASE_PARSING now). Originally it was mutually

Re: Remove LIBGCC2_HAS_?F_MODE target macros

On Sep 11, 2014, at 9:22 PM, Joseph S. Myers wrote: > This patch removes the LIBGCC2_HAS_{SF,DF,XF,TF}_MODE target macros, > replacing them by predefines with -fbuilding-libgcc, together with a > target hook that can influence those predefines when needed. > > The new default is that a floating

Re: [debug-early] reuse variable DIEs and fix their context

On 09/12/14 08:15, Jason Merrill wrote: On 09/11/2014 08:51 PM, Aldy Hernandez wrote: - timevar_start (TV_PHASE_DEFERRED); - timevar_stop (TV_PHASE_DEFERRED); - timevar_start (TV_PHASE_OPT_GEN); Why? TV_PHASE_OPT_GEN is now in compile_file(), where we call finalize_compilation_unit di

Re: [PATCH] gcc parallel make check

On Fri, Sep 12, 2014 at 04:36:05PM +, VandeVondele Joost wrote: > > > >> Regtested on x86_64-linux, ok for trunk? > > > >Oh, forgot to say, PR56408 isn't fixed by this patch, but given the > >higher granularity (10 tests instead of 1) we don't happen to trigger it > >right now. > > which me

Re: Stream ODR types

> > For ODR warnings and TBAA I think i want other types, too. But yep, we > > need to handle > > gracefuly component types that does not have names and we could drop names > > of types > > and handle them as component types as it seems fit. > > > > OK, so if you agree, I will go ahead with thi

Re: [PATCH i386 AVX512] [40/n] Extend vcvtps2ph insn patterns.

On Fri, Sep 12, 2014 at 3:57 PM, Kirill Yukhin wrote: > Patch in the bottom extends vcvtps2ph insn > patterns > > Bootstrapped. > AVX-512* tests on top of patch-set all pass > under simulator. > > Is it ok for trunk? > > gcc/ > * config/i386/sse.md > (define_insn "vcvtph2ps"): Add

Re: [PATCH i386 AVX512] [39/n] Extend ashrv insn patterns.

On Fri, Sep 12, 2014 at 3:45 PM, Kirill Yukhin wrote: > Patch in the bottom (derived with git diff -w) > extends ashrv insns patterns. > I choosen to add `_1' to `VI24_AVX512BW_1' mode iterator > because of it is irregular. > > Bootstrapped. > AVX-512* tests on top of patch-set all pass > under s

RE: [PATCH] gcc parallel make check

>> Regtested on x86_64-linux, ok for trunk? > >Oh, forgot to say, PR56408 isn't fixed by this patch, but given the >higher granularity (10 tests instead of 1) we don't happen to trigger it >right now. which means that any commit to that dir could trigger it, right ?

Re: [PATCH] gcc parallel make check

On Fri, Sep 12, 2014 at 06:32:41PM +0200, Jakub Jelinek wrote: > Regtested on x86_64-linux, ok for trunk? Oh, forgot to say, PR56408 isn't fixed by this patch, but given the higher granularity (10 tests instead of 1) we don't happen to trigger it right now. Jakub

Re: [PATCH] gcc parallel make check

On Fri, Sep 12, 2014 at 09:47:00AM +, VandeVondele Joost wrote: > Obviously, if Jakub's patch can be made to work around the testsuite > special cases, I believe it should be superior. If not, the attached > patch is working as far as I can tell, and provides a significant > improvement over

Re: [debug-early] reuse variable DIEs and fix their context

On 09/11/2014 08:51 PM, Aldy Hernandez wrote: - timevar_start (TV_PHASE_DEFERRED); - timevar_stop (TV_PHASE_DEFERRED); - timevar_start (TV_PHASE_OPT_GEN); Why? /* Generate hidden aliases for Java. */ - if (candidates) + if (java_hidden_aliases) { - build_java_method_alia

Re: C++ PATCH for c++/63201 (member variable template specialization)

On 12 September 2014 17:41, Jason Merrill wrote: > On 09/12/2014 02:06 AM, Ville Voutilainen wrote: >> >> I'd expect you want to remove the dg-bogus directives from the test, >> and the "// odd diagnostic" comment too? > They aren't necessary, but they give information about former bugs that the >

Re: C++ PATCH for c++/63201 (member variable template specialization)

On 09/12/2014 02:06 AM, Ville Voutilainen wrote: I'd expect you want to remove the dg-bogus directives from the test, and the "// odd diagnostic" comment too? They aren't necessary, but they give information about former bugs that the test found, so I'm inclined to leave them in. Jason

[PATCH 1/2] Always set DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT correctly

From: Andi Kleen When profiling is disabled force DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT for each function to one. This information is then preserved through LTO. With this patch for LTO builds -pg needs to be set on both the LTO final link and the original source build, to allow -pg (or -pg -fe

[PATCH 2/2] Add some more test cases for fentry and pg

From: Andi Kleen Test fentry and no_instrument_function overriding. No test cases for the LTO test for now, as the LTO harness doesn't seem to support different flags for the final link. gcc/testsuite/: 2014-09-11 Andi Kleen * gcc.dg/pg-override.c: New test. * gcc.dg/pg.c:

[PATCH, committed] params 2 and 3 of reg_set_between_p

The attached patch strengthens the "from_insn" and "to_insn" params of reg_set_between_p from rtx to rtx_insn * (along with some vars at a couple of callsites), and thus falls under the pre-approval granted by Jeff here: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01310.html Bootstrapped on x8

Re: [patch] Make std::deque meet C++11 allocator requirements

This follow-up patch tells the debug mode deque that its std::deque base class is a C++11 allocator aware container. Tested x86_64-linux, committed to trunk. commit 22ed11e31eb61d45f16b93b64b7b46e02e754b79 Author: Jonathan Wakely Date: Fri Sep 12 12:55:46 2014 +0100 * include/debug/deque

[PATCH i386 AVX512] [40/n] Extend vcvtps2ph insn patterns.

Hello, Patch in the bottom extends vcvtps2ph insn patterns Bootstrapped. AVX-512* tests on top of patch-set all pass under simulator. Is it ok for trunk? gcc/ * config/i386/sse.md (define_insn "vcvtph2ps"): Add masking. (define_insn "*vcvtph2ps_load"): Ditto. (def

Re: [PING] [PATCH] longlong.h: Add prototype for udiv_w_sdiv

On Fri, Sep 12, 2014 at 1:29 AM, Stefan Liebler wrote: > > the patch from Andreas Krebbel > (https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00194.html) adds a prototype > for __udiv_w_sdiv to longlong.h if needed. > > This fixes a build failure of glibc on s390 31 bit. > (see "Re: [PATCH] Turn impl

[PATCH i386 AVX512] [39/n] Extend ashrv insn patterns.

Hello, Patch in the bottom (derived with git diff -w) extends ashrv insns patterns. I choosen to add `_1' to `VI24_AVX512BW_1' mode iterator because of it is irregular. Bootstrapped. AVX-512* tests on top of patch-set all pass under simulator. Is it ok for trunk? gcc/ * config/i386/sse.m

[patch] libstdc++/59603 Prevent self-swapping in random_shuffle

Swapping an object with itself is pointless, and asserts in debug mode (but we should probably remove that check from debug mode, since it can happen in reasonable code). Tested x86_64-linux, committed to trunk. I think this makes sense for the branches too, so will backport it soon. commit 0a25

Re: ptx preliminary address space fixes [1/4]

On Fri, Sep 12, 2014 at 1:56 PM, Bernd Schmidt wrote: > On 09/12/2014 01:48 PM, Richard Biener wrote: >>> >>> Still testing whether I actually strictly need it for ARRAY_TYPE nowadays >>> (these patches are really old...). However, the TYPE_FIELDS of a >>> RECORD_TYPE >>> seem to be mostly ignored

[PATCH, PR63229] fix assert in hash_table pch routines

From: tbsaunde Hi, should be obvious changing things within an assert is a bad idea, but somehow I forgot :( tested x86_64-unknown-linux-gnu, and commited as obvious. Trev gcc/ChangeLog: 2014-09-12 Trevor Saunders * hash-table.h (gt_pch_nx): Don't call gt_pch_note_object within

Re: ptx preliminary address space fixes [3/4]

On Fri, Sep 12, 2014 at 2:14 PM, Bernd Schmidt wrote: > On 09/12/2014 01:45 PM, Richard Biener wrote: >> >> Fixing up the vector type in advance is ok with me but I'd like us to >> move away from address-space-on-types. > > > After thinking about it for a while, this idea makes no sense. Address >

Re: ptx preliminary address space fixes [3/4]

On Fri, Sep 12, 2014 at 1:51 PM, Bernd Schmidt wrote: > On 09/12/2014 01:45 PM, Richard Biener wrote: >>> >>> Let me know what you prefer. >> >> >> Hmm, neither I suppose. COMPLEX_TYPEs are also built >> with main-variant component type and I suspect the same for >> ARRAY_TYPEs. I see the addres

Re: ptx preliminary address space fixes [3/4]

On 09/12/2014 01:45 PM, Richard Biener wrote: Fixing up the vector type in advance is ok with me but I'd like us to move away from address-space-on-types. After thinking about it for a while, this idea makes no sense. Address spaces must be represented in the type system somehow - consider a

Re: ptx preliminary address space fixes [1/4]

On 09/12/2014 01:48 PM, Richard Biener wrote: Still testing whether I actually strictly need it for ARRAY_TYPE nowadays (these patches are really old...). However, the TYPE_FIELDS of a RECORD_TYPE seem to be mostly ignored once the frontends are done, but it's very easy for other parts of the com

Re: ptx preliminary address space fixes [3/4]

On 09/12/2014 01:45 PM, Richard Biener wrote: Let me know what you prefer. Hmm, neither I suppose. COMPLEX_TYPEs are also built with main-variant component type and I suspect the same for ARRAY_TYPEs. I see the address-space on types as artifact that comes from Frontend support (aka parsing).

Re: ptx preliminary address space fixes [2/4]

On Fri, Sep 12, 2014 at 1:17 PM, Bernd Schmidt wrote: > On 09/11/2014 01:30 PM, Richard Biener wrote: >> >> On Thu, Sep 11, 2014 at 12:12 PM, Bernd Schmidt >> wrote: >>> >>> This is a bug in SRA which replaces a memory reference without taking >>> care >>> to use the correct address space. >>> >>

Re: ptx preliminary address space fixes [1/4]

On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt wrote: > On 09/11/2014 01:29 PM, Richard Biener wrote: >> >> + if (TREE_CODE (type) == ARRAY_TYPE) >> +TREE_TYPE (type) = apply_as_to_type (TREE_TYPE (type), as); >> >> why is this necessary for ARRAY_TYPE but not for sth like >> a RECORD_TYPE or

Re: ptx preliminary address space fixes [3/4]

On Fri, Sep 12, 2014 at 1:09 PM, Bernd Schmidt wrote: > On 09/11/2014 01:39 PM, Richard Biener wrote: > >> Seeing this it would be nice to abstract away the exact place we store >> the address-space in a memory reference. So - can you add a helper >> reference_addr_space () please? Thus do >> >>

Re: [PATCH][match-and-simplify] Finish simplify_bitwise_binary patterns

On Fri, 12 Sep 2014, Marc Glisse wrote: > On Fri, 12 Sep 2014, Richard Biener wrote: > > > +/* x ^ ~0 -> ~x */ > > (simplify > > (bit_and @0 integer_all_onesp) > > @0) > > The comment doesn't seem to match. Thanks - fixed below which also implements simplify_mult and simplify_not_neg_expr.

Re: ptx preliminary address space fixes [2/4]

On 09/11/2014 01:30 PM, Richard Biener wrote: On Thu, Sep 11, 2014 at 12:12 PM, Bernd Schmidt wrote: This is a bug in SRA which replaces a memory reference without taking care to use the correct address space. Bootstrapped and tested together with the other patches on x86_64-linux. Ok? Ok (w

Re: ptx preliminary address space fixes [1/4]

On 09/11/2014 01:29 PM, Richard Biener wrote: + if (TREE_CODE (type) == ARRAY_TYPE) +TREE_TYPE (type) = apply_as_to_type (TREE_TYPE (type), as); why is this necessary for ARRAY_TYPE but not for sth like a RECORD_TYPE or a POINTER_TYPE? Still testing whether I actually strictly need it for

Re: ptx preliminary address space fixes [3/4]

On 09/11/2014 01:39 PM, Richard Biener wrote: Seeing this it would be nice to abstract away the exact place we store the address-space in a memory reference. So - can you add a helper reference_addr_space () please? Thus do addr_space_t as = reference_addr_space (scalar_dest); Ok, no pro

Re: [PATCH][match-and-simplify] Finish simplify_bitwise_binary patterns

On Fri, 12 Sep 2014, Richard Biener wrote: +/* x ^ ~0 -> ~x */ (simplify (bit_and @0 integer_all_onesp) @0) The comment doesn't seem to match. -- Marc Glisse

[PATCH][match-and-simplify] Fix lto.exp=20110201-1_0.c ICE

Committed. Richard. 2014-09-12 Richard Biener * genmatch.c (expr::gen_transform): Properly autocompute type of REALPART_EXPR and IMAGPART_EXPR. Index: gcc/genmatch.c === --- gcc/genmatch.c (revision 215210)

[PATCH][match-and-simplify] Finish simplify_bitwise_binary patterns

And some more. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2014-09-12 Richard Biener * match-bitwise.pd: Complete tree-ssa-forwprop.c patterns from simplify_bitwise_binary. Implement some from fold_binary. * match-constant-folding.pd: Add

Re: integer_each_onep + vector bug

On Fri, Sep 12, 2014 at 12:04 PM, Marc Glisse wrote: > Hello, > > here is a new predicate which tests if a number is 1, or (for vector and > complex) a collection of 1. The only difference with integer_onep should be > for complex where it wants 1+i and not 1. The main use would be in the match >

Re: [ARM][tests] Make input and output arrays 128-bit aligned in vectorisation tests

On 12/09/14 11:13, Richard Earnshaw wrote: On 09/09/14 16:14, Kyrill Tkachov wrote: Hi all, As Christophe mentioned at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00202.html These tests fail on big-endian. The reason is that the input is not aligned to 128 bit forcing the use of a movmisali

Re: [PATCH] gcc parallel make check

On 12/09/14 09:47 +, VandeVondele Joost wrote: a newer patch (v8) I'll send soon attached with updated changelog. Compared to the previously posted v6, only the libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the e*/* pattern, and two quickly running goal have

Re: [ARM][tests] Make input and output arrays 128-bit aligned in vectorisation tests

On 09/09/14 16:14, Kyrill Tkachov wrote: > Hi all, > > As Christophe mentioned at > https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00202.html > These tests fail on big-endian. The reason is that the input is not > aligned to 128 bit forcing the use of a movmisalign which we don't > support on bi

integer_each_onep + vector bug

Hello, here is a new predicate which tests if a number is 1, or (for vector and complex) a collection of 1. The only difference with integer_onep should be for complex where it wants 1+i and not 1. The main use would be in the match branch, so I didn't waste too much time adding many uses, I j

Re: [wwwdocs] Buildstat update for 4.8

On Fri, 5 Sep 2014, Tom G. Christensen wrote: > No new testresults just a small fixup for the update from Raghunath > Lolur. > His aarch64 build was cross built though the testsuite seems to have > been run using qemu (host=target). > I'm uncertain if this qualifies for mentioning the build host in

RE: [PATCH] gcc parallel make check

> a newer patch (v8) I'll send soon attached with updated changelog. Compared to the previously posted v6, only the libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the e*/* pattern, and two quickly running goal have been merged, in addition to fixing the pre-exisiting

[COMMITTED][PATCH] Fix register corruption bug in ree

On 11/09/14 21:10, Jeff Law wrote: On 09/08/14 11:21, Wilco Dijkstra wrote: Anyway here is the modified check: Thanks. Just needs an updated ChangeLog and it's good for the trunk. committed to trunk on behalf of Wilco as r215205 after pass bootstrapping. 2014-09-12 Wilco Dijkstra

[PATCH] Fix PR63237

The following fixes a missed gimplification of strlen in the GIMPLE strlen folding variant. Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2014-09-12 Richard Biener PR middle-end/63237 * gimple-fold.c (get_maxval_strlen): Gimplify string length.

Re: [PATCH] S/390: PR62662 Fix r14 restore optimization

On Wed, Sep 10, 2014 at 10:44:39AM +0200, Andreas Krebbel wrote: > this fixes a problem with the prologue optimization in machine > dependent reorg. For more details please see PR62662. > > No regressions on s390 and s390x. Are you going to commit these two patches? Jakub

RE: [wwwdocs] Mention Cilk Plus support

> > On Wed, 10 Sep 2014, Zamyatin, Igor wrote: > >> + Complete support for http://cilk.org";>Cilk > >> +Plus features was added to GCC > >> + [2014-09-02] > > features *were* added, plural. It's "support for features" thus singular :) > > >> + Contributed by Jakub Jelinek, Iyer Balaji a

Re: [wwwdocs] Buildstat update for 4.9

On Thu, 4 Sep 2014, Raghunath Lolur wrote: > Please find an update of test results for 4.9 as below: Thank you, added. Gerald

[PING] [PATCH] longlong.h: Add prototype for udiv_w_sdiv

Hi, the patch from Andreas Krebbel (https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00194.html) adds a prototype for __udiv_w_sdiv to longlong.h if needed. This fixes a build failure of glibc on s390 31 bit. (see "Re: [PATCH] Turn implict-function-declaration warnings into errors", https://www

Re: Remove LIBGCC2_HAS_?F_MODE target macros

On Fri, Sep 12, 2014 at 3:22 AM, Joseph S. Myers wrote: > This patch removes the LIBGCC2_HAS_{SF,DF,XF,TF}_MODE target macros, > replacing them by predefines with -fbuilding-libgcc, together with a > target hook that can influence those predefines when needed. > > The new default is that a floatin

Re: [debug-early] reuse variable DIEs and fix their context

On Fri, Sep 12, 2014 at 2:51 AM, Aldy Hernandez wrote: > On 09/09/14 02:16, Richard Biener wrote: >> >> On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez wrote: >>> >>> On 09/05/14 02:00, Richard Biener wrote: > > >>> What I have in mind is: >>> >>> 1. Move the FE specific things that come before th

Re: ptx preliminary rtl patches [3/4]

On Thu, Sep 11, 2014 at 6:36 PM, Bernd Schmidt wrote: > On 09/11/2014 06:34 PM, Steven Bosscher wrote: >> >> On Thu, Sep 11, 2014 at 6:19 PM, Bernd Schmidt wrote: > > What do you expect that function to do different? It returns the > correct > value. > No different. J

Re: Stream ODR types

On Thu, 11 Sep 2014, Jan Hubicka wrote: > > On Thu, 11 Sep 2014, Jan Hubicka wrote: > > > > > Hi, > > > this patch adds computation and streaming of mangled type names. As > > > suggested by Jason, > > > it simple calls DECL_ASSEMBLER_NAME on all names types and lets C++ > > > supply them. > >

Re: Stream ODR types

On Thu, 11 Sep 2014, Jason Merrill wrote: > On 09/11/2014 03:06 AM, Jan Hubicka wrote: > > http://kam.mff.cuni.cz/~hubicka/odr-warnings-firefox.txt > > > /aux/hubicka/firefox4/content/media/fmp4/ffmpeg/libav53/include/libavcodec/avcodec.h:997:0: > > note: the first difference of corresponding def

Re: RFA: Add a destructor to target_ira_int

Jeff Law writes: > On 09/08/14 09:26, Richard Sandiford wrote: >> This patch adds a destructor to target_ira_int, so that the data structures >> it points to are freed when the parent target_globals is freed. It fixes >> a memory leak with non-default subtargets. >> >> Tested on x86_64-linux-gnu.