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 long
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
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 need to check the value of BLOCK_REG_
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 essentially allowe
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, it's the result o
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 changing, but I didn't
real
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 load would amount to shif
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 a
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)
>> +stack_parm = reg;
>> + else
>> +/*
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 we'd rather
> +
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 assign_parms assignments using default defs
...
introduced a test fail
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.
>
> It used to work
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 uninitialized SSA
> name, due
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 sam
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 th
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 09:02:00 +
>
>> revert to assign_parms assignments using default defs
>> ...
>
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
> ...
> introduced a test failure on arm-none-eabi (using newlib, compilin
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 failure is fixed on
the bra
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 and aarch64_be, and can confirm the ABI fa
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 for the confirmation. I
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 current, revamped git
b
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 current, revamped git
b
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 aoliva/pr64164, but I've just fixe
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 in:
Alexandre Oliva 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 that this fixe
On Fri, Aug 21, 2015 at 9:46 AM, Alexandre Oliva wrote:
> On Aug 19, 2015, Alexandre Oliva wrote:
>
>> On Aug 19, 2015, Alexandre Oliva 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
>>> t
On Fri, Aug 21, 2015 at 9:57 AM, Alexandre Oliva wrote:
> On Aug 19, 2015, Alexandre Oliva 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.
>
> W
On Aug 19, 2015, Alexandre Oliva 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 -fdump-unnumbered-links no lon
On Aug 19, 2015, Alexandre Oliva wrote:
> On Aug 19, 2015, Alexandre Oliva 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 stage
On 08/19/2015 06:00 PM, Alexandre Oliva wrote:
On Aug 19, 2015, Alexandre Oliva 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
On Aug 19, 2015, Alexandre Oliva 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 -fdump-rtl-expand-details
On Aug 19, 2015, Andreas Schwab wrote:
> Andreas Schwab writes:
>> Alexandre Oliva writes:
>>
>>> [PR64164] fix regressions reported on m68k and armeb
>>>
>>> From: Alexandre Oliva
>>>
>>> Defer stack slot address assignment for all parms that can't live in
>>> pseudos, and accept pseudos a
Andreas Schwab writes:
> Alexandre Oliva writes:
>
>> [PR64164] fix regressions reported on m68k and armeb
>>
>> From: Alexandre Oliva
>>
>> Defer stack slot address assignment for all parms that can't live in
>> pseudos, and accept pseudos assignments in assign_param_setup_block.
>
> That does
Alexandre Oliva writes:
> [PR64164] fix regressions reported on m68k and armeb
>
> From: Alexandre Oliva
>
> 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 the ia64 Ada miscompilation t
On Wed, Aug 19, 2015 at 8:45 AM, Alexandre Oliva wrote:
> On Aug 18, 2015, Alexandre Oliva wrote:
>
On Aug 17, 2015, Christophe Lyon wrote:
> Since this was committed (r226901), I can see that the compiler build
> fails for armeb targets, when building libgcc:
>
>> This patch fixes
On Aug 18, 2015, Alexandre Oliva wrote:
>>> On Aug 17, 2015, Christophe Lyon 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 add this configuration
> to the
On 17/08/15 03:56, Alexandre Oliva wrote:
On Aug 16, 2015, Andreas Schwab wrote:
Alexandre Oliva writes:
On Aug 15, 2015, Andreas Schwab 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.targ
On Aug 17, 2015, Christophe Lyon wrote:
> On 17 August 2015 at 13:58, Alexandre Oliva wrote:
>> On Aug 17, 2015, Christophe Lyon wrote:
>>
>>> Since this was committed (r226901), I can see that the compiler build
>>> fails for armeb targets, when building libgcc:
>>
>> Any chance you could ge
On Mon, Aug 17, 2015 at 5:20 PM, Kyrill Tkachov
wrote:
> Hi Alexandre,
>
> On 17/08/15 03:56, Alexandre Oliva wrote:
>>
>> On Aug 16, 2015, Andreas Schwab wrote:
>>
>>> Alexandre Oliva writes:
On Aug 15, 2015, Andreas Schwab wrote:
> FAIL: gcc.target/aarch64/target_attr_crypt
On 17 August 2015 at 13:58, Alexandre Oliva wrote:
> On Aug 17, 2015, Christophe Lyon 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, pleas
On Aug 17, 2015, Christophe Lyon 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,
--
Alexandre Oliva, freedom fighter
On Aug 17, 2015, Andreas Schwab wrote:
> Alexandre Oliva 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
assign_parm_setup_stack that looked like this:
Hi Alexandre,
On 17/08/15 03:56, Alexandre Oliva wrote:
On Aug 16, 2015, Andreas Schwab wrote:
Alexandre Oliva writes:
On Aug 15, 2015, Andreas Schwab wrote:
FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error)
In file included from
/opt/gcc/gcc-20150815/gcc/test
Andreas Schwab writes:
> Alexandre Oliva 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, sch...@suse.de
GPG Key fingerprint = 0196
Alexandre Oliva 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 compiler error:
Seg
On 14 August 2015 at 20:57, Alexandre Oliva wrote:
> On Aug 11, 2015, Patrick Marlier wrote:
>
>> On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law 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-li
On Aug 16, 2015, Andreas Schwab wrote:
> Alexandre Oliva writes:
>> On Aug 15, 2015, Andreas Schwab 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_a
On Aug 16, 2015, Andreas Schwab 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: gcc.c-torture/execute/simd-4.c -O0 execut
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 -O
On Aug 15, 2015, Andreas Schwab 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 by my patch? The
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':
/opt/gcc/gcc-20150815/Bui
On Aug 11, 2015, Patrick Marlier wrote:
> On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law 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 aarch64-none-linux-gnu with trunk at
>>> r
On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law 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" wrote:
>>>
aoliva/pr64164 is fine on x32.
>>>
>>>
>>> Thanks. I have made a large num
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" 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
On Tue, Aug 04, 2015 at 12:45:28AM +0100, Alexandre Oliva wrote:
> On Jul 30, 2015, "H.J. Lu" 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 -m
On Aug 5, 2015, Richard Biener 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 memory accesses?
Since we
On Wed, Aug 5, 2015 at 2:38 AM, Alexandre Oliva wrote:
> On Aug 4, 2015, Richard Biener 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
On Aug 4, 2015, Richard Biener 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 -O0, we must
coalesce a
On Jul 30, 2015, "H.J. Lu" 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
powerpc64el-linux-gnu pass regs
On Wed, Jul 29, 2015 at 1:23 PM, H.J. Lu wrote:
> On Wed, Jul 29, 2015 at 1:13 PM, Alexandre Oliva wrote:
>> On Jul 23, 2015, "H.J. Lu" 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
On Wed, Jul 29, 2015 at 1:13 PM, Alexandre Oliva wrote:
> On Jul 23, 2015, "H.J. Lu" 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 manu
On Jul 23, 2015, "H.J. Lu" 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
-msse2 regress
On Jul 23, 2015, Segher Boessenkool 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 causes about a thousand t
On Mon, Jul 27, 2015 at 2:22 PM, Alexandre Oliva wrote:
> On Jul 24, 2015, David Edelsohn wrote:
>
>> On Fri, Jul 24, 2015 at 4:02 PM, Alexandre Oliva wrote:
>>> On Jul 23, 2015, David Edelsohn wrote:
>>>
I request that this patch be reverted (again).
>>>
>>> Might I kindly ask you to plea
On Jul 24, 2015, David Edelsohn wrote:
> On Fri, Jul 24, 2015 at 4:02 PM, Alexandre Oliva wrote:
>> On Jul 23, 2015, David Edelsohn 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
On July 24, 2015 10:47:37 PM GMT+02:00, "H.J. Lu" wrote:
>On Fri, Jul 24, 2015 at 1:36 PM, Alexandre Oliva
>wrote:
>> On Jul 24, 2015, "H.J. Lu" wrote:
>>
>>> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva
> wrote:
On Jul 23, 2015, "H.J. Lu" wrote:
> https://gcc.gnu.org/bugzill
On Fri, Jul 24, 2015 at 4:02 PM, Alexandre Oliva wrote:
> On Jul 23, 2015, David Edelsohn 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
> fi
On Fri, Jul 24, 2015 at 1:36 PM, Alexandre Oliva wrote:
> On Jul 24, 2015, "H.J. Lu" wrote:
>
>> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
>>> On Jul 23, 2015, "H.J. Lu" wrote:
>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
>>>
>>> My test logs with the patch have:
>
On Jul 24, 2015, "H.J. Lu" wrote:
> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
>> On Jul 23, 2015, "H.J. Lu" 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
>>
On Jul 24, 2015, David Edelsohn 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 changes that I used
On Jul 23, 2015, David Edelsohn 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 got corrupted, and
On Fri, Jul 24, 2015 at 3:10 PM, H.J. Lu wrote:
> On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
>> On Jul 23, 2015, "H.J. Lu" 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 executi
On Fri, Jul 24, 2015 at 11:43 AM, Alexandre Oliva wrote:
> On Jul 23, 2015, "H.J. Lu" 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 PR641
On Jul 23, 2015, "H.J. Lu" 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 fighterhttp://FSFLA.org/~lx
On Jul 23, 2015, Segher Boessenkool 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 causes about a thousand t
On Fri, Jul 24, 2015 at 2:22 AM, Richard Biener
wrote:
> On Fri, Jul 24, 2015 at 1:19 AM, H.J. Lu wrote:
>> On Thu, Jul 23, 2015 at 4:14 PM, David Edelsohn wrote:
>>> On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu wrote:
On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu wrote:
> On Thu, Jul 23, 2015
On Fri, Jul 24, 2015 at 1:19 AM, H.J. Lu wrote:
> On Thu, Jul 23, 2015 at 4:14 PM, David Edelsohn wrote:
>> On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu wrote:
>>> On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu wrote:
On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool
wrote:
> On Thu, Jul
On Thu, Jul 23, 2015 at 4:14 PM, David Edelsohn wrote:
> On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu wrote:
>> On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu wrote:
>>> On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool
>>> wrote:
On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote:
>>
On Thu, Jul 23, 2015 at 5:59 PM, H.J. Lu wrote:
> On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu wrote:
>> On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool
>> 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
On Thu, Jul 23, 2015 at 1:57 PM, H.J. Lu wrote:
> On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool
> 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 incre
On Thu, Jul 23, 2015 at 1:31 PM, Segher Boessenkool
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 causes ab
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
On Jul 23, 2015, Richard Biener 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 at the end):
[PR64164]
On Wed, Jul 22, 2015 at 7:33 PM, Alexandre Oliva wrote:
> On Jul 21, 2015, Richard Biener wrote:
>
>> On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva wrote:
>>> + if (cfun->gimple_df)
>
>> If the cfun->gimple_df check is to decide whether this is a call or a
>> function
>> then no, thi
On Jul 21, 2015, Richard Biener wrote:
> On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva 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 this test for else?
It turns out it'
On Jul 21, 2015, Richard Biener wrote:
> On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva wrote:
>> On Jul 16, 2015, Alexandre Oliva wrote:
>> + /* If we are assigning parameters for a function, rather
>> +than for a call, propagate the RTL of the complex parm to
>> +
On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva wrote:
> On Jul 16, 2015, Alexandre Oliva 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 patc
On Jul 16, 2015, Alexandre Oliva 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
split complex arg
On Jul 16, 2015, Richard Biener 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 for now, and I'll post
On Thu, Jul 16, 2015 at 9:29 AM, Alexandre Oliva wrote:
> On Jun 10, 2015, Richard Biener wrote:
>
>> On Wed, Jun 10, 2015 at 2:24 AM, Alexandre Oliva 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
On Jun 10, 2015, Richard Biener wrote:
> On Wed, Jun 10, 2015 at 2:24 AM, Alexandre Oliva 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 for the partition and the
>> promote
On Wed, Jun 10, 2015 at 2:24 AM, Alexandre Oliva wrote:
> On Jun 5, 2015, Alexandre Oliva wrote:
>
>> On Apr 27, 2015, Richard Biener 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
>>>
On Jun 5, 2015, Alexandre Oliva wrote:
> On Apr 27, 2015, Richard Biener 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 same type as the SSA_NAME, if we had
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
> 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
On Tue, Jun 09, 2015 at 05:11:45PM -0300, Alexandre Oliva wrote:
> On Jun 9, 2015, Alexandre Oliva wrote:
>
> > On Jun 9, 2015, David Edelsohn 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
On Jun 9, 2015, Alexandre Oliva wrote:
> On Jun 9, 2015, David Edelsohn 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 no
On Jun 9, 2015, David Edelsohn 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 advance,
--
Alexa
This also broke bootstrap on PPC64 LE Linux with the same error.
- David
On 8 June 2015 at 10:14, Richard Biener wrote:
> On Sat, Jun 6, 2015 at 3:14 AM, Alexandre Oliva wrote:
>> On Apr 27, 2015, Richard Biener wrote:
>>
>>> This should also mention that is_gimple_reg vars do not have their
>>> address taken.
>>
>> check
>>
+static tree
+leader_merge (tree
1 - 100 of 115 matches
Mail list logo
