Unfortunately, only 64-bit versions of popc and lzd exist, so I have
to play some shenanigans to make SImode and v8plus cases work. But
it's definitely worth it. I plan to tweak this stuff and perhaps also
add some explicit ffs patterns as well later.
There are only two sets of VIS3
On 5 October 2011 20:06, Jakub Jelinek ja...@redhat.com wrote:
Hi!
If vect_recog_func fails (or the other spot where vect_pattern_recog_1
returns early), the vector allocated in the function isn't freed, leading
to memory leak. But, more importantly, doing a VEC_alloc + VEC_free
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
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
On Wed, Oct 5, 2011 at 6:53 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Oct 5, 2011 at 11:28, Diego Novillo dnovi...@google.com wrote:
On Wed, Oct 5, 2011 at 10:51, Richard Guenther
richard.guent...@gmail.com wrote:
Did you also mark the function with always_inline? That's a
On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Oct 5, 2011 at 14:20, Mike Stump mikest...@comcast.net 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
On 4 October 2011 16:13, Ulrich Weigand uweig...@de.ibm.com wrote:
Ramana Radhakrishnan wrote:
On 26 September 2011 15:24, Ulrich Weigand uweig...@de.ibm.com 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
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
On Thu, Oct 6, 2011 at 11:28 AM, Kai Tietz kti...@redhat.com 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
On Wed, Oct 5, 2011 at 11:07 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 10/05/2011 10:46 AM, Richard Guenther wrote:
On Tue, Oct 4, 2011 at 6:28 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 10/04/2011 03:03 PM, Richard Guenther wrote:
On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries
2011/10/6 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 6, 2011 at 11:28 AM, Kai Tietz kti...@redhat.com 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
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[n], p-c[n],
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
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 around.
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 rguent...@suse.de
* fold-const.c (fold_ternary_loc): Also fold non-constant
vector CONSTRUCTORs.
On Tue, Oct 4, 2011 at 5:46 AM, Pedro Alves pe...@codesourcery.com 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
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.
Also, if
On Tue, Oct 4, 2011 at 1:24 PM, Douglas Rupp r...@gnat.com 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 already a
Richard Guenther schrieb:
On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay a...@gjlay.de 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
On Thu, Oct 6, 2011 at 1:03 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther schrieb:
On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay a...@gjlay.de wrote:
Artem Shinkarov schrieb:
Hi, Richard
There is a problem with the testcases of the patch you have committed
for me. The code
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 andreas.kreb...@de.ibm.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
*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
On Thu, Oct 6, 2011 at 2:55 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Oct 6, 2011 at 2:51 PM, Kirill Yukhin kirill.yuk...@gmail.com 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
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
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
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
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 don't think it must be
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, 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 CSE
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 m...@suse.de 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,
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
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 rguent...@suse.de
* tree-vect-generic.c (vector_element): Look at previous
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 kti...@redhat.com
*
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_DEF_STMT
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
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 same for
Hi,
tested x86_64-linux, committed.
Paolo.
2011-10-06 Paolo Carlini paolo.carl...@oracle.com
* 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.
*
2011/10/6 Michael Matz m...@suse.de:
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
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 a
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
On Thu, Oct 6, 2011 at 4:59 PM, Michael Matz m...@suse.de 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 get
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
2011/10/6 Michael Matz m...@suse.de:
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.
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 (a1 a2
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 completed -
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, the
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
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
Bernd Schmidt ber...@codesourcery.com 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
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
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.
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 ja...@redhat.com
* tree-vect-patterns.c
---
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
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 a...@gjlay.de
---
On Thu, 2011-10-06 at 16:16 +0200, Richard Guenther wrote:
snip
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
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 (op, 1))
On 6 October 2011 18:17, Jakub Jelinek ja...@redhat.com 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
On 6 October 2011 18:19, Jakub Jelinek ja...@redhat.com 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.
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. I
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.
Ok.
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
On Wed, Oct 5, 2011 at 6:48 AM, Richard Guenther rguent...@suse.de 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
-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 might
2011/10/6 Michael Matz m...@suse.de:
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)
-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 ja...@redhat.com 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,
On 10/05/2011 11:41 PM, David Miller wrote:
+(define_expand popcountmode2
+ [(set (match_operand:SIDI 0 register_operand )
+(popcount:SIDI (match_operand:SIDI 1 register_operand )))]
+ TARGET_POPC
+{
+ if (! TARGET_ARCH64)
+{
+ emit_insn (gen_popcountmode_v8plus
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
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
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
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
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:
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 IVOPTs
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/11 12:02, William J. Schmidt wrote:
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
On 10/06/2011 11:03 AM, Bernd Schmidt wrote:
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])))
On 10/06/11 20:13, Richard Henderson wrote:
What PR are you looking at here?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50632
Testcase is gcc.dg/pr50132.c.
Bernd
From: Richard Henderson r...@redhat.com
Date: Thu, 06 Oct 2011 10:47:28 -0700
You've said that POPC only operates on the full 64-bit register,
but I see no zero-extend of the SImode input? Similarly for
the clzsi patterns.
Thanks for catching this.
I guess if I emit the zero-extend, the
On Tue, Oct 4, 2011 at 3:10 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 09/30/11 18:51, Richard Henderson wrote:
Please do leave out RETURN_ADDR_REGNUM for now. If you remember why,
then you could bring it back alongside the patch for the ARM backend.
Changed.
As for the i386
On 10/06/11 20:27, H.J. Lu wrote:
It also caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
Don't you need to update ix86_expand_prologue?
In theory it should just work. It seems the x32 stuff has entertaining
properties :-( Haven't quite figured out how to build it yet, but:
-
On Oct 6, 2011, at 1:58 AM, Richard Guenther wrote:
On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo dnovi...@google.com wrote:
What's the other advantage of using inline functions? The gdb
annoyance with the macros can be solved with the .gdbinit macro
defines (which might be nice to commit to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/11 12:46, Mike Stump wrote:
On Oct 6, 2011, at 1:58 AM, Richard Guenther wrote:
On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo
dnovi...@google.com wrote: What's the other advantage of using
inline functions? The gdb annoyance with the
On Thu, Oct 6, 2011 at 11:40 AM, Bernd Schmidt ber...@codesourcery.com wrote:
On 10/06/11 20:27, H.J. Lu wrote:
It also caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
Don't you need to update ix86_expand_prologue?
In theory it should just work. It seems the x32 stuff has
Tested on x86_64-pc-linux-gnu, committed on trunk
If the compiler detects a floating division by zero,
it was unconditionally issuing a warning and raising a
constraint_error. This is wrong behavior for the case of an
unconstained floating point type. This patch corrects that
behavior as shown by
On Oct 6, 2011, at 11:53 AM, Jeff Law wrote:
Presumably it hasn't been included because not all gdb's understand
those bits and we typically don't build with -g3.
Personally, the accessors I use are muscle-memory... Which works
great until someone buries everything a level deeper :(
Yeah,
1 - 100 of 122 matches
Mail list logo
