Re: [v2 of PATCH 06/14] Strip location wrappers in operand_equal_p

On Sun, Dec 17, 2017 at 09:07:54PM -0500, David Malcolm wrote: > What do you think? > > Successfully bootstrapped on x86_64-pc-linux-gnu, as > part of the kit. > > gcc/ChangeLog: > * fold-const.c (operand_equal_p): Strip any location wrappers, > before computing hashes. > --- >

Re: [libsanitizer] Fix Mac OS X 10.7 bootstrap (PR sanitizer/82824)

On Tue, Nov 14, 2017 at 01:57:21PM +0100, Rainer Orth wrote: > > And the preexisting: > > case "$host" in > > *-*-darwin*) MAC_INTERPOSE=true ; enable_static=no ;; > > *) MAC_INTERPOSE=false ;; > > esac > > AM_CONDITIONAL(USING_MAC_INTERPOSE, $MAC_INTERPOSE) > > looks wrong too. > > Wrong in

Re: [PATCH] Add -fsanitize=pointer-{compare,subtract}.

On 12/05/2017 10:27 AM, Jakub Jelinek wrote: > On Tue, Nov 21, 2017 at 12:59:46PM +0100, Martin Liška wrote: >> On 10/16/2017 10:39 PM, Martin Liška wrote: >>> Hi. >>> >>> All nits included in mainline review request I've just done: >>> https://reviews.llvm.org/D38971 >>> >>> Martin >> >> Hi. >>

Re: [libsanitizer] Fix Mac OS X 10.7 bootstrap (PR sanitizer/82824)

On Mon, Dec 18, 2017 at 11:21:35AM +0100, Rainer Orth wrote: > I've been using the following in my tree. Still need to try and get > this upstream. Please. If that doesn't work, I think we need to do it in configure, sanitizer_internal_defs.h seems to be included very early, so there is no easy

Re: [committed][PR tree-optimization/83410] Avoid some jump threads when parallelizing loops

On Fri, Dec 15, 2017 at 6:00 PM, Richard Biener wrote: > On December 15, 2017 5:19:14 PM GMT+01:00, Jeff Law wrote: >>I hate this patch. >> >>The fundamental problem we have is that there are times when we very >>much want to thread jumps and yet

Re: [libsanitizer] Fix Mac OS X 10.7 bootstrap (PR sanitizer/82824)

Hi Jakub, > On Tue, Nov 14, 2017 at 01:57:21PM +0100, Rainer Orth wrote: >> > And the preexisting: >> > case "$host" in >> > *-*-darwin*) MAC_INTERPOSE=true ; enable_static=no ;; >> > *) MAC_INTERPOSE=false ;; >> > esac >> > AM_CONDITIONAL(USING_MAC_INTERPOSE, $MAC_INTERPOSE) >> > looks wrong

Re: [PATCH][arm] Add -mverbose-cost-dump and de-verbosify cost dumps

On 18/12/17 04:09, Sandra Loosemore wrote: On 12/14/2017 10:50 PM, Sandra Loosemore wrote: On 12/14/2017 11:48 AM, Kyrill Tkachov wrote: [snip] Thanks, done. I haven't created a new Target-specific developers options table but instead listed the targets the options apply to in

c-family PATCH for warn_logical_operator

While looking into something else I noticed that because of the missing warn_logical_op check we do unnecessary work in warn_logical_operator, like calling fold_for_warn which can put stuff into cv/fold_cache etc. It also causes more noise when debugging. Bootstrapped/regtested on x86_64-linux,

Re: [wwwdocs] mention AVR additions

On 14.12.2017 21:44, Gerald Pfeifer wrote: Hi Johann, On Wed, 13 Dec 2017, Georg-Johann Lay wrote: This adds AVR improvements to v8 Release Notes. that's quite impressive a set of improvements! Index: changes.html ===     The

Re: [libsanitizer] Fix Mac OS X 10.7 bootstrap (PR sanitizer/82824)

Hi Jakub, > On Mon, Dec 18, 2017 at 11:21:35AM +0100, Rainer Orth wrote: >> I've been using the following in my tree. Still need to try and get >> this upstream. > > Please. If that doesn't work, I think we need to do it in configure, > sanitizer_internal_defs.h seems to be included very early,

Re: [01/13] Add a qimode_for_vec_perm helper function

On Sun, Dec 10, 2017 at 12:08 AM, Richard Sandiford wrote: > The vec_perm code falls back to doing byte-level permutes if > element-level permutes aren't supported. There were two copies > of the code to calculate the mode, and later patches add another, > so this

Re: [08/13] Add a vec_perm_indices_to_tree helper function

On Sun, Dec 10, 2017 at 12:20 AM, Richard Sandiford wrote: > This patch adds a function for creating a VECTOR_CST from a > vec_perm_indices, operating directly on the encoding. Ok. > > 2017-12-09 Richard Sandiford > > gcc/ >

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Mon, Dec 18, 2017 at 02:17:18PM +0100, Jakub Jelinek wrote: > One option would be to deal with that in pop_stmt_list and the C++ caller > thereof, where we right now have: > > /* If the statement list contained exactly one statement, then > extract it immediately. */ > if

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On Mon, Dec 18, 2017 at 09:36:46AM -0700, Jeff Law wrote: > On 12/18/2017 08:10 AM, Marek Polacek wrote: > > I'm not entirely up to speed with this code, but this one seemed > > sufficiently > > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value. > > Otherwise, go with

PATCH to fix -Wrestrict ICE (PR middle-end/83463)

I'm not entirely up to speed with this code, but this one seemed sufficiently obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value. Otherwise, go with maxobjsize. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2017-12-18 Marek Polacek PR

Re: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs

On 12/15/2017 06:25 AM, Tom de Vries wrote: Proposed Solution: The patch addresses the problem, by: - marking the hard regs that have been used in lra_spill in   hard_regs_spilled_into - using hard_regs_spilled_into in lra_create_live_ranges to   make sure those registers are marked in the

C++ PATCH to fix wrong-code with constexpr call table cache (PR c++/83116)

Here the problem was that cxx_eval_call_expression can cache the result of a constexpr call in constexpr_call_table, but we have to be careful, after store_init_value the result might be invalid. So I believe we also have to clear the constexpr call table. I've lumped it together with clearing

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 08:10 AM, Marek Polacek wrote: > I'm not entirely up to speed with this code, but this one seemed sufficiently > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value. > Otherwise, go with maxobjsize. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > >

RE: [patch][x86] -march=icelake

Hi, I tried to replace 2 flags variable with c++ bitset(in patch attached). What do you think? > Please add these options first. 2 options left(they are under Kirill's review currently), I'll add PTAs for them to the patch, as soon as they will be commited. Thanks, Julia > -Original

Re: c-family PATCH for warn_logical_operator

On 12/18/2017 03:35 AM, Marek Polacek wrote: > While looking into something else I noticed that because of the missing > warn_logical_op check we do unnecessary work in warn_logical_operator, like > calling fold_for_warn which can put stuff into cv/fold_cache etc. It also > causes more noise when

[PR c++/59930] template friend injection

this patch fixes the handling of template friend classes of template classes. Our current handling was somewhat messed up, possibly because of now-clarified ambiguities in earlier versions of the std. In particular we'd search too many namespaces looking for an existing declaration, and if

Re: [PATCH PR81740]Enforce dependence check for outer loop vectorization

On Mon, Dec 18, 2017 at 1:37 PM, Richard Biener wrote: > On Fri, Dec 15, 2017 at 7:39 PM, Bin.Cheng wrote: >> On Fri, Dec 15, 2017 at 1:19 PM, Richard Biener >> wrote: >>> On Fri, Dec 15, 2017 at 1:35 PM, Bin.Cheng

Re: [PATCH PR81740]Enforce dependence check for outer loop vectorization

Hi, On Mon, 18 Dec 2017, Richard Biener wrote: > where *unroll is similar to *max_vf I think. dist_v[0] is the innermost loop. [0] is always outermost loop. > The vectorizer does way more complicated things and only looks at the > distance with respect to the outer loop as far as I can see

Re: [committed][PR tree-optimization/83410] Avoid some jump threads when parallelizing loops

On 12/18/2017 03:15 AM, Richard Biener wrote: > On Fri, Dec 15, 2017 at 6:00 PM, Richard Biener > wrote: >> On December 15, 2017 5:19:14 PM GMT+01:00, Jeff Law wrote: >>> I hate this patch. >>> >>> The fundamental problem we have is that there are

Re: [PR 81616] Deferring FMA transformations in tight loops

On Fri, Dec 15, 2017 at 3:19 PM, Martin Jambor wrote: > > Hello, > > the patch below prevents creation if fused-multiply-and-add instructions > in the widening_mul gimple pass on the Zen-based AMD CPUs and as a > result fixes regressions of native znver1 tuning when compared to >

[Committed] S/390: PR83420: Improve hotpatch option parsing.

With the attached patch we get rid of the following build failure: /home/andreas/build/../gcc/gcc/config/s390/s390.c: In function ‘void s390_option_override()’: /home/andreas/build/../gcc/gcc/config/s390/s390.c:15361:16: error: ‘char* strncpy(char*, const char*, size_t)’ specified bound 256

Re: [PATCH PR81228][AARCH64] Fix ICE by adding LTGT in vec_cmp

On 14/12/17 10:38, Sudakshina Das wrote: Hi On 13/12/17 16:56, James Greenhalgh wrote: On Wed, Dec 13, 2017 at 04:45:33PM +, Sudi Das wrote: On 13/12/17 16:42, Sudakshina Das wrote: Hi This patch is a follow up to the existing discussions on

Re: [PATCH] -fdump-tree, -save-temps=obj & subdirs

On 12/07/2017 05:10 AM, Nathan Sidwell wrote: > There's an unfortunate interaction between -save-temps=obj and > -fdump-tree- when subdirectories are in play. > > Consider: >   g++ -fdump-tree-all -save-temps=obj -c -o tgt/x.o sub/x.cc > we end up with a bunch of errors of the form: >  

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 05:27 PM, Jakub Jelinek wrote: On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote: Your warning is about restrict and argument overlap, what does it have to do with unprototyped calls? Nothing. There is no restrict in that case, and it isn't handled as builtin if it

Re: [committed][PATCH] Fix bogus propagation in DOM

On 11/21/2017 07:56 AM, Richard Biener wrote: >> >> >> I considered trying to key behavior on EDGE_DFS_BACK (6->8). It'd be >> something like don't record equivalences from a degenerate PHI where the >> remaining edge(s) are EDGE_DFS_BACK. But I just couldn't convince >> myself that was actually

Re: [PATCH] Fix IPA flattening ICE (PR ipa/82801)

On 12/12/2017 11:57 AM, Jakub Jelinek wrote: > Hi! > > We ICE on the following testcase, because we first gather all cgraph nodes > in an array and then we walk it backwards and flatten_function anything > that has "flatten" attribute. But flatten_function can result in cgraph > node removal and

Re: [005/nnn] poly_int: rtx constants

On 12/14/2017 06:25 PM, Richard Sandiford wrote: > Jeff Law writes: >> On 10/23/2017 11:00 AM, Richard Sandiford wrote: >>> This patch adds an rtl representation of poly_int values. >>> There were three possible ways of doing this: >>> >>> (1) Add a new rtl code for the poly_ints

Re: [PATCH PR81740]Enforce dependence check for outer loop vectorization

On Fri, Dec 15, 2017 at 7:39 PM, Bin.Cheng wrote: > On Fri, Dec 15, 2017 at 1:19 PM, Richard Biener > wrote: >> On Fri, Dec 15, 2017 at 1:35 PM, Bin.Cheng wrote: >>> On Fri, Dec 15, 2017 at 12:09 PM, Bin.Cheng

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Fri, Dec 15, 2017 at 09:34:44AM +0100, Richard Biener wrote: > I don't like this too much. Iff then we should do "real" lazy > computation, like adding a TREE_SIDE_EFFECTS_VALID flag on STATEMENT_LIST, > keeping TREE_SIDE_EFFECTS up-to-date when easily possible and when doing > the expensive

Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)

On Mon, Dec 18, 2017 at 02:02:52PM +0100, Jakub Jelinek wrote: > Because make_node (STATEMENT_LIST) sets TREE_SIDE_EFFECTS, but the above > memset clears it, we start with inconsistent TREE_SIDE_EFFECTS from the > beginning. > > I've tried to track TREE_SIDE_EFFECTS precisely, as below, but that

[ja...@redhat.com: Re: [PATCH] Fix -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)]

--- Begin Message --- On Mon, Dec 18, 2017 at 02:35:07PM +0100, Jakub Jelinek wrote: > On Mon, Dec 18, 2017 at 02:17:18PM +0100, Jakub Jelinek wrote: > > One option would be to deal with that in pop_stmt_list and the C++ caller > > thereof, where we right now have: > > > > /* If the

Re: [committed][PR tree-optimization/83410] Avoid some jump threads when parallelizing loops

On December 18, 2017 5:06:25 PM GMT+01:00, Jeff Law wrote: >On 12/18/2017 03:15 AM, Richard Biener wrote: >> On Fri, Dec 15, 2017 at 6:00 PM, Richard Biener >> wrote: >>> On December 15, 2017 5:19:14 PM GMT+01:00, Jeff Law >wrote:

Re: [PATCH] rtlanal: dead_or_set_regno_p should handle CLOBBER (PR83424)

On 12/16/2017 02:03 PM, Segher Boessenkool wrote: > In PR83424 combine's move_deaths puts a REG_DEAD not in the wrong place > because dead_or_set_regno_p does not account for CLOBBER insns. This > fixes it. > > Bootstrapped and tested on powerpc64-linux {-m32,-m64} and on x86_64-linux. > Is this

Re: Add support for fully-predicated loops

On 11/17/2017 07:56 AM, Richard Sandiford wrote: > This patch adds support for using a single fully-predicated loop instead > of a vector loop and a scalar tail. An SVE WHILELO instruction generates > the predicate for each iteration of the loop, given the current scalar > iv value and the loop

Re: [i386] PR81842 [CET] -fcf-protection -mcet is incompatible with makecontext family functions

On 12/17/2017 05:05 PM, Tsimbalist, Igor V wrote: -fcf-protection -mcet is incompatible with makecontext family functions since they can't properly set up and destroy shadow stack pointer. This change provides a mechanism to help detection shadow stack compatibility. The current proposal is to

Re: C++ PATCH to fix wrong-code with constexpr call table cache (PR c++/83116)

On Mon, Dec 18, 2017 at 01:07:18PM -0500, Jason Merrill wrote: > On Mon, Dec 18, 2017 at 10:09 AM, Marek Polacek wrote: > > Here the problem was that cxx_eval_call_expression can cache the result of a > > constexpr call in constexpr_call_table, but we have to be careful, after

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote: > On 12/18/2017 08:10 AM, Marek Polacek wrote: > > I'm not entirely up to speed with this code, but this one seemed > > sufficiently > > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value. > > Otherwise, go with

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 10:07 AM, Jakub Jelinek wrote: On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote: On 12/18/2017 08:10 AM, Marek Polacek wrote: I'm not entirely up to speed with this code, but this one seemed sufficiently obvious: check INTEGRAL_TYPE_P before looking at a tree's

[PATCH,WIP] Use functional parameters for data mappings in OpenACC child functions

Jakub, I'd like your thoughts on the following problem. One of the offloading bottlenecks with GPU acceleration in OpenACC is the nontrivial offloaded function invocation overhead. At present, GCC generates code to pass a struct containing one field for each of the data mappings used in the OMP

[PATCH] Improve strlen pass handling of loads from memory (PR tree-optimization/83444)

Hi! As the testcase shows, we fold strlen (str) == 0 into *str == 0 before the strlen pass has a chance to optimize. The following patch optimizes loads from the known termination '\0' into lhs = '\0' and loads from the part of the string known to be non-zero results in ~[0, 0] range being

Re: [PATCH] diagnose attribute conflicts on conversion operators (PR 83394)

On 12/13/2017 02:38 PM, Jason Merrill wrote: On Wed, Dec 13, 2017 at 12:54 PM, Martin Sebor wrote: The attached update also fixes both instances of the ICE reported in bug 83322 and supersedes Jakub's patch for that bug

Re: [PATCH] set range for strlen(array) to avoid spurious -Wstringop-overflow (PR 83373 , PR 78450)

On 12/14/2017 12:04 PM, Jeff Law wrote: On 12/14/2017 11:55 AM, Jakub Jelinek wrote: On Thu, Dec 14, 2017 at 11:51:26AM -0700, Martin Sebor wrote: Well, it would be nice to get sanitizers diagnose this at runtime. If we know the array length at compile time, simply compare after the strlen

Re: C++ PATCH to fix wrong-code with constexpr call table cache (PR c++/83116)

OK. On Mon, Dec 18, 2017 at 2:56 PM, Marek Polacek wrote: > On Mon, Dec 18, 2017 at 01:07:18PM -0500, Jason Merrill wrote: >> On Mon, Dec 18, 2017 at 10:09 AM, Marek Polacek wrote: >> > Here the problem was that cxx_eval_call_expression can cache the

Re: [PATCH] Improve strlen pass handling of loads from memory (PR tree-optimization/83444)

On 12/18/2017 02:45 PM, Jakub Jelinek wrote: > Hi! > > As the testcase shows, we fold strlen (str) == 0 into *str == 0 before > the strlen pass has a chance to optimize. The following patch optimizes > loads from the known termination '\0' into lhs = '\0' and loads from the > part of the string

Re: [PATCH] avoid false negatives in attr-nonstring-3.c (PR 83131)

Ping: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00665.html On 12/11/2017 03:54 PM, Martin Sebor wrote: The attr-nonstring-3.c test fails on targets that expand the calls to some of the tested string functions in builtins.c, before they reach the checker in calls.c. The failures were

[PATCH] Improve vect_create_epilog_for_reduction (PR tree-optimization/80631)

Hi! When backporting the wrong-code bugfix parts of PR80631 to 7.3, I've noticed that we perform the optimization to use the induc_val only when reduc_fn is IFN_REDUC_{MAX,MIN}. That is true e.g. for AVX2, but not plain SSE2, so if we have a loop like: void foo (int *v) { int found_index =

Re: Fix Debug insert_return_type

On 15 December 2017 at 21:19, François Dumont wrote: > Here is a patch to fix those failures of the latest report: > > UNRESOLVED: 23_containers/map/modifiers/extract.cc compilation failed to > produce executable > FAIL: 23_containers/set/modifiers/extract.cc (test for excess errors) > UNRESOLVED:

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote: > On 12/18/2017 10:07 AM, Jakub Jelinek wrote: > > On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote: > > > On 12/18/2017 08:10 AM, Marek Polacek wrote: > > > > I'm not entirely up to speed with this code, but this one seemed

[committed][PR middle-end/83460] Remove compromised test

As noted in the BZ, this test has been compromised by Martin's changes in . I contemplated turning the test into pure C code, but that turns out not to be a terribly useful thing to do. I also contemplated gathering the CPP output prior to Martin's changes and using that for the test. But that

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

Hi Martin, > In all cases all the information necessary to detect and diagnose > or even avoid the problem is available. In fact, one might argue > that optimizing such calls (expanding them inline) would be > preferable to doing nothing and allowing the undefined behavior > to cause a bug at

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 08:10 AM, Marek Polacek wrote: I'm not entirely up to speed with this code, but this one seemed sufficiently obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value. Otherwise, go with maxobjsize. Bootstrapped/regtested on x86_64-linux, ok for trunk? Thanks for

Re: C++ PATCH to fix wrong-code with constexpr call table cache (PR c++/83116)

On Mon, Dec 18, 2017 at 10:09 AM, Marek Polacek wrote: > Here the problem was that cxx_eval_call_expression can cache the result of a > constexpr call in constexpr_call_table, but we have to be careful, after > store_init_value the result might be invalid. So I believe we

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 10:45 AM, Jakub Jelinek wrote: On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote: On 12/18/2017 10:07 AM, Jakub Jelinek wrote: On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote: On 12/18/2017 08:10 AM, Marek Polacek wrote: I'm not entirely up to speed with

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote: > It isn't optimized either way. In fact, the only indication > of a problem in the code below is the new -Wrestrict warning: So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0, 0UL); on targets where size_t is unsigned

[PING] [PATCH] testsuite: add coverage for diagnostics relating to inlining (PR tree-optimization/83336)

Is the tweak to prune.exp at the end of this patch OK? (I can self- approve the rest of this). On Mon, 2017-12-11 at 15:44 -0500, David Malcolm wrote: > In theory, the diagnostics subsystem can print context information on > code inlining when diagnostics are emitted by the middle-end, >

Re: [v3 PATCH] PR libstdc++/68430

On 16 December 2017 at 12:30, Ville Voutilainen wrote: > The compiler-powered is_constructible that we have in gcc 8 is powerful > enough to give the right answer to an is_constructible question > that would be hard for a pure-library implementation to get right > in a well-formed fashion. This

Re: [PING] [PATCH] testsuite: add coverage for diagnostics relating to inlining (PR tree-optimization/83336)

On 12/18/2017 10:14 AM, David Malcolm wrote: > Is the tweak to prune.exp at the end of this patch OK? (I can self- > approve the rest of this). Yes. jeff

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 11:32 AM, Bernd Edlinger wrote: Hi Martin, In all cases all the information necessary to detect and diagnose or even avoid the problem is available. In fact, one might argue that optimizing such calls (expanding them inline) would be preferable to doing nothing and allowing the

Re: [patch AArch64] Do not perform a vector splat for vector initialisation if it is not useful

On 12/11/2017 08:44 AM, James Greenhalgh wrote: > Hi, > > In the testcase in this patch we create an SLP vector with only two > elements. Our current vector initialisation code will first duplicate > the first element to both lanes, then overwrite the top lane with a new > value. > > This

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote: > On 12/18/2017 12:04 PM, Jakub Jelinek wrote: > > On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote: > > > It isn't optimized either way. In fact, the only indication > > > of a problem in the code below is the new

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote: > > Your warning is about restrict and argument overlap, what does it have to do > > with unprototyped calls? Nothing. There is no restrict in that case, and > > it isn't handled as builtin if it doesn't match the builtin's prototype.

[PATCH] Fix off by one error in loop-unroll.c (PR rtl-optimization/82675).

Hello. Following patch fixes off by one in loop unroller where wont_exit has not enough elements that are later on asked for. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin gcc/ChangeLog: 2017-11-08 Martin Liska

Re: [RFA][PATCH] Stack clash protection 07/08 -- V4 (aarch64 bits)

On 11/27/2017 11:44 AM, James Greenhalgh wrote: > On Wed, Nov 22, 2017 at 06:28:24PM +, Jeff Law wrote: >> On 11/21/2017 04:57 AM, James Greenhalgh wrote: >>> I've finally built up enough courage to start getting my head around this... >> Can't blame you for avoiding :-) This stuff isn't my

[PATCH, rs6000] Add vec_mergee, vec_mergeo, vec_float2 builtin support

GCC maintainers: The following patch adds support for some missing instances of builtins, vec_mergee, vec_mergeo, vec_float2. This patch adds the missing GCC functionality and test cases for the builtins. The patch has been run on: powerpc64le-unknown-linux-gnu (Power 8 LE)

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 12:04 PM, Jakub Jelinek wrote: On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote: It isn't optimized either way. In fact, the only indication of a problem in the code below is the new -Wrestrict warning: So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0,

Re: [PATCH] avoid false negatives in attr-nonstring-3.c (PR 83131)

On 12/11/2017 03:54 PM, Martin Sebor wrote: > The attr-nonstring-3.c test fails on targets that expand > the calls to some of the tested string functions in builtins.c, > before they reach the checker in calls.c.  The failures were > reported on powrrpc64le but tests can be constructed that fail >

Re: PATCH to fix -Wrestrict ICE (PR middle-end/83463)

On 12/18/2017 04:41 PM, Jakub Jelinek wrote: On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote: On 12/18/2017 12:04 PM, Jakub Jelinek wrote: On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote: It isn't optimized either way. In fact, the only indication of a problem in

Re: [PATCH] Improve vect_create_epilog_for_reduction (PR tree-optimization/80631)

On 12/18/2017 02:50 PM, Jakub Jelinek wrote: > Hi! > > When backporting the wrong-code bugfix parts of PR80631 to 7.3, I've noticed > that we perform the optimization to use the induc_val only when reduc_fn is > IFN_REDUC_{MAX,MIN}. That is true e.g. for AVX2, but not plain SSE2, so if > we have

Re: [RFC PATCH] Avoid PRED_NEGATIVE_RETURN prediction on likely -1/0/1 comparison functions (PR middle-end/81914)

On 12/13/2017 07:39 AM, Jakub Jelinek wrote: > Hi! > > While the PRED_NEGATIVE_RETURN heuristics generally works quite well, for > qsort comparison functions and similar, including the planned C++ > spaceship operator <=> where typically negative and positive are > approximately even it doesn't

Re: [i386] PR81842 [CET] -fcf-protection -mcet is incompatible with makecontext family functions

On 12/18/2017 12:39 PM, Sandra Loosemore wrote: > On 12/17/2017 05:05 PM, Tsimbalist, Igor V wrote: >> -fcf-protection -mcet is incompatible with makecontext family functions >> since they can't properly set up and destroy shadow stack pointer. This >> change provides a mechanism to help detection