Re: Wonly-top-basic-asm

On 01/24/2016 11:23 PM, David Wohlferd wrote: +Wonly-top-basic-asm +C ObjC ObjC++ C++ Var(warn_only_top_basic_asm) Warning +Warn on unsafe uses of basic asm. Maybe just -Wbasic-asm? +/* Warn on basic asm used inside of functions, + EXCEPT when in naked functions. Also allow

Re: Patch RFA: Add option -fcollectible-pointers, use it in ivopts

On 01/22/2016 08:03 PM, Ian Lance Taylor wrote: Updated patch. I've verified that I'm changing the only relevant place in tree-ssa-loop-ivopts.c that creates a POINTER_PLUS_EXPR, so I do think that this is the only changed to fix the problem for ivopts. I don't think so. One of the problems

Re: Suspicious code in fold-const.c

On 01/22/2016 02:37 PM, Andrew MacLeod wrote: /* If the initializer is non-void, then it's a normal expression that will be assigned to the slot. */ (*) if (!VOID_TYPE_P (t)) (*) return RECURSE (t); I suspect this should also be if

Re: [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"

On 01/22/2016 02:25 PM, Jakub Jelinek wrote: What about #pragma oacc parallel? That would never do that? It shouldn't, no (IMO). Bernd

Re: [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"

On 01/22/2016 09:36 AM, Jakub Jelinek wrote: I think it is a bad idea to go against what the user wrote. Warning that some code might not be efficient? Perhaps (if properly guarded with some warning option one can turn off, either on a per-source file or using pragmas even more fine grained).

Re: [PATCH][ARM][4/4] Adjust gcc.target/arm/wmul-[123].c tests

On 01/22/2016 10:52 AM, Kyrill Tkachov wrote: AFAICT the new sequence is better than the old one even for -mtune=cortex-a9 since it contains two fewer instructions. Just curious (I think this patch series is good but will leave it to the arm folks) - are these instructions equally expensive?

Re: gomp_target_fini

Thomas, I've mentioned this issue before - there is sometimes just too much irrelevant stuff to wade through in your patch submissions, and it discourages review. The discussion of the actual problem begins more than halfway through your multi-page mail. Please try to be more concise. On

Re: [PATCH] OpenACC use_device clause ICE fix

On 01/21/2016 03:22 PM, Chung-Lin Tang wrote: On 2016/1/20 09:17 PM, Bernd Schmidt wrote: On 01/05/2016 02:15 PM, Chung-Lin Tang wrote: * omp-low.c (scan_sharing_clauses): Call add_local_decl() for use_device/use_device_ptr variables. It looks vaguely plausible, but if everything

Backport PR63681 cfglayout/doloop fix to 4.9

I've bootstrapped and tested the following on 4.9-branch. It's a backport of a patch that avoids unnecessary assertion failures, both by tuning down an assert, and restricting an optimization for the case where the assert would validly trigger. Ok to commit on the branch? Bernd PR

Re: [patch] Document restriction of scalar_storage_order

On 01/21/2016 05:34 PM, Eric Botcazou wrote: Tested on x86_64-suse-linux, OK for the mainline? 2016-01-21 Eric Botcazou * doc/extend.texi (scalar_storage_order type attribute): Document restriction on type punning and aliasing. Isn't this kind of

Re: [PATCH] gcc/configure test for AIX DWARF

On 01/18/2016 08:30 PM, David Edelsohn wrote: Bootstrapped on powerpc-ibm-aix7.1.2.0 with and without the corrected assembler. Okay? The changes seem to be in *-*-aix blocks, so as far as I'm concerned you are the maintainer and can check this in. One question though: ;; esac

Re: [PATCH v2] PR48344: Fix unrecognizable insn error when gcc

On 01/20/2016 10:49 PM, Kelvin Nilsen wrote: * toplev.c (do_compile): remove invocation of process_options () from within do_compile () (toplev::main): insert invocation of process_options () before invocation of handle_common_deferred_options (). The ChangeLog

Re: [PATCH] OpenACC use_device clause ICE fix

On 01/05/2016 02:15 PM, Chung-Lin Tang wrote: * omp-low.c (scan_sharing_clauses): Call add_local_decl() for use_device/use_device_ptr variables. It looks vaguely plausible, but if everything is part of the host function, why make a copy of the decl at all? I.e. what happens if

Fixes for PR66178

PR66178 has some testcases where we construct expressions involving additions and subtractions of label addresses, and we crash when trying to expand these. There are two different issues here, shown by various testcases in the PR: * expand_expr_real_2 can drop EXPAND_INITIALIZER and then go

Re: genattrab.c generate switch

On 01/18/2016 11:44 PM, Jesper Broge Jørgensen wrote: I found a formatting tool called uncrustify that comes with a gnu style config https://github.com/bengardner/uncrustify/blob/master/etc/gnu-indent.cfg that needed a few tweaks to format code that looked what is already in gcc/genattrtab.c

Re: [PATCH] Fix debug info handling in prepare_shrink_wrap (PR debug/65779)

On 01/19/2016 12:33 AM, Jakub Jelinek wrote: + if (MAY_HAVE_DEBUG_INSNS) +{ + for (dinsn = BB_END (bb); dinsn != insn; dinsn = PREV_INSN (dinsn)) + if (DEBUG_INSN_P (dinsn)) + { + df_ref use; + FOR_EACH_INSN_USE (use, dinsn) + if

Re: [PATCH] Fix debug info handling in prepare_shrink_wrap (PR debug/65779)

On 01/19/2016 02:08 PM, Jakub Jelinek wrote: On Tue, Jan 19, 2016 at 01:27:32PM +0100, Bernd Schmidt wrote: Is there a way to merge these two blocks (e.g. by moving this to the start of the loop and testing for insn or BB_HEAD)? Sure, like this? That's ok. I'm assuming you know best how

Re: Do not redirect calls to cxa_pure_virtual into bultin_unreachable in some cases

On 01/19/2016 05:50 PM, Jan Hubicka wrote: +static bool +is_cxa_pure_virtual_p (tree target) +{ + return target && TREE_CODE (TREE_TYPE (target)) != METHOD_TYPE +&& DECL_NAME (target) +&& !strcmp (IDENTIFIER_POINTER (DECL_NAME (target)), +

Re: [PATCH 1/9] gensupport: Fix define_subst operand renumbering.

On 01/14/2016 05:33 PM, Andreas Krebbel wrote: When processing substitutions the operands are renumbered. To find a free operand number the array used_operands_numbers is used to record the operand numbers already in use. Currently this array is used to assign new numbers *before* all the

Re: genattrab.c generate switch

On 01/13/2016 01:53 AM, Jesper Broge Jørgensen wrote: genattrab.c can generate if statements that have very deep bracket nesting causing clang to produce errors (when target=arm-none-eabi) as explained at https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html At the above link it was suggested that

Re: [PATCH] PR testsuite/69181: ensure expected multiline outputs is cleared per-test (v2)

So we do need error cleanup for both blocks (A) and (B). gcc/testsuite/ChangeLog: PR testsuite/69181 * gcc.dg/pr69181-1.c: New test file. * gcc.dg/pr69181-2.c: New test file. * lib/gcc-dg.exp (dg-test): Consolidate post-test cleanup of globals by moving

IRA fix for 47992

This is a report of a crash in IRA. If you debug it with a sufficiently old compiler, you'll find that we manage to delete some basic blocks from within IRA. Later on, reload calls alter_reg for all unallocated pseudos, including one that only occurs in the deleted blocks. reload does not

Re: PR 69246: Invalid REG_ARGS_SIZE for sibcalls

On 01/15/2016 03:31 PM, Richard Sandiford wrote: The problem in this PR was that we were treating a sibcall as popping arguments, leading to a negative REG_ARGS_SIZE. It doesn't really make sense to treat sibcalls as popping since (a) they're deallocating the caller's stack, not ours, and (b)

Thoughts on memcmp expansion (PR43052)

PR43052 is a PR complaining about how the rep cmpsb expansion that gcc uses for memcmp is slower than the library function. As is so often the case, if you investigate a bit, you can find a lot of issues with the current situation in the compiler. This PR was accidentally fixed by a patch by

Re: Optimise hash_table::empty

On 01/15/2016 07:00 PM, Richard Sandiford wrote: Calling redirect_edge_var_map_empty after each pass was slowing things down because hash_table::empty () cleared all slots even if the hash table was already empty. Tested on x86_64-linux-gnu, where it gives a 1% compile time improvement for

Re: [PATCH] Avoid simplifying RTL expressions in too large integral modes (PR target/68269)

On 01/14/2016 03:31 PM, Jakub Jelinek wrote: PR target/68269 * combine.c (expand_field_assignment): Punt if compute_mode is unsupported scalar mode. Ok. Bernd

Re: [Patch ifcvt] Add a new parameter to limit if-conversion

PR rtl-optimization/68920 * ifcvt.c (cond_move_process_if_block): Limit number of conditional moves. Ok. This should probably be consolidated a bit post 6.0. Bernd

Re: [PATCH] PR other/69006: fix extra newlines after diagnostics

On 01/13/2016 01:57 AM, David Malcolm wrote: There are five places in trunk that can call diagnostic_show_locus. I'd kind of like to see before/after example output for all of these, to make sure that we are indeed removing only unnecessary newlines. The final caller of

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

On 01/12/2016 08:55 AM, Thomas Preud'homme wrote: On Monday, January 11, 2016 04:57:18 PM Bernd Schmidt wrote: On 01/08/2016 10:33 AM, Thomas Preud'homme wrote: 2016-01-08 Thomas Preud'homme <thomas.preudho...@arm.com> * g++.dg/pr67989.C: Remove ARM-specific

Re: [patch] libsanitizer

On 01/11/2016 07:37 PM, Andreas Tobler wrote: +# Do a configure time check for -ldl +AC_CHECK_LIB(dl, dlsym, + [link_sanitizer_common="-lrt $link_sanitizer_common"]) + I'll give it a test run. If that works (with -ldl instead of -lrt) it's ok. Bernd

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175, take 2)

On 01/12/2016 11:17 AM, Jakub Jelinek wrote: PR target/69175 * ifcvt.c (cond_exec_process_if_block): When removing the last insn from then_bb, remove also any possible barriers that follow it. * g++.dg/opt/pr69175.C: New test. Ok. Bernd

Re: [Patch ifcvt] Add a new parameter to limit if-conversion

On 01/12/2016 04:41 PM, Yuri Rumyantsev wrote: Here is a simple fix to exclude dg/ifcvt-5.c test from ia64 testing. Is it OK for trunk? Please ensure patches are attached as plain text so that reviewers don't have to save them to be able to read them. It looks like ia64 is making chanes in

Re: prevent "undef var" errors on gcc --help or --version

On 01/12/2016 05:11 PM, Olivier Hainque wrote: + /* Decide if undefined variable references are allowed in specs. */ + { +/* --version and --help alone or together are safe. Note that -v would + make them unsafe, as they'd then be run for subprocesses as well, the +

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

Ok, this works too. Here is a version that adds orig_x to the if_info struct and passes it down to bbs_ok_for_cmove_arith. This passes bootstrap and test on arm, aarch64, x86_64. I think this is ok. Bernd

Re: [gomp4] teach the lto driver to error for missing decls

On 01/08/2016 11:37 PM, Cesar Philippidis wrote: In openacc there are situations where a user may fail to mark a variable or function as offloadable (either using declare or routine). This patch makes the lto wrapper reduce the missing decl assertion to an error. Hmm, it might be good to have

Re: [PATCH] OpenACC documentation for libgomp

On 01/05/2016 04:47 PM, James Norris wrote: I've updated the original patch after some very helpful comments from Sandra (thank you, thank you). OK to commit to trunk? I'm probably not fully qualified to review the contents either, but few people are and it looks reasonable enough that I

Re: [PR tree-optimization/64946] Push integer type conversion to ABS_EXPR argument when possible.

On 01/11/2016 05:33 PM, Matthew Wahab wrote: The case I'm trying to fix has (short)abs((int)short_var). I'd thought that if abs(short_var) was undefined because the result couldn't be represented then the type conversion from int to short would also be undefined. In fact, it's implementation

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

On 12/18/2015 08:05 PM, David Malcolm wrote: On Thu, 2015-12-17 at 19:21 +0100, Bernd Schmidt wrote: 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 Here's an updated version

Re: prevent "undef var" errors on gcc --help or --version

On 01/08/2016 02:23 PM, Olivier Hainque wrote: + /* Undefined variable references in specs are harmless if + we're running for --help or --version alone, or together. */ + spec_undefvar_allowed = +(((print_version || print_help_list) + && decoded_options_count == 2) + || +

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

On 01/08/2016 10:33 AM, Thomas Preud'homme wrote: 2016-01-08 Thomas Preud'homme * g++.dg/pr67989.C: Remove ARM-specific option. * gcc.target/arm/pr67989.C: New file. I checked some other arm tests and they have things like /* { dg-skip-if

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

On 01/05/2016 07:43 PM, Richard Biener wrote: IIRC the logic at some point at least used host CPU detection to select asm. That's undesirable if you want to run binaries on different hosts. Not sure if this is still the case with newer gmp/mpfr, but as long as we allow the ancient ones we

Re: [patch] libsanitizer

On 11/10/2015 11:00 PM, Andreas Tobler wrote: the attached patch removes the hard-coded requirement for the link operation with -ldl. On FreeBSD we do not need that, it breaks compilation. # Common libraries that we need to link against for all sanitizer libs.

Re: C PATCH to rectify warning for character types (PR c/23087)

On 01/07/2016 10:19 PM, Joseph Myers wrote: I don't think it's desirable to raise the warning for this case under different conditions from the warning for other signedness cases. The targets do differ in signedness - it's just that the difference is between "plain" and "signed" or "plain" and

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 09:17 PM, Jakub Jelinek wrote: As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes that are moved by shrink-wrapping in between some basic blocks and later on we end up with a barrier after the notes. From comments above cleanup_barriers pass I think it isnot

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 10:23 PM, Jakub Jelinek wrote: Now, the merge_if_block caller removes the simple_return from the then_bb in preparation of the merge and expects the two bbs to be merged together, I'd be tempted to remove the barrier as well at this point. It does look like the cfgrtl code tries

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 11:05 PM, Bernd Schmidt wrote: On 01/08/2016 10:23 PM, Jakub Jelinek wrote: Now, the merge_if_block caller removes the simple_return from the then_bb in preparation of the merge and expects the two bbs to be merged together, I'd be tempted to remove the barrier as well

Re: [PATCH] PR testsuite/69181: ensure expected multiline outputs is cleared per-test

On 01/09/2016 01:51 AM, David Malcolm wrote: The root cause here is that the logic to reset the list of expected multiline outputs was being run from: handle-multiline-outputs, called by prune.exp's prune_gcc_output and none of that happens if the test is skipped by a target exclusion in

Re: RFA: Fix ICE compiling gcc.dg/lto/pr55113_0.c for x86/x86_64

On 01/08/2016 10:41 AM, Richard Biener wrote: On Tue, Dec 22, 2015 at 10:55 AM, Nick Clifton wrote: Hi Richard, The patch below is a fix for this problem, although I am not sure if it is the correct fix. The patch selects the corresponding SFmode variant of the

Re: [C++ PATCH] Fix ICE with bitfields (PR c++/69164)

On 01/07/2016 10:43 PM, Jakub Jelinek wrote: PR c++/69164 * class.c (layout_class_type): Also copy DEC_SIZE_UNIT, DECL_BIT_FIELD and DEC_BIT_FIELD_TYPE. Any reason this isn't using copy_node? Bernd

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 01/08/2016 02:11 PM, Kyrill Tkachov wrote: How's this? Hmm. Almost there, but... - if (then_bb && else_bb && !a_simple && !b_simple - && (!bbs_ok_for_cmove_arith (then_bb, else_bb) - || !bbs_ok_for_cmove_arith (else_bb, then_bb))) + rtx orig_x = x; + if (then_bb &&

Re: [PATCH] Remove PTX link option

On 01/08/2016 04:44 PM, Jakub Jelinek wrote: And CU_JIT_TARGET / CU_TARGET_COMPUTE_30 requests JITting only on sm_30 and nothing else, or just on sm_30 or later, something else? This really should be reviewed by somebody familiar with CUDA more than myself. I'll defer to Nathan whether to ack

Re: [ping] pending patches

On 01/06/2016 08:15 PM, David Malcolm wrote: [PATCH 1/4] PR c++/62314: add fixit hint for missing "template <> " in explicit specialization: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01933.html [PATCH 2/4] PR c++/62314: add fixit hint for "expected ';' after class definition:

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

On 12/29/2015 10:17 AM, Uros Bizjak wrote: It looks that this new functionality doesn't handle conditional compilation, when /* { dg-do compile { target { ! ia32 } } } */ is added to the testcase, such as in recently changed gcc.target/i386/pr68473-1.c. The directive is passed to the next

Re: Fix PR66208

On 12/16/2015 11:14 PM, Jeff Law wrote: On 12/16/2015 10:13 AM, Bernd Schmidt wrote: 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

Re: [PATCH] Fix #pragma implementation diagnostics (PR c++/69145, take 2)

On 01/07/2016 10:05 AM, Jakub Jelinek wrote: + if (IS_ADHOC_LOC (location)) +{ + location &= MAX_SOURCE_LOCATION; + location + = pfile->line_table->location_adhoc_data_map.data[location].locus; +} This looks like it is get_location_from_adhoc_loc. Bernd

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 01/07/2016 02:45 PM, Kyrill Tkachov wrote: On 07/01/16 11:52, Bernd Schmidt wrote: I looked and this is indeed the case. Still slightly scary. Should the MEM be rtx_equal_p to TO_RENAME? It would be good to test or at least assert this. I tried asserting that and it caused trouble

Re: [PATCH] Fix #pragma implementation diagnostics (PR c++/69145, take 2)

On 01/07/2016 10:36 PM, Jakub Jelinek wrote: I've also bootstrapped/regtested on x86_64-linux and i686-linux following version: 2016-01-07 Jakub Jelinek PR c++/69145 * files.c (cpp_included_before): If IS_ADHOC_LOC (location), lookup real location

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 01/05/2016 03:22 PM, Kyrill Tkachov wrote: This works around the issue but we don't want to do perform the check for pairs of simple basic blocks because then we'll end up rejecting code that does things like: x = cond ? x + 1 : x - 1 i.e. source of the set in both blocks reads and writes

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 12/21/2015 10:23 AM, Kyrill Tkachov wrote: Here is a version integrating the new checks into bbs_ok_for_cmove_arith. We might as well do it there since it already iterates over all the instructions in the basic blocks. The patch looks somewhat complicated and asymmetrical to me. I tried to

Re: [PATCH] Fix -Wmisleading indentation false-positive for do-while statement

On 01/05/2016 10:58 PM, David Malcolm wrote: In general I don't think we can get any useful indentation warning out of a do-while statement, so this patch makes it so that we just skip them. Is this OK to commit after testing? It looks like this is PR c++/69029. FWIW, I agree with your

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

On 01/05/2016 09:44 AM, Bernd Edlinger wrote: an in-tree mpfr build enables inline asm code, which makes the mips-bootstrap fail, because at least mpfr 2.4.2 uses the "=h" constraint but in config/mips/constraints.md we find: "Formerly the @code{hi} register. This constraint is no longer

Re: [PATCH] Fix PR c/69122 (-Wmisleading-indentation false positive with empty macros)

On 01/05/2016 09:43 AM, David Malcolm wrote: gcc/c-family/ChangeLog: PR c/69122 * c-indentation.c (get_visual_column): Remove default argument. (should_warn_for_misleading_indentation): For the multiline case, update call to get_visual_column for next_stmt_exploc

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

On 12/20/2015 05:27 PM, Segher Boessenkool wrote: On Fri, Dec 18, 2015 at 02:19:37AM +0100, Bernd Schmidt wrote: 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

Re: [Patch ifcvt] Add a new parameter to limit if-conversion

On 12/31/2015 10:21 AM, Yuri Rumyantsev wrote: Here is slightly modified patch which limits a number of conditional moves instead of changing conditional branch cost. This is in fact a work-around for very poor cost model which needs to be enhanced to evaluate cost of conditional move that could

Re: cilkplus fails without pthreads for me

On 01/01/2016 07:13 PM, Mike Stump wrote: cilkplus fails without pthreads for me: xg++: error: unrecognized command line option '-pthread' compiler exited with status 1 output is: xg++: error: unrecognized command line option '-pthread' > @@ -1450,6 +1450,10 @@ proc

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 12/18/2015 02:07 PM, Kyrill Tkachov wrote: In this PR we have a THEN and an ELSE block where one uses the condition reg from the preceeding comparison but the other block has an arithmetic operation that clobbers the CC reg. ifcvt emits the latter first and dead code elimination later sees

Re: [PATCH][combine][v2] Canonicalise (r + r) to (r << 1) to aid recognition

On 12/18/2015 03:29 PM, Kyrill Tkachov wrote: Bootstrapped and tested on arm, aarch64, x86_64. As before, there were no codegen differences for SPEC2006 on x86_64. aarch64 SPEC2006 sees the effects described above. I think this is OK. There may be some question as to whether this is a bug

Fix PR67639

In an earlier fix, the following change was made in varasm.c for invalid register variables: --- trunk/gcc/varasm.c 2014/08/26 14:59:59 214525 +++ trunk/gcc/varasm.c 2014/08/26 17:06:31 214526 @@ -1371,6 +1371,11 @@ make_decl_rtl (tree decl) /* As a register variable, it has

Re: libgcc: unwind-ia64.c without malloc/free

On 12/17/2015 12:17 AM, Bernd Edlinger wrote: this is just an idea, how to avoid use of malloc in unwind-ia64.c. [...] What do you think? Not worth worrying about IMO. I think ia64 is dead and best left to rest in maintenance mode. Bernd

Re: [PATCH] Remove unused modified_noreturn_calls

On 12/17/2015 10:59 AM, Richard Biener wrote: +extern void gt_ggc_mx (gimple *&); +extern void gt_pch_nx (gimple *&); + This doesn't occur in the ChangeLog - unrelated change? 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 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,

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