Re: [patch] c/c++ asan tests for FreeBSD

On 11/30/2015 01:12 PM, Andreas Tobler wrote: On 30.11.15 11:28, Bernd Schmidt wrote: On 11/29/2015 08:32 PM, Andreas Tobler wrote: -/* { dg-do run { target { *-*-linux* } } } */ +/* { dg-do run { target { *-*-linux* *-*-freebsd* } } } */ I see a patch from you to add asan support to x86

Re: [PATCH] Update TARGET_FUNCTION_INCOMING_ARG documentation

On 11/29/2015 06:14 PM, H.J. Lu wrote: Is this safe for stage 3? Is there a reason to do it now? This doesn't include a testcase. * function.c (assign_parm_setup_stack): Force source into a register if needed. * target.def (function_incoming_arg): Update documentation

Re: [patch] link libgccjit using LDFLAGS

On 11/30/2015 01:00 AM, Matthias Klose wrote: link libgccjit using LDFLAGS (which is empty by default), but could be used to pass hardening options like -Wlz,relro. Ok when stage 1 opens. Bernd

Re: [PATCH] Fix PR68029

On 11/27/2015 01:30 PM, Jiří Engelthaler wrote: Sorry for international characters in my name. It should be Jiri Engelthaler 2015-11-27 13:29 GMT+01:00 Engelthaler Jiří : There is precedent for non-ASCII characters in ChangeLogs. Grep for Rafael Ávila de Espíndola.

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/27/2015 03:33 PM, Kyrill Tkachov wrote: Sorry for that. That is caused not by this patch but rather by the followup https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03327.html The checking assert fails: gcc_checking_assert (!emit_a || !modified_in_p (orig_b, emit_a)); emit_a is: (parallel [

Re: [PATCH][RTL-ifcvt] Reject insns that are multiple_sets

On 11/27/2015 10:45 AM, Kyrill Tkachov wrote: As discussed, I've added a check for multiple_sets to insn_valid_noce_process_p and replaced the modified_a and modified_b redundant definitions with checking asserts to catch cases if any unexpected multiple sets get through the net. Ok, thanks!

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/26/2015 10:46 AM, Richard Biener wrote: Ok with the change suggested by Micha for the asm()s. Note that I originally used gimple_vuse () instead of gimple_vdef () as even reading random memory is a barrier for the compiler to move stores across it (not reads, of course). Which is why I

regrename/i386: ROP vs df and stack-regs

This is a patch for PRs 68471 and 68472, which show problems with the ROP mitigation: * reg-stack doesn't call df_insn_update when it makes changes, and if df checking is enabled, any subsequent df_analyze call will abort * Using -mcmodel=medium fails because of a pattern that has lea

Re: [PATCH 1/6] Fix memory leak in cilk

On 11/26/2015 09:59 PM, Martin Liška wrote: I'm sending v2 of the patch, where I removed adding of 'const' to certain function arguments. Apart from that, I found one more leak related to cilk. As I've retested in valgrind, there should not be any memory leak related to cilk. Ready to be

Re: regrename/i386: ROP vs df and stack-regs

On 11/27/2015 10:26 AM, Eric Botcazou wrote: +#ifdef STACK_REGS + if (regstack_completed + && REG_P (recog_data.operand[i]) + && IN_RANGE (REGNO (recog_data.operand[i]), + FIRST_STACK_REG, LAST_STACK_REG)) +

Re: [patch] Copy-edit the Option Summary in invoke.texi

On 11/26/2015 01:16 PM, Jonathan Wakely wrote: At https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html we document -Waggressive-loop-optimizations but you can't find that option at https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html because we document -Wno-aggressive-loop-optimizations

Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

On 11/26/2015 09:53 PM, Martin Liška wrote: Is the patch still candidate to be merged in current stage3, or should I leave it to the next stage1? What about the first patch or the patch, where I just applied replacement of whitespaces? As I said previously, the one to just replace whitespace

Re: [PATCH 01/15] Selftest framework (unittests v4)

On 11/25/2015 11:47 PM, David Malcolm wrote: FWIW, the reason I special-cased the linked list was to avoid any dynamic memory allocation: the ctors run before main, so I wanted to keep them as simple as possible. Is there any particular reason for this? C++ doesn't disallow memory allocation

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/26/2015 12:12 PM, Kyrill Tkachov wrote: diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c index af7a3b9..3e3dc8d 100644 --- a/gcc/ifcvt.c +++ b/gcc/ifcvt.c @@ -2220,7 +2220,7 @@ noce_try_cmove_arith (struct noce_if_info *if_info) } } -if (emit_a && modified_in_a) +if (emit_a

Re: [PR68432 00/26] Handle size/speed choices for internal functions

On 11/25/2015 01:20 PM, Richard Sandiford wrote: This series fixes PR 68432, a regression caused by my internal-functions- for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* condition but conditionally FAIL if we're optimising for size: if (SSE_FLOAT_MODE_P (mode) &&

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/26/2015 02:52 PM, Kyrill Tkachov wrote: On 26/11/15 13:40, Bernd Schmidt wrote: On 11/26/2015 12:12 PM, Kyrill Tkachov wrote: modified_in_b = emit_b != NULL_RTX && modified_in_p (orig_a, emit_b); Can this ever be true? We arrange for emit_b to set a new pseudo, don't we

Re: [PR68432 20/22] Record attributes for define_expand

On 11/25/2015 05:08 PM, Richard Sandiford wrote: Also, using a string like that rather than some kind of identifier or a define_icode_attr maybe isn't the best approach? By "some kind of identifier" do you just mean replacing "code,alternative" with a string that doesn't have a comma? Yeah.

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/26/2015 03:35 PM, Kyrill Tkachov wrote: Would it be ok if I did that as a separate follow-up patch? We don't have a testcase where this actually causes trouble and I'd like to keep the fix for this PR as self-contained as possible. Sure. Bernd

Re: [PR68432 00/26] Handle size/speed choices for internal functions

On 11/26/2015 04:13 PM, Richard Sandiford wrote: That would mean that the validity of a gimple call would depend on both the target predicates and whether the block containing the statement is optimised for size or speed. So whenever we want to test whether a gimple call is valid, we'd need to

Re: [PR68432 00/26] Handle size/speed choices for internal functions

On 11/26/2015 05:22 PM, Richard Sandiford wrote: It also isn't suitable for optabs because the conditions are cached by init_optabs. I suppose we could have a separate cache for size and speed though. That sounds necessary given the existence of such insn conditions, unless we want to

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/26/2015 05:45 PM, Kyrill Tkachov wrote: that doesn't help, punt. */ - modified_in_a = emit_a != NULL_RTX && modified_in_p (orig_b, emit_a); if (tmp_b && then_bb) { These bits I thought would be part of a followup patch (which would also guard against single_set

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/25/2015 04:00 PM, Jakub Jelinek wrote: nonfreeing_call_p is one necessary condition (if that is true, it means the call could mean that the first access does not trap while the second one does). But I agree that we need a predicate for nonbarrier_call_p or similar. Some atomic builtins are

Re: [PR68432 04/22] Remove global which_alternative

On 11/25/2015 01:26 PM, Richard Sandiford wrote: Later patches in the series add a new form of attribute that takes the attribute number as an argument, rather than it being stored in the global which_alternative variable. Having both a local alternative number and a global alternative number

Re: [PATCH/RFC v2] PR68212: Improve Accounting of Block Frequencies During Loop Unrolling

I'm reading up on this stuff, but I'm probably still not the best person to review the actual frequency manipulation parts in this. There are a few things I can comment on, however. The first question would be, have you looked at the rebuild_frequencies code in predict.c, and whether you can

Re: [PR68432 20/22] Record attributes for define_expand

On 11/25/2015 01:35 PM, Richard Sandiford wrote: The define_subst support made it syntactically possible to add attributes to a define_expand, but until now they had been ignored by genattrtab.c. This patch allows define_expands to have "code,alternative" attributes but raises an error for

Re: [PR68432 04/22] Remove global which_alternative

On 11/25/2015 05:19 PM, Richard Sandiford wrote: I guess not, but without it we have both local and global variables called which_alternative. So call the local ones something else (alt_to_check, requested_alt or attr_alt)? Bernd

Re: [PATCH] Allocate constant size dynamic stack space in the prologue

On 11/25/2015 03:52 PM, Dominik Vogt wrote: Without looking into the details, I believe it's an optimization to have certain frequently used members of the struct always on the same cache line. Probably better to annotate the global vars then with an alignment, rather than waste space on the

Re: [PATCH][calls.c] PR rtl-optimization/67226: Take into account pretend_args_size when checking stack offsets for sibcall optimisation

On 11/25/2015 03:54 PM, Kyrill Tkachov wrote: And here it is. This fixes the bug on arm and tests on arm look ok. I've kicked off bootstraps and tests on arm, aarch64 and x86_64. Ok for trunk if they come back clean? Sure. Thanks! (Backport too.) Bernd

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

a test cycle. Bernd diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 49fa59b..1e788e8 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,11 @@ +2015-11-25 Bernd Schmidt <bschm...@redhat.com> + + * ifcvt.c (noce_mem_write_may_trap_or_fault_p, + noce_can_store_speculate):

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/23/2015 05:05 PM, Michael Matz wrote: It only does so under some conditions, amongst them if it sees a dominating access to the same memory of the same type (load or store) and size. So it doesn't introduce writes on paths that don't already contain a write, and hence are multi-thread

Re: [PATCH 01/15] Selftest framework (unittests v4)

On 11/25/2015 03:26 AM, David Malcolm wrote: Consider the case where an assumption that the host is little-endian assumption creeps into one of the bitmap functions. Some time later, another developer updates their working copy from svn on a big-endian host and finds that lots of things are

Re: [PATCH 01/02] PR/62314: add ability to add fixit-hints

On 11/24/2015 09:03 PM, Jeff Law wrote: Although this looks weird, it's deliberate, and follows the pattern earlier in those test files: the diagnostics are injected by the plugin, not by cc1. The plugin gives us a way of unit-testing how diagnostic_show_locus handles the various ways of

Re: [PATCH][calls.c] PR rtl-optimization/67226: Take into account pretend_args_size when checking stack offsets for sibcall optimisation

On 11/24/2015 04:12 PM, Kyrill Tkachov wrote: arg->value to the stack frame at argblock. arg->value is: (mem/c:BLK (plus:SI (reg/f:SI 104 virtual-incoming-args) (const_int 20 [0x14])) [1 from+0 S20 A32]) and argblock is: (plus:SI (reg/f:SI 104 virtual-incoming-args) (const_int 16

Re: [PR68432 01/22][ARM] Remove operand dependency from "type" attribute

On 11/25/2015 01:21 PM, Richard Sandiford wrote: - (plus:SI (match_operand:SI 0 "s_register_operand" "l, r") - (match_operand:SI 1 "arm_add_operand""lPv,rIL")) + (plus:SI (match_operand:SI 0 "s_register_operand" "l,l, r,r") +

Re: [PATCH][calls.c] PR rtl-optimization/67226: Take into account pretend_args_size when checking stack offsets for sibcall optimisation

On 11/25/2015 01:41 PM, Bernd Schmidt wrote: /* arg.locate doesn't contain the pretend_args_size offset, it's part of argblock. Ensure we don't count it in I. */ #ifdef STACK_GROWS_DOWNWARD i -= crtl->args.pretend_args_size #else etc. Hmm, yours looks equivalent, just address

Re: [PATCH] Allocate constant size dynamic stack space in the prologue

On 11/25/2015 01:56 PM, Dominik Vogt wrote: The attached patch fixes a warning during Linux kernel compilation on S/390 due to -mwarn-dynamicstack and runtime alignment of stack variables with constant size causing cfun->calls_alloca to be set (even if alloca is not used at all). The patched

Re: [PATCH][calls.c] PR rtl-optimization/67226: Take into account pretend_args_size when checking stack offsets for sibcall optimisation

On 11/25/2015 03:10 PM, Kyrill Tkachov wrote: What should we do when we don't have STACK_GROWS_DOWNWARD? Do we need to write: if (STACK_GROWS_DOWNWARD) i -= crtl->args.pretend_args_size; else i += crtl->args.pretend_args_size; I think so. I mean, this should mirror this code here,

Re: [PATCH] shrink-wrap: Fix thinko (PR68520)

On 11/24/2015 07:13 PM, Segher Boessenkool wrote: PR rtl-optimization/68520 * shrink-wrap.c (try_shrink_wrapping): Don't push a block to VEC if its bit was already set in BB_WITH. Ok. Bernd

Re: [PATCH] PR c/68473: sanitize source range-printing within certain macro expansions

On 11/23/2015 07:26 PM, David Malcolm wrote: In theory we could attempt to try to handle this kind of thing by looking at the macro expansions, and to print something like: 13 TEST_EQ (fmin); ^~~~ 6 if ((long)FUNC##l(xl,xl) != (long)xl) \

Re: [PATCH 12/12] always define ENABLE_OFFLOADING

On 11/23/2015 05:52 PM, Ilya Verbin wrote: There are 2 new uses of "#ifdef ENABLE_OFFLOADING" in c_parser_oacc_declare and cp_parser_oacc_declare. I don't know how to properly test OpenACC, so here is untested patch. It's documented on the Offloading wiki page, but this patch is good enough

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 11/24/2015 02:15 PM, Kyrill Tkachov wrote: This bug also affects GCC 5 and 4.9. I've confirmed that this patch fixes the miscompilations on those branches. Bootstrap and test on x86_64 on the GCC 5 branch is successful. Same on 4.9 is ongoing. The patch applies cleanly to all branches. So ok

Re: [PATCH 0/6] Another fixes of various memory leaks

On 11/23/2015 02:49 PM, marxin wrote: Following series has been just bootregtested on x86_64-linux-gnu (all patches together). All ok except 5/6 which I'm not finding obvious. Better to have a cilk/c++ person have a look. In the future, a few more explanations would help with reviewing.

Re: [PATCH, i386] PR68497. Fix ICE with -fno-checking

On 11/24/2015 12:09 AM, Mikhail Maltsev wrote: The attached patch fixes a problem introduced in r229567: the assertion gcc_assert (is_sse); is checked if flag_checking is false, and this causes an ICE when compiling with -fno-checking. Ok. Bernd

Re: [RFA] [PATCH] Fix invalid redundant extension elimination for rl78 port

As I mentioned in a prior message on the subject, this is only a problem when the source/dest of the extension are the same. When the source/dest of the extension are different, we only optimize when the original set and extension are in the same block and we verify that all affected registers

Re: [PATCH v2] Add uaddv_optab, usubv4_optab

On 11/22/2015 09:58 PM, Uros Bizjak wrote: On Sun, Nov 22, 2015 at 11:38 AM, Richard Henderson wrote: * optabs.def (uaddv4_optab, usubv4_optab): New. * internal-fn.c (expand_addsub_overflow): Use them. * doc/md.texi (Standard Names): Add uaddv4, usubv4. * config/i386/i386.c

Re: [PATCH] PR c/68473: sanitize source range-printing within certain macro expansions

On 11/23/2015 06:52 PM, David Malcolm wrote: This patch fixes PR c/68473 by bulletproofing the new diagnostic_show_locus implementation against ranges that finish before they start (which can happen when using the C preprocessor), falling back to simply printing a caret. Hmm, wouldn't it be

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/19/2015 12:49 AM, Jeff Law wrote: On 11/18/2015 12:16 PM, Bernd Schmidt wrote: I don't think so, actually. One safe option would be to rip it out and just stop transforming this case, but let's start by looking at the code just a bit further down, calling noce_can_store_speculate

Re: [PATCH 01/15] Selftest framework (unittests v4)

On 11/19/2015 07:08 PM, David Malcolm wrote: gcc_assert terminates the process and no further testing is done, whereas the approach the kit tries to run as much of the testsuite as possible, and then fail if any errors occurred. Yeah, but let's say someone is working on bitmaps and one of the

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

I1 is def_insn, I3 is cand->insn. tmp_reg is 'ax'. What we want to do is reject this transformation because the destination of def_insn (aka I1), that is 'ax', is not the operand of the extend operation in cand->insn (aka I3). As you said, rtx_equal won't work on just SET_SRC (PATTERN

Re: [patch] Fix PR lto/61313

On 11/19/2015 01:02 PM, Eric Botcazou wrote: this fixes the glitch I introduced when trying to fix another bug: https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00330.html The --with-plugin-ld value specified by the user is also stripped, although that's unnecessay to fix the original bug. So I

Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

BTW, I'm with whoever said absolutely no way to the idea of making automatic changes like this as part of a commit hook. I think the whitespace change can go in if it hasn't already, but I think the other one still has enough problems that I'll say - leave it for the next stage 1. @@

Re: [PATCH] Get rid of insn-codes.h in optabs-tree.c

On 11/19/2015 03:28 PM, Ilya Enkovich wrote: This is a refactoring patch discussed in another thread [1]. It gets rid of CODE_FOR_nothing usage in optabs-tree.c by introducing boolean predicated in optabs-query. Bootstrapped and regtesed on x86_64-unknown-linux-gnu. Looks pretty reasonable,

Re: RFC/RFA: Fix bug with REE optimization corrupting extended registers

On 11/19/2015 04:34 PM, Nick Clifton wrote: Hi Bernd, I had a look around. There's code testing HARD_REGNO_NREGS in ree.c:combine_set_extension. It's inside #if 0, and labelled "temporarily disabled". See if enabling that helps you? (Jeff, that #if 0 was added by you). I suspect that the

Re: Fix -fno-checking segfault

On 11/19/2015 05:13 PM, Michael Matz wrote: in an enabled-checking compiler gcc_checking_assert is always executed. If that depends on things having happened under flag_checking being true, but it's actually false during runtime due to -fno-checking things go awry, like segfaulting in this case.

Re: [PATCH, PR68337] Don't fold memcpy/memmove we want to instrument

On 11/19/2015 05:31 PM, Ilya Enkovich wrote: Currently we fold all memcpy/memmove calls with a known data size. It causes two problems when used with Pointer Bounds Checker. The first problem is that we may copy pointers as integer data and thus loose bounds. The second problem is that if we

Re: RFC/RFA: Fix bug with REE optimization corrupting extended registers

should just restrict the candidates for optimization much earlier. Also, I want to apply the following. Ok if testing succeeds? Bernd commit ce68938b5150f5d41a54ed317ab97d98461be064 Author: Bernd Schmidt <bernds_...@t-online.de> Date: Thu Nov 19 17:38:15 2015 +0100 Reada

Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

On 11/19/2015 11:16 AM, Martin Liška wrote: You are right, however as the original coding style was really broken, it was much easier to use the tool and clean-up fall-out. Waiting for thoughts related to v2. Better, but still some oddities. I hope you won't get mad at me if I suggest doing

Re: [PATCH 01/15] Selftest framework (unittests v4)

In general I'm much happier with this approach, and I think this series is close to ready, but I want to bring up some questions that could use wider discussion. This patch adds a selftest.h/.c to gcc, with an API loosely modelled on gtest (though without the use of CamelCase): it supports

Re: [PATCH 1/4 v2][AArch64] Generalize CCMP support

On 11/17/2015 07:35 PM, Wilco Dijkstra wrote: I've updated the comments and documentation, see below. I hope it makes sense now - returning rtx that computes the same value as the tree expression we're emitting is the most useful thing one can do. The target-independent part is ok. Note that

Re: [PATCH PR52272]Be smart when adding iv candidates

On 11/10/2015 11:19 AM, Bin.Cheng wrote: On Tue, Nov 10, 2015 at 6:06 PM, Bernd Schmidt <bschm...@redhat.com> wrote: Multi-line expressions should be wrapped in parentheses so that emacs/indent can format them automatically. Two sets of parens are needed for this. Operators should then l

Re: [C PATCH] Don't leak C_MAYBE_CONST_EXPRs into fold() (PR c/68412)

On 11/18/2015 05:16 PM, Marek Polacek wrote: Actually, no, I think we should do this instead. +++ gcc/c-family/c-common.c @@ -1924,7 +1924,7 @@ warn_tautological_cmp (location_t loc, enum tree_code code, tree lhs, tree rhs) /* We do not warn for constants because they are typical of macro

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

Ok, so this is a thorny problem. I thought I had a solution, and I'll start by describing it, but in the end I think it doesn't actually work. On 11/06/2015 10:09 PM, Jeff Law wrote: On 11/06/2015 12:30 PM, Bernd Schmidt wrote: Well, I think if MEM_READONLY_P is insufficient (and I guess

Re: [2/2] i386 ROP mitigation

On 11/16/2015 07:18 PM, Uros Bizjak wrote: On Fri, Nov 13, 2015 at 9:47 PM, Bernd Schmidt <bernds_...@t-online.de> wrote: This adds a new -mmitigate-rop option to the i386 port. The idea is to mitigate against certain forms of attack called "return oriented programming"

Re: [PATCH] Fix libcpp ICE (PR preprocessor/60736)

On 11/19/2015 12:02 AM, Jakub Jelinek wrote: 2015-11-18 Jakub Jelinek PR preprocessor/60736 * include/cpplib.h (cpp_errno_filename): New prototype. * errors.c (cpp_errno): Don't handle msgid "" specially, use _(msgid) instead of msgid as

Re: RFC/RFA: Fix bug with REE optimization corrupting extended registers

(This is on the RL78 target where HImode values occupy two hard registers and QImode values only one. The bug however is generic, not RL78 specific). The REE pass transforms this into: (insn 44 (set (reg:QI r11) (mem:QI (reg:HI r20))) (insn 45 (set (reg:HI r10)

Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

On 11/19/2015 01:50 AM, Joseph Myers wrote: I don't think all the reformattings here are things we want to do globally for most source files. While I do appreciate the sentiment behind the patch, I agree with all of Joseph's points. Especially the clearly incorrect changes should be reverted

Re: PR 68393: Handle SUBREG_PROMOTED_VAR_P in expand_direct_optab_fn

On 11/18/2015 05:32 PM, Richard Sandiford wrote: Do the usual dance when assigning to SUBREG_PROMOTED_VAR_P destinations: first convert to the outer mode, then extend to the inner mode. This fixes the powerpc64le bootstrap failure reported in PR 68393. Ok. Bernd

Re: [PATCH] Fix ifcvt one_cmpl_abs optimization (PR rtl-optimization/68376)

On 11/18/2015 11:44 PM, Jakub Jelinek wrote: noce_try_abs optimizes these cases normal abs, which doesn't really care if the original condition is x < 0 ? -x : x or x <= 0 ? -x : x, but also the x < 0 ? ~x : x case. But in this case it is significant whether for x == 0 ~x or x applies; the

Re: [PATCH] Disable shrink-wrapping for ix86_static_chain_on_stack functions (PR target/67770)

On 11/19/2015 12:18 AM, Jakub Jelinek wrote: As the testcase shows, shrink-wrapping is incompatible with ix86_static_chain_on_stack, where we rely on the very first instruction in the (nested) function to be pushl %esi and use alternate entry point right after that pushl instruction (one byte

Re: [PATCH 00/16] Unit tests framework (v3)

On 11/17/2015 02:53 AM, Mike Stump wrote: On Nov 16, 2015, at 3:12 PM, Jeff Law wrote: So I'd tend to want them either at the end of the file with a single #if CHECKING_P or as a separate foo-tests file. Hum… I kinda don’t want the main files mucked up with tests. I think

Re: [PATCH, PR middle-end/68134] Reject scalar modes in default get_mask_mode hook

On 11/17/2015 12:49 PM, Ilya Enkovich wrote: Default hook for get_mask_mode is supposed to return integer vector modes. This means it should reject calar modes returned by mode_for_vector. Bootstrapped and regtested on x86_64-unknown-linux-gnu, regtested on aarch64-unknown-linux-gnu. OK for

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 11/17/2015 10:08 AM, Kyrill Tkachov wrote: Yes, I had considered that as well. It should be equivalent. I didn't use !reg_used_between_p because I thought it'd be more expensive than checking reg_overlap_mentioned_p since we must iterate over a number of instructions and call

Re: [PATCH][GCC] Make stackalign test LTO proof

On 11/16/2015 04:48 PM, Andre Vieira wrote: On 16/11/15 15:34, Joern Wolfgang Rennecke wrote: I just happened to stumble on this problem with another port. The volatile & test solution doesn't work, though. What does work, however, is: __asm__ ("" : : "" (dummy)); I can confirm that Joern's

Re: [PATCH] Fix uninitialized src_range within c_expr (Re: libcpp/C FE source range patch committed (r230331))

On 11/17/2015 04:13 PM, David Malcolm wrote: On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote: Should c_expr perhaps acquire a constructor so that this problem is avoided in the future? The whole thing seems somewhat error-prone. I agree that it's error prone, and the ctor approach

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 11/17/2015 02:03 PM, Kyrill Tkachov wrote: + || !reg_overlap_mentioned_p (tmp_reg, SET_SRC (PATTERN (cand->insn return false; Well, I think the statement we want to make is "return false from this function if the two expressions contain the same register number". I

Re: [PATCH 1/4][AArch64] Generalize CCMP support

On 11/13/2015 05:02 PM, Wilco Dijkstra wrote: * gcc/ccmp.c (expand_ccmp_expr): Extract cmp_code from return value of expand_ccmp_expr_1. I was trying to review this part of the patch in isolation and got very confused because the patch also changes the return values of the

Re: [1/2] i386 ROP mitigation: make more of regrename callable

On 11/16/2015 12:54 PM, Eric Botcazou wrote: Bootstrapped and tested on x86_64-linux. Ok? OK once the 2/2 patch is also approved. Thank you. The 2/2 has a small regrename piece to add target_data fields, are you OK with that as well? I'm assuming Uros will take a look at the rest. Bernd

Re: [PATCH] Allow embedded timestamps by C/C++ macros to be set externally (2)

On 11/15/2015 11:14 PM, Dhole wrote: gcc/c-family/ChangeLog: 2015-10-10 Eduard Sanou I can't find a previous change from you in the sources, so the first question would be whether you've gone through the copyright assignment process. Bernd

Re: [PATCH, 0/6] Remove first_pass_instance

On 11/15/2015 11:55 AM, Tom de Vries wrote: [ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ] This patch series removes first_pass_instance. 1Remove first_pass_instance from pass_vrp 2Remove first_pass_instance from pass_reassoc 3Remove

Re: [PATCH, x86] Fix posix_memalign declaration in mm_malloc.h

On 11/13/2015 11:30 PM, Marc Glisse wrote: +__asm__("posix_memalign"); Can't say I like the __asm__ after the #if/#else/#endif block. It might also cause trouble if some systems like to prepend an underscore, maybe? Yeah, that's one of the things I had in mind when I suggested moving this

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 11/16/2015 03:07 PM, Kyrill Tkachov wrote: I've explained in the comments in the patch what's going on but the short version is trying to change the destination of a defining insn that feeds into an extend insn is not valid if the defining insn doesn't feed directly into the extend insn. In

Re: [PATCH 00/16] Unit tests framework (v3)

So Jeff and I just had a chat, and we came up with some thoughts about how to proceed. I think we both agree that it would be good to have a special testing backend, along with frontends designed to be able to read in gimple or rtl that can be operated on. That's more of a long-term thing.

Re: [PATCH] Fix uninitialized src_range within c_expr (Re: libcpp/C FE source range patch committed (r230331))

On 11/16/2015 09:50 PM, David Malcolm wrote: The root cause is uninitialized data. Specifically, the C parser's struct c_expr gained a "src_range" field, and it turns out there are a few places where I wasn't initializing this when returning c_expr instances on the stack, and in some cases the

Re: [PATCH 00/16] Unit tests framework (v3)

For some of the simpler infrastructure tests such as the ones in this patch kit (bitmap, vec or wide-int functionality testing and such), we had the idea of putting these into every ENABLE_CHECKING compiler, and run them after building stage1, controlled by a -fself-test flag. It's better to

Re: [patch] fix regrename pass to ensure renamings produce valid insns

On 11/06/2015 08:51 PM, Jeff Law wrote: I think the change is fine for the trunk, though I'm still curious about how the code as-is resulted in a comparison failure. I've been retesting and I think this was a case of something else triggering an random failure - the patch made it go away on

Re: [nvptx] complex vector reductions

On 11/13/2015 04:11 PM, Nathan Sidwell wrote: I noticed that we weren't supporting reductions of complex type, particularly complex double. I've committed this patch to add support for vector reductions. We split the complex type apart and process each half before sticking it back together

Re: [PATCH 0/2] Levenshtein-based suggestions (v3)

On 11/13/2015 04:11 PM, Marek Polacek wrote: Sorry, I changed my mind. Since QUAL_UNION_TYPE is Ada-only thing and we check (RECORD_TYPE || UNION_TYPE) in a lot of places in the C FE, introducing RECORD_OR_UNION_TYPE_P everywhere would unnecessarily slow things down. I don't think so, the

Re: [ptx] partitioning optimization

On 11/13/2015 09:06 PM, Nathan Sidwell wrote: On 11/11/15 09:19, Bernd Schmidt wrote: On 11/11/2015 02:59 PM, Nathan Sidwell wrote: That's not the problem. How to conditionally enable the test is the difficulty. I suspect porting something concerning accel_compiler from the libgomp testsuite

[1/2] i386 ROP mitigation: make more of regrename callable

This just creates a new function in regrename.c, which I need for the 2/2 patch that I'll submit in a moment. Bootstrapped and tested on x86_64-linux. Ok? Bernd * regrename.h (regrename_find_superclass): Declare. (regrename_find_superclass): New function, code moved from ...

Re: [C PATCH] Use RECORD_OR_UNION_TYPE_P macro

On 11/13/2015 07:09 PM, Marek Polacek wrote: As promised & discussed in the thread here: . diffstat shows: c/c-decl.c | 38 +-- c/c-typeck.c | 81

Re: [PATCH, x86] Fix posix_memalign declaration in mm_malloc.h

On 11/13/2015 06:11 PM, Szabolcs Nagy wrote: Followup to https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01433.html The posix_memalign declaration is incompatible with musl libc in C++, because of the exception specification (matters with -std=c++11 -pedantic-errors). It also pollutes the

Re: Automatic openacc loop partitioning

+ this_mask = (this_mask & -this_mask); Unnecessary parens. + if (!this_mask && noisy) + warning_at (loop->loc, 0, + "insufficient partitioning available to parallelize loop"); Should this really be an unconditional warning? Isn't sequential execution a

[2/2] i386 ROP mitigation

This adds a new -mmitigate-rop option to the i386 port. The idea is to mitigate against certain forms of attack called "return oriented programming" that some of our security folks are concerned about. The basic idea is that the stack gets smashed and then, just by chaining function returns

Re: [PATCH 04/N] Fix big memory leak in ix86_valid_target_attribute_p

On 11/12/2015 12:29 PM, Richard Biener wrote: +static bool opts_obstack_initialized = false; + +/* Initialize opts_obstack if not initialized. */ + +void +init_opts_obstack (void) +{ + if (!opts_obstack_initialized) +{ + opts_obstack_initialized = true; + gcc_obstack_init

Re: [PATCH] nvptx: implement automatic storage in custom stacks

I'm proposing the following patch as a step towards resolving the issue with inaccessibility of stack storage (.local memory) in PTX to other threads than the one using that stack. The idea is to have preallocated stacks, and have __nvptx_stacks[] array in shared memory hold current stack

Re: [PATCH] nvptx: implement automatic storage in custom stacks

On 11/12/2015 03:59 PM, Alexander Monakov wrote: On Thu, 12 Nov 2015, Bernd Schmidt wrote: I've run it through make -k check-c regtesting. These are new fails, all mysterious: These would have to be investigated first. Any specific suggestions? The PTX code emitted from GCC differs only

Re: [PATCH] Make disabled-optimization warning more informative; increase default max-gcse-memory

The expanded warning allowed me to see how much memory really was needed to apply gcse to some of my routines, and 128MB fixes my problem. The limit has been 50MB for over 10 years, I think we can up it a bit now. { + unsigned int memory_request = n_basic_blocks_for_fn (cfun) +*

Re: [patch] Fix PR target/67265

On 11/11/2015 12:38 PM, Eric Botcazou wrote: this is an ICE on an asm statement requiring a lot of registers, when compiled in 32-bit mode on x86/Linux with -O -fstack-check -fPIC: pr67265.c:10:3: error: 'asm' operand has impossible constraints The issue is that, since stack checking defines

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On 11/10/2015 10:35 PM, Abe wrote: I wrote: What I'm saying is I don't see a reason for a "definitely always unsafe" state. Why would any access not be made safe if a scratchpad is used? Because the RTL if-converter doesn`t "know" how to convert {everything that can be made safe using a

Re: [ptx] partitioning optimization

On 11/10/2015 11:33 PM, Nathan Sidwell wrote: I've committed this patch to trunk. It implements a partitioning optimization for a loop partitioned over both vector and worker axes. We can elide the inner vector partitioning state propagation, if there are no intervening instructions in the

<    6   7   8   9   10   11   12   13   14   15   >