Re: [PATCH][i386,AVX] Enable VNNI support [1/5]

Hello Julia, On 24 Oct 10:37, Koval, Julia wrote: > Hi, > This patch enables VNNI isaset option. The doc for isaset and instruction: > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf > > Ok for trunk? Your patch is OK

Re: [PATCH] Don't add __builtin_unreachable for -Wreturn-type places at -O0

On December 5, 2017 12:48:02 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >When debugging what turned out to be just a -Wreturn-type reported >failure now being a fatal problem even at -O0, it occurs to me that >because we are not optimizing at -O0, adding the

Re: [PATCH] gcc: xtensa: enable address sanitizer

On Mon, Dec 4, 2017 at 1:28 PM, Max Filippov wrote: > gcc/ > 2017-12-04 Max Filippov > > * config/xtensa/xtensa.c (xtensa_asan_shadow_offset): New > function. > (TARGET_ASAN_SHADOW_OFFSET): New macro definition. > *

Re: [PATCH 5/3] C++ bits to improve detection of attribute conflicts (PR 81544)

OK. On Sun, Dec 3, 2017 at 9:59 AM, Martin Sebor wrote: > Ping: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01034.html > > The attached C++ only patch is rebased on the top of trunk. > > The remaining patches in the series (C FE and the back ends) > have been approved. > >

Go patch committed: Omit nil check when dereferencing closure variable

This patch to the Go frontend by Than McIntosh adds the "no nil check needed" annotation to the dereference operations created in Parse::enclosing_var_reference (this is safe since the closure object is under control of the compiler, and pointer fields in it will always be non-nil). Bootstrapped

Re: Avoid -Werror=format-overflow error in dbxout.c (dbxout_block) on Solaris/SPARC

On 12/04/2017 01:58 PM, David Malcolm wrote: On Mon, 2017-12-04 at 12:18 -0700, Martin Sebor wrote: On 12/04/2017 05:41 AM, Rainer Orth wrote: Within test last week, 64-bit Solaris/SPARC bootstrap began to fail: /vol/gcc/src/hg/trunk/local/gcc/dbxout.c: In function 'bool dbxout_block(tree,

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

FYI: Since James approved the Aarch64 part and since I think the generic part can be considered trivial, I have gone ahead and checked this patch in. Steve Ellcey sell...@cavium.com On Tue, 2017-11-28 at 16:12 -0800, Steve Ellcey wrote: > On Tue, 2017-11-21 at 17:35 +, James Greenhalgh

Re: [PR 83141] Prevent SRA from removing type changing assignment

On Tue, Dec 05 2017, Martin Jambor wrote: Hi, > Hi, > > this is a followup to Richi's > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02396.html to fix PR > 83141. The basic idea is simple, be just as conservative about type > changing MEM_REFs as we are about actual VCEs. > > I have checked how

Update scheduling for generic tuning

Hi, currently generic is still scheduling for K8. I have run several combinations on Zen and Haswell and it seems that core is more sensitive to scheduling for its microarchitecture than Zen (or that Zen's scheduler model is less tuned). At the moment for SPECfp2006 there is only one benchmark

[PATCH] Fix ICE with extend_ref_init_temps of structured binding (PR c++/81197)

Hi! We were calling cp_finish_decl before cp_finish_decomp, so that the latter has the initializer finalized and can decompose it, and cp_finish_decomp was mangling the decl if needed. Unfortunately, as the following testcase shows, sometimes we need it mangled already earlier, during that

Re: [PATCH] emit a trap for buffer overflow in placement new

On 12/04/2017 03:44 PM, Marc Glisse wrote: On Mon, 4 Dec 2017, Martin Sebor wrote: The -Wplacement-new option warns for buffer overflow in placement new expressions with objects of constant sizes, but because it's implemented completely in the C++ front end it misses the more interesting

[PATCH] Don't add __builtin_unreachable for -Wreturn-type places at -O0

Hi! When debugging what turned out to be just a -Wreturn-type reported failure now being a fatal problem even at -O0, it occurs to me that because we are not optimizing at -O0, adding the __builtin_unreachable doesn't bring many optimization advantages (practically just optimize away epilogue)

Re: [RFA][PATCH][tree-optimization/78496] 03/03 Embed and exploit EVRP analysis within DOM

On 12/04/2017 03:42 AM, Richard Biener wrote: > On Mon, Dec 4, 2017 at 6:59 AM, Jeff Law wrote: >> And finally, the meat of the fix for pr78496. This is largely the patch >> that was posed right when stage1 closed with just minor updates. >> >> This patch embeds evrp analysis

Re: [PATCH] Fix -Wsystem-header warnings in libstdc++

On 04/12/17 23:07 +, Jonathan Wakely wrote: On 01/12/17 16:10 +, Jonathan Wakely wrote: On 01/12/17 15:11 +, Jonathan Wakely wrote: This fixes a number of warnings that show up with -Wsystem-headers This fixes some more. And some more, this time for -Wunused, -Wcomment, and

Re: [PATCH v2 3/4] [SPARC] Errata workaround for GRLIB-TN-0010

> No, there was no particular reason. mem_ref seems like a better choice > if it detects more types of loads. Right, it's supposed to detect all types of loads. Here's what I have installed on the mainline and 7 branch. 2017-12-04 Eric Botcazou *

[PR 83141] Prevent SRA from removing type changing assignment

Hi, this is a followup to Richi's https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02396.html to fix PR 83141. The basic idea is simple, be just as conservative about type changing MEM_REFs as we are about actual VCEs. I have checked how that would affect compilation of SPEC 2006 and (non LTO)

Re: [PATCH] Fix -Wsystem-header warnings in libstdc++

On 01/12/17 16:10 +, Jonathan Wakely wrote: On 01/12/17 15:11 +, Jonathan Wakely wrote: This fixes a number of warnings that show up with -Wsystem-headers This fixes some more. And some more, this time for -Wunused, -Wcomment, and -Wvariadic-macros. Tested powerpc64le-linux,

Re: [v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr

On 03/12/17 23:08 +0200, Ville Voutilainen wrote: Tested on Linux-x64. 2017-11-14 Ville Voutilainen Implement LWG 2221 * include/std/ostream (operator<<(nullptr_t)): New. * testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc: New. diff

C++ PATCH for c++/82373, constexpr if and non-constant condition

We need to require a constant-expression here, not just check for it. The constexpr.c change was necessary to fix constexpr-lambda17.C. Tested x86_64-pc-linux-gnu, applying to trunk. commit 6ba5b86d80f9aea859b7d2b9bf7c517dadf3a701 Author: Jason Merrill Date: Mon Dec 4

Re: [PATCH] emit a trap for buffer overflow in placement new

On Mon, 4 Dec 2017, Martin Sebor wrote: The -Wplacement-new option warns for buffer overflow in placement new expressions with objects of constant sizes, but because it's implemented completely in the C++ front end it misses the more interesting non-constant sizes. The attached patch

[PATCH] emit a trap for buffer overflow in placement new

The -Wplacement-new option warns for buffer overflow in placement new expressions with objects of constant sizes, but because it's implemented completely in the C++ front end it misses the more interesting non-constant sizes. The attached patch instruments both forms of operator placement new to

[PATCH] Fix typos in riscv register save/restore.

This patch fixes a few typos with computing registers to save/restore in prologue/epilogue. This fixes the github riscv/riscv-gcc issue #111. The typos are harmless, as these registers are call clobbered, but this was a problem for one person modifying gcc for academic reasons, and hence the

Re: [PATCH] gcc: xtensa: enable address sanitizer

On Mon, Dec 4, 2017 at 1:31 PM, Jakub Jelinek wrote: > On Mon, Dec 04, 2017 at 01:28:53PM -0800, Max Filippov wrote: >> gcc/ >> 2017-12-04 Max Filippov >> >> * config/xtensa/xtensa.c (xtensa_asan_shadow_offset): New >> function. >>

Re: [PATCH #2], PR target/81959, Fix ++int to _Float128 conversion on power9

On Fri, Dec 01, 2017 at 05:33:39PM -0600, Segher Boessenkool wrote: > Okay for trunk. Further improvements welcome ;-) Thanks! Here is the patch for GCC 7 (the bug shows up in GCC 7). It is slightly different due to the surrounding lines in rs6000.c being different. Is it ok to apply? There

Re: [PATCH] gcc: xtensa: enable address sanitizer

On Mon, Dec 04, 2017 at 01:28:53PM -0800, Max Filippov wrote: > gcc/ > 2017-12-04 Max Filippov > > * config/xtensa/xtensa.c (xtensa_asan_shadow_offset): New > function. > (TARGET_ASAN_SHADOW_OFFSET): New macro definition. > * config/xtensa/xtensa.h

[PATCH] gcc: xtensa: enable address sanitizer

gcc/ 2017-12-04 Max Filippov * config/xtensa/xtensa.c (xtensa_asan_shadow_offset): New function. (TARGET_ASAN_SHADOW_OFFSET): New macro definition. * config/xtensa/xtensa.h (FRAME_GROWS_DOWNWARD): Set to 1 if ASAN is enabled. ---

Re: [GCC 9][RFC][PATCH] Optimize PHIs with constant arguments better

Hi, On Thu, 30 Nov 2017, Jeff Law wrote: > And after PHI propagation we have: > # m_5 = PHI <10(5), 12(6), 14(7)> > # _2 = PHI <10(5), 12(6), 14(7)> > # _3 = PHI <320(5), 384(6), 448(7)> > : > goto ; [100.00%] > > DCE will come along and wipe out m_5 and _2 if they are unused. When I

Re: Avoid -Werror=format-overflow error in dbxout.c (dbxout_block) on Solaris/SPARC

On Mon, 2017-12-04 at 12:18 -0700, Martin Sebor wrote: > On 12/04/2017 05:41 AM, Rainer Orth wrote: > > Within test last week, 64-bit Solaris/SPARC bootstrap began to > > fail: > > > > /vol/gcc/src/hg/trunk/local/gcc/dbxout.c: In function 'bool > > dbxout_block(tree, int, tree, int)': > >

Re: [PATCH 2/2] v3: C/C++: don't suggest implementation names as spelling fixes (PR c/83236)

On Mon, Dec 4, 2017 at 12:00 PM, David Malcolm wrote: > * don't filter suggestions if the name name being looked up > is itself reserved for implementation I wonder if we want to avoid filtering if the name being looked up starts with a single _, on the theory that the user

Re: Avoid -Werror=format-overflow error in dbxout.c (dbxout_block) on Solaris/SPARC

On 12/04/2017 05:41 AM, Rainer Orth wrote: > Within test last week, 64-bit Solaris/SPARC bootstrap began to fail: > > /vol/gcc/src/hg/trunk/local/gcc/dbxout.c: In function 'bool > dbxout_block(tree, int, tree, int)': > /vol/gcc/src/hg/trunk/local/gcc/dbxout.c:3767:1: error: '%lu' directive >

Re: Avoid -Werror=format-overflow error in dbxout.c (dbxout_block) on Solaris/SPARC

On 12/04/2017 05:41 AM, Rainer Orth wrote: Within test last week, 64-bit Solaris/SPARC bootstrap began to fail: /vol/gcc/src/hg/trunk/local/gcc/dbxout.c: In function 'bool dbxout_block(tree, int, tree, int)': /vol/gcc/src/hg/trunk/local/gcc/dbxout.c:3767:1: error: '%lu' directive writing

Re: [PATCH][gimple-interchange] Random cleanups

On Mon, Dec 4, 2017 at 5:39 PM, Richard Biener wrote: > On December 4, 2017 5:01:45 PM GMT+01:00, "Bin.Cheng" > wrote: >>On Mon, Dec 4, 2017 at 3:43 PM, Richard Biener >>wrote: >>> >>> When skimming through the code I noticed the

Re: [PATCH][gimple-interchange] Random cleanups

On December 4, 2017 5:01:45 PM GMT+01:00, "Bin.Cheng" wrote: >On Mon, Dec 4, 2017 at 3:43 PM, Richard Biener >wrote: >> >> When skimming through the code I noticed the following (chatted on >IRC >> about parts of the changes). >> >> Bootstrap / regtest

Re: [Patch][aarch64] Add missing thunderx2-t99 instruction scheduling pipeline descriptions.

On Mon, 2017-12-04 at 17:18 +, Kyrill Tkachov wrote: > > +(define_insn_reservation "thunderx2t99_multiple" 1 > > +  (and (eq_attr "tune" "thunderx2t99") > > +   (eq_attr "type" "multiple")) > > +  "thunderx2t99_i0+thunderx2t99_i1+thunderx2t99_i2+thunderx2t99_ls > >

Re: [Patch][aarch64] Add missing thunderx2-t99 instruction scheduling pipeline descriptions.

Hi Steve, On 01/12/17 18:42, Steve Ellcey wrote: There are a number of instruction types defined in aarch64.md which do not have pipeline/scheduling information in thunderx2-t99.md. This patch adds some of them. This patch includes all the missing types except the neon ones that I hope to

Re: [PATCH,RFC] combine: Remove use_crosses_set_p

> Since there are no comments, I'll commit it now. The idea looks interesting but the timing is a bit more questionable. -- Eric Botcazou

Re: [PATCH, obv?] Fix missing newlines from local-pure-const pass dump

On 12/04/2017 02:01 PM, Jeff Law wrote: On 12/01/2017 11:42 AM, Luis Machado wrote: I noticed the debugging output from local-pure-const pass is missing a newline in a couple places, leading to this: local analysis of main scanning: i ={v} 0; Volatile stmt is not const/pure

[PATCH 2/2] v3: C/C++: don't suggest implementation names as spelling fixes (PR c/83236)

Changed in v3: * updated for move to c-family/c-spellcheck.cc/h Changed in v2: * don't filter suggestions if the name name being looked up is itself reserved for implementation * fix wrapping in c-decl.c's lookup_name_fuzzy * name-lookup.c (consider_binding_level): rename new variable from "name"

[PATCH 1/2] Move macro-spellchecking code from "gcc" to new files in c-family

The code for spellchecking macros really belongs in c-family, rather than in gcc/spellcheck-tree.c, so this patch moves it there. gcc/ChangeLog: * Makefile.in (C_COMMON_OBJS): Add c-family/c-spellcheck.o. gcc/c-family/ChangeLog: * c-spellcheck.cc: New file, taken from

[PATCH 0/2] v3: C/C++: don't suggest implementation names as spelling fixes (PR c/83236)

On Fri, 2017-12-01 at 19:09 -0500, David Malcolm wrote: > On Fri, 2017-12-01 at 22:56 +0100, Jakub Jelinek wrote: > > On Fri, Dec 01, 2017 at 04:48:20PM -0500, David Malcolm wrote: > > > PR c/83236 reports an issue where the C FE unhelpfully suggests > > > the > > > use > > > of glibc's private

Re: [RFA, PATCH] Deprecate stabs if dwarf2 support available.

On Mon, Dec 4, 2017 at 2:38 AM, Richard Biener wrote: > Note that "deprecation" doesn't match up with giving an error when using. > We should warn (or maybe just document deprecation) instead. OK. I can warn instead. That makes a lot of things simpler for gcc-8.

Re: [PATCH, obv?] Fix missing newlines from local-pure-const pass dump

On 12/01/2017 11:42 AM, Luis Machado wrote: > I noticed the debugging output from local-pure-const pass is missing a > newline in a couple places, leading to this: > > local analysis of main >scanning: i ={v} 0; > Volatile stmt is not const/pure > Volatile operand is not const/pure

Re: [PATCH][gimple-interchange] Random cleanups

On Mon, Dec 4, 2017 at 3:43 PM, Richard Biener wrote: > > When skimming through the code I noticed the following (chatted on IRC > about parts of the changes). > > Bootstrap / regtest running on x86_64-unknown-linux-gnu. > > Will commit tomorrow unless you beat me to that. > >

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, David Malcolm wrote: > -fverbose-asm is on the border of compiler-debugging vs end-user usage. I have yet to see a relevant percentage of end-users who even know what assembler is. On the gcc.*@ and kernel.* mailing lists, sure. But Joe Randomapp? > FWIW an

[PATCH][gimple-interchange] Random cleanups

When skimming through the code I noticed the following (chatted on IRC about parts of the changes). Bootstrap / regtest running on x86_64-unknown-linux-gnu. Will commit tomorrow unless you beat me to that. Richard. 2017-12-04 Richard Biener *

Re: [PATCH,RFC] combine: Remove use_crosses_set_p

On Thu, Nov 30, 2017 at 09:26:37AM +, Segher Boessenkool wrote: > This removes use_crosses_set_p, and uses modified_between_p instead > everywhere it was used. This improves optimisation. I'm a little bit > worried it might increase compile time; so far I haven't seen it do > that though. >

[PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

Hi, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79538 missing -Wformat-overflow with %s and non-member array arguments -Wformat-overflow uses the routine "get_range_strlen" to decide the maximum string length, however, currently

Re: [RFA][PATCH][tree-optimization/78496] 02/03 Do not exploit __builtin_unreachable if -fsanitize=unreachable

On 12/04/2017 03:40 AM, Richard Biener wrote: > On Mon, Dec 4, 2017 at 6:55 AM, Jeff Law wrote: >> >> As I brought my patches for pr78496 up to the tip of the trunk I noticed >> a couple testsuite regressions with -fsanitize=unreachable tests. >> >> The problem is VRP and EVRP

Re: [RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes

On 12/04/2017 01:11 AM, Jakub Jelinek wrote: > On Sun, Dec 03, 2017 at 10:55:27PM -0700, Jeff Law wrote: >> As we touched on in IRC, the EVRP analyzer was doing something stupid >> which caused it to not merge in existing range information under certain >> circumstances. >> >> Consider this

Re: [PATCH][gimple-interchange] Add reduction validity check

On Mon, Dec 4, 2017 at 1:11 PM, Richard Biener wrote: > > I've noticed we perform FP reduction association without the required > checks for associative math. I've added > gcc.dg/tree-ssa/loop-interchange-1b.c to cover this. > > I also noticed we happily interchange a loop

Re: [PATCH][gimple-interchange] Add reduction validity check

On Mon, 4 Dec 2017, Bin.Cheng wrote: > On Mon, Dec 4, 2017 at 1:11 PM, Richard Biener wrote: > > > > I've noticed we perform FP reduction association without the required > > checks for associative math. I've added > > gcc.dg/tree-ssa/loop-interchange-1b.c to cover this. > >

Re: [PATCH][gimple-interchange] Add reduction validity check

On Mon, Dec 4, 2017 at 1:11 PM, Richard Biener wrote: > > I've noticed we perform FP reduction association without the required > checks for associative math. I've added > gcc.dg/tree-ssa/loop-interchange-1b.c to cover this. > > I also noticed we happily interchange a loop

[PATCH] Fix PR83255

Been sitting in my tree (fixes SPEC 2k6 miscompares). Bootstrapped and tested on x86-64-unknown-linux-gnu, applied. Richard. 2017-12-04 Richard Biener PR tree-optimization/83255 * graphite-isl-ast-to-gimple.c (translate_isl_ast_node_for): Re-add

[PATCH][gimple-interchange] Add reduction validity check

I've noticed we perform FP reduction association without the required checks for associative math. I've added gcc.dg/tree-ssa/loop-interchange-1b.c to cover this. I also noticed we happily interchange a loop with a reduction like sum = a[i] - sum; where a change in order of elements isn't

Avoid -Werror=format-overflow error in dbxout.c (dbxout_block) on Solaris/SPARC

Within test last week, 64-bit Solaris/SPARC bootstrap began to fail: /vol/gcc/src/hg/trunk/local/gcc/dbxout.c: In function 'bool dbxout_block(tree, int, tree, int)': /vol/gcc/src/hg/trunk/local/gcc/dbxout.c:3767:1: error: '%lu' directive writing between 1 and 20 bytes into a region of size 14

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, Martin Sebor wrote: > adddi3_imm_carry_m1 seems (mostly) self-explanatory since it's built up > of common assembly mnemonics. I confess I don't know what the number > after # means, either on powerpc64 or on any other target. insn uid. > > Or, for that matter, what

Re: [PATCH v2 3/4] [SPARC] Errata workaround for GRLIB-TN-0010

Any particular reason to use MEM_P instead of mem_ref here? It looks like there is also a case for the b2bst workaround (only loads are concerned). No, there was no particular reason. mem_ref seems like a better choice if it detects more types of loads. /Daniel C

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

On Wed, Nov 29, 2017 at 08:56:44AM -0700, Martin Sebor wrote: > On 11/29/2017 01:30 AM, Jakub Jelinek wrote: > > On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote: > > > On 11/27/2017 02:22 AM, Dominik Inführ wrote: > > > > Thanks for all the reviews! I’ve revised the patch, the > > >

Re: [PATCH v2 3/4] [SPARC] Errata workaround for GRLIB-TN-0010

> @@ -1024,6 +1040,31 @@ sparc_do_work_around_errata (void) > emit_insn_before (gen_nop (), target); > } > > + /* Insert a NOP between load instruction and atomic > + instruction. Insert a NOP at branch target if load > + in delay slot and atomic instruction at

Re: [RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes

On Mon, Dec 4, 2017 at 6:55 AM, Jeff Law wrote: > As we touched on in IRC, the EVRP analyzer was doing something stupid > which caused it to not merge in existing range information under certain > circumstances. > > Consider this fragment: > > x_1 = foo () > if (x_1 > 2) >

[PATCH] Add testcase for PR83252 (was Re: patch to fix PR80818)

On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote: > The following patch fixes > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818 > > The patch was successfully tested and bootstrapped on x86_64. The patch > has no test because it is hard to check the problem. I checked

Re: [RFA][PATCH][tree-optimization/78496] 03/03 Embed and exploit EVRP analysis within DOM

On Mon, Dec 4, 2017 at 6:59 AM, Jeff Law wrote: > And finally, the meat of the fix for pr78496. This is largely the patch > that was posed right when stage1 closed with just minor updates. > > This patch embeds evrp analysis into DOM and exploits it in the minimal > way

Re: [RFA][PATCH][tree-optimization/78496] 02/03 Do not exploit __builtin_unreachable if -fsanitize=unreachable

On Mon, Dec 4, 2017 at 6:55 AM, Jeff Law wrote: > > As I brought my patches for pr78496 up to the tip of the trunk I noticed > a couple testsuite regressions with -fsanitize=unreachable tests. > > The problem is VRP and EVRP analysis/optimization could exploit >

Re: [RFA, PATCH] Deprecate stabs if dwarf2 support available.

On Sun, Dec 3, 2017 at 5:17 AM, Jim Wilson wrote: > This is based on an idea from Richard Biener that was mentioned here > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02376.html > > If we are interested in doing this, it would be accompanied by documentation > changes to

Re: [PATCH, rs6000] gimple folding of vec_msum()

On Sat, Dec 2, 2017 at 12:08 AM, Bill Schmidt wrote: > Hi Will, > >> On Dec 1, 2017, at 3:43 PM, Will Schmidt wrote: >> >> On Fri, 2017-12-01 at 18:46 +0100, Richard Biener wrote: >>> On December 1, 2017 6:22:21 PM GMT+01:00, Will Schmidt

[patch][i386, AVX] Adding missing mask[z]_range[_round]_s[d,s] intrinsics

Hi, This patch adds missing intrinsics for _mm_mask[z]_range[_round]_[sd,ss]. 04.12.2017 Olga Makhotina  gcc/ * config/i386/avx512dqintrin.h (_mm_mask_range_sd, _mm_maskz_range_sd, _mm_mask_range_round_sd, _mm_maskz_range_round_sd, _mm_mask_range_ss,

Re: [PATCH] lra: Clobbers in a parallel are earlyclobbers (PR83245)

On 12/04/2017 01:13 AM, Vladimir Makarov wrote: > > > On 12/02/2017 01:59 PM, Segher Boessenkool wrote: >> The documentation (rtl.texi) says: >> >>When a @code{clobber} expression for a register appears inside a >>@code{parallel} with other side effects, the register allocator >>

[PATCH] Fix PR83238

This fixes PR83238, biitstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-12-04 Richard Biener PR tree-optimization/83238 * graphite-scop-detection.c (scop_detection::merge_sese): Make code match comment, rejecting invalid

Re: [PATCH] Re: loading of zeros into {x,y,z}mm registers (take 2)

On Mon, Dec 04, 2017 at 01:15:46AM -0700, Jan Beulich wrote: > >>> On 02.12.17 at 01:13, wrote: > > On Fri, Dec 01, 2017 at 02:54:28PM +0100, Jakub Jelinek wrote: > >> Will try this: > > > > That failed to bootstrap, but here is an updated version that passed > >

[PATCH] Re: loading of zeros into {x,y,z}mm registers (take 2)

>>> On 02.12.17 at 01:13, wrote: > On Fri, Dec 01, 2017 at 02:54:28PM +0100, Jakub Jelinek wrote: >> Will try this: > > That failed to bootstrap, but here is an updated version that passed > bootstrap/regtest on x86_64-linux and i686-linux, ok for trunk? Thanks for the quick

Re: [RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes

On Sun, Dec 03, 2017 at 10:55:27PM -0700, Jeff Law wrote: > As we touched on in IRC, the EVRP analyzer was doing something stupid > which caused it to not merge in existing range information under certain > circumstances. > > Consider this fragment: > > x_1 = foo () > if (x_1 > 2) >