Hi,
this patch adds support for the 64x64->128 bit unsigned multiplication
to the s390 backend. We always the instruction but for some reason
forgot to add a pattern :(
Thanks to Torbjorn Granlund for the pointer!
Committed to mainline after testing on s390 and s390x.
Bye,
-Andreas-
2011-10-
On Wed, Oct 5, 2011 at 12:35 PM, Richard Guenther
wrote:
> On Wed, Oct 5, 2011 at 1:28 PM, Artem Shinkarov
> wrote:
>> On Wed, Oct 5, 2011 at 9:40 AM, Richard Guenther
>> wrote:
>>> On Wed, Oct 5, 2011 at 12:18 AM, Artem Shinkarov
>>> wrote:
Hi
Here is a patch to inform a program
In 49818, it's pointed out that none of the EH routines required by
chapter four of the C++ ABI docs are in cxxabi.h. Instead, they are in
unwind-cxx.h. Along with other, GNU-specific implementation items.
Note that the function definitions have always been exported from
the libsupc++/libstdc++ b
On 6 October 2011 23:15, Benjamin Kosnik wrote:
>
>> Does anyone have any comments or objections to going in this
>> direction? If the new base classes aren't OK the NSDMI syntax could
>> still be used, just without refactoring to remove the code
>> duplication.
>
> I like where you are going here
On Thu, Oct 06, 2011 at 10:22:12PM +0200, Paul Richard Thomas wrote:
>
> 2011-10-06 Paul Thomas
>
> PR fortran/47844
> * trans-array.c (gfc_conv_array_index_offset): Use descriptor
> stride for pointer function results.
>
> 2011-10-06 Paul Thomas
>
> PR fortran/478
On Thu, Oct 06, 2011 at 03:28:02PM -0700, Richard Henderson wrote:
> The layout of trees has been restructured since anyone has tried
> to enable fold checking (or =all checking). One of the types
> referenced, struct tree_type, doesn't exist anymore.
>
> Jakub, I was hoping you could remember ex
The layout of trees has been restructured since anyone has tried
to enable fold checking (or =all checking). One of the types
referenced, struct tree_type, doesn't exist anymore.
Jakub, I was hoping you could remember exactly what you were
trying to test for with this assert. It looks terribly a
We lost a REG_ARGS_SIZE note, leading to the incorrect unwind info,
and the verification ICE.
r~
* combine-stack-adjust.c (maybe_move_args_size_note): Add after
parameter; use it to decide whether to merge two notes.
(combine_stack_adjustments_for_block): Use maybe_move_ar
On 10/06/2011 02:39 PM, Bernd Schmidt wrote:
> * function.c (frame_required_for_rtx): Remove function.
> (requires_stack_frame_p): New arg set_up_by_prologue. All callers
> changed. Compute a set of mentioned registers and compare against
> the new arg rather than calling
> ... I went ahead and reverted the change, wasn't documented anywhere,
> definitely unintended.
Thanks
-benjamin
This is PR 49801.
The problem is that liveness data is not updated by split2, so when
cmp-elim runs next and *does* update it, we get verify failures.
As I note in the PR, I clearly have no idea how the interface to df
is supposed to work. All of the examples say df_analyze is supposed
to be run
> Does anyone have any comments or objections to going in this
> direction? If the new base classes aren't OK the NSDMI syntax could
> still be used, just without refactoring to remove the code
> duplication.
I like where you are going here. This looks good to me.
-benjamin
On 10/06/11 21:33, Ian Lance Taylor wrote:
> Note that you can test Go yourself by adding --enable-languages=go to
> your configure line. Nothing special is required to build Go. It works
> better if you use the gold linker but that is not required.
Oh, ok. For some reason I thought I was remem
On Tue, Oct 4, 2011 at 11:58 AM, H.J. Lu wrote:
> On Tue, Oct 4, 2011 at 11:51 AM, Uros Bizjak wrote:
>> On Tue, Oct 4, 2011 at 8:37 PM, H.J. Lu wrote:
>>
>> OTOH, x86_64 and i686 targets can also benefit from this change. If
>> combine can't create more complex address (covered by lea),
> On Mon, Oct 3, 2011 at 9:52 AM, Jan Hubicka wrote:
> >> This caused:
> >>
> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50601
> > Hi,
> > do you use linker with V2 API?
> >
>
> No.
Hi,
the problem is that partitioning algorithm forgets about the aliase and don't
put it into any partition.
I
Merge symbols. This patch doesn't actually fix anything, but it does
reorganize to address known issues. In particular, the code shifts
from merging into a namespace to merging into a particular chain.
This prevents a latent bug in merging into inappropriate chains. It
also sets us up to merge s
Dear All,
As the testcase shows, pointer array functions can return strides that
are different to their initial values before the function call. This
fix makes use of the descriptor strides since they are returned
durectly.
Bootstrapped and regtested of x86_64/FC9 - OK for trunk?
Cheers
Paul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/05/11 14:48, Bernd Schmidt wrote:
> This adds a little mini-pass to shrink-wrapping, to eliminate a
> common case that often makes shrink-wrapping unavailable. If a move
> insn copies an argument registers to a call-saved register, the
> prologue
Just needed to adjust the existing check for redefinition of an
implicitly declared function to cover =default as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4b566a62381c2701abe930c49fd2d41e5f7ce3d1
Author: Jason Merrill
Date: Mon Oct 3 11:33:24 2011 -0400
PR c++/39164
On Thu, Oct 6, 2011 at 3:48 PM, Kirill Yukhin wrote:
>>
>> 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
For the platforms where the full capability of GNAT.Traceback.Symbolic,
there is now a default implementation where the tracebacks are given as
a list of addresses expressed as "0x..." separated by line feed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-06 Vincent Celier
The signature and semantics of the priority queue operation
Dequeue_Only_High_Priority changed during the ARG meeting in Edinburgh (June
2011). That operation had been a protected entry in earlier drafts of
AI05-0159, but it was discovered that that operation as formerly specified was
not in fact i
Bernd Schmidt writes:
> 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
>> spl
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
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
From: Richard Henderson
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.
This addresses all of the problems you found, and also exposes the
"sub 32" to th
On Thu, Oct 6, 2011 at 11:40 AM, Bernd Schmidt 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 entertaining
> pro
-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
>> wrote: What's the other advantage of using
>> inline functions? The gdb annoyance with the macros can be
>>
On Oct 6, 2011, at 1:58 AM, Richard Guenther wrote:
> On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo 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 SVN btw).
http:
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 Tue, Oct 4, 2011 at 3:10 PM, Bernd Schmidt 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 backend changes,
From: Richard Henderson
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 compiler will e
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
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])))
>
-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, s
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
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
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
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
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
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,
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
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_
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
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
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
-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,
>
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 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
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
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 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 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 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 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
> 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 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
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
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
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 +++
---
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
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_
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
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-
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
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
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
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
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~
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 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
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
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
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
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
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
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
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
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
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!
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, 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,
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
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!
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
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!
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, 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
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
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 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
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
>
> 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
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
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
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 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?
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: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.
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
1 - 100 of 135 matches
Mail list logo
