Re: [PATCH][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes

On 12/17/2015 04:36 PM, Kyrill Tkachov wrote: The documentation on RTL canonical forms in md.texi says: "Equality comparisons of a group of bits (usually a single bit) with zero will be written using @code{zero_extract} rather than the equivalent @code{and} or @code{sign_extract}

Re: [PATCH][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes

On 12/17/2015 05:10 PM, Kyrill Tkachov wrote: Well, this patch still produces the QImode comparison if the target has a QImode comparison (the have_insn_for check in the simplify_comparison hunk). Ok, I didn't look that closely because I had doubts about the approach. This kind of check also

Re: [PATCH] PR c++/68795: fix uninitialized close_paren_loc in cp_parser_postfix_expression

On 12/17/2015 07:32 PM, David Malcolm wrote: + if (close_paren_loc) close_paren_loc != UNKNOWN_LOCATION - it's very confusing otherwise. Bernd

Re: [PATCH][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes

On 12/17/2015 06:44 PM, Kyrill Tkachov wrote: Perhaps I had underestimated how involved this issue is :) So if I want to improve the aarch64 situation for GCC 6, would the recommended course of action be to just define the QI and HImode compare against zero patterns? For GCC 6 I think this is

Fix PR66206

This is a small problem found by a static analyzer, a function in bt-load can in theory return the address of a local variable. Bootstrapped and tested on x86_64-linux, ok? Bernd PR rtl-optimization/66206 * bt-load.c (find_btr_use): Change first arg to be a pointer to an rtx. All callers

Re: [PATCH] shrink-wrap: Once more PRs 67778, 68634, and now 68909

On 12/17/2015 10:07 PM, Segher Boessenkool wrote: It turns out v4 wasn't quite complete anyway; so here "v5". If a candidate PRE cannot get the prologue because a block BB is reachable from it, but PRE does not dominate BB, we try again with the dominators of PRE. That "try again" needs to

Re: Fix PR66206

On 12/18/2015 02:15 AM, Andrew Pinski wrote: Except PATTERN (insn) will never be a REG. The only case where the input can be a REG is: gcc_assert (!find_btr_use (src)); Yeah, so we _are_ calling it with a REG. It's a minor issue that won't trigger in practice, but in order to close the PR we

Fix PR66208

This is a relatively straightforward PR where we should mention a macro expansion in a warning message. The patch below implements the suggestion by Marek to pass a location down from build_function_call_vec. Ok if tests pass on x86_64-linux? One question I have is about -Wformat, which is

Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition

On 12/15/2015 05:21 PM, Kyrill Tkachov wrote: Then for the shift pattern in the MD file we'd have to dynamically select the scheduling type depending on whether or not the shift amount is 1 and the costs line up? Yes. This isn't unusual, take a look at i386.md where you have a lot of switches

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

On 12/14/2015 03:31 PM, Dhole wrote: The copyright assignment process is now complete :) Let me know if I'm required to do anything else regarding the patch I sent. Right now we're in a bug fixing stage; please wait until stage 1 reopens and then resend your patch. Bernd

Re: [RFC, rtl optimization]: Better heuristics for estimate_reg_pressure_cost in presence of call for LICM.

On 12/16/2015 12:54 PM, Ajit Kumar Agarwal wrote: The estimate on target_clobbered_registers based on the call_used arrays is not correct. This is the worst case heuristics on the estimate on target_clobbered_registers. This disables many of the loop Invariant code motion opportunities in

Re: [RFC, rtl optimization]: Better heuristics for estimate_reg_pressure_cost in presence of call for LICM.

On 12/16/2015 12:54 PM, Ajit Kumar Agarwal wrote: /* If there is a call in the loop body, the call-clobbered registers are not available for loop invariants. */ + if (call_p) available_regs = available_regs - target_clobbered_regs; - + /* If we have enough registers, we

Re: [PATCH][LTO,ARM] Fix vector TYPE_MODE in streaming-out

On 12/15/2015 04:09 PM, Christian Bruel wrote: in "normal" mode, the TYPE_MODE for vector_type __simd64_int8_t is set to V8QImode by arm_vector_mode_supported_p during the builtins type initializations, thanks to TARGET_NEON set bu the global flag. Now, in LTO mode the streamer writes the

Re: [PATCH] gcc: read -fdebug-prefix-map OLD from environment (improved reproducibility)

On 12/15/2015 03:14 PM, Daniel Kahn Gillmor wrote: On Tue 2015-12-15 07:19:30 -0500, Bernd Schmidt wrote: On 12/11/2015 08:14 PM, Daniel Kahn Gillmor wrote: Here's a one-liner patch for this approach (also at https://gcc.gnu.org/bugzilla/attachment.cgi?id=37007): I think that one-liner

Re: [PATCH] gcc: read -fdebug-prefix-map OLD from environment (improved reproducibility)

On 12/11/2015 08:14 PM, Daniel Kahn Gillmor wrote: I think you mean so that we would just ignore -fdebug-prefix-map entirely when writing DW_AT_producer, so that you could build reproducibly with (for example): gcc -fdebug-prefix-map=$(pwd)=/usr/src We'd considered and discarded this

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

On 12/15/2015 06:20 PM, Wilco Dijkstra wrote: Adding Bernd - would you mind reviewing the ccmp.c change please? Oh sorry, didn't realize there was one in here as well. Looks ok. Bernd

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

On 12/15/2015 08:30 PM, David Malcolm wrote: I got thinking about what we'd have to do to support Perforce-style markers, and began to find my token-matching approach to be a little clunky (in conjunction with reading Martin's observations on c_parser_peek_nth_token). Here's a reimplementation

Re: [PATCH][rtlanal.c] Convert conditional compilation on WORD_REGISTER_OPERATIONS

On 12/15/2015 06:25 PM, Kyrill Tkachov wrote: Bootstrapped and tested on arm, aarch64, x86_64. I'd say let's wait. Some of the changes look misindented btw. Bernd

Re: [PATCH, IA64] Fix building a bare-metal ia64 compiler

On 12/15/2015 10:13 PM, Bernd Edlinger wrote: due to recent discussion on the basic asm, and the special handling of ASM_INPUT in ia64, I tried to build a bare-metal cross-compiler for ia64, but that did not work, because it seems to be impossible to build it without having a stdlib.h.

Re: [PATCH 4/4] Cost CCMP instruction sequences to choose better expand order

On 12/15/2015 06:30 PM, Jiong Wang wrote: You approved this patch at https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01722.html under the condition that AArch64 cost on ccmp instruction should be fixed first. Wilco has fixed the cost issue in this patch set [3/4], and the

Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition

On 12/14/2015 01:25 PM, Kyrill Tkachov wrote: For this PR I want to teach combine to deal with unrecognisable patterns that contain a sub-expression like (x + x) by transforming it into (x << 1) and trying to match the result. This is because some instruction sets like arm and aarch64 can

Re: [PATCH] IRA: Fix % constraint modifier handling on disabled alternatives.

On 12/14/2015 02:05 PM, Andreas Krebbel wrote: the constraint modifier % applies to all the alternatives of a pattern and hence is mostly added to the first constraint of an operand. IRA currently ignores it if the alternative with the % gets disabled by using the `enabled' attribute or if it

Re: C PATCH for c/68907 (bogus warning with _Atomic predecrement)

On 12/15/2015 03:59 PM, Marek Polacek wrote: Here, missing TREE_NO_WARNING on an artificial variable caused bogus -Wunused-value warning. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-12-15 Marek Polacek PR c/68907 * c-typeck.c

Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition

On 12/14/2015 01:25 PM, Kyrill Tkachov wrote: PR 68651 is a code quality regression for GCC 5 and GCC 6 that was introduced due to updated rtx costs for -mcpu=cortex-a53 that affected expansion. The costs changes were correct (to the extent that rtx costs have any meaning) and I think this is a

Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition

On 12/15/2015 03:33 PM, Richard Earnshaw wrote: It's also possible that this would explicitly break some other optimization passes (such as the way in which multiplies are synthesised with shift/add operations). How so? IMO such a change would make cost calculations more accurate and should

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

On 12/14/2015 10:07 AM, Richard Biener wrote: Note that we also record alignment to make sure we can spill to properly aligned stack slots. I don't see why we don't need to do that for used statics/externs. That is are you sure we never need to spill a var of their type? Why would they be

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

On 12/11/2015 07:45 PM, David Malcolm wrote: The third patch in the kit is the earlier workaround for the bug; as before it degrades diagnostic-printing to just print a caret for the awkward cases, rather than attempting to print a range. I'm a little confused now, do the first two patches

Re: [PATCH] Fix -Werror= handling with aliases (PR c/68833)

On 12/11/2015 09:18 PM, Jakub Jelinek wrote: Unfortunately, my patch broke some cases with warning aliases that happened to work (by accident) and left some other warning alias cases broken. This patch attempts to fix that (and add Warning keyword to two warning aliases that didn't have it),

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

On 12/14/2015 03:20 PM, Richard Biener wrote: But there must be a reason statics/externals are expected and handled in all the callers (and the function). At the time this was written (git rev 60d031234), expand_one_var looked very different. It called a subroutine expand_one_static_var

Re: [PATCH] gcc: read -fdebug-prefix-map OLD from environment (improved reproducibility)

On 12/11/2015 05:49 PM, Daniel Kahn Gillmor wrote: I've re-rolled the patch (attached below, here) to use the ENV: prefix instead of the $. It might be irrelevant at this point, but the "ENV:" prefix is used in AmigaOS and could be part of a filename. + if (0 == strncmp(ENV_PREFIX, arg,

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: 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: [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? -/* {

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