Re: [v4] avoid alignment of static variables affecting stack's

On 12/11/2015 02:48 PM, Jan Beulich wrote: Function (or more narrow) scope static variables (as well as others not placed on the stack) should also not have any effect on the stack alignment. I noticed the issue first with Linux'es dynamic_pr_debug() construct using an 8-byte aligned

Fix PR21273

Maybe not the most important PR in the database, but we might as well fix and close it. Count the number of alternatives in a MATCH_SCRATCH against the max. Bootstrapped and tested on x86_64-linux (one testcase timed out, almost certainly because another test went heavily into swap at one

Re: [PATCH] update -Wall and -Wextra documentation

On 12/10/2015 05:52 PM, Martin Sebor wrote: The updated patch is attached. Ok. Bernd

Re: [PATCH] testsuite/lib/multline.exp: show test name and line numbers

On 12/10/2015 03:56 PM, David Malcolm wrote: The following patch updates multiline.exp to use the global $testname_with_flags as a prefix in such results. I also dropped the printing of the index in favor of printing the line numbers enclosed within dg-{begin|end}-multiline-output. After

Re: Free up bits in DECLs and TYPEs

On 12/10/2015 04:04 PM, Michael Matz wrote: This isn't stage 3 material really, OTOH fairly low risk. Anyway, okay for trunk now or once stage 1 opens? This is cool and we want it, but not now. Ok for stage 1, with the formatting problems quoted below fixed. Bernd +#define

Re: [PATCH] update -Wall and -Wextra documentation

On 12/10/2015 12:07 AM, Martin Sebor wrote: * invoke.texi (Warning Options): Update -Wall options. Clarify when some -Wextra options are enabled. Add -Wplacement-new example. I tried to check this list against c.opt - I figure this should contain essentially the ones that

Re: Splitting up gcc/omp-low.c?

On 12/10/2015 09:08 AM, Jakub Jelinek wrote: On Wed, Dec 09, 2015 at 06:23:22PM +0100, Bernd Schmidt wrote: On 12/09/2015 05:24 PM, Thomas Schwinge wrote: In addition to that, how about we split up gcc/omp-low.c into several files? Would it make sense (I have not yet looked in detail) to do

Re: [PATCH v4] Fix shrink-wrapping bug (PR67778, PR68634)

On 12/09/2015 09:47 PM, Segher Boessenkool wrote: After shrink-wrapping has found the "tightest fit" for where to place the prologue, it tries move it earlier (so that frame saves are run earlier) -- but without copying any more basic blocks. Unfortunately a candidate block we select can be

Re: [v3] avoid alignment of static variables affecting stack's

On 12/10/2015 05:07 PM, Jan Beulich wrote: If not reaching if (TREE_CODE (origvar) == SSA_NAME) { gcc_assert (TREE_CODE (var) != VAR_DECL || (!DECL_EXTERNAL (var) && !DECL_HAS_VALUE_EXPR_P (var) && !TREE_STATIC (var)

Re: [v3] avoid alignment of static variables affecting stack's

On 12/10/2015 01:38 PM, Jan Beulich wrote: * cfgexpand.c (expand_one_var): Exclude static and external variables when adjusting stack alignment related state. gcc/testsuite/ 2015-12-10 Jan Beulich * gcc.c-torture/execute/stkalign.c: New. ---

Re: [PATCH] Fix up noce_try_abs again (PR rtl-optimization/68670)

On 12/09/2015 11:37 PM, Jakub Jelinek wrote: Not sure what I've been thinking when writing the previous noce_try_abs fix. I thought that the optimization can be applied for all the conditions, and whether it can be applied depends on if it is cond ? ~x : x or cond ? x : ~x. But that is not the

Re: [PATCH][combine] Don't create LSHIFTRT of zero bits in change_zero_ext

On 12/10/2015 03:36 PM, Kyrill Tkachov wrote: I'm okay with delaying this for next stage 1 if people prefer, though I think it's pretty low risk. I think this is something we should fix now. + x = XEXP (x, 0); + if (start > 0) + x = gen_rtx_LSHIFTRT (mode, x,

Re: [PATCH] Make basic asm implicitly clobber memory, pr24414

On 12/09/2015 03:18 AM, Bernd Edlinger wrote: Furthermore there is a documented use for asm(""): The empty assembler string is used to make a function volatile, thus calls can not be optimized away. But I think it is not necessary to make this clobber anything, nor should it be an instruction

Re: [PATCH] GCC-5 backport of PR lto/65948

On 12/09/2015 12:50 PM, Martin Liška wrote: I would like to backport forgotten patch to GCC-5 branch. Bootstrap and regression tests have been running, ready after it finishes? Ok. Bernd

Re: [Patch,rtl Optimization]: Better register pressure estimate for Loop Invariant Code Motion.

On 12/09/2015 12:22 PM, Ajit Kumar Agarwal wrote: This is because the available_regs = 6 and the regs_needed = 1 and new_regs = 0 and the regs_used = 10. As the reg_used that are based on the Liveness given above is greater than the available_regs, then > it's candidate of spill and the

Re: [PATCH] Add levels to -Wmisleading-indentation; add level 1 to -Wall

On 12/09/2015 04:38 PM, David Malcolm wrote: +/* The following function contains examples of bad indentation that's + arguably not misleading, due to a blank line between the guarded and the + non-guarded code. Some of the blank lines deliberately contain + redundant whitespace, to verify

Re: [PATCH] Make basic asm implicitly clobber memory, pr24414

On 12/09/2015 04:09 PM, Bernd Edlinger wrote: So would you agree on the general direction of the patch, if I drop the hunk in sched-deps.c ? I'm not sure there was any consensus in that other thread, but I think assuming that basic asms clobber memory and CC, can be justified. That

Re: Splitting up gcc/omp-low.c?

On 12/09/2015 05:24 PM, Thomas Schwinge wrote: In addition to that, how about we split up gcc/omp-low.c into several files? Would it make sense (I have not yet looked in detail) to do so along the borders of the several passes defined therein? Or, can you tell already that there would be too

Re: [PATCH] Better error recovery for merge-conflict markers (v4)

On 12/09/2015 05:58 PM, David Malcolm wrote: On Wed, 2015-11-04 at 14:56 +0100, Bernd Schmidt wrote: This seems like fairly low impact but also low cost, so I'm fine with it in principle. I wonder whether the length of the marker is the same across all versions of patch (and VC tools)? It's

Re: [PATCH] Add levels to -Wmisleading-indentation; add level 1 to -Wall

On 12/09/2015 05:49 PM, David Malcolm wrote: +void +fn_40_implicit_level_1 (int arg) +{ +if (flagA) + foo (0); + + foo (1); + The distinction I want to make here is between badly indented code vs misleadingly indented code. Yes, the code is badly indented, but to my eyes the code is

Re: [PATCH] Add testcase for c++/68116

On 12/07/2015 06:49 PM, Marek Polacek wrote: diff --git gcc/testsuite/g++.dg/cpp0x/pr68116.C gcc/testsuite/g++.dg/cpp0x/pr68116.C index e69de29..04ed901 100644 --- gcc/testsuite/g++.dg/cpp0x/pr68116.C +++ gcc/testsuite/g++.dg/cpp0x/pr68116.C @@ -0,0 +1,12 @@ +// PR c++/68116 +// { dg-do

Re: [PATCH 9/N] Fix memory leak tree-if-conv.c

On 12/08/2015 12:32 PM, Martin Liška wrote: Simple memory leak fix. Patch can bootstrap and survives regression tests on x86_64-unknown-linux-gnu. This one is OK. For the larger one I'm not sure whether we shouldn't be saying no around this point and wait until stage 1 (unless we have

Re: [PATCH] Fix Changelog entry and add pr66896.C

On 12/07/2015 04:05 PM, Martin Liška wrote: As Jakub pointed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896#c15, I forgot to add a test-case to both GCC-5-branch and trunk. May I please installed the suggested patch to both these branches? Sure. Bernd

Re: [PATCH] Fix -Werror= handling for Joined warnings, add a few missing Warning keywords (PRs c/48088, c/68657)

On 12/07/2015 11:41 PM, Jakub Jelinek wrote: On Mon, Dec 07, 2015 at 04:11:48PM +0100, Bernd Schmidt wrote: Let's document arguments; for the ones identical to read_cmdline_option an explicit pointer there is sufficient, but errors is new. This also needs an update to the function comment

Re: [PATCH v3] Fix shrink-wrapping bug (PR67778, PR68634)

On 12/08/2015 01:40 AM, Segher Boessenkool wrote: - if (can_get_prologue (pro, prologue_clobbered)) - last_ok = pro; } Where did that test go? Bernd

Re: [PATCH] Add testcase for c++/68116

On 12/08/2015 03:21 PM, Marek Polacek wrote: +C::T C::b[] +{ + T (::foo) +}; The problem I have with approving C++ testcases is that I have no idea whether this is valid or not or what it expresses. You should Cc Jason (which I've now done). That's odd code--I don't approve of the cast in

Re: [PATCH,RFC] Introduce RUN_UNDER_VALGRIND in test-suite

On 12/08/2015 04:28 PM, Martin Liška wrote: Majority of them (~2600 BTs) are in fortran FE (BT contains 'gfc_'): [2]. The rest contains some issues in CP FE, many GGC invalid read/write operations ([4]) and many memory leaks in gcc.c (for instance option handling). My question is if a bug

Re: [PATCH 1/2] PR c/68757: fix uninitialied src_range for various builtins

On 12/08/2015 05:02 PM, David Malcolm wrote: I actually implemented something like this when implementing these two patches. Work-in-progress patch attached, which introduces an INVALID_LOCATION value for source_location/location_t, and uses it to "poison" the initial value of c_expr's

Re: [PATCH 1/2] PR c/68757: fix uninitialied src_range for various builtins

On 12/08/2015 04:43 PM, David Malcolm wrote: This fixes various uninitialized src_range of c_expr, this time in the various builtins that are parsed via c_parser_get_builtin_args. Bootstrapped on x86_64-pc-linux-gnu. OK for trunk? I think both of these patches are OK. Some questions though.

Re: [patch] Fix PR middle-end/68291 & 68292

On 12/08/2015 11:50 AM, Eric Botcazou wrote: I'm going to test it on x86-64, SPARC64 and Aarch64. PR middle-end/68291 PR middle-end/68292 * cfgexpand.c (set_rtl): Always accept mode mismatch for SSA names with BLKmode promoted mode based on RESULT_DECLs. I

Re: [PATCH] Fix -Werror= handling for Joined warnings, add a few missing Warning keywords (PRs c/48088, c/68657)

On 12/07/2015 02:44 PM, Jakub Jelinek wrote: So like this? +/* Perform diagnostics for read_cmdline_option and control_warning_option + functions. Returns true if an error has been diagnosed. */ Let's document arguments; for the ones identical to read_cmdline_option an explicit

Re: [PTX] no return fns

On 12/07/2015 06:03 PM, Nathan Sidwell wrote: On 12/07/15 11:18, Nathan Sidwell wrote: calls to no return fns can cause problems with the PTX JIT. It doesn't understand their no-return nature and can erroneously think there are unexitable loops (depending on the precise placement of bbs). It

Re: [PTX] no return fns

On 12/07/2015 06:34 PM, Nathan Sidwell wrote: Aren't noreturn fns required to be void? It certainly doesn't make sense for them to do otherwise. The documentation says "it makes no sense" for them to have a type other than void, but I don't think that translates into a requirement. I

Re: [patch] Fix PR middle-end/68291 & 68292

On 12/07/2015 10:35 AM, Eric Botcazou wrote: As discussed with Alexandre in the audit trail, the attached minimal fix just prevents the problematic BLKmode REG from being generated, which appears to be sufficient to restore the nominal operating mode. PR middle-end/68291 PR

Re: [PATCH] Fix -Werror= handling for Joined warnings, add a few missing Warning keywords (PRs c/48088, c/68657)

On 12/04/2015 08:36 PM, Jakub Jelinek wrote: On Fri, Dec 04, 2015 at 06:19:19PM +, Manuel López-Ibáñez wrote: My guess is that the first error_at should use arg instead of option->opt_text to be equivalent. Of course, ideally, this code would not be duplicated, but rather merged "somehow".

Re: [PATCH] Fix missing range information for "%q+D" format code

On 12/04/2015 10:09 PM, David Malcolm wrote: Updated patch to comment attached, which rewrites things to clarify the meaning of SHOW_CARET_P. I guess this is OK for now. I think I'll go play with the Fortran frontend a bit to see what exactly is going on with its use of set_range there, I

Re: [Patch] Fix bug for frame instructions in annulled delay slots

On 12/07/2015 07:54 PM, Steve Ellcey wrote: if (must_annul) - used_annul = 1; + { + /* Frame related instructions cannot go into annulled delay +slots, it messes up the dwarf info. */ + if (RTX_FRAME_RELATED_P (trial)) +

Re: [Patch] Fix bug for frame instructions in annulled delay slots

On 12/07/2015 08:43 PM, Steve Ellcey wrote: I am not sure about this. There is an earlier if statement in the loop that does a 'return' instead of a break (or continue) and there is a return in the 'else' part of the if that sets must_annul. Both of these are inside the loop that looks at all

Re: [PATCH] Fix missing range information for "%q+D" format code

On 12/03/2015 09:33 PM, David Malcolm wrote: The attached patch updates the handling of %q+D, simplifying the implementation, and ensuring that it retains the range information of the decl, giving: diagnostic-ranges-1.c:6:7: warning: unused variable ‘redundant’ [-Wunused-variable] int

Re: Ping [PATCH] c++/42121 - diagnose invalid flexible array members

> The patch should bring C++ support for flexible array members closer > to C (most of the same constructs should be accepted and rejected). > The only C change in this patch is to include the size of excessively > large types in diagnostics (I found knowing the size helpful when > adding tests

Re: [PATCH] Use explicit UNKNOWN_LOCATION instead of input_location (which is line 1) for process_options diagnostics (PR c/68656)

On 12/04/2015 05:45 PM, Jakub Jelinek wrote: This patch fixes it to use explicit UNKNOWN_LOCATION, instead of explicit or implicit input_location, which for most of process_options is somewhere on line 1 of the main source file. Ok. Bernd

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

On 12/04/2015 04:18 PM, Andre Vieira wrote: Reworked following Joern's suggestion. Is this OK? Yes. Bernd

Re: [PATCH] Fix -Werror= handling for Joined warnings, add a few missing Warning keywords (PRs c/48088, c/68657)

I think marking stuff with Warning as appropriate qualifies as obvious. On 12/04/2015 05:37 PM, Jakub Jelinek wrote: + /* If the switch takes an integer, convert it. */ + if (arg && cl_options[opt_index].cl_uinteger) + { + value = integral_argument (arg);

Re: [PATCH] Fix shrink-wrap bug with anticipating into loops (PR67778, PR68634)

On 12/02/2015 07:21 PM, Segher Boessenkool wrote: After shrink-wrapping has found the "tightest fit" for where to place the prologue, it tries move it earlier (so that frame saves are run earlier) -- but without copying any more basic blocks. Unfortunately a candidate block we select can be

Re: [PATCH] Fix shrink-wrap bug with anticipating into loops (PR67778, PR68634)

On 12/02/2015 07:21 PM, Segher Boessenkool wrote: After shrink-wrapping has found the "tightest fit" for where to place the prologue, it tries move it earlier (so that frame saves are run earlier) -- but without copying any more basic blocks. Another question would be - is there really a good

Re: Add fuzzing coverage support

On 12/02/2015 06:38 PM, Dmitry Vyukov wrote: One thing to consider would be whether you really need this split between O0/optimize versions, or whether you can find a place in the queue where to insert it unconditionally. Have you considered this at all or did you just follow asan/tsan? I

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68624: Clean up logic that checks for clobbering conflicts across basic blocks

On 12/03/2015 10:33 AM, Kyrill Tkachov wrote: PR rtl-optimization/68624 * ifcvt.c (noce_try_cmove_arith): Check clobbers of temp regs in both blocks if they exist and simplify the logic choosing the order to emit them in. 2015-12-03 Kyrylo Tkachov

Re: Documentation tweaks for internal-fn-related optabs

On 12/03/2015 02:06 PM, Richard Sandiford wrote: As Bernd requested, this patch adds "This pattern cannot FAIL" to the documentation of optabs that came to be mapped to interal functions. For consistency I did the same for optabs that were already being used for internal functions. Many of the

Re: [PATCH,RFC] Introduce RUN_UNDER_VALGRIND in test-suite

On 11/23/2015 10:34 AM, Martin Liška wrote: On 11/21/2015 05:26 AM, Hans-Peter Nilsson wrote: IIRC you can replace the actual dg-runtest proc with your own (implementing a wrapper). Grep aroung, I think we do that already. That's certainly preferable instead of touching all callers. You are

Re: [PTX] simplify movs

On 12/02/2015 04:09 PM, Nathan Sidwell wrote: The PTX md file goes to a lot of effort handling SC and DC movs, including for unspecs to mov low and high parts around. However, these code paths are not exercised in any gcc test or the build of newlib. The generic handling of these movs deals

Re: Add fuzzing coverage support

On 12/02/2015 05:55 PM, Dmitry Vyukov wrote: Can you point to some concrete coding style violations (besides function comments)? (flag_sanitize & (SANITIZE_ADDRESS | SANITIZE_THREAD \ - | SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT))) +

Re: Add fuzzing coverage support

On 12/02/2015 05:10 PM, Dmitry Vyukov wrote: ping I do not see the original submission in my archives. This one comes too late to make it into gcc-6. I can make some initial comments. This patch adds support for coverage-guided fuzzing: https://codereview.appspot.com/280140043 Please

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

On 12/02/2015 08:05 PM, Jeff Law wrote: On 11/27/2015 07:09 AM, Dominik Vogt wrote: New patch with the following changes: * Fixed comment about dynamic var area placement. * The area is now placed further away from the stack pointer than the non-dynamic stack variables (tested only with

Re: [gomp-nvptx 1/9] nvptx backend: allow emitting COND_EXEC insns

On 12/01/2015 04:28 PM, Alexander Monakov wrote: This allows to use COND_EXEC patterns on nvptx. The backend is mostly ready for that, although I had to slightly fix nvptx_print_operand. I've also opted to make calls predicable to make the uniform-simt patch simpler, and to that end I need a

Re: [gomp-nvptx 2/9] nvptx backend: new "uniform SIMT" codegen variant

On 12/02/2015 02:46 PM, Jakub Jelinek wrote: Or does the OpenACC execution model not allow anything like that, i.e. have some function with an automatic variable pass the address of that variable to some other function and that other function use #acc loop kind that expects the caller to be at

Re: PR 68432: Add a target hook to control size/speed optab choices

On 12/01/2015 10:15 PM, Richard Sandiford wrote: [This is a less invasive fix for the PR, without any changes to the .md attribute handling] As a minimal fix I like this much better. I'll ok it under the condition that you have verified in all ports that size/speed issues are the only

Re: RFD: annotate iterator patterns with expanded forms

On 12/01/2015 04:31 PM, Bernd Schmidt wrote: On 12/01/2015 04:23 PM, Jakub Jelinek wrote: With the comments in the *.md file I'd worry about them getting out of date, or people feeling they have to edit them manually (rather than being regenerated or whatever). I suppose we could have

Re: [gomp-nvptx 6/9] nvptx libgcc: rewrite in C

What exactly is the problem with having asm files? I'm asking because this... On 12/01/2015 04:28 PM, Alexander Monakov wrote: +/* __shared__ char *__nvptx_stacks[32]; */ +asm ("// BEGIN GLOBAL VAR DEF: __nvptx_stacks"); +asm (".visible .shared .u64 __nvptx_stacks[32];"); + +/* __shared__

RFD: annotate iterator patterns with expanded forms

One problem I have whenever I try to edit i386.md is that I can't find the patterns I'm looking for. Let's say I'm looking for lshrsi3, but there's no pattern by this name, what I'm looking for is "3". Even worse are things like "*xordi_2", which has just "*_2" and can't reasonably be searched

Re: RFD: annotate iterator patterns with expanded forms

On 12/01/2015 04:23 PM, Jakub Jelinek wrote: On Tue, Dec 01, 2015 at 04:14:21PM +0100, Bernd Schmidt wrote: One problem I have whenever I try to edit i386.md is that I can't find the patterns I'm looking for. Let's say I'm looking for lshrsi3, but there's no pattern by this name, what I'm

Re: [gomp-nvptx 8/9] libgomp: update gomp_nvptx_main for -mgomp

On 12/01/2015 04:28 PM, Alexander Monakov wrote: Bernd, is your position on exposing shared memory as first-class address space on NVPTX subject to change? Do you remember what middle-end issues you've encountered when trying that? TYPE_ADDR_SPACE does not reliably contain the address space.

Re: [gomp-nvptx 2/9] nvptx backend: new "uniform SIMT" codegen variant

On 12/01/2015 04:28 PM, Alexander Monakov wrote: I'm taking a different approach. I want to execute all insns in all warp members, while ensuring that effect (on global and local state) is that same as if any single thread was executing that instruction. Most instructions automatically satisfy

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

On 11/26/2015 05:22 PM, Richard Sandiford wrote: Bernd Schmidt <bschm...@redhat.com> writes: I wish we'd taken some more time to think through the consequences of the original internal_fn patchset. I don't think this PR shows that the approach was wrong. I think it does. Internal fun

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

On 12/01/2015 01:16 PM, Richard Biener wrote: On Tue, Dec 1, 2015 at 12:54 PM, Bernd Schmidt <bschm...@redhat.com> wrote: On 11/26/2015 05:22 PM, Richard Sandiford wrote: Bernd Schmidt <bschm...@redhat.com> writes: I wish we'd taken some more time to think through the

Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk

On 12/01/2015 06:31 AM, Gary Funck wrote: At this time, we would like to re-submit the UPC patches for comment with the goal of introducing these changes into GCC 6.0. This has missed stage 1 by a few weeks, we'd have to make an exception to include it at this late stage. @@ -857,9 +875,14

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

On 12/01/2015 02:43 PM, Richard Sandiford wrote: I don't think what you say is an argument that the approach is wrong. The C conditions for optabs have always been more restricted than other define_expands and define_insns, since they cannot refer to operands. When caching of optabs was added,

Re: Solaris vtv port breaks x32 build

(add gcc-patches) On 12/01/2015 08:39 AM, Matthias Klose wrote: On 01.12.2015 03:58, Ulrich Drepper wrote: On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote: Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test? The problem macro is _AC_COMPILER_EXEEXT_WORKS.

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

On 11/27/2015 10:02 AM, Bernd Schmidt wrote: 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

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

On 11/29/2015 08:32 PM, Andreas Tobler wrote: Hi all, the attached patch prepares the testsuite, c and c++, for the upcoming ASAN support for FreeBSD (x86_64 first). I tested the patch on CentOS7.1 x86_64 and on FreeBSD x86_64. Results can be seen on the list. Is this ok for trunk? -/* {

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

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