Re: AVR CC0 transition

On 4/23/20 8:31 AM, Eric Botcazou wrote: Thanks, I will take a look at Bernd's work. IIRC, he took a different approach from what was suggested in the wiki, right? Yes, let's say that it's a half-baked conversion, probably a consequence of the bounty. This might be good enough, depending on

Re: Not usable email content encoding

On 3/18/20 3:22 PM, Frank Ch. Eigler via Gcc wrote: The From: header rewriting for DMARC participants is something sourceware is doing now. Out of curiousity, is this rewriting you are talking about the cause for a lot of mails showing up as "From: GCC List" rather than their real senders?

Re: Proposal for the transition timetable for the move to GIT

On 1/10/20 8:33 AM, Maxim Kuvyrkov wrote: Joseph, please point to message on gcc@ mailing list that expresses consensus of GCC community to use reposurgeon conversion. Otherwise, it is not appropriate to substitute one's opinion for community consensus. I was on the fence for a long time,

Re: Test GCC conversion with reposurgeon available

On 12/18/19 10:55 PM, Joseph Myers wrote: git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git I cloned this one and started trying random things again. The previous one had some strange-looking merge commits, but it sounded like that was a known issue, and indeed the ones I had seen

Re: Test GCC conversion with reposurgeon available

On 12/17/19 10:32 PM, Joseph Myers wrote: git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git It seems that permission bits are not reproduced entirely correctly. For example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn (and the git-svn repository) to -rw-r--r-- in this

Re: Proposal for the transition timetable for the move to GIT

On 12/9/19 7:19 PM, Joseph Myers wrote: For any conversion we're clearly going to need to run various validation (comparing properties of the converted repository, such as contents at branch tips, with expected values of those properties based on the SVN repository) and fix issues shown up by

Re: Proposal for the transition timetable for the move to GIT

On 12/6/19 6:21 PM, Eric S. Raymond wrote: Your approach sounds pretty reasonable except for that part. I don't trust git-svn at *all* - I've collided with it too often during past conversions. It has a nasty habit of leaving damage in places that are difficult to audit. So, which steps are

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/28/19 8:53 PM, Gunther Nikl wrote:> Bernd Schmidt : >> On 11/23/19 9:53 PM, Bernd Schmidt wrote: >> move.w %a4,%d0 >> - tst.b %d0 >> - jeq .L352 >> + jeq .L353 >> >> And the reason - that's a movqi using move.w. > >

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/26/19 3:21 AM, Joseph Myers wrote: > > The soft-float ColdFire build (--with-arch=cf --with-cpu=54455 > --disable-multilib) successfully built libgcc and glibc, but ran into an > ICE building the glibc tests. Again, I've not bisected but this commit > seems likely to be responsible.

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/26/19 1:36 AM, Joseph Myers wrote: > I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py > bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's > building _mulsc3.o; I get assembler errors: I overlooked a difference in the 68881 vs coldfire

Autoinc vs reload and LRA

So I was curious what would happen if I turned on LRA for m68k. It turns out my autoinc patches from the cc0 patch set expose a bug in how LRA handles autoincrement. While it copies the logic from reload's inc_for_reload, it appears to be missing the find_reloads_address code to ensure an autoinc

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/25/19 1:38 PM, Tobias Burnus wrote: > Thanks for the m68k work! Can you also update > https://gcc.gnu.org/backends.html ? Committed as obvious. Bernd commit f42834ad5e77c05cb6bc0908b8fc9282fec7fc19 Author: Bernd Schmidt Date: Mon Nov 25 13:48:08 2019 +0100 Change backends

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote: > Are all 4 + 2 patches in now? Thus, can we close the bug? We're missing one piece for better autoinc generation, but that's a small optimization issue. The cc0 conversion is complete. Bernd

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/23/19 6:36 PM, Jeff Law wrote: > Not really. I've already indicated to Bernd that he should go ahead and > commit the changes and we can iterate on any problems that arise. After the last fix, I did some more testing and since I feel confident that it really is in good shape now, I

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/25/19 12:26 PM, Andreas Schwab wrote: > On Nov 24 2019, Bernd Schmidt wrote: > >> Whew, I think I have it. One tst instruction eliminated when it >> shouldn't have been: >> >> move.w %a4,%d0 >> - tst.b %d0 >> - jeq .L352 >>

Re: [PATCH 4/4] Fix autoinc cbranch

On 11/24/19 8:43 PM, Segher Boessenkool wrote: > But. Allowing autoinc into jump insns means those jump insns may then > eventually need an output reload; it may just have been because of that? That's almost certainly the reasoning, but as I pointed out in my original mail - reload is careful

Re: [PATCH 4/4] Fix autoinc cbranch

On 11/19/19 1:27 AM, Segher Boessenkool wrote: > The combine parts are okay for trunk, if you keep an eye out :-) Thanks, now committed. That leaves the auto-inc-dec part. Since we're being adventurous, I've also bootstrapped and tested the following in the meantime (on the gcc135 machine). This

Re: [PATCH ix86] Fix rtx_costs for flag-setting adds

y) @@ -1,3 +1,8 @@ +2019-11-24 Bernd Schmidt + + * config/i386/i386.c (ix86_rtx_costs): Handle care of a PLUS in a + COMPARE, representing an overflow detection. + 2019-11-23 Jan Hubicka * cif-code.def (MAX_INLINE_INSNS_SINGLE_O2_LIMIT): Remove. Index: gcc/con

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/23/19 9:53 PM, Bernd Schmidt wrote: > I'll spend a few more days trying to see if I can do something about the > bootstrap failure Mikael saw (currently trying to do a two-stage cross > build rather than a really slow bootstrap). Whew, I think I have it. One tst instruction elimin

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/23/19 6:36 PM, Jeff Law wrote: > Not really. I've already indicated to Bernd that he should go ahead and > commit the changes and we can iterate on any problems that arise. In the meantime I've made an aranym setup in addition to the qemu setup I had, and I've not been able to reproduce

Re: [PATCH ix86] Fix rtx_costs for flag-setting adds

On 11/22/19 3:04 PM, Uros Bizjak wrote: > On Fri, Nov 22, 2019 at 1:58 PM Bernd Schmidt wrote: >> >> A patch I posted recently fixes combine to take costs of JUMP_INSNs into >> account. That causes the pr30315 test to fail with -m32, since the cost >> of an add that

[PATCH ix86] Fix rtx_costs for flag-setting adds

A patch I posted recently fixes combine to take costs of JUMP_INSNs into account. That causes the pr30315 test to fail with -m32, since the cost of an add that sets the flags is estimated too high. The following seems to fix it. Bootstrapped and tested on x86_64-linux, ok? Bernd *

Re: [PATCH 3/4] Set costs for jumps in combine

On 11/22/19 1:42 AM, Segher Boessenkool wrote: > On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote: >> Thanks. Just FYI, this is held up a little. I decided I'd also test on >> x86, and there it shows a case where ix86_rtx_cost misses something: the >> i386/pr3

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/21/19 1:30 PM, Matthias Klose wrote: > > that would be apt build-dep gcc-9. The former would only install the build > dependencies of the gcc-defaults package. That gets me E: You must put some 'source' URIs in your sources.list where /etc/apt/sources.list looks like deb

Re: [PATCH 3/4] Set costs for jumps in combine

On 11/13/19 5:16 PM, Segher Boessenkool wrote: > On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote: >> Also, it does not compute costs for jump >> insns, so they are always set to zero. As a consequence, any possible >> substitution is performed if a combination in

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/20/19 8:27 PM, Mikael Pettersson wrote: > On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt wrote: >> Probably best to just run tests on stage1 and hope something shows up. > > Ok, how do I did that? I've always just done 'make -k check' after > full bootstraps. >

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/20/19 2:50 PM, Mikael Pettersson wrote: > On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson > wrote: >> >> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt wrote: >>> >>> Hi Mikael, >>> >>>> This fixed the problem, thanks. >>>

Re: [PATCH 0/4] Eliminate cc0 from m68k

Hi Mikael, > This fixed the problem, thanks. Could you also run the testsuite to see if you can reproduce the g++.old-deja failures Andreas reported? Bernd

Re: [PATCH 2/4] The main m68k cc0 conversion

(Apologies to Jeff who's getting this twice because I didn't hit reply-all the first time.) On 11/17/19 6:56 PM, Jeff Law wrote: > While scanning this patch I did notice the introduction of > CC_STATUS_INIT in output_{and,ior,xor}si. You might want to check that. That is intentional.

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/16/19 9:18 AM, Andreas Schwab wrote: > On Nov 16 2019, Bernd Schmidt wrote: > >> Well, there has to be some difference between what you are doing and >> what I am doing, because: >> >> Running /local/src/egcs/git/gcc/testsuite/g++.old-deja/old-deja.exp ... >

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/15/19 11:50 PM, Andreas Schwab wrote: > On Nov 15 2019, Bernd Schmidt wrote: > >> I meant the compiler command line of course... for any -mcpu flags that >> might differ from my test run. > > There are none. Well, there has to be some difference between what you

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/15/19 10:58 PM, Andreas Schwab wrote: > On Nov 15 2019, Bernd Schmidt wrote: > >> Any chance you could show the command lines from the log files or some >> other way of reproducing the issue? > > Executing on aranym: OMP_NUM_THREADS=2 > LD_LIBRARY_PATH=.:/da

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/15/19 5:34 PM, Andreas Schwab wrote: > On Nov 15 2019, Bernd Schmidt wrote: > >> Are these with the patch? > > Yes. > >> Are you on real hardware > > No, I'm using aranym. Any chance you could show the command lines from the log files or some other way of reproducing the issue? Bernd

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/15/19 2:48 PM, Andreas Schwab wrote: > Here are the results of running the testsuite on m68k-linux: > > http://gcc.gnu.org/ml/gcc-testresults/2019-11/msg00908.html > > This is a list of regressions: Are these with the patch? I'm not seeing any of these in my testing with qemu. Are you on

Re: [PATCH 1/4] Preliminary m68k patches

On 11/13/19 9:03 PM, Jeff Law wrote: > OK. I'd actually recommend this go ahead and get installed. My tester > will bootstrap it overnight. Alright, let me know how that turns out. What kind of machine do you have for that? Bernd

Re: [PATCH 0/4] Eliminate cc0 from m68k

On 11/13/19 7:16 PM, Segher Boessenkool wrote: > I tried this out with a kernel build (just the defconfig). > during RTL pass: jump2 > /home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf_core_dump': > /home/segher/src/kernel/fs/binfmt_elf.c:2409:1: internal compiler error: in >

[PATCH 4/4] Fix autoinc cbranch

After the m68k cc0 conversion, there is one code quality regression that I can see: we no longer generate autoinc addressing modes in comparisons. This is because the parts of the compiler that generate autoinc are unwilling to substitute into jumps. If you look at the code in reload, you'll see

[PATCH 3/4] Set costs for jumps in combine

The combiner is somewhat strange about how it uses costs. If any of the insns involved in a comparison have a cost of 0, it does not verify that the substitution is cheaper. Also, it does not compute costs for jump insns, so they are always set to zero. As a consequence, any possible substitution

[PATCH 2/4] The main m68k cc0 conversion

This achieves the conversion by using combined cbranch/cstore patterns, and using a mechanism similar to the cc_status tracking to elide certain comparisons. Unlike cc_status, this is opt-in and requires a flags_valid attribute to be set for suitable instructions. Due to lack of test hardware,

Re: [PATCH 1/4] Preliminary m68k patches

This tidies up a few spots in the m68k backend in preparation for the large patch to follow. This is purely for review purposes: this patch has not been tested independently, and will be committed together with the following one. Noteworthy changes: Some patterns and peepholes were unified

[PATCH 0/4] Eliminate cc0 from m68k

This is a set of patches to convert m68k so that it no longer uses cc0. The approach is to combine cc0 setter/user pairs into cbranch and cstore patterns. It does not expose the flag register directly. Since m68k is a target that is not under active development, and probably receives very limited

Re: Repo conversion troubles.

On 07/09/2018 09:19 PM, Eric S. Raymond wrote: > Last time I did a comparison between SVN head and the git conversion > tip they matched exactly. This time I have mismatches in the following > files. So what are the diffs? Are we talking about small differences (like one change missing) or

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/15/2018 12:58 PM, A. Skrobov wrote: >>> That makes me wonder if there is a latent bug though. Consider pushing >>> args to a pure function. Could we then try to CSE the memory reference >>> and get it wrong because we haven't accounted for the autoinc? >> >> Can't know for sure but one

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/14/2018 10:55 PM, Jeff Law wrote: > That does sound vaguely familiar. Did we put autoinc notes on the stack > pushes? Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps. > That makes me wonder if there is a latent bug though. Consider pushing > args to a pure function.

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/12/2018 07:01 PM, Jeff Law wrote: > No. We're not supposed to have any auto-inc insns prior to the auto-inc > pass. A stack push/pop early in the compiler would have to be > represented by a PARALLEL. > > It's been this way forever. It's documented in the internals manual > somewhere.

Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations

On 08/27/2017 09:36 PM, Jon Beniston wrote: > I have an out-of-tree GCC port and it is struggling supporting > auto-vectorization on some dot product instructions. For example, I have an > instruction that takes three operands which are all 32-bit general > registers. The second and third

Re: combiner: how to compute cost for bit insertion?

On 07/10/2017 05:10 PM, Georg-Johann Lay wrote: > (set (zero_extract:QI (reg/i:QI 24 r24) > (const_int 1 [0x1]) > (const_int 6 [0x6])) > (lshiftrt:QI (reg:QI 52) > (const_int 6 [0x6]))) > The problem is that the backend only sees > >

Re: MAINTAINERS update

On 06/11/2017 08:03 PM, Gerald Pfeifer wrote: > On Tue, 30 May 2017, Bernd Schmidt wrote: >> On 05/30/2017 09:05 AM, Richard Biener wrote: >>> This leaves the nvptx and c6x ports without a maintainer. Do >>> you have any recommendations for a successor here? >>

Re: MAINTAINERS update

On 05/30/2017 09:05 AM, Richard Biener wrote: > This leaves the nvptx and c6x ports without a maintainer. Do you have > any recommendations for a successor here? Not really. It would be a shame to lose the C6X port though. If I'm CC'd on any bug reports I'm prepared to keep it working - if

Re: MAINTAINERS update

On 05/27/2017 12:52 PM, Bernd Schmidt wrote: I am no longer working for Red Hat, so I've updated my email address. Also, I don't expect to be around very much in the near future, so I've removed myself as maintainer for some areas. Judging by a reply I got, I may have been too terse. No need

MAINTAINERS update

(revision 248535) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2017-05-27 Bernd Schmidt <bschm...@redhat.com> + + * MAINTAINERS: Update my email address, and remove myself as + maintainer in some areas. + 2017-05-25 Eric Gallager <eg...@gwmail.gwu.edu> * MAINTAINERS: Add self to

PR78972, 80283: Extend TER with scheduling

If you look at certain testcases like the one for PR78972, you'll find that the code generated by TER is maximally pessimal in terms of register pressure: we can generate a large number of intermediate results, and defer all the statements that use them up. Another observation one can make is

Re: [PATCH 1/5] nvptx: implement SIMT enter/exit insns

On 03/27/2017 12:56 PM, Alexander Monakov wrote: Hello Bernd, Can you have a look at this patch (unchanged from previous posting in January)? The rest of the patches in the set are reviewed. On Wed, 22 Mar 2017, Alexander Monakov wrote: This patch adds handling of new

LRA fix for 80160

(revision 246472) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2017-03-25 Bernd Schmidt <bschm...@redhat.com> + + PR rtl-optimization/80160 + PR rtl-optimization/80159 + * lra-assigns.c (must_not_spill_p): Tighten new test to also take + reg_alternate_class into account. + 2017-03-24 Vl

Re: [PATCH] Decrease compile time memory with heavy find_base_{value,term} on i?86/x86_64 (PR rtl-optimization/63191, take 2)

On 03/22/2017 04:38 PM, Uros Bizjak wrote: LGTM, but I don't want to step on Bernd's toes, so let's wait for his opinion. I was waiting for yours really, that's the one that counts. Bernd

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 07:38 PM, Pinski, Andrew wrote: One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226 r246227 Can you help narrow that down? Bernd

Re: [PATCH] Fix tree-prof/pr66295.c

On 03/15/2017 09:59 PM, Segher Boessenkool wrote: This testcase can only ever be built on x86 (it needs the "avx*" attributes). This patch skips the test elsewhere. Is this okay for trunk? Ok. Bernd

Re: [PATCH] Remove dead stores and initializations

On 03/16/2017 01:31 PM, Markus Trippelsdorf wrote: clang --analyze pointed out a number of dead stores and initializations. Tested on ppc64le. Ok for trunk? I'd say - not now. Ideally someone would delve into the commit history to figure out what happened with each of these, and whether any

Document PR79806 as a non-bug

I suggest we apply the following and close the PR as INVALID (not a bug). Ok? Bernd Index: pr65693.c === --- pr65693.c (revision 245685) +++ pr65693.c (working copy) @@ -2,6 +2,11 @@ /* { dg-do compile } */ /* { dg-options

Re: Combiner fix for PR79910

On 03/15/2017 04:00 PM, Bernd Schmidt wrote: On 03/15/2017 12:09 AM, Bernd Schmidt wrote: I'll retest with your suggestion and with the bitmap creation conditional on i1 being nonnull. Like this (also had to throw in a bitmap_empty_p). Retested as before. Ok? Oops, that one also has

Re: Combiner fix for PR79910

On 03/15/2017 12:09 AM, Bernd Schmidt wrote: I'll retest with your suggestion and with the bitmap creation conditional on i1 being nonnull. Like this (also had to throw in a bitmap_empty_p). Retested as before. Ok? Bernd Index: gcc/combine.c

Fix C6X hwloop issue

This fixes a failure in the testsuite. When we transform the doloop pattern, the decrement of the old iteration register goes away, which is a problem if it's used after the loop (where it should have the value zero). Committed. Bernd * config/c6x/c6x.c (predicate_insn): Avoid rtl sharing

Reload fix for an old aarch64 issue

This triggered a kernel miscompilation with an old (4.8 I think) aarch64 toolchain. Here's the reloads for the insn where things go wrong: Reloads for insn # 210 Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ]) GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)

Re: Combiner fix for PR79910

On 03/15/2017 12:03 AM, Jeff Law wrote: On 03/10/2017 04:24 PM, Bernd Schmidt wrote: PR rtl-optimization/79910 * combine.c (record_used_regs): New static function. (try_combine): Handle situations where there is an additional instruction between I2 and I3 which needs to have

Combiner fix for PR79910

In this PR, we have a few insns involved in two instruction combinations: insn 16: set r100 insn 27: some calculation insn 28: some calculation insn 32: using r100 insn 33: using r100 insn 35: some calculation Then we combine insns 27, 28 and 33, producing two output insns, As a result, insn

Re: Fix IRA issue, PR79728

Ping (minus the require-effective-target line, as Uros pointed out). Bernd On 03/03/2017 02:51 PM, Bernd Schmidt wrote: This is an ICE where setup_pressure_classes fails if xmm0 is a global reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only SSE_FIRST_REG as the third register class

Re: [PATCH] Fix out-of-bounds write in RTL function reader (PR bootstrap/79952)

On 03/10/2017 08:03 PM, David Malcolm wrote: print-rtl.c:rtx_writer::print_rtx_operand_code_0 has some special -casing for SYMBOL_REF, but if I'm reading things right we don't yet dump SYMBOL_REF_BLOCK and SYMBOL_REF_BLOCK_OFFSET, so we'd need to dump these somehow. Yeah. Perhaps as an extra

Re: [PATCH] Decrease compile time memory with heavy find_base_{value,term} on i?86/x86_64 (PR rtl-optimization/63191)

On 03/10/2017 06:53 PM, Jakub Jelinek wrote: + +template +static inline rtx +ix86_delegitimize_address_tmpl (rtx x) { Why is this a template and not a function arg? Bernd

Re: [PATCH] Fix out-of-bounds write in RTL function reader (PR bootstrap/79952)

On 03/09/2017 08:28 PM, David Malcolm wrote: The root cause is an out-of-bounds memory write in the RTL dump reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO set. Such SYMBOL_REFs are normally created by varasm.c:create_block_symbol, which has: Hmm, I don't actually recall

Re: C PATCH to fix c/79758 (ICE-on-invalid with function redefinition and old style decls)

On 03/03/2017 02:33 PM, Marek Polacek wrote: 2017-03-03 Marek Polacek PR c/79758 * c-decl.c (store_parm_decls_oldstyle): Check if the element of current_function_prototype_arg_types is error_mark_node. Fix formatting. Use TREE_VALUE

Fix IRA issue, PR79728

This is an ICE where setup_pressure_classes fails if xmm0 is a global reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only SSE_FIRST_REG as the third register class. The problem is that the costs for moving between SSE_FIRST_REG and SSE_REGS are inflated because we think we have no

Fix (work around) LRA infinite loop, PR78911

In this PR, we have an endless cycle in LRA, generating ever more instructions. The relevant portions of the dump seem to be these: ** Local #9: ** Creating newreg=130 from oldreg=128, assigning class CREG to r130 18:

Re: GCSE: Use HOST_WIDE_INT instead of int (PR, rtl-optimization/79574).

On 03/02/2017 06:50 PM, Martin Liška wrote: Hello. This is second part of fixes needed to not trigger integer overflow in gcse pass. So, how is this intended to work? The min/max stored in the param is an int, and by using a HOST_WIDE_INT here, we expect that it is a larger type and

Re: C PATCH to fix c/79758 (ICE-on-invalid with function redefinition and old style decls)

On 03/02/2017 06:35 PM, Marek Polacek wrote: While at it, I fixed wrong formatting in the nearby code. Also use NULL_TREE instead of 0 where appropriate. I really dislike those zeros-as-trees; one day I'll just go and turn them into NULL_TREEs. I sympathize, but it makes it harder to see

Re: [PATCH] Fix ICE with multiple conditional traps turned into unconditional in one bb (PR rtl-optimization/79780)

On 03/02/2017 10:23 AM, Jakub Jelinek wrote: 2017-03-02 Jakub Jelinek PR rtl-optimization/79780 * cprop.c (one_cprop_pass): When second and further conditional trap in a single basic block is turned into an unconditional trap, turn it into a

Re: [PATCH] Improve ifcvt (PR tree-optimization/79389)

On 02/23/2017 10:27 PM, Jakub Jelinek wrote: Now successfully bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? LGTM. Bernd

Re: [PATCH] Improve ifcvt (PR tree-optimization/79389)

On 02/23/2017 02:36 PM, Jakub Jelinek wrote: and both UNLT and GE can be reversed. But if the arguments of the condition are canonicalized, we run into: /* Test for an integer condition, or a floating-point comparison in which NaNs can be ignored. */ if (CONST_INT_P (arg0) ||

Re: [PATCH] Improve ifcvt (PR tree-optimization/79389)

On 02/23/2017 12:46 PM, Jakub Jelinek wrote: But as soon as we only have the (unlt (reg:DF 100) (reg:DF 97)), reversed_comparison_code fails on it: case UNLT: case UNLE: case UNGT: case UNGE: /* We don't have safe way to reverse these yet. */ return UNKNOWN; I do

Re: [PATCH 1/6] c6x: Fix for RTL checking

On 02/21/2017 03:48 PM, Segher Boessenkool wrote: 2017-02-21 Segher Boessenkool * config/c6x/c6x.c (predicate_insn): Do not incorrectly share RTL. Ok, thanks. Bernd

Re: fwprop fix for PR79405

On 02/17/2017 10:11 AM, Richard Biener wrote: Index: gcc/fwprop.c === --- gcc/fwprop.c(revision 245501) +++ gcc/fwprop.c(working copy) @@ -1478,7 +1478,8 @@ fwprop (void) Do not forward propagate addresses into

Re: Improving code generation in the nvptx back end

On 02/17/2017 02:09 PM, Thomas Schwinge wrote: Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: [...] for "normal" functions there is no reason to use the ".param" space for passing arguments in and out of functions. We can then get rid of the boilerplate code to move ".param %in_ar*" into

Re: Improving code generation in the nvptx back end

On 02/17/2017 02:09 PM, Thomas Schwinge wrote: Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: [...] for "normal" functions there is no reason to use the ".param" space for passing arguments in and out of functions. We can then get rid of the boilerplate code to move ".param %in_ar*" into

fwprop fix for PR79405

We have two registers being assigned to each other: (set (reg 213) (reg 209)) (set (reg 209) (reg 213)) These being the only definitions, we are happy to forward propagate reg 209 for reg 213 into a third insn, making a new use for reg 209. We are then happy to forward propagate reg 213 for

Re: C PATCH to fix ICE with -Wdouble-promotion (PR c/79515)

On 02/15/2017 12:49 PM, Marek Polacek wrote: We ICEd on this testcase in do_warn_double_promotion because an invalid conversion had produced an error result type and accessing that via TYPE_MAIN_VARIANT crashes. Fixed in an obvious way. Bootstrapped/regtested on x86_64-linux, ok for trunk?

Re: [PATCH] Replace XALLOCAVEC with XCNEWVEC (PR c/79471).

On 02/13/2017 02:06 PM, Martin Liška wrote: On 02/13/2017 01:58 PM, Bernd Schmidt wrote: On 02/13/2017 11:15 AM, Martin Liška wrote: In order to not cause a stack overflow, lets use a vector allocated on heap instead of the one created by XALLOCVEC. Patch can bootstrap on ppc64le-redhat

Re: [PATCH] Invalidate combiner's cached last value upon insn removal (PR rtl-optimization/79388, PR rtl-optimization/79450)

On 02/10/2017 08:50 PM, Jakub Jelinek wrote: 2017-02-10 Jakub Jelinek PR rtl-optimization/79388 PR rtl-optimization/79450 * combine.c (distribute_notes): When removing TEM_INSN for which corresponding dest has last value recorded, invalidate

Re: [PATCH] Replace XALLOCAVEC with XCNEWVEC (PR c/79471).

On 02/13/2017 11:15 AM, Martin Liška wrote: In order to not cause a stack overflow, lets use a vector allocated on heap instead of the one created by XALLOCVEC. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ok. I'm surprised this is marked as a regression, but

Re: [patch] Fix PR middle-end/78468

On 01/27/2017 01:02 PM, Eric Botcazou wrote: The attached patch is a middle ground between the previously working and currently broken situations: if the back-end defines STACK_DYNAMIC_OFFSET, then the middle-end assumes that STACK_DYNAMIC_OFFSET maintains the alignment; if it doesn't, which

One more cprop trap_if fix, PR79194

This PR seems to be curable by fixing up the CFG a little earlier. Bootstrapped and tested on x86_64-linux, and it seems to cure the testcase with a ppc cross. I'd appreciate if someone ran full ppc tests with this though. Ok? Bernd PR rtl-optimization/79194 * cprop.c (one_cprop_pass):

Re: [RFC] sched: Do not move expensive insns speculatively (PR68664)

On 01/27/2017 02:19 AM, Segher Boessenkool wrote: But what is "insn cost"? Latency is no good at all -- we *want* insns with higher latency to be earlier. fsqrt is not pipelined, and that is what makes it so costly. (This isn't modeled in the scheduling description btw: that would make the

Re: Improve things for PR71724, in combine/if_then_else_cond

On 01/25/2017 08:46 PM, Segher Boessenkool wrote: It turns out my patch (see the PR) causes (or at least triggers) miscompilations on tilegx. I will drop it for now. Curious, it looked very reasonable. What's needed to reproduce this? Bernd

Re: Improve things for PR71724, in combine/if_then_else_cond

On 01/25/2017 10:18 AM, Kyrill Tkachov wrote: The test is supposed to test the generation of the vsel instruction. I believe adding an -mcpu=cortex-a57 to the testcases would be best, as VSEL isn't actually available on Cortex-A5, it's just enabled by the -mfpu=fp-armv8 option. A more realistic

Re: Improve things for PR71724, in combine/if_then_else_cond

On 01/24/2017 06:03 PM, Christophe Lyon wrote: Ha... the regression occurred between r 244818 and r 244816, and I read r 244816 ChangeLog too quickly and did not notice it was modifying ifcvt.c in addition to x86-only files. So it's likely that it's your other patch for pr78634 that caused the

Re: Improve things for PR71724, in combine/if_then_else_cond

On 01/24/2017 05:50 PM, Kyrill Tkachov wrote: Actually trying it out with an explicit -mcpu=cortex-a5 (so -O2 -S -mfpu=fp-armv8 -mcpu=cortex-a57 -mfloat-abi=hard) I get the test failing before and after the patch. The code generated is vcmp.f64d0, d1 vmrsAPSR_nzcv,

Re: Improve things for PR71724, in combine/if_then_else_cond

On 01/24/2017 05:30 PM, Kyrill Tkachov wrote: The -mfpu is overridden in the testcase to add the ARMv8 instructions. So to reproduce the compilation in that testcase you'd want -mfpu=fp-armv8 or something equivalent rather than vfpv3-d16-fp16. Exact steps please. No one who's not well-versed

Re: Improve things for PR71724, in combine/if_then_else_cond

On 01/24/2017 09:38 AM, Christophe Lyon wrote: It seems that Bernd's patch causes regressions on arm-linux-gnueabihf --with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16: gcc.target/arm/vselvcdf.c scan-assembler-times vselvs.f64\td[0-9]+ 1 gcc.target/arm/vselvcsf.c scan-assembler-times

Re: [PATCH v5] add -fprolog-pad=N,M option

There's still a a few details that need addressing, and some questions I have. Also Ccing Jakub to have another pair of eyes on the name of the section - I don't know if we want some sort of .gnu.something name. On 01/13/2017 01:19 PM, Torsten Duwe wrote: 2017-01-13 Torsten Duwe

Improve things for PR71724, in combine/if_then_else_cond

The PR is about infinite recursion in combine_simplify_rtx, because if_then_else_cond does strange things to an expression, and we end up simplifying something to itself. The patch below tries to address this by improving that function a little. As stated in the PR, the situation is that we

Another cprop trap_if fix, PR79125

This is essentially the same patch I sent for the previous instance of this problem, but this time applied to local_cprop_pass. Bootstrapped and tested on x86_64-linux, and it seems to fix the testcase with a ppc cross. Ok? Bernd PR rtl-optimization/79125 * cprop.c (local_cprop_pass):

Re: PR78634: ifcvt/i386 cost updates

On 12/09/2016 12:49 PM, Bernd Schmidt wrote: On 12/03/2016 10:49 AM, Uros Bizjak wrote: Based on the above explanation, the patch is OK. I'll be treating the ifcvt part of it as obvious. However, testing showed an issue with the i386 funcspec-11 test: /* PR target/36936 */ /* { dg-do

  1   2   3   4   5   6   7   8   9   10   >