Re: [PATCH 12/18] haifa-sched.c: make insn_queue[] a vec

On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote: -/* Remove INSN from queue. */ +/* Remove INSN at idx from queue. */ +static void +queue_remove (unsigned int q, unsigned int idx) +{ + QUEUE_INDEX (insn_queue[q][idx]) = QUEUE_NOWHERE; + insn_queue[q].ordered_remove (idx); +

Re: [PATCH 09/18] make pattern_regs a vec

On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote: -static rtx_expr_list * +static vec extract_mentioned_regs (rtx x) { - rtx_expr_list *mentioned_regs = NULL; + vec mentioned_regs = vNULL; subrtx_var_iterator::array_type array; FOR_EACH_SUBRTX_VAR (iter, array, x, NONCONST)

Re: [PATCH 15/18] make nonlocal_goto_handler_labels a vec

On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote: - remove_node_from_insn_list (insn, _goto_handler_labels); + + unsigned int len = vec_safe_length (nonlocal_goto_handler_labels); + for (unsigned int i = 0; i < len; i++) + if ((*nonlocal_goto_handler_labels)[i] ==

Re: [PATCH 00/18] towards removing rtx_insn_list and rtx_expr_list

On 04/21/2016 01:24 AM, Trevor Saunders wrote: On Wed, Apr 20, 2016 at 06:03:01AM -0700, Andi Kleen wrote: A vector can have very different performance than a list, depending how it is used. Do your patches cause any measure performance difference for the compiler? I haven't measured, but I

Re: [PATCH 07/18] loop-iv.c: make cond_list a vec

On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders + unsigned int len = cond_list.length (); + for (unsigned int i = len - 1; i < len; i--) This is a really icky way to write a loop, the i < len

Re: An abridged "Writing C" for the gcc web pages

On 04/22/2016 09:45 PM, Sandra Loosemore wrote: On 04/22/2016 10:42 AM, paul_kon...@dell.com wrote: Would you expect people to conform to the abridged version or the full standard? If the full standard, then publishing an abridged version is not a good idea, it will just cause confusion.

Re: [PATCH, www] Fix typo in htdocs/develop.html

On 04/21/2016 02:16 PM, Kirill Yukhin wrote: Hello, This looks like a typo to me. GCC 6 Stage 4 (starts 2016-01-20)GCC 5.3 release (2015-12-04) | +-- GCC 5 branch created + | \ v

Re: Allow embedded timestamps by C/C++ macros to be set externally (3)

On 04/18/2016 02:26 PM, Dhole wrote: A few months ago I submited a patch to allow the embedded timestamps by C/C++ macros to be set externally [2], which was already an improvement over [1]. I was told to wait until the GCC 7 stage 1 started to send this patch again. +/* Read

Re: [DOC Patch] Add sample for @cc constraint

On 04/16/2016 01:12 AM, David Wohlferd wrote: There were basically 3 changes I was trying for in that doc patch. Are any of them worth keeping? Or are we done? 1) "Do not clobber flags if they are being used as outputs." 2) Output flags sample (with #if removed). 3) "On the x86 platform,

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

On 04/20/2016 04:57 PM, H.J. Lu wrote: On Wed, Apr 20, 2016 at 7:54 AM, Jakub Jelinek wrote: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html This is wrong, see my other comment on the libgomp patch. See my reply to your reply on the libgomp patch. Since Jakub

Re: [PATCH 01/18] stop using rtx_insn_list in reorg.c

On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote: - rtx_insn_list *merged_insns = 0; + auto_vec merged_insns; I see Jeff has already acked this, but some of the expressions here are getting unwieldy. can we maybe shorten some of this using typedefs? Bernd

Re: IRA costs tweaks, PR 56069

On 03/02/2016 10:53 PM, Vladimir Makarov wrote: The patch is ok for me. But I'd wait for GCC7. People are sensitive to their code performance degradation. Even in most cases the patch improves performance, in some case it can worsen code and people might fill new PRs after such change.

Re: C, C++: New warning for memset without multiply by elt size

On 04/22/2016 03:57 PM, Jason Merrill wrote: This looks good, but can we move the code into c-common rather than duplicate it? That would be this patch. Also passes testing on x86_64-linux. Bernd * doc/invoke.texi (Warning Options): Add -Wmemset-elt-size. (-Wmemset-elt-size): New item.

Re: [PATCH] Fix missed DSE opportunity with operator delete.

On 04/19/2016 10:48 PM, Mikhail Maltsev wrote: On 04/18/2016 12:14 PM, Richard Biener wrote: Enlarging tree_function_decl is bad. Probably using 3 bits for malloc_flag, operator_new_flag and free_flag is redundant. I packed the state into 2 bits. Passes should get at the info via

An abridged "Writing C" for the gcc web pages

(Apologies if you get this twice, the mailing list didn't like the html attachment in the first attempt). We frequently get malformatted patches, and it's been brought to my attention that some people don't even make the effort to read the GNU coding standards before trying to contribute

Re: C, C++: New warning for memset without multiply by elt size

On 04/22/2016 05:31 PM, Jason Merrill wrote: On Fri, Apr 22, 2016 at 11:24 AM, Bernd Schmidt <bernds_...@t-online.de> wrote: On 04/22/2016 03:57 PM, Jason Merrill wrote: This looks good, but can we move the code into c-common rather than duplicate it? Probably not without a fair

Re: C, C++: New warning for memset without multiply by elt size

On 04/22/2016 03:57 PM, Jason Merrill wrote: This looks good, but can we move the code into c-common rather than duplicate it? Probably not without a fair amount of surgery, since the cdw_ and ds_ codes are private to each frontend. Bernd

C, C++: New warning for memset without multiply by elt size

We had this problem in the C frontend until very recently: int array[some_count]; memset (array, 0, some_count); which forgets to multiply by sizeof int. The following patch implements a new warning option for this. Bootstrapped and tested (a while ago, will retest) on x86_64-linux. Ok

C, C++: Fix PR 69733 (bad location for ignored qualifiers warning)

The PR is for a C++ form of the form const double val() const { ... } where the warning location is at the second const (by accident, in reality it's just past the function's declarator), while the first const is the one that we are warning about. This patch adds some logic to the C and C++

Re: Fix some x86 peepholes vs. the red-zone

On 04/15/2016 10:32 AM, Uros Bizjak wrote: This fixes possible wrong code with a tricky failure mode, so OK now. Thanks. [...] While changing this part, it can be rewritten using dg-additional options, e.g.: /* { dg-options "-Os -fomit-frame-pointer -fasynchronous-unwind-tables

Re: Fix for PR70498 in Libiberty Demangler

On 04/13/2016 03:04 PM, Marcel Böhme wrote: Hi Bernd, Shouldn't we check for overflows before performing the +1 addition (i.e. 0 <= num < INT_MAX)? Ideally we'd also have a way to signal from d_number if we had an overflow while parsing that number. Without an overflow signal, d_number will

Re: [PATCH] rtlanal: Fix bits/bytes confusion in set_noop_p (PR68814)

On 04/15/2016 02:35 AM, Segher Boessenkool wrote: This now also shows up on GCC 5, see PR70672. It there happens in the jump1 pass already. Is this okay to backport to 5 and 4.9? Ok. Bernd

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

On 04/14/2016 03:36 PM, Thomas Schwinge wrote: I don't know how meaningful it is to create/discuss/review/commit the following patch until the overall approach has been agreed upon? Why not? We agree the file should be split, and this makes it easier. So I'll approve it for stage1, or

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

On 04/13/2016 07:56 PM, Thomas Schwinge wrote: Best way to present this might be to do diff -du old-omp-low.c . OK, I found Git "-C5%" produce something very similar to that; 0001-Split-up-gcc-omp-low.c-plain.patch.xz attached. That looks much better. However, the //OMPWHATEVER comments are

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

On 04/13/2016 06:01 PM, Thomas Schwinge wrote: The attached 0001-Split-up-gcc-omp-low.c.patch.xz is a Git "--color --word-diff --ignore-space-change" patch, purely meant for manual review; I'm intentionally ;-) not attaching a "patch-applyable" patch at this point, to minimize the risk of other

Re: PATCH for c++/70639 (ICE-on-valid with -Wmisleading-indentation and switch)

On 04/13/2016 06:11 PM, David Malcolm wrote: Your approach encapsulates the logic for rejecting this situation within should_warn_for_misleading_indentation, rather than at the callers, which is arguably better for modularity (similar to how we already call it for "do", which is then always

Re: C/C++ PATCH to add -Wdangling-else option

On 04/13/2016 04:14 PM, Marek Polacek wrote: This patch is meant to be applied on top of the "Wparentheses overhaul" patch. I really think that warning about the dangling else problem isn't appropriate as a part of the -Wparentheses warning, which I think should only deal with stuff like

Re: C PATCH to overhaul warning about dangling else (PR c/70436)

On 04/13/2016 04:14 PM, Marek Polacek wrote: I revamped the warning so that it follows what the C++ FE does (i.e. passing IF_P bools here and there) and it seems to work quite well. I didn't mean to tackle the OMP bits but I bet it would be just a matter of passing IF_P somewhere.

Re: [PATCH] Fix debug ICE on aarch64 due to bad rtl simplification (PR debug/70628)

On 04/12/2016 10:34 PM, Jakub Jelinek wrote: + return temp ? gen_rtx_fmt_ee (GET_CODE (x), to_mode, + temp, XEXP (x, 1)) + : temp; Wrap multi-line expressions in parens. No need for a full retest, just make sure the file still

Re: [PATCH] Fix debug ICE on aarch64 due to bad rtl simplification (PR debug/70628)

On 04/12/2016 10:06 PM, Jakub Jelinek wrote: On Tue, Apr 12, 2016 at 10:02:18PM +0200, Bernd Schmidt wrote: On 04/12/2016 05:10 PM, Jakub Jelinek wrote: This patch arranges for a new argument to convert_memory_address_addr_space_1 and calls it with that new argument set to true, to make sure

Re: [PATCH] Fix debug ICE on aarch64 due to bad rtl simplification (PR debug/70628)

On 04/12/2016 05:10 PM, Jakub Jelinek wrote: This patch arranges for a new argument to convert_memory_address_addr_space_1 and calls it with that new argument set to true, to make sure it never emits instructions or creates pseudos. I think the approach looks sensible, but I don't know if you

Re: [DOC Patch] Add sample for @cc constraint

On 04/12/2016 12:49 AM, David Wohlferd wrote: First draft is attached. It tests all 28 (14 conditions plus 14 inverted). I wasn't sure what to set for optimization (O2? O3? O0?), so I left the default. I've had it in a successful test run, and committed it with a minor tweak

Fix some x86 peepholes vs. the red-zone

With some changes I was working on, I produced a situation where one of the x86 peepholes made an incorrect transformation. In the prologue expansion code, we have /* When using red zone we may start register saving before allocating the stack frame saving one cycle of the prologue.

Followup fix for PR69650

As shown by Roger Orr in the comments of this PR, cpp_get_token can cause a reallocation that invalidates some of the variables in do_linemarker. It seems to occur in this call to linemap_add: /* Allocate the new line_map. However, if the current map only has a single line we

Re: [PATCH] Don't add REG_EQUAL notes in fwprop for paradoxical subregs (PR rtl-optimization/70574)

On 04/08/2016 07:05 PM, Jakub Jelinek wrote: After IRC discussions, I've bootstrapped/regtested following patch that just punts if *loc contains any paradoxical subregs, together with additional statistics gathering that proved that the new testcase is the only spot in which this patch makes a

Re: Fix for PR70498 in Libiberty Demangler

I've been looking through this patch. I had intended to commit it, but after looking through it a little more carefully I think there are a few things left to solve. So, d_number/d_compact_number now return ints rather than longs, which makes sense since the lengths in things like struct

Re: Fix for PR70492

On 04/01/2016 05:03 AM, Marcel Böhme wrote: This fixes the invalid write of size 8 detailed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70492 Handle the special case when consume_count returns -1 due to an integer overflow when parsing the length of the virtual table qualifier in

Re: [PATCH] Don't add REG_EQUAL notes in fwprop for paradoxical subregs (PR rtl-optimization/70574)

On 04/07/2016 11:56 PM, Jakub Jelinek wrote: Not sure if this patch catches everything though, perhaps there could be e.g. (set (reg:SI ...) (plus:SI ((subreg:SI (reg:QI ...) 0) (const_int ...))) and we'd still assign REG_EQUAL note. So maybe instead we should walk the *loc expression and look

Re: [Patch] Fix PR 60040

On 04/07/2016 01:52 PM, Senthil Kumar Selvaraj wrote: The below patch fixes PR 60040 by not halting with a hard error on a spill failure, if reload knows that it has to run again anyway. Some additional information as to how this situation creates a spill failure would be useful. It's

Re: [PATCH] Add security_sensitive attribute to clean function stack and regs.

On 03/22/2016 03:15 PM, Marcos Díaz wrote: the attached patch adds a new attribute 'security_sensitive' for functions. The idea was discussed in PR middle-end/69976. The first question would be: I see several submissions from folks @tallertechnologies.com. Do you and your employer have

Re: [patch] Fix PR target/67172

On 04/04/2016 09:39 AM, Eric Botcazou wrote: The audit trail of the PR is quite confused: __LIBGCC_EH_FRAME_SECTION_NAME__ needs to be (and is correctly) defined during the libgcc build because DWARF2 exceptions are used. The problem is that libgcc2.c expects the usual non-ELF setup, with

Re: Fix for PR70498 in Libiberty Demangler

On 04/02/2016 11:49 AM, Marcel Böhme wrote: Bootstrapped and regression tested on x86_64-pc-linux-gnu. Test cases added + checked PR70498 is resolved. Richard - any objections from an RM perspective to check in such potentially security-related fixes now even if not regressions? The patch

Re: Fix for PR70498 in Libiberty Demangler

On 04/01/2016 07:41 PM, Pedro Alves wrote: On 04/01/2016 11:21 AM, Marcel Böhme wrote: static inline void -d_append_num (struct d_print_info *dpi, long l) +d_append_num (struct d_print_info *dpi, int l) { char buf[25]; sprintf (buf,"%ld", l); Doesn't this warn about %ld format vs

Re: [PATCH] Fix PR70484, RTL DSE using wrong dependence check

On 04/01/2016 11:08 AM, Richard Biener wrote: { ! if (canon_true_dependence (s_info->mem, !GET_MODE (s_info->mem), !s_info->mem_addr, !mem, mem_addr)) {

Re: [PATCH] Fix PR70484, RTL DSE using wrong dependence check

On 04/01/2016 05:05 PM, Jakub Jelinek wrote: with my usual pair of rtl,yes checking bootstraps/regtests (x86_64-linux and i686-linux, former one with ada, latter without), both without your patch and with the patch. Without the patch got 66555 successful replace_reads, with your patch only

Re: [PATCH] Improve CSE (PR rtl-optimization/70467)

On 04/01/2016 04:51 PM, Jakub Jelinek wrote: On Fri, Apr 01, 2016 at 03:35:19PM +0200, Bernd Schmidt wrote: On 04/01/2016 03:14 PM, Jakub Jelinek wrote: As the testcase below shows, we can end up with lots of useless instructions from multi-word arithmetics. simplify-rtx.c can optimize x

Re: Fix for PR70498 in Libiberty Demangler

On 04/01/2016 03:39 PM, Marcel Böhme wrote: Hi Bernd, Thanks for the feedback! Patches need to be bootstrapped and regression tested, and patch submissions should include which target this was done on. Ideally you'd also want to include testcases along with your patches, although I'm not

Re: Proposed Patch for Bug 69687

On 03/31/2016 06:56 AM, Marcel Böhme wrote: Hi Bernd, Are all the places being patched really problematic ones where an input file could realistically cause an overflow, or just the string functions? The loop in demangle_args allows to call the patched register*- and remember*-methods

Re: [PATCH] Improve CSE (PR rtl-optimization/70467)

On 04/01/2016 03:14 PM, Jakub Jelinek wrote: As the testcase below shows, we can end up with lots of useless instructions from multi-word arithmetics. simplify-rtx.c can optimize x {&,|,^}= {0,-1}, but while x &= 0 or x {|,^}= -1 are optimized into constants and CSE can handle those fine, we

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

Cc'ing Matt Thomas who is listed as the vax maintainer; most of the patch should be reviewed by him IMO. If he is no longer active I'd frankly rather deprecate the port rather than invest effort in keeping it running. Index: gcc/except.c

Re: Fix for PR70498 in Libiberty Demangler

On 04/01/2016 12:21 PM, Marcel Böhme wrote: This fixes the write access violation detailed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498 (and a few other unreported cases). Sometimes length-variables for strings and arrays are of type long other times of type int. Since cp-demangle.h

Re: [PATCH 1/2] Fix new -Wparentheses warnings encountered during bootstrap

On 03/31/2016 10:53 PM, Patrick Palka wrote: This patch fixes the new -Wparentheses warnings (implemented by the subsequent patch) that are encountered during bootstrap: /home/patrick/code/gcc/gcc/omp-low.c: In function ‘void scan_sharing_clauses(tree, omp_context*, bool)’:

Re: Fix for PR70481 Libiberty Demangler

On 03/31/2016 07:22 PM, Jeff Law wrote: @@ -1237,11 +1237,13 @@ squangle_mop_up (struct work_stuff *work) Thanks. I've just installed this patch, along with suitable tests from 70481 and 67394. What are the rules for modifying libiberty again? Do we have to patch binutils/gdb at the same

Re: [PATCH] Fix ira.c indirect_jump_optimize (PR rtl-optimization/70460)

On 03/30/2016 11:27 PM, Jakub Jelinek wrote: Hi! As mentioned in the PR, we are miscompiling glibc on i686-linux, because the new indirect_jump_optimize mini-pass thinks that a insn which has REG_LABEL_OPERAND note necessarily has to set the target register to that label, while in the glibc

Re: out of bounds access in insn-automata.c

On 03/25/2016 04:43 AM, Aldy Hernandez wrote: If Bernd is fine with this, I'm happy to retract my patch and any possible followups. I'm just interested in having no path causing a possible out of bounds access. If your patch will do that, I'm cool. I'll need to see that patch first to

Re: [PATCH] Fix num_imm_uses (PR tree-optimization/70405)

On 03/29/2016 07:28 PM, Jeff Law wrote: On 03/29/2016 11:23 AM, Jakub Jelinek wrote: Hi! The recent change to num_imm_uses (to add support for NULL USE_STMT) broke it totally, fortunately we have just one user of this function right now. I've filed a PR for GCC 7 so that we get a warning on

Re: Proposed Patch for Bug 69687

On 03/03/2016 03:55 PM, Marcel Böhme wrote: @@ -4254,7 +4255,9 @@ Please use "diff -p" so that we get information about which function is being patched. Are all the places being patched really problematic ones where an input file could realistically cause an overflow, or just the string

Re: [DOC Patch] Add sample for @cc constraint

On 03/28/2016 12:03 AM, David Wohlferd wrote: On 3/24/2016 8:00 AM, Bernd Schmidt wrote: > More problematic than a lack of documentation is that I haven't been able to find an executable testcase. If you could adapt your example for use in gcc.target/i386, that would be even more import

Re: Goodbye REG_LIVE_LENGTH

On 03/25/2016 11:00 PM, Alan Modra wrote: I'll also prepare a patch to delete REG_LIVE_LENGTH everywhere. Like this. Bootstrapped and regression tested x86_64-linux. OK for stage1? Oh wow that's a lot of stuff removed. Ok for this and the FREQ_CALLS_CROSSED patch. Bernd

Re: [DOC Patch] Add sample for @cc constraint

In principle we probably should have an example, but once again I have some problems with the style of the added documentation. I prefer concise writing without unnecessary repetition. Any other reviewers can of course override me, but the following is my opinion on these changes. More

Re: Fix 69650, bogus line numbers from libcpp

On 03/23/2016 03:21 PM, Richard Biener wrote: On Wed, Mar 23, 2016 at 2:15 PM, Bernd Schmidt <bschm...@redhat.com> wrote: On 03/23/2016 01:41 PM, Richard Biener wrote: Btw, the issue in the PR is also fixed with a simple Index: libcpp/line

Re: out of bounds access in insn-automata.c

On 03/24/2016 11:17 AM, Aldy Hernandez wrote: On 03/23/2016 10:25 AM, Bernd Schmidt wrote: It looks like this block of code is written by a helper function that is really intended for other purposes than for maximal_insn_latency. Might be worth changing to int insn_code = dfa_insn_code

Re: [patch] avoid double evaluation of PIC_OFFSET_TABLE_REGNUM

On 03/24/2016 11:32 AM, Aldy Hernandez wrote: On x86, PIC_OFFSET_TABLE_REGNUM calls a function (ix86_use_pseudo_pic_reg) so its value can theoretically change between its first and second use in the following conditional: if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM

Re: Also test -O0 for OpenACC C, C++ offloading test cases

On 03/23/2016 07:47 AM, Thomas Schwinge wrote: Want me to re-word that? :-| I thought it would be obvious from looking at the test case code; will not be a problem in practice. It's because of constructs used in the test cases, like the following, for example: if

Re: Fix 69650, bogus line numbers from libcpp

On 03/23/2016 01:41 PM, Richard Biener wrote: Btw, the issue in the PR is also fixed with a simple Index: libcpp/line-map.c === --- libcpp/line-map.c (revision 234415) +++ libcpp/line-map.c (working copy) @@ -543,7 +543,7 @@

Re: [PATCH 7/7] ira.c validate_equiv_mem

On 03/21/2016 02:43 AM, Alan Modra wrote: +enum valid_equiv { valid_none, valid_combine, valid_reload }; + Might be worth documenting that each step represents a superset of the previous one. + ret = valid_combine; + if (! MEM_READONLY_P (memref) + && !

Re: Also test -O0 for OpenACC C, C++ offloading test cases

On 03/22/2016 11:23 AM, Thomas Schwinge wrote: diff --git libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c index 01d1dc8..5806cb3 100644 --- libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c +++

Re: [PATCH 6/7] ira.c use DF infrastructure for combine_and_move_insns

On 03/21/2016 02:42 AM, Alan Modra wrote: * ira.c (combine_and_move_insns): Rather than scanning insns, use DF infrastucture to find use and def insns. - remove_death (regno, insn); This call appears to have gone missing. Is that intentional? Other than

Re: Fix 70278 (LRA split_regs followup patch)

On 03/22/2016 10:24 AM, Christophe Lyon wrote: The ARM test isn't sufficiently protected against non-compliant configurations, and fails if GCC is configured for arm*linux-gnueabihf for instance (see

Re: Fix 69650, bogus line numbers from libcpp

On 03/21/2016 09:15 PM, David Malcolm wrote: On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote: On 03/11/2016 11:09 PM, David Malcolm wrote: + cpp_error (pfile, CPP_DL_ERROR, +"file \"%s\" left but not ent

Re: [RFA][PATCH] Adding missing calls to bitmap_clear

On 03/21/2016 08:06 PM, Jeff Law wrote: As noted last week, find_removable_extensions initializes several bitmaps, but doesn't clear them. This is not strictly a leak as the GC system should find dead data, but it's better to go ahead and clear the bitmaps. That releases the elements back to

Re: Fix 69650, bogus line numbers from libcpp

Ping. Bernd On 03/14/2016 02:20 PM, Bernd Schmidt wrote: On 03/11/2016 11:09 PM, David Malcolm wrote: + cpp_error (pfile, CPP_DL_ERROR, + "file \"%s\" left but not entered", new_file); Al

Re: [PATCH 0/7] ira.c tidies

On 03/21/2016 02:37 AM, Alan Modra wrote: This series tidies some of the early ira code, in the process making a tiny improvement to register pressure. Patches 1 to 3 are fairly simple tidies, with zero impact on generated code. Patch 4 also is mainly a tidy, but could see some extra REG_EQUIV

Re: [PATCH, aarch64] Fix target/70120

On 03/17/2016 08:17 PM, Richard Henderson wrote: With -g, and a code section that ends unaligned, the assembler complains of "unaligned opcodes detected". Except there are no such unaligned opcodes, nor dwarf2 code ranges covering the end of the section, which arguably makes this an assembler

Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic

On 03/17/2016 04:06 PM, H.J. Lu wrote: This is the patch I am going to check in. That still mentions darwin which I imagine might not be an exhaustive test. Bernd

Fix 70278 (LRA split_regs followup patch)

This fixes an oversight in my previous patch here. I used biggest_mode in the assumption that if the reg was used in the function, it would be set to something other than VOIDmode, but that fails if we have a multiword access - only the first hard reg gets its biggest_mode assigned in that

Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes

On 03/18/2016 08:14 PM, Jeff Law wrote: I also added a blurb to the dump file when we create these equivalences and included a test to verify the code fires. I verified it fired on x86 and x86-64. It may or may not fire on other targets, so I left the test in the i386 specific subdirectory.

Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic

On 03/17/2016 02:59 PM, H.J. Lu wrote: On Fri, Mar 11, 2016 at 9:09 AM, H.J. Lu wrote: We can't set flag_pie to the default when flag_pic == 0, which may be set by -fno-pic or -fno-PIC, since the default value of flag_pie is non-zero when GCC is configured with

Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic

On 03/17/2016 04:13 PM, H.J. Lu wrote: On Thu, Mar 17, 2016 at 8:09 AM, Bernd Schmidt <bschm...@redhat.com> wrote: On 03/17/2016 04:06 PM, H.J. Lu wrote: This is the patch I am going to check in. That still mentions darwin which I imagine might not be an exhaustive test. We c

Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic

On 03/17/2016 04:26 PM, H.J. Lu wrote: On Thu, Mar 17, 2016 at 8:23 AM, Bernd Schmidt <bschm...@redhat.com> wrote: On 03/17/2016 04:13 PM, H.J. Lu wrote: We can add an effective target, something like ignore_pic_pie, and use it instead of *-*-darwin*. That should have been done _b

Re: RFA: PATCH to load_register_parameters for empty structs and sibcalls

On 03/16/2016 07:45 PM, Jason Merrill wrote: Discussion of empty class parameter passing ABI led me to notice that r162402 broke sibcalls with arguments of size 0 in some cases. Before that commit, the code read else if ((partial == 0 || args[i].pass_on_stack) && size != 0) { [...]

Re: [PATCH] Change replace_rtx if from is a REG (PR target/70245, take 2)

On 03/17/2016 12:16 PM, Jakub Jelinek wrote: Thus, I've reverted the patch (kept the testcase), and after some discussions on IRC bootstrapped/regtested on x86_64-linux and i686-linux following version, which right now should change behavior just for the i?86 case and nothing else, so shouldn't

Re: [PATCH] Change replace_rtx if from is a REG (PR target/70245)

On 03/16/2016 01:22 PM, Jakub Jelinek wrote: So, this is what we've converged to on IRC and passed bootstrap/regtest on x86_64-linux and i686-linux. Is this ok for trunk? The explanation was a bit confusing at first, but I think this looks reasonable. The assert worries me, but triggering it

Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes

On 03/17/2016 06:37 PM, Jeff Law wrote: + bitmap seen_insns; + seen_insns = BITMAP_ALLOC (NULL); You could save an allocation here by making this a bitmap_head and using bitmap_initialize. + bitmap_set_bit (seen_insns, INSN_UID (insn)); + if (! INSN_P (insn))

Re: Wonly-top-basic-asm

On 03/17/2016 06:23 AM, David Wohlferd wrote: 2016-03-16 David Wohlferd <d...@limegreensocks.com> Bernd Schmidt <bschm...@redhat.com> * doc/extend.texi: Doc basic asm behavior re clobbers. Any objections from the release managers if I install this for David at

Re: Wonly-top-basic-asm

On 03/17/2016 06:23 AM, David Wohlferd wrote: On 3/14/2016 8:28 AM, Bernd Schmidt wrote: The example is not good, as discussed previously, and IMO the best option is to remove it. Otherwise I have no objections to the latest variant. Despite the problems I have with the existing sample

Re: [PATCH] PR69195, Reload confused by invalid reg equivs

On 03/15/2016 03:27 AM, Alan Modra wrote: On Mon, Mar 14, 2016 at 01:00:39PM -0600, Jeff Law wrote: Right. Tolerant as in not crash. So can someone please approve my ira.c:indirect_jump_optimize patch? I'm not quite audacious enough to claim it is obvious. Looks good to me. Bernd

Re: [PATCH] Fix combine's simplify_shift_const_1 (PR rtl-optimization/70222)

On 03/15/2016 12:14 PM, Jakub Jelinek wrote: - if (orig_code == LSHIFTRT && result_mode != shift_mode) + turn off all the bits that the shift would have turned off. + Similarly do this if we've optimized varop so that we don't perform + any shift. */ + if (orig_code == LSHIFTRT +

Re: [PATCH] genrecog: Fix crash on invalid input

On 03/14/2016 09:00 PM, Segher Boessenkool wrote: There is just the single caller, and pred is set right before the call there. How about this patch, then? Looks alright. Bernd

Re: [PATCH] genrecog: Fix crash on invalid input

On 03/14/2016 04:38 PM, Segher Boessenkool wrote: If your machine description refers to a non-existent predicate genrecog crashes. This fixes it. Might be better to fix the caller? Bernd

Re: [01/05] Fix PR 64411

On 03/14/2016 05:23 PM, Alexander Monakov wrote: On Mon, 14 Mar 2016, Andrey Belevantsev wrote: In this case, we get an inconsistency between the sched-deps interface, saying we can't move an insn writing the si register through a vector insn, and the liveness analysis, saying we can. The

Re: Wonly-top-basic-asm

On 03/11/2016 01:55 AM, David Wohlferd wrote: So, we have been discussing this issue for 4 months now. Over that time, I have tried to incorporate everyone's feedback. As a result we have gone from a tiny doc patch (just describe the current semantics), to a big doc patch (completely deprecate

Re: Fix 69650, bogus line numbers from libcpp

On 03/11/2016 11:09 PM, David Malcolm wrote: + cpp_error (pfile, CPP_DL_ERROR, +"file \"%s\" left but not entered", new_file); Although it looks like you're preserving the existing behavior from when

Re: [PATCH][ARM] PR driver/70132: Avoid double fclose in driver-arm.c

On 03/11/2016 04:32 PM, Kyrill Tkachov wrote: PR driver/70132 * config/arm/driver-arm.c (host_detect_local_cpu): Set file pointer to NULL after closing file. Doesn't match the patch. Either variant is fine but please use the right combination :) Bernd

LRA remat issue with hard regs (PR70123)

When I submitted my previous lra-remat patch, I mentioned I had some concerns about the way we dealt with register number comparisons, but I didn't want to change things blindly without a testcase. PR70123 has now provided such a testcase where we are trying to rematerialize a hard register

Re: [PATCH] PR69195, Reload confused by invalid reg equivs

On 03/10/2016 10:18 AM, Alan Modra wrote: Doing the indirect jump optimization turned out to be quite easy. Bootstrapped and regression tested powerpc64le-linux, gcc-6, gcc-5 and gcc-4.9. Bootstrap and regression test x86_64-linux still running. OK to apply? So much nicer. Ok, and thanks.

Fix 69650, bogus line numbers from libcpp

This is a case where bogus #line directives can confuse libcpp into producing nonsensical line numbers, even leading to a crash later on in LTO. The following patch moves the test earlier to a point where we can more easily recover from the error condition. I should note that I changed the

Fix 70083, lra-induced crash

This crash happens because LRA tries to save an AVX hard reg in a large mode, and it only appears in the function in smaller modes. Stack alignment isn't set up to support the larger mode. Currently, biggest_mode for hard registers is set up from regno_reg_rtx, set up to a large mode for

Re: Fix postreload_combine miscompilation (PR 69941)

On 03/05/2016 06:27 AM, Jeff Law wrote: PR rtl-optimization/69941 * postreload.c (reload_combine_recognize_pattern): Ensure all uses of the reg share its mode. testsuite/ PR rtl-optimization/69941 * gcc.dg/torture/pr69941.c: New test. OK. For branches as well? Bernd

Fix postreload_combine miscompilation (PR 69941)

This is a transformation which looks for (set reg1 const) (set reg2 (plus reg2 reg1)) and tries to replace all further uses of reg2 with (plus reg2 reg1). The problem here is that one of the uses is in a narrower mode, inside a zero_extend, so we produce wrong results. The fix seems rather

<    2   3   4   5   6   7   8   9   10   11   >