> Probably the best place to add a code for this is in
> lra-constraints.c::simplify_operand_subreg by permitting subreg reload
> for paradoxical subregs whose hard regs are not fully in allocno class
> of the inner pseudo.
>
> It needs a good testing (i'd check that the generated code is not
> cha
Hi,
Tim Shen ha scritto:
>Is it OK not to bootstrap it ? Tested under -m64 and -m32.
Ok, thanks.
Paolo
Forget to let _M_clone and _M_eliminate_dummy follow
_S_opcode_subexpr_lookahead, which also have _M_alt.
Is it OK not to bootstrap it ? Tested under -m64 and -m32.
Thanks!
--
Tim Shen
a.patch
Description: Binary data
There was a bug in the libgo implementation of reflect.Call when passing
a function following a non-pointer type. This patch fixes the bug and
adds a test. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.8 branch.
Ian
diff -r 7c369498bb81 libgo/go/ref
This patch implements support for VSX vector loads and stores in little
endian mode. VSX loads and stores permute the register image with
respect to storage in a unique manner that is not truly little endian.
This can cause problems (for example, when a vector appears in a union
with a different t
Richard Biener writes:
> On Sun, Sep 29, 2013 at 11:08 AM, Richard Sandiford
> wrote:
>> Michael Matz writes:
>>>Trever Saunders writes:
Richard Biener writes:
> Btw, I've come around multiple coding-styles in the past and I
> definitely would prefer m_mode / m_count to mark mem
Hi,
this ICE seems easy to avoid: just check the return value of
make_typename_type for error_mark_node, like we normally do everywhere
else in the parser.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2013-09-30 Paolo Carlini
PR c++/58563
* parse
As per my previous comments on this patch, I will not approve the
changes to the m32c backend, as they will cause real bugs in real
hardware, and violate the hardware's ABI. The user may use
-fno-strict-volatile-bitfields if they do not desire this behavior and
understand the consequences.
I am
On 09/30/13 14:11, Teresa Johnson wrote:
Oh, I can do that right now if you want - let me know if you haven't
hit the trigger yet. Thanks,
Already done :-0
jeff
Nevermind - see that you did this already. Thanks!
Teresa
On Mon, Sep 30, 2013 at 1:11 PM, Teresa Johnson wrote:
> Oh, I can do that right now if you want - let me know if you haven't
> hit the trigger yet. Thanks,
> Teresa
>
> On Mon, Sep 30, 2013 at 1:06 PM, Jeff Law wrote:
>> On 09/30/13 13:0
Oh, I can do that right now if you want - let me know if you haven't
hit the trigger yet. Thanks,
Teresa
On Mon, Sep 30, 2013 at 1:06 PM, Jeff Law wrote:
> On 09/30/13 13:07, Jeff Law wrote:
>>
>> On 09/30/13 12:52, Teresa Johnson wrote:
>>>
>>> The jump threading handling in the case of a joiner
On 09/30/13 13:07, Jeff Law wrote:
On 09/30/13 12:52, Teresa Johnson wrote:
The jump threading handling in the case of a joiner block was not
updating
profile information (it was being updated in the non-joiner case). Added
profile updates for the joiner case, in one place by commoning the
handl
On 09/30/2013 03:24 AM, Tristan Gingold wrote:
> 2013-09-03 Tristan Gingold
>
> * tree.c (set_call_expr_flags): Reject ECF_TM_PURE.
> (build_common_builtin_nodes): Set "transaction_pure"
> attribute on __builtin_eh_pointer function type (and not on
> its declaration).
O
On 09/30/13 13:42, Mike Stump wrote:
On Sep 30, 2013, at 7:23 AM, Nick Clifton wrote:
Several tests in the gcc.c-torture/compile directory need a target
with 32-bit integers and/or 32-bit pointers.
OK to apply ?
Ok.
It may be reasonable to special case ptr32plus to say no on your pl
On Sep 30, 2013, at 7:23 AM, Nick Clifton wrote:
> Several tests in the gcc.c-torture/compile directory need a target
> with 32-bit integers and/or 32-bit pointers.
> OK to apply ?
Ok.
It may be reasonable to special case ptr32plus to say no on your platform, from
check_effective_target_tls
On 09/30/13 12:52, Teresa Johnson wrote:
The jump threading handling in the case of a joiner block was not updating
profile information (it was being updated in the non-joiner case). Added
profile updates for the joiner case, in one place by commoning the
handling between the joiner and non-joine
The jump threading handling in the case of a joiner block was not updating
profile information (it was being updated in the non-joiner case). Added
profile updates for the joiner case, in one place by commoning the
handling between the joiner and non-joiner cases.
Bootstrapped and tested on x86_64
This patch from Chris Manghane changes the Go frontend to use the
backend interface for variable expressions. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.8
branch.
Ian
2013-09-30 Chris Manghane
* go-gcc.cc (Backend::error_expression):
On 09/30/2013 01:02 PM, Tom Tromey wrote:
Tom> How about putting it into libiberty?
Tom> That way other hashtab users, like gdb, can use it.
Andrew> I have no problem with that, but Jakub didn't seem to think it
Andrew> belonged there.
All I found was this:
http://gcc.gnu.org/ml/gcc-patches/20
Hi,
thus the below are the patches which I'm applying to mainline and
4_7/4_8, respectively. Tested x86_64-linux.
Thanks,
Paolo.
/
2013-09-30 Chris Jefferson
PR libstdc++/58437
* include/bits/stl_algo.h (__move_median_first): Rename to
__mov
Tom> How about putting it into libiberty?
Tom> That way other hashtab users, like gdb, can use it.
Andrew> I have no problem with that, but Jakub didn't seem to think it
Andrew> belonged there.
All I found was this:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00721.html
Quoting from it: "It do
On 09/28/13 08:31, Andrew MacLeod wrote:
temps would be OK with me, but there are a couple of concerns.
- I'd want to be able to declare the temps at the point of use, not
the top of the function. this would actually help with clarity I think.
Not sure what the current coding standard says abo
On 09/30/13 02:05, Michael Matz wrote:
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
My example in this form would look something like:
int unsignedsrcp = ptrvar.type().type().type_unsigned();
<...>
GimpleType t1 = ptrvar.type ();
GimpleType t2 = t1.type ();
Stop that CamelCase dyslexia al
On 09/30/2013 12:08 PM, Tom Tromey wrote:
"Andrew" == Andrew MacLeod writes:
Andrew> Jakub didn't like removing this hash table iterator functionality even
Andrew> though it is currently unused in the compiler.
Andrew> So it seems reasonable to put it in tree-hasher.h since its purpose is
Andr
> "Andrew" == Andrew MacLeod writes:
Andrew> Jakub didn't like removing this hash table iterator functionality even
Andrew> though it is currently unused in the compiler.
Andrew> So it seems reasonable to put it in tree-hasher.h since its purpose is
Andrew> "Hash Table Helper for Trees"?
Ho
On Mon, Sep 30, 2013 at 2:29 AM, Zhenqiang Chen wrote:
> Hi,
>
> The patch enhances phiopt to handle cases like:
>
> if (a == 0 && (...))
> return 0;
> return a;
>
> Boot strap and no make check regression on X86-64 and ARM.
>
> Is it OK for trunk?
>From someone who wrote lot of this code
On 30 Sep 2013, at 08:45, Paolo Bonzini wrote:
> Il 27/09/2013 21:45, Gerald Pfeifer ha scritto:
>> I believe this may be breaking all my testers on FreeBSD
>> (i386-unknown-freebsd10.0 for example). The timing of when this
>> patchset went in fits pretty much when my builds started to break
>>
Move the prototype for coalesce_ssa_name() out of tree-ssa-live.h and
put it in a new tree-ssa-coalesce.h file.
Include tree-ssa-coalesce.h from tree-outof-ssa.h as it forms part of
the out-of-ssa module.
Also move gimple_can_coalesce_p from tree-ssa-coalesce.c to gimple.h as
it operates on g
Jakub didn't like removing this hash table iterator functionality even
though it is currently unused in the compiler.
So it seems reasonable to put it in tree-hasher.h since its purpose is
"Hash Table Helper for Trees"?
bootstraps on build/x86_64-unknown-linux-gnu with no new regressions. O
On Mon, Sep 30, 2013 at 7:07 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> On Mon, Sep 30, 2013 at 6:07 AM, Rainer Orth
>> wrote:
>>> Ian Lance Taylor writes:
>>>
Following up on my earlier patch, this patch implements the
reflect.MakeFunc function for 386.
Tom Trom
Yes, that will do. Can you do it for me? I can't do testing easily
on arm myself.
thanks,
David
On Mon, Sep 30, 2013 at 3:29 AM, Kyrill Tkachov wrote:
> Hi Richard, David,
>
>> In principle yes. Note that it changes the behavior of -O2
>> -ftree-vectorize
>> as -ftree-vectorize does not i
On 09/09/13 07:54, Aldy Hernandez wrote:
PING^3
Hi guys!
PING for both C and C++.
Thanks.
Original Message
Subject: Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
Date: Tue, 27 Aug 2013 15:03:26 -0500
From: Aldy Hernandez
To: Richard Henderson
CC: jas
> "Iain" == Iain Sandoe writes:
Joseph> Do you need these compilation rules at all? Or could you change
Joseph> config.host to use paths such as config/host-darwin.o rather
Joseph> than just host-darwin.o, and so allow the generic rules to be
Joseph> used (my understanding was that the auto-
Hi Guys,
Several tests in the gcc.c-torture/compile directory need a target
with 32-bit integers and/or 32-bit pointers. The patch below adds
"dg-require-effective-target in32plus" to these tests. This fixes
~200 unexpected failures for the MSP430, RL78 and XSTORMY16 targets.
Note - I
On 09/30/2013 04:05 AM, Michael Matz wrote:
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
My example in this form would look something like:
int unsignedsrcp = ptrvar.type().type().type_unsigned();
<...>
GimpleType t1 = ptrvar.type ();
GimpleType t2 = t1.type ();
Stop that CamelCase dyslexi
Ian Lance Taylor writes:
> On Mon, Sep 30, 2013 at 6:07 AM, Rainer Orth
> wrote:
>> Ian Lance Taylor writes:
>>
>>> Following up on my earlier patch, this patch implements the
>>> reflect.MakeFunc function for 386.
>>>
>>> Tom Tromey pointed out to me that the libffi closure support can
>>> pro
On Mon, Sep 30, 2013 at 6:07 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> Following up on my earlier patch, this patch implements the
>> reflect.MakeFunc function for 386.
>>
>> Tom Tromey pointed out to me that the libffi closure support can
>> probably be used for this. I was not awa
On Mon, 30 Sep 2013, Jakub Jelinek wrote:
> Hi!
>
> Apparently sign_bit_p looks through both sign and zero extensions.
> That is just fine for the single bit test optimization, where we know the
> constant is a power of two, and it is (A & power_of_two) == 0 (or != 0)
> test. sign_bit_p is also
On Mon, 30 Sep 2013, Jakub Jelinek wrote:
> Hi!
>
> Related to the last patch, this handles also BOOLEAN_TYPE and
> ENUMERAL_TYPE the same as INTEGER_TYPE in tree_unary_nonnegative_warnv_p,
> which means we e.g. fold properly the (int) (x != 0 && y != 0) < 0
> when (x != 0 && y != 0) has BOOLEAN_
Hi!
Related to the last patch, this handles also BOOLEAN_TYPE and
ENUMERAL_TYPE the same as INTEGER_TYPE in tree_unary_nonnegative_warnv_p,
which means we e.g. fold properly the (int) (x != 0 && y != 0) < 0
when (x != 0 && y != 0) has BOOLEAN_TYPE.
Bootstrapped/regtested on x86_64-linux and i686-
Hi!
Apparently sign_bit_p looks through both sign and zero extensions.
That is just fine for the single bit test optimization, where we know the
constant is a power of two, and it is (A & power_of_two) == 0 (or != 0)
test. sign_bit_p is also used to check for minimum value of some integral
type,
Hello all,
Sorry for my last patch that cause some test regressions. I have correct
it, and it has been tested for arm-none-eabi on the model.
This patch will replace all explicit calls to gen_rtx_PLUS and GEN_INT
with plus_constant.
OK for trunk?
Kind regards,
Renlin Li
gcc/ChangeLog:
2
Hello all,
Sorry for my last patch that cause some test regressions. I have correct
it, and it has been tested for aarch64-none-elf on the model.
This patch will replace all explicit calls to gen_rtx_PLUS and GEN_INT
with plus_constant.
OK for trunk?
Kind regards,
Renlin Li
gcc/ChangeLog:
On Mon, Sep 30, 2013 at 05:04:23PM +0400, Ilya Tocar wrote:
> On 27 Sep 12:08, Jakub Jelinek wrote:
>
> Looks like you forgot some files. I've checked
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=202968
> And e. g. hashtab.h is missing. So currently branch is failing to build,
> with ta
Ian Lance Taylor writes:
> Following up on my earlier patch, this patch implements the
> reflect.MakeFunc function for 386.
>
> Tom Tromey pointed out to me that the libffi closure support can
> probably be used for this. I was not aware of that support. It
> supports a lot more processors, and
On 27 Sep 12:08, Jakub Jelinek wrote:
Looks like you forgot some files. I've checked
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=202968
And e. g. hashtab.h is missing. So currently branch is failing to build,
with task.c:46:21: fatal error: hashtab.h: No such file or directory
> Here is
On 27/09/13 17:08, Steve Ellcey wrote:
On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote:
I'm in two minds about whether further sticky tape of this form is the
right approach or whether the original patch should be reverted until a
proper fix that does not regress the tree can be found
Hi Jan,
Here is a patch we've talked about recently - it merges expanders of memset and
memmov. As a natural side effect, this enables vector_loop in memset expanding
as well.
Though in some places merging movmem and setmem isn't so efficient (the original
code in these versions differed a lot),
This fixes PR58554, pattern recognition in loop distribution now
needs to check whether all stmts are unconditionally executed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2013-09-30 Richard Biener
PR tree-optimization/58554
* tree-loop-di
On Sun, Sep 29, 2013 at 11:08 AM, Richard Sandiford
wrote:
> Michael Matz writes:
>>Trever Saunders writes:
>>> Richard Biener writes:
>>> > Btw, I've come around multiple coding-styles in the past and I
>>> > definitely would prefer m_mode / m_count to mark members vs. mode_ and
>>> > count_.
Hi,
while looking into schedules produced for Buldozer and Core I noticed that they
do not seem to match reality. This is because ix86_issue_rate limits those CPUs
into 3 instructions per cycle, while they are designed to do 4 and somewhat
confused ix86_adjust_cost.
I also added stack engine int
Hello,
This patch adds support to generate SADDL/SSUBL/UADDL/USUBL. Part of the support
is available already (supported for intrinsics). This patch extends this support
to generate these instructions (and lane variations) in all scenarios and adds a
testcase. Tested for aarch64-none-elf, aarch64_b
Hi Richard, David,
In principle yes. Note that it changes the behavior of -O2 -ftree-vectorize
as -ftree-vectorize does not imply changing the default cost model. I am
fine with that, but eventually this will have some testsuite fallout.
Indeed I am observing a regression with this patch on ar
On Sep 24, 2013, at 8:51 PM, Richard Henderson wrote:
> On 09/03/2013 07:08 AM, Tristan Gingold wrote:
>> Hi,
>>
>> The field state->ehp_region wasn't updated before lowering constructs in the
>> eh
>> path of EH_ELSE. As a consequence, __builtin_eh_pointer is lowered to 0 (or
>> possibly to
On 30 September 2013 09:52, James Greenhalgh wrote:
>
> Hi,
>
> aarch64-common.c. These functions expect a particular form
You meant aarch-common.c here and in the title ;-)
This is fine by me, but as a config/arm/ change needs OK from Ramana or Richard.
/Marcus
> 2013-09-30 James Greenhalgh
> 1. For cmp/test with rip-relative addressing mem operand, don't group
> insns. Bulldozer also doesn't support fusion for cmp/test with both
> displacement MEM and immediate operand, while m_CORE_ALL doesn't
> support fusion for cmp/test with MEM and immediate operand. I simplify
> choose to u
Hi,
The patch enhances phiopt to handle cases like:
if (a == 0 && (...))
return 0;
return a;
Boot strap and no make check regression on X86-64 and ARM.
Is it OK for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2013-09-30 Zhenqiang Chen
* tree-ssa-phiopt.c (operand_equal_for_phi_ar
Hi,
My commit r203019 contained an oversight which is fixed by the obvious patch
below.
tested on cross to powerpc-linux-gnu and a build of cc1 for AIX-6.1.3 (and
stage1 for powerpc-darwin9).
applied as r203027
Apologies for the breakage, and that this slipped through my usual testing,
Iain
g
Hi,
Recently I've found myself getting a number of segfaults from
code calling in to the arm_early_load/alu_dep functions in
aarch64-common.c. These functions expect a particular form
for the RTX patterns they work over, but some of them do
not validate this form.
This patch fixes that, removing
On 28 September 2013 11:57, Venkataramanan Kumar
wrote:
> 2013-10-28 Venkataramanan Kumar
>
>* config/aarch64/aarch64.h (MCOUNT_NAME): Define.
>(NO_PROFILE_COUNTERS): Likewise.
>(PROFILE_HOOK): Likewise.
>(FUNCTION_PROFILER): Likewise.
>* config/aarch64
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
> My example in this form would look something like:
> int unsignedsrcp = ptrvar.type().type().type_unsigned();
>
> <...>
> GimpleType t1 = ptrvar.type ();
> GimpleType t2 = t1.type ();
Stop that CamelCase dyslexia already, will you? ;-)
Ciao,
M
Il 27/09/2013 21:45, Gerald Pfeifer ha scritto:
> I believe this may be breaking all my testers on FreeBSD
> (i386-unknown-freebsd10.0 for example). The timing of when this
> patchset went in fits pretty much when my builds started to break
> and I am wondering about some code.
>
> Here is the f
This fixes PR58532, a bootstrap-debug issue with -O3. Debug stmts
got in the way of adding abnormal edges during inlining.
Bootstrapped on x86_64-unkown-linux-gnu (with -O3 and default flags),
committed to trunk.
Richard.
2013-09-30 Richard Biener
PR middle-end/58532
* tree
63 matches
Mail list logo
