Re: [PR64164] drop copyrename, integrate into expand

On Fri, Mar 27, 2015 at 03:04:05PM -0300, Alexandre Oliva wrote: > This patch reworks the out-of-ssa expander to enable coalescing of SSA > partitions that don't share the same base name. This is done only when > optimizing. > > The test we use to tell whether two partitions can be merged no

Re: [PR64164] drop copyrename, integrate into expand

On 11/16/2015 05:07 PM, Alexandre Oliva wrote: The check is not in my patch, indeed. That's because the previous block performs the runtime check, and it only lets through two cases: the one we handle, and the one nobody uses. That was the conclusion I was starting to come to, but expressed so

Re: [PR64164] drop copyrename, integrate into expand

On Nov 13, 2015, Jeff Law wrote: > On 11/11/2015 11:10 AM, Alexandre Oliva wrote: >> On Nov 10, 2015, Jeff Law wrote: >> * function.c (assign_parm_setup_block): Right-shift upward-padded big-endian args when bypassing the stack slot. >>> Don't you

Re: [PR64164] drop copyrename, integrate into expand

On 11/11/2015 11:10 AM, Alexandre Oliva wrote: On Nov 10, 2015, Jeff Law wrote: * function.c (assign_parm_setup_block): Right-shift upward-padded big-endian args when bypassing the stack slot. Don't you need to check the value of BLOCK_REG_PADDING at runtime? The padding is

Re: [PR64164] drop copyrename, integrate into expand

On Nov 10, 2015, Jeff Law wrote: >> * function.c (assign_parm_setup_block): Right-shift >> upward-padded big-endian args when bypassing the stack slot. > Don't you need to check the value of BLOCK_REG_PADDING at runtime? > The padding is essentially allowed to vary. Well, yeah,

Re: [PR64164] drop copyrename, integrate into expand

On 05/11/15 05:08, Alexandre Oliva wrote: [PR67753] fix copy of PARALLEL entry_parm to CONCAT target_reg for gcc/ChangeLog PR rtl-optimization/67753 PR rtl-optimization/64164 * function.c (assign_parm_setup_block): Avoid allocating a stack slot if we don't have

Re: [PR64164] drop copyrename, integrate into expand

On Nov 10, 2015, Alan Lawrence wrote: > FAIL: gcc.target/aarch64/aapcs64/func-ret-4.c execution, -O2 Ugh, sorry. I even checked that testcase by hand before submitting the patch, because I knew it took the paths I was changing, but I didn't realize the stack store and

Re: [PR64164] drop copyrename, integrate into expand

On 11/10/2015 03:58 PM, Alexandre Oliva wrote: On Nov 10, 2015, Alan Lawrence wrote: FAIL: gcc.target/aarch64/aapcs64/func-ret-4.c execution, -O2 Ugh, sorry. I even checked that testcase by hand before submitting the patch, because I knew it took the paths I was

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Nov 5, 2015 at 6:08 AM, Alexandre Oliva wrote: > On Sep 23, 2015, Alexandre Oliva wrote: > >> @@ -2982,38 +2887,39 @@ assign_parm_setup_block (struct assign_parm_data_all >> *all, > [snip] >> + if (GET_CODE (reg) != CONCAT) >> +

Re: [PR64164] drop copyrename, integrate into expand

On Sep 23, 2015, Alexandre Oliva wrote: > @@ -2982,38 +2887,39 @@ assign_parm_setup_block (struct assign_parm_data_all > *all, [snip] > + if (GET_CODE (reg) != CONCAT) > +stack_parm = reg; > + else > +/* This will use or allocate a stack slot that

Re: [PR67828] don't unswitch loops on undefined SSA values (was: Re: [PR64164] drop copyrename, integrate into expand)

On Fri, Oct 9, 2015 at 7:26 AM, Alexandre Oliva wrote: > This patch fixes a latent bug in loop unswitching exposed by the PR64164 > changes. > > We would move a test out of a loop that might never have been executed, > and that accessed an uninitialized variable. The

Re: [PR67766] reorder return value copying from PARALLELs and CONCATs (was: Re: [PR64164] drop copyrename, integrate into expand)

On Fri, Oct 9, 2015 at 7:36 AM, Alexandre Oliva wrote: > This fixes fallout from the PR64164 expander revamp. On alpha, PARALLEL > hard return values may be modeless, and this confuses the code that > wants to copy the pseudo/s in the returned value to the return hard > regs.

Re: [PR64164] drop copyrename, integrate into expand

On 10/07/2015 04:36 PM, Alexandre Oliva wrote: On Sep 29, 2015, Szabolcs Nagy wrote: this commit commit 33cc9081157a8c90460e4c0bdda2ac461a3822cc Author: aoliva Date: 2015-09-27 09:02:00 + revert to

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Oct 8, 2015 at 12:36 AM, Alexandre Oliva wrote: > On Sep 29, 2015, Szabolcs Nagy wrote: > >> this commit > >> commit 33cc9081157a8c90460e4c0bdda2ac461a3822cc >> Author: aoliva >> Date: 2015-09-27

[PR67766] reorder return value copying from PARALLELs and CONCATs (was: Re: [PR64164] drop copyrename, integrate into expand)

This fixes fallout from the PR64164 expander revamp. On alpha, PARALLEL hard return values may be modeless, and this confuses the code that wants to copy the pseudo/s in the returned value to the return hard regs. It used to work because PARALLELs and CONCATs used to lead to DECL_RTL with the

[PR67828] don't unswitch loops on undefined SSA values (was: Re: [PR64164] drop copyrename, integrate into expand)

This patch fixes a latent bug in loop unswitching exposed by the PR64164 changes. We would move a test out of a loop that might never have been executed, and that accessed an uninitialized variable. The uninitialized SSA name, due to uncprop, now gets coalescesd with other SSA names, expanding

Re: [PR64164] drop copyrename, integrate into expand

On Sep 29, 2015, Szabolcs Nagy wrote: > this commit > commit 33cc9081157a8c90460e4c0bdda2ac461a3822cc > Author: aoliva > Date: 2015-09-27 09:02:00 + > revert to assign_parms assignments using default defs > ...

Re: [PR64164] drop copyrename, integrate into expand

On 23/09/15 21:07, Alexandre Oliva wrote: On Sep 18, 2015, Alan Lawrence wrote: With the latest git commit 2b27ef197ece54c4573c5a748b0d40076e35412c on branch aoliva/pr64164, I am now able to build a cross toolchain for aarch64 and aarch64_be, and can confirm the ABI

Re: [PR64164] drop copyrename, integrate into expand

On Wed, Sep 23, 2015 at 10:07 PM, Alexandre Oliva wrote: > On Sep 18, 2015, Alan Lawrence wrote: > >> With the latest git commit 2b27ef197ece54c4573c5a748b0d40076e35412c on >> branch aoliva/pr64164, I am now able to build a cross toolchain for >> aarch64

Re: [PR64164] drop copyrename, integrate into expand

On Sep 18, 2015, Alan Lawrence wrote: > With the latest git commit 2b27ef197ece54c4573c5a748b0d40076e35412c on > branch aoliva/pr64164, I am now able to build a cross toolchain for > aarch64 and aarch64_be, and can confirm the ABI failure is fixed on > the branch. Thanks

Re: [PR64164] drop copyrename, integrate into expand

On 02/09/15 23:12, Alexandre Oliva wrote: On Sep 2, 2015, Alan Lawrence wrote: One more failure to report, I'm afraid. On AArch64 Bigendian, aapcs64/func-ret-4.c ICEs in simplify_subreg (line refs here are from r227348): Thanks. The failure mode was different in the

Re: [PR64164] drop copyrename, integrate into expand

On 02/09/15 23:12, Alexandre Oliva wrote: On Sep 2, 2015, Alan Lawrence wrote: One more failure to report, I'm afraid. On AArch64 Bigendian, aapcs64/func-ret-4.c ICEs in simplify_subreg (line refs here are from r227348): Thanks. The failure mode was different in the

Re: [PR64164] drop copyrename, integrate into expand

On 14/08/15 19:57, Alexandre Oliva wrote: I'm glad it appears to be working to everyone's satisfaction now. I've just committed it as r226901, with only a context adjustment to account for a change in use_register_for_decl in function.c. /me crosses fingers :-) Here's the patch as checked

Re: [PR64164] drop copyrename, integrate into expand

On Sep 2, 2015, Alan Lawrence wrote: > One more failure to report, I'm afraid. On AArch64 Bigendian, > aapcs64/func-ret-4.c ICEs in simplify_subreg (line refs here are from > r227348): Thanks. The failure mode was different in the current, revamped git branch

Re: [PR64164] drop copyrename, integrate into expand

Alexandre Oliva aol...@redhat.com writes: PR rtl-optimization/64164 PR rtl-optimization/67227 * alias.c (memrefs_conflict_p): Handle VALUEs in PLUS better. (nonoverlapping_memrefs_p): Test offsets and sizes when given identical gimple_reg exprs. I can confirm

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Aug 21, 2015 at 9:57 AM, Alexandre Oliva aol...@redhat.com wrote: On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: I have verified in the expand dumps that both the gimple and the rtl representation in the relevant parts of the code are identical, except for the presence of

Re: [PR64164] drop copyrename, integrate into expand

On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: I have verified in the expand dumps that both the gimple and the rtl representation in the relevant parts of the code are identical, except for the presence of debug stmts and insns. While comparing the dumps, I noticed

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Aug 21, 2015 at 9:46 AM, Alexandre Oliva aol...@redhat.com wrote: On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: I'm having some difficulty getting access to an ia64 box ATM, and for ada bootstraps, a cross won't do,

Re: [PR64164] drop copyrename, integrate into expand

On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: I'm having some difficulty getting access to an ia64 box ATM, and for ada bootstraps, a cross won't do, so... if you still have that build tree around, any chance you could

Re: [PR64164] drop copyrename, integrate into expand

On 08/19/2015 06:00 PM, Alexandre Oliva wrote: On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: I'm having some difficulty getting access to an ia64 box ATM, and for ada bootstraps, a cross won't do, so... if you still have that build tree around, any chance you could recompile par.o

Re: [PR64164] drop copyrename, integrate into expand

Alexandre Oliva aol...@redhat.com writes: [PR64164] fix regressions reported on m68k and armeb From: Alexandre Oliva aol...@redhat.com Defer stack slot address assignment for all parms that can't live in pseudos, and accept pseudos assignments in assign_param_setup_block. That doesn't fix

Re: [PR64164] drop copyrename, integrate into expand

Andreas Schwab sch...@linux-m68k.org writes: Alexandre Oliva aol...@redhat.com writes: [PR64164] fix regressions reported on m68k and armeb From: Alexandre Oliva aol...@redhat.com Defer stack slot address assignment for all parms that can't live in pseudos, and accept pseudos assignments

Re: [PR64164] drop copyrename, integrate into expand

On Aug 19, 2015, Andreas Schwab sch...@linux-m68k.org wrote: Andreas Schwab sch...@linux-m68k.org writes: Alexandre Oliva aol...@redhat.com writes: [PR64164] fix regressions reported on m68k and armeb From: Alexandre Oliva aol...@redhat.com Defer stack slot address assignment for all

Re: [PR64164] drop copyrename, integrate into expand

On Aug 19, 2015, Alexandre Oliva aol...@redhat.com wrote: I'm having some difficulty getting access to an ia64 box ATM, and for ada bootstraps, a cross won't do, so... if you still have that build tree around, any chance you could recompile par.o with both stage1 and stage2, with

Re: [PR64164] drop copyrename, integrate into expand

On Aug 18, 2015, Alexandre Oliva aol...@redhat.com wrote: On Aug 17, 2015, Christophe Lyon christophe.l...@linaro.org wrote: Since this was committed (r226901), I can see that the compiler build fails for armeb targets, when building libgcc: This patch fixes this particular case. I'll also

Re: [PR64164] drop copyrename, integrate into expand

On Wed, Aug 19, 2015 at 8:45 AM, Alexandre Oliva aol...@redhat.com wrote: On Aug 18, 2015, Alexandre Oliva aol...@redhat.com wrote: On Aug 17, 2015, Christophe Lyon christophe.l...@linaro.org wrote: Since this was committed (r226901), I can see that the compiler build fails for armeb targets,

Re: [PR64164] drop copyrename, integrate into expand

On 17/08/15 03:56, Alexandre Oliva wrote: On Aug 16, 2015, Andreas Schwab sch...@linux-m68k.org wrote: Alexandre Oliva aol...@redhat.com writes: On Aug 15, 2015, Andreas Schwab sch...@linux-m68k.org wrote: FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error) In

Re: [PR64164] drop copyrename, integrate into expand

On Aug 17, 2015, Andreas Schwab sch...@linux-m68k.org wrote: Alexandre Oliva aol...@redhat.com writes: Would you be so kind as to give it a spin on a m68k native? TIA, I tried it on ia64, and it falls flat on the floor. Doh, I see a logic flaw in the patch I posted. The hunk in

Re: [PR64164] drop copyrename, integrate into expand

On Aug 17, 2015, Christophe Lyon christophe.l...@linaro.org wrote: Since this was committed (r226901), I can see that the compiler build fails for armeb targets, when building libgcc: Any chance you could get me a preprocessed testcase for this failure, please? Thanks in advance, --

Re: [PR64164] drop copyrename, integrate into expand

Hi Alexandre, On 17/08/15 03:56, Alexandre Oliva wrote: On Aug 16, 2015, Andreas Schwab sch...@linux-m68k.org wrote: Alexandre Oliva aol...@redhat.com writes: On Aug 15, 2015, Andreas Schwab sch...@linux-m68k.org wrote: FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler

Re: [PR64164] drop copyrename, integrate into expand

On Aug 17, 2015, Christophe Lyon christophe.l...@linaro.org wrote: On 17 August 2015 at 13:58, Alexandre Oliva aol...@redhat.com wrote: On Aug 17, 2015, Christophe Lyon christophe.l...@linaro.org wrote: Since this was committed (r226901), I can see that the compiler build fails for armeb

Re: [PR64164] drop copyrename, integrate into expand

On 17 August 2015 at 13:58, Alexandre Oliva aol...@redhat.com wrote: On Aug 17, 2015, Christophe Lyon christophe.l...@linaro.org wrote: Since this was committed (r226901), I can see that the compiler build fails for armeb targets, when building libgcc: Any chance you could get me a

Re: [PR64164] drop copyrename, integrate into expand

On Mon, Aug 17, 2015 at 5:20 PM, Kyrill Tkachov kyrylo.tkac...@foss.arm.com wrote: Hi Alexandre, On 17/08/15 03:56, Alexandre Oliva wrote: On Aug 16, 2015, Andreas Schwab sch...@linux-m68k.org wrote: Alexandre Oliva aol...@redhat.com writes: On Aug 15, 2015, Andreas Schwab

Re: [PR64164] drop copyrename, integrate into expand

On 14 August 2015 at 20:57, Alexandre Oliva aol...@redhat.com wrote: On Aug 11, 2015, Patrick Marlier patrick.marl...@gmail.com wrote: On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law l...@redhat.com wrote: On 08/10/2015 02:23 AM, James Greenhalgh wrote: For what it is worth, I bootstrapped and

Re: [PR64164] drop copyrename, integrate into expand

Alexandre Oliva aol...@redhat.com writes: Would you be so kind as to give it a spin on a m68k native? TIA, I tried it on ia64, and it falls flat on the floor. ../../../libgcc/config/ia64/unwind-ia64.c: In function ‘_Unwind_SetGR’: ../../../libgcc/config/ia64/unwind-ia64.c:1683:1: internal

Re: [PR64164] drop copyrename, integrate into expand

Andreas Schwab sch...@linux-m68k.org writes: Alexandre Oliva aol...@redhat.com writes: Would you be so kind as to give it a spin on a m68k native? TIA, I tried it on ia64, and it falls flat on the floor. It fixes the m68k failures, though. Andreas. -- Andreas Schwab, SUSE Labs,

Re: [PR64164] drop copyrename, integrate into expand

On Aug 15, 2015, Andreas Schwab sch...@linux-m68k.org wrote: FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error) In file included from /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0: Are you sure this is a regression introduced

Re: [PR64164] drop copyrename, integrate into expand

On m68k: FAIL: gcc.c-torture/execute/20050316-1.c -O0 execution test FAIL: gcc.c-torture/execute/20050316-2.c -O0 execution test FAIL: gcc.c-torture/execute/20050316-3.c -O0 execution test FAIL: gcc.c-torture/execute/simd-4.c -O0 execution test FAIL: gcc.c-torture/execute/simd-6.c

Re: [PR64164] drop copyrename, integrate into expand

On Aug 16, 2015, Andreas Schwab sch...@linux-m68k.org wrote: Alexandre Oliva aol...@redhat.com writes: On Aug 15, 2015, Andreas Schwab sch...@linux-m68k.org wrote: FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error) In file included from

Re: [PR64164] drop copyrename, integrate into expand

On Aug 16, 2015, Andreas Schwab sch...@linux-m68k.org wrote: On m68k: FAIL: gcc.c-torture/execute/20050316-1.c -O0 execution test FAIL: gcc.c-torture/execute/20050316-2.c -O0 execution test FAIL: gcc.c-torture/execute/20050316-3.c -O0 execution test FAIL:

Re: [PR64164] drop copyrename, integrate into expand

FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error) In file included from /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0: /opt/gcc/gcc-20150815/Build/gcc/include/arm_neon.h: In function 'test_vsha1cq_u32':

Re: [PR64164] drop copyrename, integrate into expand

On Aug 11, 2015, Patrick Marlier patrick.marl...@gmail.com wrote: On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law l...@redhat.com wrote: On 08/10/2015 02:23 AM, James Greenhalgh wrote: For what it is worth, I bootstrapped and tested the consolidated patch on arm-none-linux-gnueabihf and

Re: [PR64164] drop copyrename, integrate into expand

On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law l...@redhat.com wrote: On 08/10/2015 02:23 AM, James Greenhalgh wrote: On Tue, Aug 04, 2015 at 12:45:28AM +0100, Alexandre Oliva wrote: On Jul 30, 2015, H.J. Lu hjl.to...@gmail.com wrote: aoliva/pr64164 is fine on x32. Thanks. I have made a

Re: [PR64164] drop copyrename, integrate into expand

On 08/10/2015 02:23 AM, James Greenhalgh wrote: On Tue, Aug 04, 2015 at 12:45:28AM +0100, Alexandre Oliva wrote: On Jul 30, 2015, H.J. Lu hjl.to...@gmail.com wrote: aoliva/pr64164 is fine on x32. Thanks. I have made a large number of changes since you tested it, fixing all the reported

Re: [PR64164] drop copyrename, integrate into expand

On Tue, Aug 04, 2015 at 12:45:28AM +0100, Alexandre Oliva wrote: On Jul 30, 2015, H.J. Lu hjl.to...@gmail.com wrote: aoliva/pr64164 is fine on x32. Thanks. I have made a large number of changes since you tested it, fixing all the reported issues and then some. Now, x86_64-linux-gnu

Re: [PR64164] drop copyrename, integrate into expand

On Wed, Aug 5, 2015 at 2:38 AM, Alexandre Oliva aol...@redhat.com wrote: On Aug 4, 2015, Richard Biener richard.guent...@gmail.com wrote: Though I wonder on whether splitting the patch into a first one with disabling coalescing of parms (their default defs(?)) and a followup implementing

Re: [PR64164] drop copyrename, integrate into expand

On Aug 5, 2015, Richard Biener richard.guent...@gmail.com wrote: It was just a hunch when you talked about BLKmode and params in memory. As coalescing is about SSA name (thus register) coalescing I was thinking that if you coalesce a register with incoming memory you'll end up with more

Re: [PR64164] drop copyrename, integrate into expand

On Aug 4, 2015, Richard Biener richard.guent...@gmail.com wrote: Though I wonder on whether splitting the patch into a first one with disabling coalescing of parms (their default defs(?)) and a followup implementing the support for that. We can't disable coalescing of parms altogether. With

Re: [PR64164] drop copyrename, integrate into expand

On Jul 30, 2015, H.J. Lu hjl.to...@gmail.com wrote: aoliva/pr64164 is fine on x32. Thanks. I have made a large number of changes since you tested it, fixing all the reported issues and then some. Now, x86_64-linux-gnu (-m64 and -m32), i686-pc-linux-gnu, powerpc64-linux-gnu and

Re: [PR64164] drop copyrename, integrate into expand

On Wed, Jul 29, 2015 at 1:23 PM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, Jul 29, 2015 at 1:13 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66978

Re: [PR64164] drop copyrename, integrate into expand

On Jul 23, 2015, Segher Boessenkool seg...@kernel.crashing.org wrote: On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote: Yeah. Thanks, I've tested it with this change, and I'm now checking this in (full patch first; adjusted incremental patch at the end): Unfortunately it

Re: [PR64164] drop copyrename, integrate into expand

On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66978 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983 Thanks, both of these are also fixed (I merged your patch for x32, and I verified manually that another fix I just wrote fixes all the -m32

Re: [PR64164] drop copyrename, integrate into expand

On Wed, Jul 29, 2015 at 1:13 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66978 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983 Thanks, both of these are also fixed (I merged your patch for

Re: [PR64164] drop copyrename, integrate into expand

On Jul 24, 2015, David Edelsohn dje@gmail.com wrote: On Fri, Jul 24, 2015 at 4:02 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, David Edelsohn dje@gmail.com wrote: I request that this patch be reverted (again). Might I kindly ask you to please do so for me. I've

Re: [PR64164] drop copyrename, integrate into expand

On Mon, Jul 27, 2015 at 2:22 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 24, 2015, David Edelsohn dje@gmail.com wrote: On Fri, Jul 24, 2015 at 4:02 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, David Edelsohn dje@gmail.com wrote: I request that this patch be

Re: [PR64164] drop copyrename, integrate into expand

On July 24, 2015 10:47:37 PM GMT+02:00, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jul 24, 2015 at 1:36 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 24, 2015, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015,

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Jul 24, 2015 at 1:19 AM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 4:14 PM, David Edelsohn dje@gmail.com wrote: On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23,

Re: [PR64164] drop copyrename, integrate into expand

On Jul 24, 2015, David Edelsohn dje@gmail.com wrote: Did you commit the final, complete version of the patches? Yes, I have double-checked that reverting the patch I posted on the r225979 tree I used for testing reverts it to the base revision, except for unrelated libgfortran configury

Re: [PR64164] drop copyrename, integrate into expand

On Jul 24, 2015, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983 My test logs with the patch have: PASS:

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Jul 24, 2015 at 1:36 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 24, 2015, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote:

Re: [PR64164] drop copyrename, integrate into expand

On Jul 23, 2015, David Edelsohn dje@gmail.com wrote: I request that this patch be reverted (again). Might I kindly ask you to please do so for me. I've just found out that, after yesterday's memory upgrade on my local build machine, the filesystem that I normally use for GCC development

Re: [PR64164] drop copyrename, integrate into expand

On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983 My test logs with the patch have: PASS: c-c++-common/dfp/func-vararg-dfp.c execution test so I think this one is not caused by the PR64164 patch. -- Alexandre Oliva, freedom fighter

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983 My test logs with the patch have: PASS: c-c++-common/dfp/func-vararg-dfp.c execution test so I think this one

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Jul 24, 2015 at 3:10 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, H.J. Lu hjl.to...@gmail.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983 My test logs with the patch have: PASS:

Re: [PR64164] drop copyrename, integrate into expand

On Jul 23, 2015, Segher Boessenkool seg...@kernel.crashing.org wrote: On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote: Yeah. Thanks, I've tested it with this change, and I'm now checking this in (full patch first; adjusted incremental patch at the end): Unfortunately it

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Jul 24, 2015 at 4:02 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 23, 2015, David Edelsohn dje@gmail.com wrote: I request that this patch be reverted (again). Might I kindly ask you to please do so for me. I've just found out that, after yesterday's memory upgrade on my

Re: [PR64164] drop copyrename, integrate into expand

On Fri, Jul 24, 2015 at 2:22 AM, Richard Biener richard.guent...@gmail.com wrote: On Fri, Jul 24, 2015 at 1:19 AM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 4:14 PM, David Edelsohn dje@gmail.com wrote: On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu hjl.to...@gmail.com wrote: On

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote: Yeah.

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote: Yeah. Thanks, I've tested it with this change, and I'm now checking this in (full patch first; adjusted incremental patch at the end):

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Jul 23, 2015 at 4:14 PM, David Edelsohn dje@gmail.com wrote: On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool seg...@kernel.crashing.org wrote:

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote: Yeah. Thanks, I've tested it with this change, and I'm now checking this in (full patch first; adjusted incremental patch at the end): Unfortunately it causes about a thousand test fails on powerpc64-linux (at least, it seems to

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote: Yeah. Thanks, I've tested it with this change, and I'm now checking this

Re: [PR64164] drop copyrename, integrate into expand

On Jul 23, 2015, Richard Biener richard.guent...@gmail.com wrote: Hmm, ok. Does using if (currently_expanding_to_rtl) work? I think it's slightly more descriptive. Yeah. Thanks, I've tested it with this change, and I'm now checking this in (full patch first; adjusted incremental patch

Re: [PR64164] drop copyrename, integrate into expand

On Wed, Jul 22, 2015 at 7:33 PM, Alexandre Oliva aol...@redhat.com wrote: On Jul 21, 2015, Richard Biener richard.guent...@gmail.com wrote: On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva aol...@redhat.com wrote: + if (cfun-gimple_df) If the cfun-gimple_df check is to decide whether

Re: [PR64164] drop copyrename, integrate into expand

On Jul 21, 2015, Richard Biener richard.guent...@gmail.com wrote: On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva aol...@redhat.com wrote: On Jul 16, 2015, Alexandre Oliva aol...@redhat.com wrote: + /* If we are assigning parameters for a function, rather +than for a

Re: [PR64164] drop copyrename, integrate into expand

On Jul 21, 2015, Richard Biener richard.guent...@gmail.com wrote: On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva aol...@redhat.com wrote: + if (cfun-gimple_df) If the cfun-gimple_df check is to decide whether this is a call or a function then no, this can't work reliably. What is

Re: [PR64164] drop copyrename, integrate into expand

On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva aol...@redhat.com wrote: On Jul 16, 2015, Alexandre Oliva aol...@redhat.com wrote: So, I decided to run a ppc64le-linux-gnu bootstrap, just in case, and there are issues with split complex parms that caused go and fortran libs to fail the

Re: [PR64164] drop copyrename, integrate into expand

On Jul 16, 2015, Alexandre Oliva aol...@redhat.com wrote: So, I decided to run a ppc64le-linux-gnu bootstrap, just in case, and there are issues with split complex parms that caused go and fortran libs to fail the build. This incremental patch, along with the previously-posted patches, fix

Re: [PR64164] drop copyrename, integrate into expand

On Jun 10, 2015, Richard Biener richard.guent...@gmail.com wrote: On Wed, Jun 10, 2015 at 2:24 AM, Alexandre Oliva aol...@redhat.com wrote: This caused the sparc regression reported by Eric in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164#c37 We need to match the mode of the rtl created

Re: [PR64164] drop copyrename, integrate into expand

On Thu, Jul 16, 2015 at 9:29 AM, Alexandre Oliva aol...@redhat.com wrote: On Jun 10, 2015, Richard Biener richard.guent...@gmail.com wrote: On Wed, Jun 10, 2015 at 2:24 AM, Alexandre Oliva aol...@redhat.com wrote: This caused the sparc regression reported by Eric in

Re: [PR64164] drop copyrename, integrate into expand

On Jul 16, 2015, Richard Biener richard.guent...@gmail.com wrote: Is this ok to install? Yes. So, I decided to run a ppc64le-linux-gnu bootstrap, just in case, and there are issues with split complex parms that caused go and fortran libs to fail the build. I will refrain from installing this

Re: [PR64164] drop copyrename, integrate into expand

On Wed, Jun 10, 2015 at 2:24 AM, Alexandre Oliva aol...@redhat.com wrote: On Jun 5, 2015, Alexandre Oliva aol...@redhat.com wrote: On Apr 27, 2015, Richard Biener richard.guent...@gmail.com wrote: +/* Return the promoted mode for name. If it is a named SSA_NAME, it + is the same as

Re: [PR64164] drop copyrename, integrate into expand

On 8 June 2015 at 10:14, Richard Biener richard.guent...@gmail.com wrote: On Sat, Jun 6, 2015 at 3:14 AM, Alexandre Oliva aol...@redhat.com wrote: On Apr 27, 2015, Richard Biener richard.guent...@gmail.com wrote: This should also mention that is_gimple_reg vars do not have their address

Re: [PR64164] drop copyrename, integrate into expand

This also broke bootstrap on PPC64 LE Linux with the same error. - David

Re: [PR64164] drop copyrename, integrate into expand

On Jun 9, 2015, David Edelsohn dje@gmail.com wrote: This also broke bootstrap on PPC64 LE Linux with the same error. Thanks for your reports. I'm looking into the problem. I'd appreciate a preprocessed testcase from either of you to confirm the fix, if not to help debug it. Thanks in

Re: [PR64164] drop copyrename, integrate into expand

On Tue, Jun 09, 2015 at 05:11:45PM -0300, Alexandre Oliva wrote: On Jun 9, 2015, Alexandre Oliva aol...@redhat.com wrote: On Jun 9, 2015, David Edelsohn dje@gmail.com wrote: This also broke bootstrap on PPC64 LE Linux with the same error. Thanks for your reports. I'm looking into

Re: [PR64164] drop copyrename, integrate into expand

On Jun 9, 2015, Alexandre Oliva aol...@redhat.com wrote: On Jun 9, 2015, David Edelsohn dje@gmail.com wrote: This also broke bootstrap on PPC64 LE Linux with the same error. Thanks for your reports. I'm looking into the problem. I'd appreciate a preprocessed testcase from either of

Re: [PR64164] drop copyrename, integrate into expand

Alex, I sent you a pre-processed file off-list. You could try bootstrapping on PPC64 on the GCC Compile Farm. The SPARC failure reports a different error than PPC and ARM. The PPC and ARM failures are the same message, but seem to be on different files. After the breakage from Aldy's patch all

Re: [PR64164] drop copyrename, integrate into expand

I'll look into cross-building some embedded targets and see if any further issues surface. SPARC is also broken, see my message and the tescase under the PR. -- Eric Botcazou

Re: [PR64164] drop copyrename, integrate into expand

On Jun 5, 2015, Alexandre Oliva aol...@redhat.com wrote: On Apr 27, 2015, Richard Biener richard.guent...@gmail.com wrote: +/* Return the promoted mode for name. If it is a named SSA_NAME, it + is the same as promote_decl_mode. Otherwise, it is the promoted + mode of a temp decl of

  1   2   >