On 6 October 2011 02:57, Paolo Carlini wrote:
>
> today I ran the whole testsuite in C++0x mode and I'm pretty sure that
> 23_containers/vector/modifiers/swap/3.cc, which is now failing, wasn't a
> couple of days ago (I ran the whole testsuite like that in order to validate
> my std::list changes).
On 10/05/2011 10:16 PM, William J. Schmidt wrote:
OK, I see. If there's a better place downstream to make a swizzle, I'm
certainly fine with that.
I disabled locally_poor_mem_replacement and added some dump information
in should_replace_address to show the costs for the replacement I'm
trying t
This handles the case of CSEing part of an SSA name that is stored
to memory and defined with a composition like COMPLEX_EXPR or
CONSTRUCTOR. This fixes the remaining pieces of PR38884 and
PR38885.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-10-06 Rich
On Wed, Oct 5, 2011 at 6:53 PM, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 11:28, Diego Novillo wrote:
>> On Wed, Oct 5, 2011 at 10:51, Richard Guenther
>> wrote:
>>
>>> Did you also mark the function with always_inline? That's a requirement
>>> as artificial only works for inlined function
On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 14:20, Mike Stump wrote:
>> On Oct 5, 2011, at 6:18 AM, Diego Novillo wrote:
>>> I think we need to find a solution for this situation.
>>
>> The solution Apple found and implemented is a __nodebug__ attribute, as can
On 4 October 2011 16:13, Ulrich Weigand wrote:
> Ramana Radhakrishnan wrote:
>> On 26 September 2011 15:24, Ulrich Weigand wrote:
>> > Is this sufficient, or should I test any other set of options as well?
>>
>> Could you run one set of tests with neon ?
>
> Sorry for the delay, but I had to swit
Hello,
this patch improves in fold_truth_andor the generation of branch-conditions for
targets having LOGICAL_OP_NON_SHORT_CIRCUIT set. If right-hand side operation
of a TRUTH_(OR|AND)IF_EXPR is simple operand, has no side-effects, and doesn't
trap, then try to convert expression to a TRUTH_(A
Hello,
Sorry attached non-updated change. Here with proper attached patch.
This patch improves in fold_truth_andor the generation of branch-conditions for
targets having LOGICAL_OP_NON_SHORT_CIRCUIT set. If right-hand side operation
of a TRUTH_(OR|AND)IF_EXPR is simple operand, has no side-eff
On Thu, Oct 6, 2011 at 11:28 AM, Kai Tietz wrote:
> Hello,
>
> Sorry attached non-updated change. Here with proper attached patch.
> This patch improves in fold_truth_andor the generation of branch-conditions
> for targets having LOGICAL_OP_NON_SHORT_CIRCUIT set. If right-hand side
> operation
On Wed, Oct 5, 2011 at 11:07 PM, Tom de Vries wrote:
> On 10/05/2011 10:46 AM, Richard Guenther wrote:
>> On Tue, Oct 4, 2011 at 6:28 PM, Tom de Vries wrote:
>>> On 10/04/2011 03:03 PM, Richard Guenther wrote:
On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries
wrote:
> On 10/01/2011 05:
2011/10/6 Richard Guenther :
> On Thu, Oct 6, 2011 at 11:28 AM, Kai Tietz wrote:
>> Hello,
>>
>> Sorry attached non-updated change. Here with proper attached patch.
>> This patch improves in fold_truth_andor the generation of branch-conditions
>> for targets having LOGICAL_OP_NON_SHORT_CIRCUIT s
On Thu, Oct 6, 2011 at 11:38 AM, Kirill Yukhin wrote:
> Thanks for review. I did all but one
>
>> you have disabled all tests on ia32 - unconditionally use "-O2 -mfma
>> -mfpmath=sse" for dg-options, and these instructions will magically
>> appear on all targets.
>
> I am enabling these tests to
On Wed, 5 Oct 2011, William J. Schmidt wrote:
> This patch addresses the poor code generation in PR46556 for the
> following code:
>
> struct x
> {
> int a[16];
> int b[16];
> int c[16];
> };
>
> extern void foo (int, int, int);
>
> void
> f (struct x *p, unsigned int n)
> {
> foo (p->a
On 10/06/2011 02:03 AM, Paolo Carlini wrote:
Hi,
the below hunk seems spurious?!?
... I went ahead and reverted the change, wasn't documented anywhere,
definitely unintended.
Paolo.
Paolo Bonzini writes:
> On 09/22/2011 08:18 PM, Rainer Orth wrote:
>> [build] Move gthr to toplevel libgcc
>> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00762.html
>
> Can you post an updated patch for this one? I'll try to review the others
> as soon as possible.
Do you see a c
On 10/06/2011 12:21 PM, Rainer Orth wrote:
> Can you post an updated patch for this one? I'll try to review the others
> as soon as possible.
Do you see a change to get the other patches reviewed before stage1
closes? I'd like to get them into 4.7 rather than carry them forward
for several m
Hi Richard,
The SMIN pattern has the same problem.
*sigh* Fixed.
Cheers
Nick
On 10/06/11 05:17, Ian Lance Taylor wrote:
> Thinking about it I think this is the wrong approach. The -fsplit-stack
> code by definition has to wrap the entire function and it can not modify
> any callee-saved registers. We should do shrink wrapping before
> -fsplit-stack, not the other way arou
Noticed when working on vector/complex folding and simplification.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-10-06 Richard Guenther
* fold-const.c (fold_ternary_loc): Also fold non-constant
vector CONSTRUCTORs. Make more efficient.
On Tue, Oct 4, 2011 at 5:46 AM, Pedro Alves wrote:
> On Tuesday 04 October 2011 11:16:30, Gabriel Dos Reis wrote:
>
>> > Do we need to consider ABIs that have calling conventions that
>> > treat unprototyped and varargs functions differently? (is there any?)
>>
>> Could you elaborate on the equiva
Artem Shinkarov schrieb:
> Hi, Richard
>
> There is a problem with the testcases of the patch you have committed
> for me. The code in every test-case is doubled. Could you please,
> apply the following patch, otherwise it would fail all the tests from
> the vector-shuffle-patch would fail.
>
> A
On Tue, Oct 4, 2011 at 1:24 PM, Douglas Rupp wrote:
> On 10/3/2011 8:35 AM, Gabriel Dos Reis wrote:
>>
>> "unnamed variadic functions" sounds as if the function itself is
>> unnamed, so not good.
>>
>>
>> -funnamed-variadic-parameter
>
> How about
> -fvariadic-parameters-unnamed
>
> there's alread
On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
> Artem Shinkarov schrieb:
>> Hi, Richard
>>
>> There is a problem with the testcases of the patch you have committed
>> for me. The code in every test-case is doubled. Could you please,
>> apply the following patch, otherwise it would fail
Richard Guenther schrieb:
> On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
>> Artem Shinkarov schrieb:
>>> Hi, Richard
>>>
>>> There is a problem with the testcases of the patch you have committed
>>> for me. The code in every test-case is doubled. Could you please,
>>> apply the followi
On Thu, Oct 6, 2011 at 1:03 PM, Georg-Johann Lay wrote:
> Richard Guenther schrieb:
>> On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
>>> Artem Shinkarov schrieb:
Hi, Richard
There is a problem with the testcases of the patch you have committed
for me. The code in ev
On Thu, Oct 06, 2011 at 12:51:54PM +0200, Georg-Johann Lay wrote:
> The following patch avoids __SIZEOF_INT__.
>
> Ok by some maintainer to commit?
That is unnecessary. You can just add
#else
int
main ()
{
return 0;
}
before the final #endif in the files instead.
Or move around the #ifdefs, so
Hi,
this fixes a bootstrap problem on s390. s390 doesn't have "return"
nor "simple_return" expanders so the last_bb_active variable stays
unused in thread_prologue_and_epilogue_insns.
Committed to mainline as obvious.
Bye,
-Andreas-
2011-10-06 Andreas Krebbel
* function.c (thread
Richard Guenther schrieb:
> On Thu, Oct 6, 2011 at 1:03 PM, Georg-Johann Lay wrote:
>> Richard Guenther schrieb:
>>> On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
Artem Shinkarov schrieb:
> Hi, Richard
>
> There is a problem with the testcases of the patch you have com
On 11-10-06 04:58 , Richard Guenther wrote:
I know you are on to that C++ thing and ending up returning a reference
to make it an lvalue. Which I very much don't like (please, if you go
that route add _set functions and lower the case of the macros).
Not necessarily. I'm after making the deb
*ping*
http://gcc.gnu.org/ml/fortran/2011-09/msg00160.html
On 09/30/2011 10:50 AM, Tobias Burnus wrote:
Dear all,
with the following change in 4.5, the -Walign-commons warning got
disabled:
"The |COMMON| default padding has been changed – instead of adding the
padding before a variable it i
*ping*
http://gcc.gnu.org/ml/fortran/2011-09/msg00150.html
On 09/28/2011 04:28 PM, Tobias Burnus wrote:
This patch makes the GCC extension __float128 (_Complex) available in
the C bindings via C_FLOAT128 and C_FLOAT128_COMPLEX.
Additionally, I have improved the diagnostic for explicitly use
a
On 10/1/2011 22:31, JonY wrote:
> On 10/1/2011 19:16, Paolo Carlini wrote:
>> Hi,
>>
>>> Thanks, but I am having problems sending a proper diff with the
>>> regenerated files, they have a lot of unrelated, even if I made sure I
>>> am using autoconf 2.64 and automake 1.11.1.
>>
>> To be clear, rege
On Thu, Oct 6, 2011 at 2:51 PM, Kirill Yukhin wrote:
> Wow, it works!
>
> Thank you. New patch attached.
> ChangeLogs were not touched.
>
> Tests pass both on ia32/x86-64 with and without simulator.
You are missing closing curly braces in dg-do compile directives.
Also, please write:
TYPE __att
On Thu, Oct 6, 2011 at 2:55 PM, Uros Bizjak wrote:
> On Thu, Oct 6, 2011 at 2:51 PM, Kirill Yukhin wrote:
>> Wow, it works!
>>
>> Thank you. New patch attached.
>> ChangeLogs were not touched.
>>
>> Tests pass both on ia32/x86-64 with and without simulator.
>
> You are missing closing curly brace
On Thu, 2011-10-06 at 09:47 +0200, Paolo Bonzini wrote:
> And IIUC the other address is based on pseudo 125 as well, but the
> combination is (plus (plus (reg 126) (reg 128)) (const_int X)) and
> cannot be represented on ppc. I think _this_ is the problem, so I'm
> afraid your patch could cause
This corrects a brain fart in one of my patches last year: I added
another alternative to a subsi for subtraction of a constant. This is
bogus because such an operation should be canonicalized to a PLUS with
the negative constant, Normally that's what happens, and so testing
never showed that the a
On 10/06/2011 03:02 PM, Michael Meissner wrote:
On the x86 (with Fedora 13), I built and tested the C, C++, Objective C, Java,
Ada,
and Go languages with no regressions
On a power6 box with RHEL 6.1, I
have done the same for C, C++, Objective C, Java, and Ada languages with no
regressions.
As reported in the PR, FreeBSD/SPARC bootstrap is broken by one of my
previous libgcc patches. While the crtstuff one will fix it, I'd like
to avoid breaking the target.
The following patch fixes the problem, as confirmed in the PR.
Ok for mainline?
Rainer
2011-10-04 Rainer Orth
On 10/06/2011 03:29 PM, Rainer Orth wrote:
As reported in the PR, FreeBSD/SPARC bootstrap is broken by one of my
previous libgcc patches. While the crtstuff one will fix it, I'd like
to avoid breaking the target.
The following patch fixes the problem, as confirmed in the PR.
Ok for mainline?
Hi,
On Wed, 5 Oct 2011, Richard Henderson wrote:
> Tested on x86_64 with
>
> check-gcc//unix/{,-mssse3,-msse4}
>
> Hopefully one of the AMD guys can test on a bulldozer with -mxop?
=== gcc Summary for unix//-mxop ===
# of expected passes160
Ciao,
Michael.
On Thu, 2011-10-06 at 12:13 +0200, Richard Guenther wrote:
> People have already commented on pieces, so I'm looking only
> at the tree-ssa-reassoc.c pieces (did you consider piggy-backing
> on IVOPTs instead? The idea is to expose additional CSE
> opportunities, right? So it's sort-of a strength
On 10/06/11 01:47, Bernd Schmidt wrote:
> This appears to be because the split prologue contains a jump, which
> means the find_many_sub_blocks call reorders the block numbers, and our
> indices into bb_flags are off.
Testing of the patch completed - ok? Regardless of split-stack it seems
like a c
>
> BTW, don't you also need "-mfmpath=sse" in dg-options?
>
According to doc/invoke.texi
...
@itemx -mfma
...
These options will enable GCC to use these extended instructions in
generated code, even without @option{-mfpmath=sse}.
Seems it -mfpmath=sse is useless..
Although, if this is wrong, we
Hi,
On Thu, 6 Oct 2011, Richard Guenther wrote:
> > + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
> > + && TREE_CODE (arg1) != TRUTH_NOT_EXPR)
> > + || !FLOAT_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1, 0)
>
> ? simple_operand_p would have rejected both ! and
On Oct 3, 2011, at 10:23 PM, Joseph S. Myers wrote:
> On Mon, 3 Oct 2011, Douglas Rupp wrote:
>
>> On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
>>> On Fri, 30 Sep 2011, Tristan Gingold wrote:
>>>
If you prefer a target hook, I'm fine with that. I will write such a
patch.
I
The appended patch adds a few macros that XLC now defines on AIX.
- David
* config/rs6000/aix.h (TARGET_OS_AIX_CPP_BUILTINS): Define
__powerpc__, __PPC__, __unix__.
Index: aix.h
===
--- aix.h (revision 179610)
On Thu, 6 Oct 2011, Tristan Gingold wrote:
> So the consensus is for a dedicated option. Which one do you prefer ?
>
> -funnamed-variadic-parameter
> -fpointless-variadic-functions
> -fallow-parameterless-variadic-functions
I prefer -fallow-parameterless-variadic-functions.
--
Joseph S. Myers
On Thu, 6 Oct 2011, William J. Schmidt wrote:
> On Thu, 2011-10-06 at 12:13 +0200, Richard Guenther wrote:
> > People have already commented on pieces, so I'm looking only
> > at the tree-ssa-reassoc.c pieces (did you consider piggy-backing
> > on IVOPTs instead? The idea is to expose additional
Hi!
If the second argument of gimple_build_assign_with_ops is an SSA_NAME,
gimple_build_assign_with_ops_stat calls gimple_assign_set_lhs
which does
if (lhs && TREE_CODE (lhs) == SSA_NAME)
SSA_NAME_DEF_STMT (lhs) = gs;
so the SSA_NAME_DEF_STMT assignments in tree-vect-patterns.c aren't needed
On Thu, Oct 6, 2011 at 3:49 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 6 Oct 2011, Richard Guenther wrote:
>
>> > + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
>> > + && TREE_CODE (arg1) != TRUTH_NOT_EXPR)
>> > + || !FLOAT_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1, 0
Hi!
The 3 functions in builtins.c that dispatch builtin folding give up
if avoid_folding_inline_builtin (fndecl) returns true, because we
want to wait with those functions until they are inlined (which for
-D_FORTIFY_SOURCE contains security checks). Unfortunately
gimple_fold_builtin calls fold_b
This makes us lookup previous intermediate vector results when
decomposing a operation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-10-06 Richard Guenther
* tree-vect-generic.c (vector_element): Look at previous
generated results.
In
Hi,
I modified the patch so, that it always just converts two leafs of a
TRUTH(AND|OR)IF chain into a TRUTH_(AND|OR) expression, if branch costs are
high and leafs are simple without side-effects.
Additionally I added some testcases for it.
2011-10-06 Kai Tietz
* fold-const.c (fold
On Thu, 6 Oct 2011, Jakub Jelinek wrote:
> Hi!
>
> If the second argument of gimple_build_assign_with_ops is an SSA_NAME,
> gimple_build_assign_with_ops_stat calls gimple_assign_set_lhs
> which does
> if (lhs && TREE_CODE (lhs) == SSA_NAME)
> SSA_NAME_DEF_STMT (lhs) = gs;
> so the SSA_NAME_
Hi!
CAST_RESTRICT based disambiguation unfortunately isn't reliable,
e.g. to store a non-restrict pointer into a restricted field,
we add a non-useless cast to restricted pointer in the gimplifier,
and while we don't consider that field to have a special restrict tag
because it is unsafe to do so,
On Thu, Oct 06, 2011 at 03:23:07PM +0200, Tobias Burnus wrote:
> On 10/06/2011 03:02 PM, Michael Meissner wrote:
> >On the x86 (with Fedora 13), I built and tested the C, C++, Objective C,
> >Java, Ada,
> >and Go languages with no regressions
>
> >On a power6 box with RHEL 6.1, I
> >have done the
Hi,
tested x86_64-linux, committed.
Paolo.
2011-10-06 Paolo Carlini
* testsuite/27_io/ios_base/cons/assign_neg.cc: Tidy dg- directives,
for C++0x testing too.
* testsuite/27_io/ios_base/cons/copy_neg.cc: Likewise.
* testsuite/ext/pb_ds/exampl
2011/10/6 Michael Matz :
> Hi,
>
> On Thu, 6 Oct 2011, Richard Guenther wrote:
>
>> > + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
>> > + && TREE_CODE (arg1) != TRUTH_NOT_EXPR)
>> > + || !FLOAT_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1, 0)
>>
>> ? simple_operan
On Thu, 6 Oct 2011, Jakub Jelinek wrote:
> Hi!
>
> CAST_RESTRICT based disambiguation unfortunately isn't reliable,
> e.g. to store a non-restrict pointer into a restricted field,
> we add a non-useless cast to restricted pointer in the gimplifier,
> and while we don't consider that field to have
Hi,
On Sat, 3 Sep 2011, Richard Guenther wrote:
> > OTOH it's a nice invariant that can actually be checked for (that all
> > reachable vars whatsoever have to be in referenced_vars), so I'm going
> > to do that.
>
> Yes, until we get rid of referenced_vars (which we still should do at
> some
This patch is a follow-up both to my patches here:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00049.html
and Paul Brook's patch here:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01076.html
The patch fixes both the original problem, in which negative shift
constants caused an ICE (pr501
On Thu, Oct 6, 2011 at 4:59 PM, Michael Matz wrote:
> Hi,
>
> On Sat, 3 Sep 2011, Richard Guenther wrote:
>
>> > OTOH it's a nice invariant that can actually be checked for (that all
>> > reachable vars whatsoever have to be in referenced_vars), so I'm going
>> > to do that.
>>
>> Yes, until we ge
Hi,
On Thu, 6 Oct 2011, Kai Tietz wrote:
> That's not the hole story. The difference between TRUTH_(AND|OR)IF_EXPR
> and TRUTH_(AND|OR)_EXPR are, that for TRUTH_(AND|OR)IF_EXPR gimplifier
> creates a COND expression, but for TRUTH_(AND|OR)_EXPR it doesn't.
Yes, of course. That is what implem
2011/10/6 Michael Matz :
> Hi,
>
> On Thu, 6 Oct 2011, Kai Tietz wrote:
>
>> That's not the hole story. The difference between TRUTH_(AND|OR)IF_EXPR
>> and TRUTH_(AND|OR)_EXPR are, that for TRUTH_(AND|OR)IF_EXPR gimplifier
>> creates a COND expression, but for TRUTH_(AND|OR)_EXPR it doesn't.
>
> Y
On Thu, Oct 06, 2011 at 05:28:36PM +0200, Kai Tietz wrote:
> None. I had this implemented first. But Richard was concerned about
> making non-IF conditions too long.I understand that point that it
> might not that good to always modify unconditionally to AND/OR chain.
> For example
>
> if (a
On 10/06/2011 06:37 AM, Bernd Schmidt wrote:
> On 10/06/11 01:47, Bernd Schmidt wrote:
>> This appears to be because the split prologue contains a jump, which
>> means the find_many_sub_blocks call reorders the block numbers, and our
>> indices into bb_flags are off.
>
> Testing of the patch compl
On 10/06/2011 04:46 AM, Georg-Johann Lay wrote:
> So here it is. Lightly tested on my target: All tests either PASS or are
> UNSUPPORTED now.
>
> Ok?
Not ok, but only because I've completely restructured the tests again.
Patch coming very shortly...
r~
Hi,
On Thu, 6 Oct 2011, Kai Tietz wrote:
> > at which point this association doesn't make sense anymore, as
>
> Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and
> therefore it isn't transformed into and AND.
Right ...
> > ((W AND X) AND Y) AND Z
> >
> > is just as fine. So
This patch supplies __sync_mem_is_lock_free (size) and
__sync_mem_always_lock_free (size).
__sync_mem_always_lock_free requires a compile time constant, and
returns true if an object of the specified size will *always* generate
lock free instructions on the current architecture. Otherwise fal
After almost two months, two tests are still XPASSing everywhere:
XPASS: gcc.dg/uninit-B.c uninit i warning (test for warnings, line 12)
XPASS: gcc.dg/uninit-pr19430.c (test for warnings, line 32)
XPASS: gcc.dg/uninit-pr19430.c uninitialized (test for warnings, line 41)
I think it's time to remo
Bernd Schmidt writes:
> On 10/06/11 05:17, Ian Lance Taylor wrote:
>> Thinking about it I think this is the wrong approach. The -fsplit-stack
>> code by definition has to wrap the entire function and it can not modify
>> any callee-saved registers. We should do shrink wrapping before
>> -fsplit
On 10/06/11 17:57, Ian Lance Taylor wrote:
> There is absolutely no reason to try to shrink wrap that code. It will
> never help. That code always has to be first. It especially has to be
> first because the gold linker recognizes the prologue specially when a
> split-stack function calls a non-
Hi!
Since Richard's changes recently to allow different modes in vcond
patterns (so far on i?86/x86_64 only I think) we can vectorize more
COND_EXPRs than before, and this patch improves it a tiny bit more
- even i?86/x86_64 support vconds only if the sizes of vector element
modes are the same. W
Hi!
tree-vectorizer.h already has typedefs for the recog functions,
and using that typedef we can make these two functions slightly more
readable.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-10-06 Jakub Jelinek
* tree-vect-patterns.c (vect_pattern_recog_
---
gcc/ChangeLog |5 +
gcc/optabs.c | 16 +++-
2 files changed, 12 insertions(+), 9 deletions(-)
* optabs.c (expand_vec_shuffle_expr): Use the proper mode for the
mask operand. Tidy the code.
This patch is required before I rearrange the testsuite to actu
This allows the use of blendvpd instead of pblendvb on the
final step. I don't *really* know if this helps or hurts
with the re-interpretation of the data from byte data to
double data. But it looks "nicer" anyway.
r~
---
gcc/ChangeLog |6 ++
gcc/config/i386/i386.c | 28 +++
This was tested only via compile, and inspecting the output.
I'm attempting to set up the Intel SDE as a sim target for
the testsuite, but apparently it only supports 32-bit binaries.
r~
---
gcc/ChangeLog |9
gcc/config/i386/i386.c | 112
Test vector sizes 8, 16, and 32. Test most data types for each size.
This should also solve the problem that Georg reported for AVR.
Indeed, I hope that except for the DImode/DFmode tests, these
actually execute on that target.
r~
Cc: Georg-Johann Lay
---
gcc/testsuite/ChangeLog
On Thu, 2011-10-06 at 16:16 +0200, Richard Guenther wrote:
>
> Doh, I thought you were matching gimple stmts that do the address
> computation. But now I see you are matching the tree returned from
> get_inner_reference. So no need to check anything for that case.
>
> But that keeps me wonde
> I believe this patch to be nothing but an improvement over the current
> state, and that a fix to the constraint problem should be a separate patch.
>
> In that basis, am I OK to commit?
One minor nit:
> (define_special_predicate "shift_operator"
>...
>+ (ior (match_test "GET_CODE (XEXP (
On 6 October 2011 18:17, Jakub Jelinek wrote:
> Hi!
>
> Since Richard's changes recently to allow different modes in vcond
> patterns (so far on i?86/x86_64 only I think) we can vectorize more
> COND_EXPRs than before, and this patch improves it a tiny bit more
> - even i?86/x86_64 support vconds
On 6 October 2011 18:19, Jakub Jelinek wrote:
> Hi!
>
> tree-vectorizer.h already has typedefs for the recog functions,
> and using that typedef we can make these two functions slightly more
> readable.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Ira
>
>
On Thu, Oct 06, 2011 at 07:27:28PM +0200, Ira Rosen wrote:
> > + i = 1;
> > + if ((rhs_code == COND_EXPR || rhs_code == VEC_COND_EXPR)
>
> I don't understand why we need VEC_COND_EXPR here.
Only for completeness, as VEC_COND_EXPR is the same weirdo thingie like
COND_EXPR.
On 10/06/2011 09:19 AM, Jakub Jelinek wrote:
> * tree-vect-patterns.c (vect_pattern_recog_1): Use
> vect_recog_func_ptr typedef for the first argument.
> (vect_pattern_recog): Rename vect_recog_func_ptr variable
> to vect_recog_func, use vect_recog_func_ptr typedef for it.
On 10/06/2011 09:01 AM, Bernd Schmidt wrote:
> On 10/06/11 17:57, Ian Lance Taylor wrote:
>> There is absolutely no reason to try to shrink wrap that code. It will
>> never help. That code always has to be first. It especially has to be
>> first because the gold linker recognizes the prologue sp
On Wed, Oct 5, 2011 at 6:48 AM, Richard Guenther wrote:
>
> I'm testing a pair of patches to fix PR38885 (for constants)
> and PR38884 (for non-constants) stores to complex/vector memory
> and CSE of component accesses from SCCVN.
>
> This is the piece that handles stores from constants and partia
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/11 09:37, Jakub Jelinek wrote:
> On Thu, Oct 06, 2011 at 05:28:36PM +0200, Kai Tietz wrote:
>> None. I had this implemented first. But Richard was concerned
>> about making non-IF conditions too long.I understand that
>> point that it mi
2011/10/6 Michael Matz :
> Hi,
>
> On Thu, 6 Oct 2011, Kai Tietz wrote:
>
>> > at which point this association doesn't make sense anymore, as
>>
>> Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and
>> therefore it isn't transformed into and AND.
>
> Right ...
>
>> > ((W AND X) AND
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/11 04:13, Richard Guenther wrote:
>
> People have already commented on pieces, so I'm looking only at the
> tree-ssa-reassoc.c pieces (did you consider piggy-backing on IVOPTs
> instead? The idea is to expose additional CSE opportunities,
>
On 6 October 2011 19:28, Jakub Jelinek wrote:
> On Thu, Oct 06, 2011 at 07:27:28PM +0200, Ira Rosen wrote:
>> > + i = 1;
>> > + if ((rhs_code == COND_EXPR || rhs_code == VEC_COND_EXPR)
>>
>> I don't understand why we need VEC_COND_EXPR here.
>
> Only for completeness, as VE
On 10/05/2011 11:41 PM, David Miller wrote:
> +(define_expand "popcount2"
> + [(set (match_operand:SIDI 0 "register_operand" "")
> +(popcount:SIDI (match_operand:SIDI 1 "register_operand" "")))]
> + "TARGET_POPC"
> +{
> + if (! TARGET_ARCH64)
> +{
> + emit_insn (gen_popcount_v8p
Hi,
This is V3 of a series of 5 patches relating to ARM atomic operations;
they incorporate most of the feedback from V2. Note the patch numbering/
ordering is different from v2; the two simple patches are now first.
1) Correct the definition of TARGET_HAVE_DMB_MCR so that it doesn't
pr
gcc/
* config/arm/arm.c (TARGET_HAVE_DMB_MCR): MCR Not available in Thumb1
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 993e3a0..f6f1da7 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -288,7 +288,8 @@ extern void (*arm_lang_output_object_attributes_
Micahel K. Edwards points out in PR/48126 that the sync is in the wrong
place
relative to the branch target of the compare, since the load could float
up beyond the ldrex.
PR target/48126
* config/arm/arm.c (arm_output_sync_loop): Move label before
Add support for ARM 64bit sync intrinsics.
gcc/
* arm.c (arm_output_ldrex): Support ldrexd.
(arm_output_strex): Support strexd.
(arm_output_it): New helper to output it in Thumb2 mode only.
(arm_output_sync_loop): Support DI mode,
Add ARM 64bit sync helpers for use on older ARMs. Based on 32bit
versions but with check for sufficiently new kernel version.
gcc/
* config/arm/linux-atomic-64bit.c: New (based on linux-atomic.c)
* config/arm/linux-atomic.c: Change comment to point to 64bit version
Test support for ARM 64bit sync intrinsics.
gcc/testsuite/
* gcc.dg/di-longlong64-sync-1.c: New test.
* gcc.dg/di-sync-multithread.c: New test.
* gcc.target/arm/di-longlong64-sync-withhelpers.c: New test.
* gcc.target/arm/di-longlong64-sync-withldrexd.c: Ne
On Thu, 2011-10-06 at 11:35 -0600, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/06/11 04:13, Richard Guenther wrote:
>
> >
> > People have already commented on pieces, so I'm looking only at the
> > tree-ssa-reassoc.c pieces (did you consider piggy-backing on IVOPT
HJ found some more maybe_record_trace_start failures. In one case I
debugged, we have
(insn/f 31 0 32 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BL
Richard Henderson schrieb:
On 10/06/2011 04:46 AM, Georg-Johann Lay wrote:
So here it is. Lightly tested on my target: All tests either PASS or are
UNSUPPORTED now.
Ok?
Not ok, but only because I've completely restructured the tests again.
Patch coming very shortly...
Thanks, I hope your
1 - 100 of 135 matches
Mail list logo
