Limit vector alignments (PR 69973)

This is a problem I ran into before, although I can't remember the details. The problem here is that a user program requests an unreasonably large vector, the default_vector_alignment returns an unreasonably large alignment in a HOST_WIDE_INT, which then gets stored int TYPE_ALIGN, which is an

Fix PR69824, crash in C frontend

This is a crash encountered with an implicit declaration inside an argument list. In the PR, Jakub identified a place where we change the DECL_CONTEXT for such decls, and I think I agree with him that this seems wrong. The following patch ensures they aren't placed on the list in the first

Re: [pr/69916] ICE with empty loops

On 02/24/2016 09:07 PM, Nathan Sidwell wrote: this patch fixes the ICE reported in pr69916 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69916) The loop is lowered at omp-lowering, but subsequently determined to be dead before we get to oacc-target-lower. The loop CF is removed along with the

Re: [PING] genattrab.c generate switch

On 03/04/2016 06:56 PM, Jakub Jelinek wrote: I think we don't need to guarantee identical assembly, the reason I've suggested that was if it passed, it would be much easier to verify. Without that, I think it should be bootstrapped at least on one other target. Note the cases you remove the

Re: [PING] genattrab.c generate switch

On 03/04/2016 06:27 PM, Bernd Schmidt wrote: On 03/04/2016 06:14 PM, Patrick Palka wrote: I just quickly tested building the generated insn-attrtab.c with and without the patch using my host gcc 5.3 compiler and the .s output is not the same. Hmm, looking at the 003t.original dump it looks

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

On 03/04/2016 03:54 PM, Alan Modra wrote: This is a fix for two testcases that show reload replacing pseudos that don't get hard regs, with their equivalent mem initialization, but failing to address the mem properly. The short story is that ira analysis creates reg equivalence info for use by

Re: [PING] genattrab.c generate switch

On 03/04/2016 05:03 PM, Jesper Broge Jørgensen wrote: I can look into that if you deem it worth it, or would you rather just go with Patriks suppressed parenthesis? For the moment (in stage4) we'll at most go with Patrick's patch. Whether we do anything beyond that depends on whether we can

Re: [PING] genattrab.c generate switch

On 03/04/2016 06:14 PM, Patrick Palka wrote: I just quickly tested building the generated insn-attrtab.c with and without the patch using my host gcc 5.3 compiler and the .s output is not the same. Hmm, looking at the 003t.original dump it looks like there are differences in SAVE_EXPRs.

Re: [PING] genattrab.c generate switch

On 03/04/2016 03:27 PM, Patrick Palka wrote: I still suggest to try making write_test_expr() avoid emitting redundant parentheses for chains of || or &&, which would fix the original issue all the same. Previously you claimed that such a change would not be simpler than your current patch, but

Re: [PATCH 2/2] PR c/68187: fix overzealous -Wmisleading-indentation (comment #1)

On 03/03/2016 06:15 PM, Patrick Palka wrote: Cool, this also fixes the false-positives seen in bdwgc, whose coding style suggests indenting things inside an #ifdef as if it were an if(), e.g.: if (a) foo (); # ifndef A bar (); # endif ... Once again I find myself

Re: IRA costs tweaks, PR 56069

On 03/02/2016 10:53 PM, Vladimir Makarov wrote: 2. update_costs_from_allocno records a cost update not just for the initial allocno, but for each of the visited ones. I can sort of see an argument for doing that (let's say if you assign an allocno in the middle of a copy chain you'd want the

Re: Proposed Patch for Bug 69687

On 03/03/2016 04:18 PM, Mike Stump wrote: On Mar 3, 2016, at 6:55 AM, Marcel Böhme wrote: I have revised the patch and removed the limits. I looked at the patch, I can find no more unreasonable limits! Wonderful. Hope someone will finish off the review and

Re: Proposed Patch for Bug 69687

On 03/02/2016 06:22 PM, Mike Stump wrote: So, check for overflow, or better use unsigned values that are large enough to never overflow. With no possibility for overflow, you can then retest the bug and see if there are any other failure modes and fix those. What C standard can we assume for

Re: [Ping^2][PATCH][GCC-5] Fix "#pragma GCC pop_options" warning.

so adding Bernd Schmidt to the CC. Yeah, I think I remember this one. Ok. Bernd

Re: Fix/work around PR57676, LRA terminates prematurely

On 02/24/2016 11:01 PM, Jeff Law wrote: As Vlad noted, the test is definitely a pathological case. I think Bernd's patch is a very reasonable approach to address the current problem. Namely that LRA can be making progress on a pathological testcase, but it gets terminated by the anti-looping

IRA costs tweaks, PR 56069

I had a look at the costs issues in this PR. I think I've found a fair number of bugs, but fixing those alone doesn't solve the issue; one additional tweak is needed. As for the bugs, they are primarily in the mechanism of recording cost updates and restoring them. When adjusting costs for

Re: [PATCH,testsuite] Print markers to stderr to avoid races with sanitizer output

On 03/01/2016 02:20 PM, Maxim Kuvyrkov wrote: On Mar 1, 2016, at 12:31 PM, Maxim Kuvyrkov wrote: This patch improves sanitizer testsuite to avoid sporadic failures, especially when [cross-]testing on a remote machine. There are several unstable sanitizer tests in

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

On 03/01/2016 01:15 PM, James Greenhalgh wrote: On Tue, Mar 01, 2016 at 10:29:28AM +0100, Andreas Krebbel wrote: On 02/29/2016 02:36 PM, Bernd Schmidt wrote: Didn't I approve this a while ago? Not sure it's appropriate for stage4 though; is this series fixing an important regression? Yes you

Re: Fix PR44281 (bad RA with global regs)

On 02/29/2016 06:07 PM, Michael Matz wrote: %rbx would have to be implicitly used/clobbered by the asm. In addition it would have to be used by all function entries and exits (so that a function body where the global reg var is merely visible but not used doesn't accidentally clobber that

Re: Fix PR44281 (bad RA with global regs)

On 02/27/2016 08:12 PM, Richard Biener wrote: Am Freitag, 26. Februar 2016 schrieb Jeff Law : The other case that came to mind was signal handlers. What happens if we're using the global register as a scratch, we hit a memory reference that faults and inside the signal handler

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

On 02/29/2016 09:46 AM, Andreas Krebbel wrote: Ok for mainline? * gensupport.c (process_substs_on_one_elem): Split loop to complete mark_operands_used_in_match_dup on all expressions in the vector first. (adjust_operands_numbers): Inline into

Re: Fix PR44281 (bad RA with global regs)

On 02/22/2016 03:37 PM, Richard Biener wrote: Do calls properly clobber them even if they are not in the set of call-clobbered regs? Are asm()s properly using/clobbering them? I think you are allowed to use them in asm()s without adding constraints for them? Calls do, asms currently don't

Re: Wonly-top-basic-asm

On 02/21/2016 11:27 AM, David Wohlferd wrote: So now what? I have one Bernd who likes the sample, and one who doesn't. Obviously I think what I'm proposing is better than what's there now and I've done my best to say why. But me believing it to be better doesn't get anything checked in. I

Fix PR44281 (bad RA with global regs)

In this PR, we generate unnecessarily bad code for code that declares a global register var. Since global regs get added to fixed_regs, IRA never considers them as candidates. However, we do seem to have proper data flow information for them. In the testcase, the global reg dies, some

i386: add a variant peephole for decl (mem)

PR 49095 requested the following optimization: - movl-120(%rax), %ecx - leal-1(%rcx), %edx - movl%edx, -120(%rax) - testl %edx, %edx + subl$1, -120(%rax) jne .L92 The PR was fixed by adding a peephole, but it doesn't actually trigger

i386: relax scan-assembler test in lzcnt-1 testcase

I'm working on some IRA cost fixes, and I've had the lzcnt-1.c test fail because the register allocator started making different decisions. In both cases we end up generating two instructions, but with slightly different register assignments. Hence, this patch, which relaxes the test slightly.

Fix/work around PR57676, LRA terminates prematurely

The testcase in this PR causes gcc to abort with internal compiler error: Maximum number of LRA constraint passes is achieved (30) [in theory - I've not managed to reproduce this on my system with any compiler] The abort is premature, allowing LRA to continue would allow the testcase to

Re: [PATCH] Avoid bugs like PR68273 to trigger

On 02/19/2016 09:36 AM, Richard Biener wrote: Yup, so we should make sure we don't (even not "out of nowhere"). See my attempts on adding some SSA verification for this (needs to be restricted to overaligned, then it doesn't trigger that often...). One issue is that we've often got DECLs that

Re: [PING] genattrab.c generate switch

On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote: Here is the reformatted patch: This will probably have to wait until stage1. + const int code = GET_CODE (op2); + if (code != IOR) +{ + if (code == EQ_ATTR) All the formatting still looks completely mangled. This was

Re: Fix c/69522, memory management issue in c-parser

On 02/18/2016 12:22 PM, Marek Polacek wrote: On Thu, Feb 18, 2016 at 11:53:04AM +0100, Christophe Lyon wrote: FWIW, I'm seeing the new test failing on the 4.9 branch: gcc/testsuite/gcc.dg/pr69522.c:2:8: error: struct has no members [-Wpedantic] gcc/testsuite/gcc.dg/pr69522.c:9:8: error: ISO C

Re: [PATCH] Add a new option "-fmerge-bitfields" (patch / doc inside)

On 02/17/2016 02:18 PM, Daniel Gutson wrote: On Wed, Nov 26, 2014 at 5:46 AM, Andrew Pinski wrote: FYI. This causes gfc_add_interface_mapping in fortrant/trans-expr.c to be miscompiled for aarch64-linux-gnu. I am still debugging it and trying to get a smaller testcase.

Re: lra-remat issues (PR68730)

... and I managed to confuse myself about which LRA issue I had approval for on gcc-5-branch, and checked it in. Sorry. If I don't hear back until tomorrow I'll revert it. Sorry, Bernd. I should be more clear too. The patch is ok for any GCC version with lra-remat.c (it includes gcc-5 and

Re: lra-remat issues (PR68730)

On 02/15/2016 02:13 PM, Bernd Schmidt wrote: On 02/04/2016 09:27 PM, Vladimir Makarov wrote: After a few false starts, I came up with the patch below, which keeps track of not just the candidate insn, but also an activation insn, and chooses candidates only if they are both available

Re: Fix c/69522, memory management issue in c-parser

On 02/08/2016 05:30 PM, Jeff Law wrote: On 01/29/2016 04:40 AM, Bernd Schmidt wrote: c/ PR c/69522 * c-parser.c (c_parser_braced_init): New arg outer_obstack. All callers changed. If nested_p is true, use it to call finish_implicit_inits. * c-tree.h (finish_implicit_inits

Re: lra-remat issues (PR68730)

On 02/04/2016 09:27 PM, Vladimir Makarov wrote: After a few false starts, I came up with the patch below, which keeps track of not just the candidate insn, but also an activation insn, and chooses candidates only if they are both available and active. Besides passing a new arg to create_cand,

Re: Fix PR69752, insn with REG_INC being removed as equiv_init insn

On 02/12/2016 08:43 AM, Jeff Law wrote: On 02/11/2016 06:28 PM, Bernd Schmidt wrote: PR rtl-optimization/69752 * ira.c (update_equiv_regs): When looking for more than a single SET, also take other side effects into account. OK for the trunk. Branches too? The problem obviously

Re: Fix c/69522, memory management issue in c-parser

On 02/12/2016 02:26 PM, Marek Polacek wrote: On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote: FAIL: gcc.dg/pr69522.c (test for excess errors) Excess errors: /daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error: struct has no members [-Wpedantic]

Re: AW: Wonly-top-basic-asm

On 02/12/2016 08:05 AM, David Wohlferd wrote: Actually, it was my intent that this apply to v6. It's not like there is a significant change here. We're documenting long-time behavior, and adding a (disabled) warning. The doc patch (minus mentioning the warning) could go in now, but for

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On 02/12/2016 11:46 AM, Richard Biener wrote: On Fri, 12 Feb 2016, Jakub Jelinek wrote: On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote: I am testing the following patch which fixes PR69771 where the code doesn't match the comment before it. We get to expand a QImode <<

Re: [PATCH, reload] PRE_INC with invalid hard reg

On 02/12/2016 04:27 AM, Alan Modra wrote: I don't understand this comment. If we're pushing a reload of the inner reg, then the SECONDARY_MEMORY_NEEDED code in push_reload will fire. Why then should there be any need to do anything special in find_reloads_address_1 regarding secondary memory?

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On 02/12/2016 02:47 PM, Richard Biener wrote: Another possibility, only do the convert_modes from VOIDmode for shift_optab_p's xop1, and keep doing what we've done before otherwise. That looks like a very targeted and safe fix indeed. You two can obviously go ahead and sort this out, I'll

Re: Fix PR69752, insn with REG_INC being removed as equiv_init insn

On 02/12/2016 02:18 PM, Jiong Wang wrote: PR rtl-optimization/69752 * ira.c (update_equiv_regs): When looking for more than a single SET, also take other side effects into account. Will it be better that we don't remove the insn if it has side-effect instead of don't record the

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

So do you prefer e.g. following? Bootstrapped/regtested on x86_64-linux and i686-linux. - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; + mode1 = (GET_MODE (xop1) != VOIDmode || canonicalize_op1) + ? GET_MODE (xop1) : mode; Placement of parentheses is wrong for

Re: [PATCH] Add testcase for ICE in assemble_integer

On 02/12/2016 03:08 PM, Marek Polacek wrote: We've got a report that GCC is crashing when building a package on i686; there was an ICE in assemble_integer. Turned out this ICE was already fixed by r233216, so I reduced it and would like to add it to the testsuite. Tested on x86_64-linux and

bswap PRs 69714, 67781

PR69714 is an issue where the bswap pass makes an incorrect transformation on big-endian targets. The source has a 32-bit bswap, but PA doesn't have a pattern for that. Still, we recognize that there is a 16-bit bswap involved, and generate code for that - loading the halfword at offset 2 from

Fix PR69648: lra removes set of PIC reg, then introduces new use

This is a PR where LRA creates a read from an uninitialized stack slot. That stack slot is supposed to hold the value of the PIC register. What seems to happen is that we have two passes making different choices: Choosing alt 0 in insn 143: (0) =x (1) 0 (2) r {sse2_pinsrw} [...]

Re: bswap PRs 69714, 67781

On 02/13/2016 03:36 AM, John David Anglin wrote: As far as the avcrc.c reduced testcase, it didn't trigger the original bug on hppa-unknown-linux-gnu. Odd, I see the same transformation in the dumps. Do you think you could investigate a bit so we get a useful testcase to add? Bernd

Re: [PATCH] Fix PR69291, RTL if-conversion bug

On 02/10/2016 03:03 PM, Richard Biener wrote: Ok, the following is in testing now. Ok? Thanks, Richard. 2016-02-10 Richard Biener PR rtl-optimization/69291 * ifcvt.c (noce_try_store_flag_constants): Do not allow subexpressions affected by

Re: [PATCH, reload] PRE_INC with invalid hard reg

On 02/11/2016 10:45 AM, Alan Modra wrote: Due to uses elsewhere in vsx instructions, reload chooses to put psuedo 185 in fr31, which can't be used as a base register in the following: What code exactly makes the choice of fr31? I assume this is in reg_renumber, so it's IRA and not reload

Re: AW: Wonly-top-basic-asm

On 02/11/2016 12:49 AM, David Wohlferd wrote: I believe the attached patch addresses all the other outstanding comments. Bernd Edlinger made some thorough comments; I'll just add a few more. I don't think this is a patch we're considering for gcc-6, at least not for the initial release - I

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

On 02/11/2016 11:01 AM, Thomas Schwinge wrote: The "avoid offloading" mechanism. Owed to the non-shared-memory offloading architecture, if the compiler/runtime decides to "avoid offloading", then this has to apply to *all* code offloading, for data consistency reasons. Do we agree on that?

Re: [PATCH v4] PR48344: Fix unrecognizable insn error with -fstack-limit-register=r2

On 02/11/2016 04:12 PM, Kelvin Nilsen wrote: * opts-global.c (handle_common_deferred_options): Introduce and initialize two global variables to remember command-line options specifying a stack-limiting register. * opts.h: Add extern declarations of the two new

Fix PR69752, insn with REG_INC being removed as equiv_init insn

This seems fairly straightforward: (insn 213 455 216 6 (set (reg:SI 266) (mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748 {*thumb1_movsi_insn} (expr_list:REG_EQUAL (const_int -1044200508 [0xc1c2c3c4]) (expr_list:REG_INC (reg/f:SI 267) (nil

Re: [PATCH] Fix ICE when expanding incorrect shift counts (PR rtl-optimization/69764)

On 02/12/2016 12:26 AM, Jakub Jelinek wrote: When expanding shifts with invalid shift counts (negative or too large), the shift count on the GIMPLE level is typically an int mode INTEGER_CST, but when it is passed down through various layers up to expand_binop_directly, we only have one known

Re: [PATCH] Fix PR69291, RTL if-conversion bug

On 02/10/2016 02:35 PM, Richard Biener wrote: Index: gcc/ifcvt.c === --- gcc/ifcvt.c (revision 233262) +++ gcc/ifcvt.c (working copy) @@ -1274,7 +1274,8 @@ noce_try_store_flag_constants (struct no && CONST_INT_P (XEXP (a,

Re: [PATCH] Fix PR69291, RTL if-conversion bug

On 02/10/2016 02:50 PM, Richard Biener wrote: On Wed, 10 Feb 2016, Bernd Schmidt wrote: On 02/10/2016 02:35 PM, Richard Biener wrote: Index: gcc/ifcvt.c === --- gcc/ifcvt.c (revision 233262) +++ gcc/ifcvt.c (working copy

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

On 02/10/2016 12:49 PM, Thomas Schwinge wrote: Hi! Ping. I think this has to be considered after gcc-6. In general, what's the state of OpenACC these days? I'm slightly confused by the interface between offloaded code and libgomp. It looks like you're collecting avoid-offloading flags

Re: [PATCH] Fix PR69291, RTL if-conversion bug

On 02/10/2016 02:33 PM, Richard Biener wrote: But if you prefer I can instead test the following Index: gcc/ifcvt.c === --- gcc/ifcvt.c (revision 233262) +++ gcc/ifcvt.c (working copy) @@ -1274,7 +1274,7 @@

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

On 02/10/2016 03:39 PM, Thomas Schwinge wrote: Yes, we need a hammer that big: we have to ensure consistency between data regions on the device and code offloading to the device, as otherwise we'll very easily run into inconsistencies, because of the non-shared memory. In the general case,

Re: [PATCH] Fix PR69291, RTL if-conversion bug

On 02/10/2016 02:04 PM, Richard Biener wrote: where noce_try_store_flag_constants identifies (plus:SI (reg/v:SI 160 [ mod_tlen ]) (reg/v:SI 224 [ ])) as "common" and then tries to detect the case where setting the result would clobber that value. It doesn't seem to expect anything

Re: [PATCH] PR driver/69265: improved suggestions for various misspelled options

On 02/09/2016 09:44 PM, David Malcolm wrote: This is a bug in a new feature, so it isn't a regression as such, but it's fairly visible, and I believe the fix is relatively low-risk (error-handling of typos of command-line options). This also now covers PR driver/69453 (and its duplicate PR

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

On 02/10/2016 05:23 PM, Thomas Schwinge wrote: Why? A user of GCC has no intrinsic interest in getting OpenACC kernels constructs' code offloaded; the user wants his code to execute as fast as possible. If you consider the whole of OpenACC kernels code offloading as a compiler optimization,

Warning location fix, PR c++/69733

This PR notes that in this warning: const.ii:5:25: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] const double value() const {return val;} ^ we are pointing at the wrong qualifier. Below I'm attaching a patch that makes it

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

On 02/10/2016 06:37 PM, Thomas Schwinge wrote: On Wed, 10 Feb 2016 17:37:30 +0100, Bernd Schmidt <bschm...@redhat.com> wrote: IIUC it's also disabling offloading for parallels rather than just kernels, which we previously said shouldn't happen. Ah, you're talking about mixed OpenACC pa

Fix incomplete initialization of declspecs

I've noticed that build_null_declspecs fails to clear out all location information since it's missing a multiplication with the type size. The simplest fix seems to be to just clear the entire structure. Bootstrapping & testing now on x86_64-linux, ok if that succeeds? Depending on what we do

Re: [PATCH] PR rtl-optimization/64081: Enable RTL loop unrolling for duplicated exit blocks and back edges.

On 02/10/2016 12:34 PM, Alexander Fomin wrote: This patch still causes bootrstrap failure on AIX when applied on top of r219827. I tried to bisect first commit eliminating AIX problem - it may be useful anyway - but my current results seem misleading. Therefore, I'll to continue the

Re: [PATCH] PR plugins/69758: add params.list to PLUGIN_HEADERS

On 02/11/2016 04:29 AM, David Malcolm wrote: gcc/ChangeLog: PR plugins/69758 * Makefile.in (PLUGIN_HEADERS): Add params.list. Ok. Bernd

Re: [PATCH] Fix PR69274, 435.gromacs performance regression due to RA

On 02/08/2016 10:09 AM, Richard Biener wrote: The gcc.target/i386/addr-sel-1.c (for PR28940) seems to just started working at some point past in time and thus it was added and the bug closed. You could say RA does a better job after the patch as it uses 1 less register but that restricts the

Re: [PATCH v3] PR48344: Fix unrecognizable insn error with -fstack-limit-register=r2

On 01/27/2016 07:12 PM, Kelvin Nilsen wrote: +/* During execution of handle_common_deferred_options (), the Pmode + variable cannot be used because it has not yet been initialized. + For this reason, handling of the OPT_fstack_limit_register_ and + OPT_fstack_limit_symbol_ options is

Re: Fix PR67639

On 12/21/2015 08:39 PM, Jeff Law wrote: On 12/18/2015 11:38 AM, Bernd Schmidt wrote: In an earlier fix, the following change was made in varasm.c for invalid register variables: --- trunk/gcc/varasm.c2014/08/26 14:59:59214525 +++ trunk/gcc/varasm.c2014/08/26 17:06:31214526

Re: [PATCH] Fix valgrind reported issue during char constant lexing (PR c++/69628)

On 02/03/2016 09:05 PM, Jakub Jelinek wrote: 2016-02-03 Jakub Jelinek PR c++/69628 * charset.c (cpp_interpret_charconst): Clear *PCHARS_SEEN and *UNSIGNEDP if bailing out early due to errors. * g++.dg/parse/pr69628.C: New test. Ok. Bernd

Re: Fix c/69522, memory management issue in c-parser

Ping. On 01/29/2016 12:40 PM, Bernd Schmidt wrote: Let's say we have struct a { int x[1]; int y[1]; } x = { 0, { 0 } }; ^ When we reach the marked brace, we call into push_init_level, where we notice that we have implicit initializers (for x[]) lying around that we should deal

Remove -fshort-double (PR60410)

This patch fixes PR60410 by removing -fshort-double. Nick earlier propsed a fix for the crash, but Richard B suggested removing the option entirely, and I'd agree with that. It's a pointless ABI-changing option on most targets, and if a port really needs it, it should be a -m option that

Re: [PATCH] Fix PR69274, 435.gromacs performance regression due to RA

On 02/05/2016 01:10 PM, Richard Biener wrote: It fails FAIL: gcc.target/i386/addr-sel-1.c scan-assembler b+1 on i?86 (or x86_64 -m32) though, generating f: .LFB0: .cfi_startproc movl4(%esp), %eax leal1(%eax), %edx movsbl a+1(%eax), %eax

Re: [PATCH] Fix PR69274, 435.gromacs performance regression due to RA

On 02/05/2016 01:42 PM, Richard Biener wrote: so indeed the issue is not dx dieing in insn 10 but ax dieing in insn 8... Maybe LRA can prefer to not do that if enough free registers are available (that is, never re-use a register)? Maybe, but at this stage that will probably also have some

lra-remat issues (PR68730)

In this PR, we have, at an intermediate stage during LRA (before create_cands): (insn 420 (set (reg:HI 276 [orig:132 g.2_118 ] [132]) (reg:HI 132 [ g.2_118 ])) 88 {*movhi_internal} (nil)) [] (insn 436 (set (reg/v:HI 290 [orig:87 g ] [87]) (reg/v:HI 87 [ g ])) (insn 14

Re: [PATCH] gcc: invoke: delete -mno-fma4 docs

On 02/01/2016 08:13 AM, Mike Frysinger wrote: We don't document the -mno-xxx variants for other flags here, and the paragraph here specifically says "Each has a corresponding -mno- option to disable use of these instructions". Drop the -mno-fma4 line. 2016-01-31 Mike Frysinger

Re: [PATCH] PR69619: Fix exponential issue in ccmp.c

On 02/03/2016 05:35 PM, Wilco Dijkstra wrote: - tmp2 = targetm.gen_ccmp_first (_seq_2, _seq_2, rcode1, -gimple_assign_rhs1 (gs1), -gimple_assign_rhs2 (gs1)); - It looks like after this patch tmp2 could be

Re: [PATCH] Fix compile/memory hog in the combiner (PR rtl-optimization/69592)

On 02/02/2016 09:59 AM, Jakub Jelinek wrote: I wonder if it wouldn't be better to pass around some structure, containing for the common case fixed size cache and perhaps fall back to hash_map if there are more calls to cache than that. Plus perhaps a recursion depth, so that we avoid other

Re: [PATCH] Fix compile/memory hog in the combiner (PR rtl-optimization/69592)

On 02/01/2016 09:34 PM, Jakub Jelinek wrote: On the following testcase we completely uselessly consume about 5.5GB of RAM and lots of compile time. The problem is the code to avoid exponential behavior of nonzero_bits/num_sign_bit_copies on binary arithmetics rtxes, which causes us to recurse

Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

On 01/29/2016 08:42 PM, Bernd Edlinger wrote: On 29.01.2016 16:47 Bernd Schmidt wrote: Yes. What is the problem with that? If we have (plus sfp const_int) at any point before reload, we can check whether that offset is inside frame_size. If it isn't or if the offset isn't known, it could trap

Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

On 02/01/2016 01:49 PM, Richard Biener wrote: What prevents motion of those across a stack adjustment (thus a place they are _not_ valid?) If the address is SP-based, dependencies on the address register. If you're thinking prologue stack adjustments, ports where this could be an issue emit

Fix some i386 testcases for -frename-registers

This patch corrects some tests that can fail with -frename-registers. The problems typically are of the form "xmm[0-7]+", disallowing registers 8 and 9, and "xmm[0-9]". disallowing numbers higher than 9. Most the patch was automatically generated, but there were some other cases as well.

Fix c/69522, memory management issue in c-parser

Let's say we have struct a { int x[1]; int y[1]; } x = { 0, { 0 } }; ^ When we reach the marked brace, we call into push_init_level, where we notice that we have implicit initializers (for x[]) lying around that we should deal with now that we've seen another open brace. The

Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

On 01/29/2016 04:41 PM, Jakub Jelinek wrote: On Fri, Jan 29, 2016 at 02:09:25AM +0100, Bernd Schmidt wrote: I think a better approach might be to just mark accesses at known locations in the frame, or arg pushes, as MEM_NOTRAP_P, and consider accesses with non-constant or calculated offsets

Enabling -frename-registers?

So PR57193 has an example of sub-optimal code generation, with some unnecessary register moves left after LRA. These seem to be difficult to prevent, but last year Robert Suchanek made some modifications to regrename that allow it to clean up such cases. Enabling -frename-registers removes one

Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

On 01/28/2016 12:36 AM, Eric Botcazou wrote: [cc-ing Eric as RTL maintainer] Sorry for the delay, the message apparently bounced] IMO the problem is that rtx_addr_can_trap_p_1 duplicates a large bit of LRA/reload logic: [...] Under the current interface macros like

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

On 01/27/2016 04:18 PM, Ian Lance Taylor wrote: On Wed, Jan 27, 2016 at 7:16 AM, Bernd Schmidt <bschm...@redhat.com> wrote: Still, I feel uncomfortable about making a promise we don't really expect to fully keep yet, so I would prefer this option to be undocumented for now. I won't

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

On 01/08/2016 02:00 PM, Bernd Schmidt wrote: On 01/08/2016 10:41 AM, Richard Biener wrote: On Tue, Dec 22, 2015 at 10:55 AM, Nick Clifton <ni...@redhat.com> wrote: Richard Biener wrote: I think the option should be simply removed... Tempting - but we are in stage 3... My patch at

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

+This option is disabled by default for most languages, enabled by +default for languages that use garbage collection. This is not true as of this patch. Index: tree-ssa-loop-ivopts.c === --- tree-ssa-loop-ivopts.c (revision

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

On 01/27/2016 02:59 PM, Ian Lance Taylor wrote: +This option is disabled by default for most languages, enabled by +default for languages that use garbage collection. This is not true as of this patch. Yes. As I said elsewhere, my intent is to do that as a separate patch. Then the

Re: Wonly-top-basic-asm

On 01/26/2016 01:29 AM, Segher Boessenkool wrote: In my opinion we should not warn for any asm that means the same both as basic and as extended asm. The problem then becomes, what *is* the meaning of a basic asm, what does it clobber. I think this may be too hard to figure out in general

Re: [PATCH] pr69477 - attribute aligned documentation misleading

On 01/25/2016 11:13 PM, Martin Sebor wrote: The attached patch adjusts the documentation of attribute aligned and attribute pack so as to prevent misreading the text of the former attribute as if it had read: Specifying attribute aligned for struct and union types is equivalent to

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

On 01/25/2016 05:03 PM, Ian Lance Taylor wrote: On Mon, Jan 25, 2016 at 3:39 AM, Bernd Schmidt <bschm...@redhat.com> wrote: On 01/23/2016 12:52 AM, Ian Lance Taylor wrote: 2016-01-22 Ian Lance Taylor <i...@google.com> * common.opt (fkeep-gc-roots-live): New option. * tree-ssa-l

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

On 01/25/2016 09:13 PM, David Malcolm wrote: Here's an updated version of the patch. Thanks! Instead of testing one particular kind of output via a plugin, this version of the patch adds code to gcc-dg-prune to issue a FAIL for any testcase containing blank lines, with a new

Re: [PATCH] Fix handling of ZERO_EXTRACT lhs with REG_EQUAL note in the combiner (PR target/69442)

On 01/26/2016 09:39 AM, Jakub Jelinek wrote: PR target/69442 * combine.c (combine_instructions): For REG_EQUAL note with SET_DEST being ZERO_EXTRACT, also temporarily set SET_DEST to the underlying register. * doc/rtl.texi (REG_EQUAL): Document the

Re: [PATCH] Handle -fsanitize=* in lto-wrapper (PR lto/69254)

On 01/26/2016 02:24 PM, Jakub Jelinek wrote: just designed to enable DEF_SANITIZER_BUILTIN (IIUC). Also, why use shift and not just sanitize=undefined? Because -fsanitize=undefined is a large collection of individual sanitizers, and at least some of them affect also post-IPA code (e.g.

Re: [PATCH] Handle -fsanitize=* in lto-wrapper (PR lto/69254)

On 01/25/2016 09:30 PM, Jakub Jelinek wrote: Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? I've been staring at it for a while, and on the whole I think I can make sense of this. However - it does not have test coverage. Can this be added? Also, is this a regression?

Re: [PATCH] pr 65702 - error out for invalid register asms earlier

On 01/25/2016 04:36 PM, tbsaunde+...@tbsaunde.org wrote: $subject. To avoid regressions I kept the checks when generating rtl, but I believe its impossible for those to trigger now and we can remove the checks. bootstrapped + regtested on x86_64-linux-gnu, ok? Is this still an issue? I

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

On 01/23/2016 12:52 AM, Ian Lance Taylor wrote: 2016-01-22 Ian Lance Taylor * common.opt (fkeep-gc-roots-live): New option. * tree-ssa-loop-ivopts.c (add_candidate_1): If -fkeep-gc-roots-live, skip pointers. (add_iv_candidate_for_biv): Handle add_candidate_1 returning NULL.

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