Re: [Patch,Fortran] Fix tree-walking issue
Dear all,
attached is an updated version of Patch 2. The change is that I removed
the global variable for fill_st_vector and updated the comment for
do_traverse_symtree to make assumptions clearer.
This version of the patch was build and regtested (gfortran + libgomp).
OK?
Dear Tobias S.,
Tobias Schlüter wrote:
I don't remember all this very clearly, but I think that the
gfc_symbol::tlink field is intended for something like this
I think that's a rather different issue: It relates to undoing a symbol,
which I do not want to do. Additionally, a tlink symbol is already added
to a symtree (which is hence rebalanced). One possibility is to delay
the inclusion of symbols into the symtree - and do only so after the
traversal - but that might cause issues if one later searches in called
function for that symtree. Thus, I think my current patch should be
sufficiently simple, fast and solid.
Tobias
2011-11-02 Tobias Burnus bur...@net-b.de
* symbol.c (clear_sym_mark, traverse_ns): Remove functions.
(count_st_nodes, do_traverse_symtree, fill_st_vector): New functions.
(gfc_traverse_symtree, gfc_traverse_ns): Call do_traverse_symtree.
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 67d65cb..c3a0867 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -3310,46 +3310,81 @@ gfc_symbol_done_2 (void)
}
-/* Clear mark bits from symbol nodes associated with a symtree node. */
+/* Count how many nodes a symtree has. */
-static void
-clear_sym_mark (gfc_symtree *st)
+static unsigned
+count_st_nodes (const gfc_symtree *st)
{
+ unsigned nodes;
+ if (!st)
+return 0;
- st-n.sym-mark = 0;
+ nodes = count_st_nodes (st-left);
+ nodes++;
+ nodes += count_st_nodes (st-right);
+
+ return nodes;
}
-/* Recursively traverse the symtree nodes. */
+/* Convert symtree tree into symtree vector. */
-void
-gfc_traverse_symtree (gfc_symtree *st, void (*func) (gfc_symtree *))
+static unsigned
+fill_st_vector (gfc_symtree *st, gfc_symtree **st_vec, unsigned node_cntr)
{
if (!st)
-return;
+return node_cntr;
+
+ node_cntr = fill_st_vector (st-left, st_vec, node_cntr);
+ st_vec[node_cntr++] = st;
+ node_cntr = fill_st_vector (st-right, st_vec, node_cntr);
- gfc_traverse_symtree (st-left, func);
- (*func) (st);
- gfc_traverse_symtree (st-right, func);
+ return node_cntr;
}
-/* Recursive namespace traversal function. */
+/* Traverse namespace. As the functions might modify the symtree, we store the
+ symtree as a vector and operate on this vector. Note: We assume that
+ sym_func or st_func never deletes nodes from the symtree - only adding is
+ allowed. */
static void
-traverse_ns (gfc_symtree *st, void (*func) (gfc_symbol *))
+do_traverse_symtree (gfc_symtree *st, void (*st_func) (gfc_symtree *),
+ void (*sym_func) (gfc_symbol *))
{
+ gfc_symtree **st_vec;
+ unsigned nodes, i, node_cntr;
- if (st == NULL)
-return;
+ gcc_assert ((st_func !sym_func) || (!st_func sym_func));
+ nodes = count_st_nodes (st);
+ st_vec = XALLOCAVEC (gfc_symtree *, nodes);
+ node_cntr = 0;
+ fill_st_vector (st, st_vec, node_cntr);
+
+ if (sym_func)
+{
+ /* Clear marks. */
+ for (i = 0; i nodes; i++)
+ st_vec[i]-n.sym-mark = 0;
+ for (i = 0; i nodes; i++)
+ if (!st_vec[i]-n.sym-mark)
+ {
+ (*sym_func) (st_vec[i]-n.sym);
+ st_vec[i]-n.sym-mark = 1;
+ }
+ }
+ else
+ for (i = 0; i nodes; i++)
+ (*st_func) (st_vec[i]);
+}
- traverse_ns (st-left, func);
- if (st-n.sym-mark == 0)
-(*func) (st-n.sym);
- st-n.sym-mark = 1;
+/* Recursively traverse the symtree nodes. */
- traverse_ns (st-right, func);
+void
+gfc_traverse_symtree (gfc_symtree *st, void (*st_func) (gfc_symtree *))
+{
+ do_traverse_symtree (st, st_func, NULL);
}
@@ -3357,12 +3392,9 @@ traverse_ns (gfc_symtree *st, void (*func) (gfc_symbol *))
care that each gfc_symbol node is called exactly once. */
void
-gfc_traverse_ns (gfc_namespace *ns, void (*func) (gfc_symbol *))
+gfc_traverse_ns (gfc_namespace *ns, void (*sym_func) (gfc_symbol *))
{
-
- gfc_traverse_symtree (ns-sym_root, clear_sym_mark);
-
- traverse_ns (ns-sym_root, func);
+ do_traverse_symtree (ns-sym_root, NULL, sym_func);
}
Re: New port: Renesas RL78
On Wed, 2 Nov 2011, DJ Delorie wrote: The Renesas RL78 is a new low-power 8/16 bit microcontroller, with an architecture much like the original Z80. Just some random spottings. Index: configure.ac +# Dereferencing -1 is a compile-time error This (those lines) look a little cryptic (and lack punctuation ;) Wild improvement guess: Too small 'int'?. Also spotted a: Index: libgcc/config/rl78/trampoline.S \ No newline at end of file Wouldn't some tools behave better if the asm files had ELF decorations on the functions? Also spotted some +#if 1 and + /*print_simple_rtl (file, op);*/ and +#if DEBUG0 and +#if DEBUG_PEEP and +#define DEBUG_ALLOC 0 and I'll stop right there. brgds, H-P
Re: -fdump-go-spec option does not handle redefinitions
On Wed, Nov 2, 2011 at 6:06 AM, Ian Lance Taylor i...@google.com wrote:
The problem with your proposal is that the output would be invalid Go,
because it would attempt to define the name _aa twice. However, it does
seem plausible that in most scenarios of this type it would be more
useful for -fdump-go-spec to generate
const _aa = 3
I agree.
This patch implements this approach. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Thanks, bu this is still not enough to determine corretc IOCTL number :(
#defines with arguments are not working at all. Please consider
following testcase:
--cut here--
#define _IOC_NRBITS8
#define _IOC_TYPEBITS 8
#define _IOC_SIZEBITS 13
#define _IOC_DIRBITS 3
#define _IOC_NRMASK((1 _IOC_NRBITS)-1)
#define _IOC_TYPEMASK ((1 _IOC_TYPEBITS)-1)
#define _IOC_SIZEMASK ((1 _IOC_SIZEBITS)-1)
#define _IOC_DIRMASK ((1 _IOC_DIRBITS)-1)
#define _IOC_NRSHIFT 0
#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS)
/*
* Direction bits _IOC_NONE could be 0, but OSF/1 gives it a bit.
* And this turns out useful to catch old ioctl numbers in header
* files for us.
*/
#define _IOC_NONE 1U
#define _IOC_READ 2U
#define _IOC_WRITE 3U
#define _IOC(dir,type,nr,size) \
((unsigned int) \
(((dir) _IOC_DIRSHIFT) | \
((type) _IOC_TYPESHIFT) |\
((nr)_IOC_NRSHIFT) | \
((size) _IOC_SIZESHIFT)))
/* used to create numbers */
#define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0)
#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))
#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
#define FIOCLEX _IO('f', 1)
#define FIONCLEX_IO('f', 2)
#define TCGETS _IOR('t', 19, struct termios)
#define TCSETS _IOW('t', 20, struct termios)
--cut here--
Resulting -fdump-go-spec file:
...
const __IOC_NRSHIFT = 0
const __IOC_TYPESHIFT = (__IOC_NRSHIFT+__IOC_NRBITS)
const __IOC_SIZESHIFT = (__IOC_TYPESHIFT+__IOC_TYPEBITS)
const __IOC_DIRSHIFT = (__IOC_SIZESHIFT+__IOC_SIZEBITS)
const __IOC_NONE = 1
const __IOC_READ = 2
const __IOC_WRITE = 3
// unknowndefine FIOCLEX _IO('f', 1)
// unknowndefine FIONCLEX _IO('f', 2)
// unknowndefine TCGETS _IOR('t', 19, struct termios)
// unknowndefine TCSETS _IOW('t', 20, struct termios)
Please note missing struct terminfos define, so I understand that
TC[GS]ETS is unknown, but FIOCLEX should be fully defined by
preceeding definitions.
Uros.
Re: RFC: PATCH to adjust warning flags for C++
On 11/01/2011 06:54 PM, Jason Merrill wrote: Paolo Carlini's patch to add -Wnarrowing to -Wc++0x-compat (and thus -Wall) broke bootstrap because of narrowing warnings, so I'd like to add -Wno-narrowing to the stage 2+ warning flags. Is this the best way to do that? Is this a C++-only warning? Also, how did you test the patch? Paolo
Re: building binutils from same directory as gcc
On 11/01/2011 04:51 PM, Mike Stump wrote: On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote: On 10/30/2011 01:51 PM, Gerald Pfeifer wrote: Why not just declare that building from the same directory is not support and have one simple set of instructions that always works, as opposed to this ought to work with snapshots but not with direct checkouts? That's right. Is there ever any advantage to building in-srcdir? Yes. You can do configure make make install. Huh? I do that all the time without building in-srcdir. I need a path to configure, but that'll always be true for everyone who doesn't have . in their PATH. Andrew.
Re: [PATCH, devirtualization] Detect the new type in type change detection
On Tue, Nov 1, 2011 at 10:02 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Tue, Nov 01, 2011 at 10:37:10AM +0100, Richard Guenther wrote:
On Mon, Oct 31, 2011 at 5:58 PM, Martin Jambor mjam...@suse.cz wrote:
On Fri, Oct 28, 2011 at 11:21:23AM +0200, Richard Guenther wrote:
On Thu, Oct 27, 2011 at 9:54 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Thu, Oct 27, 2011 at 11:06:02AM +0200, Richard Guenther wrote:
On Thu, Oct 27, 2011 at 1:22 AM, Martin Jambor mjam...@suse.cz wrote:
Hi,
I've been asked by Maxim Kuvyrkov to revive the following patch which
has not made it to 4.6. Currently, when type based devirtualization
detects a potential type change, it simply gives up on gathering any
information on the object in question. This patch adds an attempt to
actually detect the new type after the change.
Maxim claimed this (and another patch I'll post tomorrow) noticeably
improved performance of some real code. I can only offer a rather
artificial example in the attachment. When the constructors are
inlined but the function multiply_matrices is not, this patch makes
the produced executable run for only 7 seconds instead of about 20 on
my 4 year old i686 desktop (with -Ofast).
Anyway, the patch passes bootstrap and testsuite on x86_64-linux.
What do you think, is it a good idea for trunk now?
Thanks,
Martin
2011-10-21 Martin Jambor mjam...@suse.cz
* ipa-prop.c (type_change_info): New fields object,
known_current_type
and multiple_types_encountered.
(extr_type_from_vtbl_ptr_store): New function.
(check_stmt_for_type_change): Use it, set
multiple_types_encountered if
the result is different from the previous one.
(detect_type_change): Renamed to detect_type_change_1. New
parameter
comp_type. Set up new fields in tci, build known type jump
functions if the new type can be identified.
(detect_type_change): New function.
* tree.h (DECL_CONTEXT): Comment new use.
* testsuite/g++.dg/ipa/devirt-c-1.C: Add dump scans.
* testsuite/g++.dg/ipa/devirt-c-2.C: Likewise.
* testsuite/g++.dg/ipa/devirt-c-7.C: New test.
Index: src/gcc/ipa-prop.c
===
--- src.orig/gcc/ipa-prop.c
+++ src/gcc/ipa-prop.c
@@ -271,8 +271,17 @@ ipa_print_all_jump_functions (FILE *f)
struct type_change_info
{
+ /* The declaration or SSA_NAME pointer of the base that we are
checking for
+ type change. */
+ tree object;
+ /* If we actually can tell the type that the object has changed
to, it is
+ stored in this field. Otherwise it remains NULL_TREE. */
+ tree known_current_type;
/* Set to true if dynamic type change has been detected. */
bool type_maybe_changed;
+ /* Set to true if multiple types have been encountered.
known_current_type
+ must be disregarded in that case. */
+ bool multiple_types_encountered;
};
/* Return true if STMT can modify a virtual method table pointer.
@@ -338,6 +347,49 @@ stmt_may_be_vtbl_ptr_store (gimple stmt)
return true;
}
+/* If STMT can be proved to be an assignment to the virtual method
table
+ pointer of ANALYZED_OBJ and the type associated with the new
table
+ identified, return the type. Otherwise return NULL_TREE. */
+
+static tree
+extr_type_from_vtbl_ptr_store (gimple stmt, tree analyzed_obj)
+{
+ tree lhs, t, obj;
+
+ if (!is_gimple_assign (stmt))
gimple_assign_single_p (stmt)
OK.
+ return NULL_TREE;
+
+ lhs = gimple_assign_lhs (stmt);
+
+ if (TREE_CODE (lhs) != COMPONENT_REF)
+ return NULL_TREE;
+ obj = lhs;
+
+ if (!DECL_VIRTUAL_P (TREE_OPERAND (lhs, 1)))
+ return NULL_TREE;
+
+ do
+ {
+ obj = TREE_OPERAND (obj, 0);
+ }
+ while (TREE_CODE (obj) == COMPONENT_REF);
You do not allow other components than component-refs (thus, for
example an ARRAY_REF - that is for a reason?). Please add
a comment why. Otherwise this whole sequence would look like
it should be replaceable by get_base_address (obj).
I guess I might have been overly conservative here, ARRAY_REFs are
fine. get_base_address only digs into MEM_REFs if they are based on
an ADDR_EXPR while I do so always. But I can check that either both
obj and analyzed_obj are a MEM_REF of the same SSA_NAME or they are
the same thing (i.e. the same decl)... which even feels a bit cleaner,
so I did that.
Well, as you are looking for a must-change-type pattern I think you cannot
simply ignore offsets. Consider
T a[10];
new (T') (a[9]);
a[8]-foo();
Re: [PATCH, devirtualization] Intraprocedural devirtualization pass
On Tue, Nov 1, 2011 at 11:06 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
the patch below is the second (and last) revived type-based
devirtualization patch that did not make it to 4.6. It deals with
virtual calls from the function in which the there is also the object
declaration:
void foo()
{
A a;
a.foo ();
}
Normally, the front-end would do the devirtualization on its own,
however, early-inlining can create these situations too. Since there
is nothing interprocedural going on, the current inlining and IPA-CP
devirtualization bits are of no help. We do not do type-based
devirtualization in OBJ_TYPE_REF folding either, because the necessary
type-changing checks might make it quite expensive.
But in the above case - a is not address-taken - we do not need
type-based devirtualization. So, can you explain why we do not
forward the proper vtable from the vtable store that would lead to
the known-type info?
Thanks,
Richard.
Thus, this patch
introduces a new pass to do that.
The patch basically piggy-tails on the intraprocedural
devirtualization mechanism, trying to construct a known-type jump
function for all objects in OBJ_TYPE_REF calls and then immediately
using it like we do in IPA-CP.
The original patch was doing this as a part of
pass_rebuild_cgraph_edges. Honza did not like this idea so I made it
a separate pass. First, I scheduled it after
pass_rebuild_cgraph_edges and was only traversing indirect edges,
avoiding a sweep over all of the IL. Unfortunately, this does not
work in one scenario. If the newly-known destination of a virtual
call is known not to throw, we may have to purge some EH CFG edges and
potentially basic blocks. If these basic blocks contain calls
(typically calls to object destructors), we may end up having stale
call edges in the call graph... and our current approach to that
problem is to call pass_rebuild_cgraph_edges. I think that I was not
running into this problem when the mechanism was a part of that pass
just because of pure luck. Anyway, this is why I eventually opted for
a sweep over the statements.
My best guess is that it is probably worth it, but only because the
overhead should be still fairly low. The pass triggers quite a number
of times when building libstdc++ and it can speed up an artificial
testcase which I will attach from over 20 seconds to 7s on my older
desktop - it is very similar to the one I posted with the previous
patch but this time the object constructors must not get early inlined
but the function multiply_matrices has to. Currently I have problems
compiling Firefox even without LTO so I don't have any numbers from it
either. IIRC, Honza did not see this patch trigger there when he
tried the ancient version almost a year go. On the other hand, Maxim
claimed that the impact can be noticeable on some code base he is
concerned about.
I have successfully bootstrapped and tested the patch on x86_64-linux.
What do you think, should we include this in trunk?
Thanks,
Martin
2011-10-31 Martin Jambor mjam...@suse.cz
* ipa-cp.c (ipa_value_from_known_type_jfunc): Moved to...
* ipa-prop.c (ipa_binfo_from_known_type_jfunc): ...here, exported and
updated all callers.
(intraprocedural_devirtualization): New function.
(gate_intra_devirtualization): Likewise.
(pass_intra_devirt): New pass.
* ipa-prop.h (ipa_binfo_from_known_type_jfunc): Declared.
* passes.c (init_optimization_passes): Schedule pass_intra_devirt.
* tree-pass.h (pass_intra_devirt): Declare.
* testsuite/g++.dg/ipa/imm-devirt-1.C: New test.
* testsuite/g++.dg/ipa/imm-devirt-2.C: Likewise.
Index: src/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C
===
--- /dev/null
+++ src/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C
@@ -0,0 +1,62 @@
+/* Verify that virtual calls are folded even when a typecast to an
+ ancestor is involved along the way. */
+/* { dg-do run } */
+/* { dg-options -O2 -fdump-tree-devirt } */
+
+extern C void abort (void);
+
+class A
+{
+public:
+ int data;
+ virtual int foo (int i);
+};
+
+
+class B : public A
+{
+public:
+ __attribute__ ((noinline)) B();
+ virtual int foo (int i);
+};
+
+int __attribute__ ((noinline)) A::foo (int i)
+{
+ return i + 1;
+}
+
+int __attribute__ ((noinline)) B::foo (int i)
+{
+ return i + 2;
+}
+
+int __attribute__ ((noinline,noclone)) get_input(void)
+{
+ return 1;
+}
+
+__attribute__ ((noinline)) B::B()
+{
+}
+
+static inline int middleman_1 (class A *obj, int i)
+{
+ return obj-foo (i);
+}
+
+static inline int middleman_2 (class B *obj, int i)
+{
+ return middleman_1 (obj, i);
+}
+
+int main (int argc, char *argv[])
+{
+ class B b;
+
+ if (middleman_2 (b, get_input ()) != 3)
+ abort ();
+ return 0;
+}
+
+/* { dg-final { scan-tree-dump Immediately
Re: [PATCH, ARM] Fix stack red zone bug (PR38644)
On Wed, Nov 2, 2011 at 3:27 AM, Jiangning Liu jiangning@arm.com wrote:
Hi,
This patch is to fix PR38644 in ARM back-end. OK for trunk?
For every detail, please refer to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644.
Ok in absence of any target maintainer objection within 24h.
Thanks,
Richard.
ChangeLog:
2011-11-2 Jiangning Liu jiangning@arm.com
PR rtl-optimization/38644
* config/arm/arm.c (thumb1_expand_epilogue): Add memory barrier
for epilogue having stack adjustment.
ChangeLog of testsuite:
2011-11-2 Jiangning Liu jiangning@arm.com
PR rtl-optimization/38644
* gcc.target/arm/stack-red-zone.c: New.
Thanks,
-Jiangning
Patch:
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f1ada6f..1f6fc26
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -22215,6 +22215,8 @@ thumb1_expand_epilogue (void)
gcc_assert (amount = 0);
if (amount)
{
+ emit_insn (gen_blockage ());
+
if (amount 512)
emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx,
GEN_INT (amount)));
diff --git a/gcc/testsuite/gcc.target/arm/stack-red-zone.c
b/gcc/testsuite/gcc.target/arm/stack-red-zone.c
new file mode 100644
index 000..b9f0f99
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/stack-red-zone.c
@@ -0,0 +1,12 @@
+/* No stack red zone. PR38644. */
+/* { dg-options -mthumb -O2 } */
+/* { dg-final { scan-assembler ldrb\[^\n\]*\\n\[\t \]*add\[\t \]*sp } }
*/
+
+extern int doStreamReadBlock (int *, char *, int size, int);
+
+char readStream (int *s)
+{
+ char c = 0;
+ doStreamReadBlock (s, c, 1, *s);
+ return c;
+}
[v3] PR libstdc++/50951
Hi,
just consistently save the whole state and compare the whole state (in
operator==). Tested x86_64-linux, committed to mainline. Maybe will go
to 4_6-branch too.
Thanks,
Paolo.
///
2011-11-02 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/50951
* include/bits/random.tcc (operator(basic_ostream,
const mersenne_twister_engine): Output _M_p too.
(operator(basic_ostream, const
subtract_with_carry_engine): Likewise.
(operator(basic_istream, mersenne_twister_engine):
Reload it.
(operator(basic_istream, subtract_with_carry_engine):
Likewise.
* include/bits/random.h (mersenne_twister_engine::operator==):
Compare _M_p too.
(subtract_with_carry_engine::operator==): Compare _M_carry
and _M_p too.
(shuffle_order_engine::operator==): Compare _M_v(s) and _M_y too.
* testsuite/26_numerics/random/independent_bits_engine/
operators/serialize.cc: Extend.
* testsuite/26_numerics/random/subtract_with_carry_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/discard_block_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/mersenne_twister_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/linear_congruential_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/shuffle_order_engine/
operators/serialize.cc: Likewise.
Index: include/bits/random.tcc
===
--- include/bits/random.tcc (revision 180749)
+++ include/bits/random.tcc (working copy)
@@ -471,9 +471,9 @@
__os.flags(__ios_base::dec | __ios_base::fixed | __ios_base::left);
__os.fill(__space);
- for (size_t __i = 0; __i __n - 1; ++__i)
+ for (size_t __i = 0; __i __n; ++__i)
__os __x._M_x[__i] __space;
- __os __x._M_x[__n - 1];
+ __os __x._M_p;
__os.flags(__flags);
__os.fill(__fill);
@@ -498,6 +498,7 @@
for (size_t __i = 0; __i __n; ++__i)
__is __x._M_x[__i];
+ __is __x._M_p;
__is.flags(__flags);
return __is;
@@ -627,7 +628,7 @@
for (size_t __i = 0; __i __r; ++__i)
__os __x._M_x[__i] __space;
- __os __x._M_carry;
+ __os __x._M_carry __space __x._M_p;
__os.flags(__flags);
__os.fill(__fill);
@@ -649,6 +650,7 @@
for (size_t __i = 0; __i __r; ++__i)
__is __x._M_x[__i];
__is __x._M_carry;
+ __is __x._M_p;
__is.flags(__flags);
return __is;
Index: include/bits/random.h
===
--- include/bits/random.h (revision 180749)
+++ include/bits/random.h (working copy)
@@ -491,7 +491,8 @@
friend bool
operator==(const mersenne_twister_engine __lhs,
const mersenne_twister_engine __rhs)
- { return std::equal(__lhs._M_x, __lhs._M_x + state_size, __rhs._M_x); }
+ { return (std::equal(__lhs._M_x, __lhs._M_x + state_size, __rhs._M_x)
+__lhs._M_p == __rhs._M_p); }
/**
* @brief Inserts the current state of a % mersenne_twister_engine
@@ -705,7 +706,9 @@
friend bool
operator==(const subtract_with_carry_engine __lhs,
const subtract_with_carry_engine __rhs)
- { return std::equal(__lhs._M_x, __lhs._M_x + long_lag, __rhs._M_x); }
+ { return (std::equal(__lhs._M_x, __lhs._M_x + long_lag, __rhs._M_x)
+__lhs._M_carry == __rhs._M_carry
+__lhs._M_p == __rhs._M_p); }
/**
* @brief Inserts the current state of a % subtract_with_carry_engine
@@ -1370,7 +1373,9 @@
friend bool
operator==(const shuffle_order_engine __lhs,
const shuffle_order_engine __rhs)
- { return __lhs._M_b == __rhs._M_b; }
+ { return (__lhs._M_b == __rhs._M_b
+std::equal(__lhs._M_v, __lhs._M_v + __k, __rhs._M_v)
+__lhs._M_y == __rhs._M_y); }
/**
* @brief Inserts the current state of a %shuffle_order_engine random
Index:
testsuite/26_numerics/random/independent_bits_engine/operators/serialize.cc
===
--- testsuite/26_numerics/random/independent_bits_engine/operators/serialize.cc
(revision 180749)
+++ testsuite/26_numerics/random/independent_bits_engine/operators/serialize.cc
(working copy)
@@ -3,7 +3,7 @@
//
// 2008-11-24 Edward M. Smith-Rowland 3dw...@verizon.net
//
-// Copyright (C) 2008, 2009 Free Software Foundation, Inc.
+// Copyright (C) 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -44,6 +44,20 @@
str v;
[PATCH] Fix PR50902
This fixes PR50902.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-11-02 Richard Guenther rguent...@suse.de
PR tree-optimization/50902
* tree-vect-stmts.c (vectorizable_load): Properly convert
an invariant initializer element.
* gcc.dg/torture/pr50902.c: New testcase.
Index: gcc/tree-vect-stmts.c
===
*** gcc/tree-vect-stmts.c (revision 180762)
--- gcc/tree-vect-stmts.c (working copy)
*** vectorizable_load (gimple stmt, gimple_s
*** 4726,4736
/* 4. Handle invariant-load. */
if (inv_p !bb_vinfo)
{
! tree vec_inv;
gimple_stmt_iterator gsi2 = *gsi;
gcc_assert (!strided_load);
gsi_next (gsi2);
! vec_inv = build_vector_from_val (vectype, scalar_dest);
new_temp = vect_init_vector (stmt, vec_inv,
vectype, gsi2);
new_stmt = SSA_NAME_DEF_STMT (new_temp);
--- 4726,4745
/* 4. Handle invariant-load. */
if (inv_p !bb_vinfo)
{
! tree tem, vec_inv;
gimple_stmt_iterator gsi2 = *gsi;
gcc_assert (!strided_load);
gsi_next (gsi2);
! tem = scalar_dest;
! if (!useless_type_conversion_p (TREE_TYPE (vectype),
! TREE_TYPE (tem)))
! {
! tem = fold_convert (TREE_TYPE (vectype), tem);
! tem = force_gimple_operand_gsi (gsi2, tem, true,
! NULL_TREE, true,
! GSI_SAME_STMT);
! }
! vec_inv = build_vector_from_val (vectype, tem);
new_temp = vect_init_vector (stmt, vec_inv,
vectype, gsi2);
new_stmt = SSA_NAME_DEF_STMT (new_temp);
Index: gcc/testsuite/gcc.dg/torture/pr50902.c
===
*** gcc/testsuite/gcc.dg/torture/pr50902.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr50902.c (revision 0)
***
*** 0
--- 1,9
+ /* { dg-do compile } */
+
+ _Bool data[128];
+ void foo (_Bool *init)
+ {
+ int i;
+ for (i = 0; i 128; i++)
+ data[i] = *init;
+ }
Re: [PATCH, devirtualization] Intraprocedural devirtualization pass
Hi,
On Wed, Nov 02, 2011 at 11:02:48AM +0100, Richard Guenther wrote:
On Tue, Nov 1, 2011 at 11:06 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
the patch below is the second (and last) revived type-based
devirtualization patch that did not make it to 4.6. It deals with
virtual calls from the function in which the there is also the object
declaration:
void foo()
{
A a;
a.foo ();
}
Normally, the front-end would do the devirtualization on its own,
however, early-inlining can create these situations too. Since there
is nothing interprocedural going on, the current inlining and IPA-CP
devirtualization bits are of no help. We do not do type-based
devirtualization in OBJ_TYPE_REF folding either, because the necessary
type-changing checks might make it quite expensive.
But in the above case - a is not address-taken - we do not need
type-based devirtualization. So, can you explain why we do not
forward the proper vtable from the vtable store that would lead to
the known-type info?
We can only do that when the object constructor is early-inlined. If
it is only slightly bigger, or in a different compilation unit, the
store ends up in a different function (or unit) and we cannot do it.
LTO is not necessary with this approach and we still can be quite
helpful if foo is in the same TU and we can inline it.
Martin
Thanks,
Richard.
Thus, this patch
introduces a new pass to do that.
The patch basically piggy-tails on the intraprocedural
devirtualization mechanism, trying to construct a known-type jump
function for all objects in OBJ_TYPE_REF calls and then immediately
using it like we do in IPA-CP.
The original patch was doing this as a part of
pass_rebuild_cgraph_edges. Honza did not like this idea so I made it
a separate pass. First, I scheduled it after
pass_rebuild_cgraph_edges and was only traversing indirect edges,
avoiding a sweep over all of the IL. Unfortunately, this does not
work in one scenario. If the newly-known destination of a virtual
call is known not to throw, we may have to purge some EH CFG edges and
potentially basic blocks. If these basic blocks contain calls
(typically calls to object destructors), we may end up having stale
call edges in the call graph... and our current approach to that
problem is to call pass_rebuild_cgraph_edges. I think that I was not
running into this problem when the mechanism was a part of that pass
just because of pure luck. Anyway, this is why I eventually opted for
a sweep over the statements.
My best guess is that it is probably worth it, but only because the
overhead should be still fairly low. The pass triggers quite a number
of times when building libstdc++ and it can speed up an artificial
testcase which I will attach from over 20 seconds to 7s on my older
desktop - it is very similar to the one I posted with the previous
patch but this time the object constructors must not get early inlined
but the function multiply_matrices has to. Currently I have problems
compiling Firefox even without LTO so I don't have any numbers from it
either. IIRC, Honza did not see this patch trigger there when he
tried the ancient version almost a year go. On the other hand, Maxim
claimed that the impact can be noticeable on some code base he is
concerned about.
I have successfully bootstrapped and tested the patch on x86_64-linux.
What do you think, should we include this in trunk?
Thanks,
Martin
2011-10-31 Martin Jambor mjam...@suse.cz
* ipa-cp.c (ipa_value_from_known_type_jfunc): Moved to...
* ipa-prop.c (ipa_binfo_from_known_type_jfunc): ...here, exported and
updated all callers.
(intraprocedural_devirtualization): New function.
(gate_intra_devirtualization): Likewise.
(pass_intra_devirt): New pass.
* ipa-prop.h (ipa_binfo_from_known_type_jfunc): Declared.
* passes.c (init_optimization_passes): Schedule pass_intra_devirt.
* tree-pass.h (pass_intra_devirt): Declare.
* testsuite/g++.dg/ipa/imm-devirt-1.C: New test.
* testsuite/g++.dg/ipa/imm-devirt-2.C: Likewise.
Index: src/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C
===
--- /dev/null
+++ src/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C
@@ -0,0 +1,62 @@
+/* Verify that virtual calls are folded even when a typecast to an
+ ancestor is involved along the way. */
+/* { dg-do run } */
+/* { dg-options -O2 -fdump-tree-devirt } */
+
+extern C void abort (void);
+
+class A
+{
+public:
+ int data;
+ virtual int foo (int i);
+};
+
+
+class B : public A
+{
+public:
+ __attribute__ ((noinline)) B();
+ virtual int foo (int i);
+};
+
+int __attribute__ ((noinline)) A::foo (int i)
+{
+ return i + 1;
+}
+
+int __attribute__ ((noinline)) B::foo (int i)
Re: [PATCH][2/n] LTO option handling/merging rewrite
On Fri, 28 Oct 2011, Joseph S. Myers wrote: On Fri, 28 Oct 2011, Richard Guenther wrote: + /* Fallthru. */ + case OPT_fPIC: + case OPT_fpic: + case OPT_fpie: + case OPT_fcommon: + case OPT_fexceptions: + append_option (decoded_options, decoded_options_count, foption); + break; No doubt this is what the previous code did, but in this case shouldn't union mean the biggest PIC status of any file wins (thus, if -fPIC was the PIC option that actually had effect on some object, that wins over an explicit -fno-PIC or -fpic on another object)? In general whether the options are positive or negative matters, and I don't see that handled here. Thinking about this again I think -fPIC and -fno-PIC in two objects should cause a diagnostic. The whole point of this (and the old) code is to make sure we use -fPIC at link-time, but we should only do so if there is consistent use in the separate CUs. The same probably applies to target specific opts - a -mavx on one unit shouldn't really cause -mavx being used for the whole program at link-time (even if it currently does ...). The following slight adjustment to the patch marks the code identifying duplicates accordingly - that it does what the old code did. I'll try to clean this up as a followup (I basically want to make sure we do not regress with the switch to handling things in the driver, changing behavior on purpose will just make bisecting this harder). I've also arranged to do more pruning on the saved options on the writing side (drop all diagnostic options and options that are also handled by the driver). What we want to preserve are IL changing and optimization / target options. Thus, I really want to go forward with this ... as this also eliminates the most often seen reason for LTO bytecode incompatibility on branches (OPT_ enum changes). Re-LTO-bootstrap and test running on x86_64-unknown-linux-gnu, ok for trunk? Thanks, Richard. 2011-10-28 Richard Guenther rguent...@suse.de * lto-opts.c: Re-implement. * lto-streamer.h (lto_register_user_option): Remove. (lto_read_file_options): Likewise. (lto_reissue_options): Likewise. (lto_clear_user_options): Likewise. (lto_clear_file_options): Likewise. * opts-global.c (post_handling_callback): Remove. (set_default_handlers): Do not set post_handling_callback. (decode_options): Remove LTO specific code. * lto-wrapper.c (merge_and_complain): New function. (run_gcc): Read all input file options and prepend a merged set before the linker driver options. * gcc.c (driver_post_handling_callback): Remove. (set_option_handlers): Do not set post_handling_callback. * opts-common.c (handle_option): Do not call post_handling_callback. * opts.h (struct cl_option_handlers): Remove post_handling_callback. lto/ * lto-lang.c (lto_post_options): Do not read file options. * lto.c (lto_read_all_file_options): Remove. (lto_init): Call lto_set_in_hooks here. Index: trunk/gcc/lto-opts.c === *** trunk.orig/gcc/lto-opts.c 2011-10-28 14:20:11.0 +0200 --- trunk/gcc/lto-opts.c2011-11-02 12:22:43.0 +0100 *** *** 1,6 /* LTO IL options. !Copyright 2009, 2010, 2011 Free Software Foundation, Inc. Contributed by Simon Baldwin sim...@google.com This file is part of GCC. --- 1,6 /* LTO IL options. !Copyright 2009, 2010, 2011, 2012 Free Software Foundation, Inc. Contributed by Simon Baldwin sim...@google.com This file is part of GCC. *** along with GCC; see the file COPYING3. *** 33,422 #include common/common-target.h #include diagnostic.h #include lto-streamer.h ! ! /* When a file is initially compiled, the options used when generating !the IL are not necessarily the same as those used when linking the !objects into the final executable. In general, most build systems !will proceed with something along the lines of: ! ! $ gcc cc-flags -flto -c f1.c -o f1.o ! $ gcc cc-flags -flto -c f2.c -o f2.o ! ... ! $ gcc cc-flags -flto -c fN.c -o fN.o ! !And the final link may or may not include the same cc-flags used !to generate the initial object files: ! ! $ gcc ld-flags -flto -o prog f1.o ... fN.o ! !Since we will be generating final code during the link step, some !of the flags used during the compile step need to be re-applied !during the link step. For instance, flags in the -m family. ! !The idea is to save a selected set of cc-flags in a special !section of the initial object files. This section is then read !during linking and the options re-applied. ! !FIXME lto. Currently the scheme is limited in that only the !options saved on the first object file (f1.o) are read
Re: [PATCH, devirtualization] Intraprocedural devirtualization pass
On Wed, Nov 2, 2011 at 12:12 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Wed, Nov 02, 2011 at 11:02:48AM +0100, Richard Guenther wrote:
On Tue, Nov 1, 2011 at 11:06 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
the patch below is the second (and last) revived type-based
devirtualization patch that did not make it to 4.6. It deals with
virtual calls from the function in which the there is also the object
declaration:
void foo()
{
A a;
a.foo ();
}
Normally, the front-end would do the devirtualization on its own,
however, early-inlining can create these situations too. Since there
is nothing interprocedural going on, the current inlining and IPA-CP
devirtualization bits are of no help. We do not do type-based
devirtualization in OBJ_TYPE_REF folding either, because the necessary
type-changing checks might make it quite expensive.
But in the above case - a is not address-taken - we do not need
type-based devirtualization. So, can you explain why we do not
forward the proper vtable from the vtable store that would lead to
the known-type info?
We can only do that when the object constructor is early-inlined. If
it is only slightly bigger, or in a different compilation unit, the
store ends up in a different function (or unit) and we cannot do it.
LTO is not necessary with this approach and we still can be quite
helpful if foo is in the same TU and we can inline it.
So we are using that fishy calls-cannot-change-object-types logic here?
Even if the actual call is the constructor?
Well, the cases seem to be pretty obscure - do we really want to add
another walk over the entire IL for that? Can't you piggy-back on
some other transform for that? Like for example FREs eliminate() walk,
which already does some of the devirt work?
Thanks,
Richard.
Martin
Thanks,
Richard.
Thus, this patch
introduces a new pass to do that.
The patch basically piggy-tails on the intraprocedural
devirtualization mechanism, trying to construct a known-type jump
function for all objects in OBJ_TYPE_REF calls and then immediately
using it like we do in IPA-CP.
The original patch was doing this as a part of
pass_rebuild_cgraph_edges. Honza did not like this idea so I made it
a separate pass. First, I scheduled it after
pass_rebuild_cgraph_edges and was only traversing indirect edges,
avoiding a sweep over all of the IL. Unfortunately, this does not
work in one scenario. If the newly-known destination of a virtual
call is known not to throw, we may have to purge some EH CFG edges and
potentially basic blocks. If these basic blocks contain calls
(typically calls to object destructors), we may end up having stale
call edges in the call graph... and our current approach to that
problem is to call pass_rebuild_cgraph_edges. I think that I was not
running into this problem when the mechanism was a part of that pass
just because of pure luck. Anyway, this is why I eventually opted for
a sweep over the statements.
My best guess is that it is probably worth it, but only because the
overhead should be still fairly low. The pass triggers quite a number
of times when building libstdc++ and it can speed up an artificial
testcase which I will attach from over 20 seconds to 7s on my older
desktop - it is very similar to the one I posted with the previous
patch but this time the object constructors must not get early inlined
but the function multiply_matrices has to. Currently I have problems
compiling Firefox even without LTO so I don't have any numbers from it
either. IIRC, Honza did not see this patch trigger there when he
tried the ancient version almost a year go. On the other hand, Maxim
claimed that the impact can be noticeable on some code base he is
concerned about.
I have successfully bootstrapped and tested the patch on x86_64-linux.
What do you think, should we include this in trunk?
Thanks,
Martin
2011-10-31 Martin Jambor mjam...@suse.cz
* ipa-cp.c (ipa_value_from_known_type_jfunc): Moved to...
* ipa-prop.c (ipa_binfo_from_known_type_jfunc): ...here, exported
and
updated all callers.
(intraprocedural_devirtualization): New function.
(gate_intra_devirtualization): Likewise.
(pass_intra_devirt): New pass.
* ipa-prop.h (ipa_binfo_from_known_type_jfunc): Declared.
* passes.c (init_optimization_passes): Schedule pass_intra_devirt.
* tree-pass.h (pass_intra_devirt): Declare.
* testsuite/g++.dg/ipa/imm-devirt-1.C: New test.
* testsuite/g++.dg/ipa/imm-devirt-2.C: Likewise.
Index: src/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C
===
--- /dev/null
+++ src/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C
@@ -0,0 +1,62 @@
+/* Verify that virtual calls are folded even when a typecast to an
+ ancestor is
Re: [PATCH i386] PR47698 no CMOV for volatile mem
On Sat, 29 Oct 2011, Sergey Ostanevich wrote:
On Fri, Oct 28, 2011 at 7:25 PM, Sergey Ostanevich sergos@gmail.com
wrote:
On Fri, Oct 28, 2011 at 4:52 PM, Richard Guenther rguent...@suse.de wrote:
On Fri, 28 Oct 2011, Sergey Ostanevich wrote:
On Fri, Oct 28, 2011 at 12:16 PM, Richard Guenther rguent...@suse.de
wrote:
On Thu, 27 Oct 2011, Uros Bizjak wrote:
Hello!
Here's a patch for PR47698, which is about CMOV should not be
generated for memory address marked as volatile.
Successfully bootstrapped and passed make check on
x86_64-unknown-linux-gnu.
PR rtl-optimization/47698
* config/i386/i386.c (ix86_expand_int_movcc) prevent CMOV
generation
for volatile mem
PR rtl-optimization/47698
* gcc.target/i386/47698.c: New test
Please use punctuation marks and correct capitalization in ChangeLog
entries.
OTOH, do we want to fix this per-target, or in the middle-end?
The middle-end pattern documentation does not say operands 2 and 3
are not evaluated if they do not end up being stored, so a middle-end
fix is more appropriate.
Richard.
I have two observations:
- the code for CMOV is under #ifdef in the mddle-end, which is
explicitly marked as have to be removed (ifcvt.c:1446)
- I have no clear evidence all platforms that support conditional move
have the same semantics that lead to the PR
I think the best way to address both concerns is to implement code
that relies on а new hookup volatile-safe CMOV that is false by
default.
I suppose it's never safe for all architectures that support
memory operands in the source operand.
Richard.
ok, at least there should be no big problem of missing optimization
around volatile memory.
apparently the problem is here:
ifcvt.c:2539 there is a test for side effects of source (which is 'a'
in this case)
2539 if (! noce_operand_ok (a) || ! noce_operand_ok (b))
(gdb) p debug_rtx(a)
(mem/v/c/i:DI (symbol_ref:DI (mmio) [flags 0x40] var_decl
0x71339140 mmio) [2 mmio+0 S8 A64])
but inside noce_operand_ok() there is a wrong order of tests:
2332 if (MEM_P (op))
2333 return ! side_effects_p (XEXP (op, 0));
2334
2335 if (side_effects_p (op))
2336 return FALSE;
2337
where XEXP removes the memory reference leaving just symbol reference,
that has no volatile attribute
#0 side_effects_p (x=0x7149c660) at ../../gcc/rtlanal.c:2152
(gdb) p debug_rtx(x)
(symbol_ref:DI (mmio) [flags 0x40] var_decl 0x71339140 mmio)
Is the following fix is Ok?
I'm testing it so far.
Sergos
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 784e2e8..3b05c2a 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2329,12 +2329,12 @@ noce_operand_ok (const_rtx op)
{
/* We special-case memories, so handle any of them with
no address side effects. */
- if (MEM_P (op))
- return ! side_effects_p (XEXP (op, 0));
-
if (side_effects_p (op))
return FALSE;
+ if (MEM_P (op))
+ return ! side_effects_p (XEXP (op, 0));
+
return ! may_trap_p (op);
}
diff --git a/gcc/testsuite/gcc.target/i386/47698.c
b/gcc/testsuite/gcc.target/i386/47698.c
new file mode 100644
index 000..2c75109
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/47698.c
@@ -0,0 +1,10 @@
+/* { dg-options -Os } */
+/* { dg-final { scan-assembler-not cmov } } */
+
+extern volatile unsigned long mmio;
+unsigned long foo(int cond)
+{
+ if (cond)
+ return mmio;
+ return 0;
+}
bootstrapped and passed make check successfully on x86_64-unknown-linux-gnu
Ok.
Thanks,
Richard.
[PATCH, i386]: Fix gcc.target/i386/avx-vcvttpd2dq-256-1.c execution test failure
Hello!
2011-11-02 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (bdesc_args) [IX86_BUILTIN_CVTTPD2DQ256]: Use
CODE_FOR_fix_truncv4dfv4si2, not CODE_FOR_fix_truncv4sfv4si2.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: i386.c
===
--- i386.c (revision 180762)
+++ i386.c (working copy)
@@ -26189,7 +26189,7 @@
{ OPTION_MASK_ISA_AVX, CODE_FOR_avx_cvtpd2ps256,
__builtin_ia32_cvtpd2ps256, IX86_BUILTIN_CVTPD2PS256, UNKNOWN, (int)
V4SF_FTYPE_V4DF },
{ OPTION_MASK_ISA_AVX, CODE_FOR_avx_cvtps2dq256,
__builtin_ia32_cvtps2dq256, IX86_BUILTIN_CVTPS2DQ256, UNKNOWN, (int)
V8SI_FTYPE_V8SF },
{ OPTION_MASK_ISA_AVX, CODE_FOR_avx_cvtps2pd256,
__builtin_ia32_cvtps2pd256, IX86_BUILTIN_CVTPS2PD256, UNKNOWN, (int)
V4DF_FTYPE_V4SF },
- { OPTION_MASK_ISA_AVX, CODE_FOR_fix_truncv4sfv4si2,
__builtin_ia32_cvttpd2dq256, IX86_BUILTIN_CVTTPD2DQ256, UNKNOWN, (int)
V4SI_FTYPE_V4DF },
+ { OPTION_MASK_ISA_AVX, CODE_FOR_fix_truncv4dfv4si2,
__builtin_ia32_cvttpd2dq256, IX86_BUILTIN_CVTTPD2DQ256, UNKNOWN, (int)
V4SI_FTYPE_V4DF },
{ OPTION_MASK_ISA_AVX, CODE_FOR_avx_cvtpd2dq256,
__builtin_ia32_cvtpd2dq256, IX86_BUILTIN_CVTPD2DQ256, UNKNOWN, (int)
V4SI_FTYPE_V4DF },
{ OPTION_MASK_ISA_AVX, CODE_FOR_fix_truncv8sfv8si2,
__builtin_ia32_cvttps2dq256, IX86_BUILTIN_CVTTPS2DQ256, UNKNOWN, (int)
V8SI_FTYPE_V8SF },
{ OPTION_MASK_ISA_AVX, CODE_FOR_avx_vperm2f128v4df3,
__builtin_ia32_vperm2f128_pd256, IX86_BUILTIN_VPERM2F128PD256, UNKNOWN, (int)
V4DF_FTYPE_V4DF_V4DF_INT },
Re: [PING] Re: [PATCH] Fix PR46556 (poor address generation)
On Sun, 30 Oct 2011, William J. Schmidt wrote:
Ping.
On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
OK, I've removed the pointer-arithmetic case from expand, to be handled
later by straight-line strength reduction. Here's the patch to deal
with just the specific pattern of PR46556 (which will also eventually be
handled by strength reduction, but not as quickly).
(FYI, I've been thinking through the strength reduction pass, and my
plan is to stage in some of the easiest cases first, hopefully for 4.7,
and gradually add the more complex pieces. Explicit multiplies in the
IL with known constants can be done pretty easily. More complexity is
added when the multiplier is a variable, when conditional increments are
present, and when multiplies are hidden in addressing expressions.)
The present patch was bootstrapped and regression-tested on
powerpc64-linux. OK for trunk?
Hmmm ...
Thanks,
Bill
2011-10-24 Bill Schmidt wschm...@linux.vnet.ibm.com
gcc:
PR rtl-optimization/46556
* expr.c (restructure_base_and_offset): New function.
(expand_expr_real_1): Replace result of get_inner_reference
with result of restructure_base_and_offset when applicable.
* Makefile.in (expr.o): Update dependencies.
gcc/testsuite:
PR rtl-optimization/46556
* gcc.dg/tree-ssa-pr46556-1.c: New testcase.
* gcc.dg/tree-ssa-pr46556-2.c: Likewise.
* gcc.dg/tree-ssa-pr46556-3.c: Likewise.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+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], p-b[n]);
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 2 expand } }
*/
+/* { dg-final { scan-rtl-dump-times const_int 128 1 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\) \\\[
1 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+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], p-b[n]);
+ if (n 12)
+foo (p-a[n], p-c[n], p-b[n]);
+ else if (n 3)
+foo (p-b[n], p-a[n], p-c[n]);
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 6 expand } }
*/
+/* { dg-final { scan-rtl-dump-times const_int 128 3 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\) \\\[
3 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c (revision 0)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+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], p-b[n]);
+ if (n 3)
+{
+ foo (p-a[n], p-c[n], p-b[n]);
+ if (n 12)
+ foo (p-b[n], p-a[n], p-c[n]);
+}
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 6 expand } }
*/
+/* { dg-final { scan-rtl-dump-times const_int 128 3 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\) \\\[
3 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/expr.c
===
--- gcc/expr.c (revision 180378)
+++ gcc/expr.c (working copy)
@@ -56,6 +56,7 @@ along with GCC; see the file COPYING3. If not see
#include ssaexpand.h
#include target-globals.h
#include params.h
+#include tree-pretty-print.h
/* Decide whether a function's arguments should be processed
from first to last or from last to first.
@@ -7648,7 +7649,66 @@ expand_constructor (tree exp, rtx target, enum exp
return target;
}
+/* Given BASE, OFFSET, and BITPOS derived from EXPR, determine whether
+ there is a profitable opportunity to restructure
[PATCH, i386]: Testsuite adjustments
Hello!
2011-11-02 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/avx-cvt-2.c (dg-options): Add -mtune=generic.
* gcc.target/i386/avx2-cvt-2.c (dg-options): Ditto.
* gcc.target/i386/sse2-cvt-2.c (dg-options): Ditto.
* gcc.target/i386/vectorize4-avx.c (dg-final): Remove xfail *-*-*.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: gcc.target/i386/avx-cvt-2.c
===
--- gcc.target/i386/avx-cvt-2.c (revision 180768)
+++ gcc.target/i386/avx-cvt-2.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O3 -mavx -mno-avx2 -fdump-tree-vect-details } */
+/* { dg-options -O3 -mavx -mno-avx2 -mtune=generic -fdump-tree-vect-details
} */
#include avx-cvt-1.c
Index: gcc.target/i386/sse2-cvt-2.c
===
--- gcc.target/i386/sse2-cvt-2.c(revision 180768)
+++ gcc.target/i386/sse2-cvt-2.c(working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O3 -msse2 -mno-sse3 -fdump-tree-vect-details } */
+/* { dg-options -O3 -msse2 -mno-sse3 -mtune=generic -fdump-tree-vect-details
} */
#include sse2-cvt-1.c
Index: gcc.target/i386/vectorize4-avx.c
===
--- gcc.target/i386/vectorize4-avx.c(revision 180768)
+++ gcc.target/i386/vectorize4-avx.c(working copy)
@@ -11,4 +11,4 @@
dest[i] = sqrt (tmp_out[i]);
}
-/* { dg-final { scan-assembler vsqrtpd\[ \\t\]+\[^\n\]*%ymm { xfail *-*-* }
} } */
+/* { dg-final { scan-assembler vsqrtpd\[ \\t\]+\[^\n\]*%ymm } } */
Index: gcc.target/i386/avx2-cvt-2.c
===
--- gcc.target/i386/avx2-cvt-2.c(revision 180768)
+++ gcc.target/i386/avx2-cvt-2.c(working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O3 -mavx2 -fdump-tree-vect-details } */
+/* { dg-options -O3 -mavx2 -mtune=generic -fdump-tree-vect-details } */
#include avx2-cvt-1.c
Re: [Patch,AVR]: Implement PR50931 (24-bit integers) (divmod) [2/n]
Georg-Johann Lay wrote: To support the upcoming named address space support in avr, a 24-bit pointer type is needed. This patch adds respective support of a 24-bit integer mode called PSI. The patch supports more than is actually needed for a pointer-only implementation: is supplies almost all needed insns to render the new mode efficient for use in arithmetic. The impact on already existing code for non-PSI part of the backend is very small and just a handfull of lines: - avr_out_plus_1, output_reload_in_const and avr_simplify_comparison_p can handle 3-byte types now. - avr_libcall_value: 3-byte values will be passed in even registers. - TARGET_SCALAR_MODE_SUPPORTED_P reports PSI as supported scalar - avr_init_builtins exposes the new mode to user land as new build-in types __int24_t and __uint24_t. - avr_cpu_cpp_builtins adds build-in macros __INT24_MAX__, __INT24_MIN__ and __UINT24_MAX__ so that user can test if the new mode is available for arithmetic. The rest of the patch is PSI-specific: Routines for comparison, addition, rotation, and, or, xor were already generic enough to support the new type without effort. Shifts and load/store/move are a bit lengthy routines as it is the case with SI, too. There are some parts missing and are planned to supply them in separate patches: - Documentation - Test cases - libgcc support of __[u]divmodpsi4 - Perhaps more efficient MUL. At the moment, multiplication is extended to 32 bits. This leads to suboptimal code because of 32-bit arithmetic and more SUBREGs than with a native mulpsi3 support. Patch is lightly tested and passes the test suites. Ok for trunk? Johann PR target/50931 * config/avr/avr-modes.def: New file defining PSImode. * config/avr/avr-c.c (__INT24_MAX__, __INT24_MIN__, __UINT24_MAX__): New built-in defines. * config/avr/avr.md (adjust_len): Add tstpsi, mov24, reload_in24, ashlpsi, ashrpsi, lshrpsi. (HISI, HIDI, MPUSH, rotx, rotsmode): Add PSI. (MOVMODE): New mode iterator. (movpsi): New expander. (movqi, movhi, movsi, movsf, movpsi): Write as one using MOVMODE. (*reload_inpsi, *movpsi): New insns. (*reload_inpsi): New RTL peephole. (addpsi3, *addpsi3_zero_extend.qi, *addpsi3_zero_extend.hi, *addpsi3_sign_extend.hi): New insns. (subpsi3, *subpsi3_zero_extend.qi, *subpsi3_zero_extend.hi, *subpsi3_sign_extend.hi): New insns. (divmodpsi4, udivmodpsi4): New define insn-and-split. (*divmodpsi4_call, *udivmodpsi4_call): New insns. (andpsi3, iorpsi3, xorpsi3): New insns. (*rotlpsi2.1, *rotlpsi2.23): New insns. (*rotwmode): Insn condition only allow even-sized modes. (*rotbmode): Insn condition allows odd-sized modes. (ashlpsi3, ashrpsi3, lshrpsi3): New insns. (negpsi2, one_cmplpsi2): New insns. (extendqipsi2, extendhipsi2, extendpsisi2): New insns. (zero_extendqipsi2, zero_extendhipsi2, zero_extendpsisi2): New insn-and-splits. (*cmppsi, *negated_tstpsi, *reversed_tstpsi): New insns. (cbranchpsi4): New expander. * config/avr/constraints.md (Ca3, Co3, Cx3): New constraints. * config/avr/avr-protos.h (avr_out_tstpsi, avr_out_movpsi, avr_out_ashlpsi3, avr_out_ashrpsi3, avr_out_lshrpsi3, avr_out_reload_inpsi): New prototypes. * config/avr/avr.c (TARGET_SCALAR_MODE_SUPPORTED_P): Define to... (avr_scalar_mode_supported_p): ...this new static function. (avr_asm_len): Always return . (avr_out_load_psi, avr_out_store_psi): New static functions. (avr_out_movpsi, avr_out_reload_inpsi): New functions. (avr_out_tstpsi): New function. (avr_out_ashlpsi3, avr_out_ashrpsi3, avr_out_lshrpsi3): New functions. (avr_out_plus_1, output_reload_in_const): Handle 3-byte types. (avr_simplify_comparison_p): Ditto. (adjust_insn_length): Handle ADJUST_LEN_RELOAD_IN24, ADJUST_LEN_MOV24, ADJUST_LEN_TSTPSI, ADJUST_LEN_ASHLPSI, ADJUST_LEN_ASHRPSI, ADJUST_LEN_LSHRPSI. (avr_rtx_costs_1): Report PSI costs. (avr_libcall_value): Handle odd-sized parameters. (avr_init_int24): New static function. (avr_init_builtins): Use it. This patch is the div/mod support for libgcc. With this patch, 24-bit integers are fully supported for integer arithmetic. During the implementation it turned out that the register footprint is smaller than that of SImode: PSI need 3 registers less so that the representation in avr.md needs adjustment like so: @@ -2199,6 +2294,66 @@ (define_insn *udivmodhi4_call [(set_attr type xcall) (set_attr cc clobber)]) +;; + +(define_insn_and_split divmodpsi4 + [(parallel [(set (match_operand:PSI 0 pseudo_register_operand ) + (div:PSI (match_operand:PSI 1
Re: [PING] Re: [PATCH] Fix PR46556 (poor address generation)
On Wed, 2011-11-02 at 12:55 +0100, Richard Guenther wrote:
On Sun, 30 Oct 2011, William J. Schmidt wrote:
Ping.
On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
OK, I've removed the pointer-arithmetic case from expand, to be handled
later by straight-line strength reduction. Here's the patch to deal
with just the specific pattern of PR46556 (which will also eventually be
handled by strength reduction, but not as quickly).
(FYI, I've been thinking through the strength reduction pass, and my
plan is to stage in some of the easiest cases first, hopefully for 4.7,
and gradually add the more complex pieces. Explicit multiplies in the
IL with known constants can be done pretty easily. More complexity is
added when the multiplier is a variable, when conditional increments are
present, and when multiplies are hidden in addressing expressions.)
The present patch was bootstrapped and regression-tested on
powerpc64-linux. OK for trunk?
Hmmm ...
Thanks,
Bill
2011-10-24 Bill Schmidt wschm...@linux.vnet.ibm.com
gcc:
PR rtl-optimization/46556
* expr.c (restructure_base_and_offset): New function.
(expand_expr_real_1): Replace result of get_inner_reference
with result of restructure_base_and_offset when applicable.
* Makefile.in (expr.o): Update dependencies.
gcc/testsuite:
PR rtl-optimization/46556
* gcc.dg/tree-ssa-pr46556-1.c: New testcase.
* gcc.dg/tree-ssa-pr46556-2.c: Likewise.
* gcc.dg/tree-ssa-pr46556-3.c: Likewise.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+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], p-b[n]);
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 2 expand }
} */
+/* { dg-final { scan-rtl-dump-times const_int 128 1 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\)
\\\[ 1 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+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], p-b[n]);
+ if (n 12)
+foo (p-a[n], p-c[n], p-b[n]);
+ else if (n 3)
+foo (p-b[n], p-a[n], p-c[n]);
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 6 expand }
} */
+/* { dg-final { scan-rtl-dump-times const_int 128 3 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\)
\\\[ 3 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c (revision 0)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+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], p-b[n]);
+ if (n 3)
+{
+ foo (p-a[n], p-c[n], p-b[n]);
+ if (n 12)
+ foo (p-b[n], p-a[n], p-c[n]);
+}
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 6 expand }
} */
+/* { dg-final { scan-rtl-dump-times const_int 128 3 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\)
\\\[ 3 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/expr.c
===
--- gcc/expr.c(revision 180378)
+++ gcc/expr.c(working copy)
@@ -56,6 +56,7 @@ along with GCC; see the file COPYING3. If not see
#include ssaexpand.h
#include target-globals.h
#include params.h
+#include tree-pretty-print.h
/* Decide whether a function's arguments should be processed
from first to last or from last to first.
@@ -7648,7 +7649,66 @@ expand_constructor (tree exp, rtx
Re: [PATCH] Canonicalize sparc movcc patterns such that operand 0 always appears in operand 4.
Anyways, instead what I do here is normalize all expansions of
conditional moves to be of the form:
(set op0 (if_then_else (cmp X Y)
op3
op0))
and in the instruction patterns I use register_operand and
constraint 0 for operand 4.
This is enough to keep the combiner from recognizing sequences
like the above.
Committed to trunk.
gcc/
* config/sparc/sparc-protos.h (sparc_expand_conditional_move): Declare.
* config/sparc/sparc.md (movI:modecc, movF:modecc): Call it.
(*movI:mode_cc_v9): Normalize to expect operand 0 always in operand 4.
(*movI:mode_cc_reg_sp64): Likewise.
(*movsf_cc_v9): Likewise.
(*movsf_cc_reg_sp64): Likewise.
(*movdf_cc_v9): Likewise.
(*movdf_cc_reg_sp64): Likewise.
(*movtf_cc_hq_v9): Likewise.
(*movtf_cc_reg_hq_sp64): Likewise.
(*movtf_cc_v9): Likewise.
(*movtf_cc_reg_sp64): Likewise.
* config/sparc/sparc.c (sparc_expand_conditional_move): New function.
(sparc_print_operand): Delete 'c' and 'd' handling, no longer used.
This has reintroduced PR target/49965.
@@ -11377,4 +11361,58 @@ sparc_secondary_reload (bool in_p, rtx x,
reg_class_t rclass_i, return NO_REGS;
}
+bool
+sparc_expand_conditional_move (enum machine_mode mode, rtx *operands)
+{
+ enum rtx_code rc = GET_CODE (operands[1]);
+ enum machine_mode cmp_mode;
+ rtx cc_reg, dst, cmp;
+
+ cmp = operands[1];
+ cmp_mode = GET_MODE (XEXP (cmp, 0));
+ if (cmp_mode == DImode !TARGET_ARCH64)
+return false;
+
+ dst = operands[0];
+
+ if (! rtx_equal_p (operands[2], dst)
+ ! rtx_equal_p (operands[3], dst))
+{
+ if (reg_overlap_mentioned_p (dst, cmp))
+ dst = gen_reg_rtx (mode);
+
+ emit_move_insn (dst, operands[3]);
+}
+ else if (operands[2] == dst)
+{
+ operands[2] = operands[3];
+
+ if (GET_MODE_CLASS (cmp_mode) == MODE_FLOAT)
+rc = reverse_condition_maybe_unordered (rc);
+ else
+rc = reverse_condition (rc);
+}
+
+ if (cmp_mode == TFmode !TARGET_HARD_QUAD)
+cmp = sparc_emit_float_lib_cmp (XEXP (cmp, 0), XEXP (cmp, 1), rc);
You cannot cache anything from operands[1] as sparc_emit_float_lib_cmp will
modify it, including RC.
+ if (XEXP (cmp, 1) == const0_rtx
+ GET_CODE (XEXP (cmp, 0)) == REG
+ cmp_mode == DImode
+ v9_regcmp_p (rc))
+cc_reg = XEXP (cmp, 0);
+ else
+cc_reg = gen_compare_reg_1 (rc, XEXP (cmp, 0), XEXP (cmp, 1));
+
+ cmp = gen_rtx_fmt_ee (rc, GET_MODE (cc_reg), cc_reg, const0_rtx);
RC is wrong here if we went through sparc_emit_float_lib_cmp above.
--
Eric Botcazou
Re: RFC: PATCH to adjust warning flags for C++
On Wed, Nov 2, 2011 at 12:40 AM, Jason Merrill ja...@redhat.com wrote: On 11/02/2011 12:05 AM, Gabriel Dos Reis wrote: And I think that your code won't work in C++11 is a warning that most C++ programmers will be interested in if they are asking for warnings. Even when -std=c++03 -Wall or -std=c++98 -Wall? Yes. -Wc++0x-compat has been part of -Wall for almost 5 years. If people don't want narrowing warnings, they can use -Wno-narrowing, which is helpfully mentioned in the warnings themselves. narrowing is just one issue. Originally, we were checking mostly for clashes in identifiers and the like. And we should have been more cautious then. Now that C++11 support is far better, I think it is still time to correct what we should have done. At least not warning when the standard is explicitly selected, as opposed to whatever the default is. That is, if -std=c++03 or -std=c++98 is explicitly given on the command line, we should avoid including -Wc++0x-compat in -Wall.
Re: [PATCH] strlenopt improvements
2011-10-24 Andreas Krebbel andreas.kreb...@de.ibm.com * gcc.dg/strlenopt-22.c: New testcase. This doesn't link if you don't have stpcpy in the libc, e.g. on Solaris. Here's an excerpt from the Linux man pages: CONFORMING TO This function is not part of the C or POSIX.1 standards, and is not customary on Unix systems, but is not a GNU invention either. Perhaps it comes from MS-DOS. -- Eric Botcazou
Re: [PATCH] strlenopt improvements
On Wed, Nov 02, 2011 at 01:41:30PM +0100, Eric Botcazou wrote:
2011-10-24 Andreas Krebbel andreas.kreb...@de.ibm.com
* gcc.dg/strlenopt-22.c: New testcase.
This doesn't link if you don't have stpcpy in the libc, e.g. on Solaris.
Here's an excerpt from the Linux man pages:
CONFORMING TO
This function is not part of the C or POSIX.1 standards, and is not
customary on Unix systems, but is not a GNU invention either. Perhaps
it comes from MS-DOS.
The man page is outdated, stpcpy is a standard POSIX2008 function.
Anyway, in the other gcc.dg/strlenopt-* testcases for USE_GNU I was using
the convention that the name ended with g (i.e. strlenopt-22g.c) and
the test would start with:
/* This test needs runtime that provides stpcpy function. */
/* { dg-do run { target *-*-linux* } } */
instead of just
/* { dg-do run } */
Jakub
[Patch, i386] Add minus to list of promotable operators
Currently gcc will promote from QI/HI mode to SI mode various operators but not minus. It will however promote a neg followed by an add (add is in the current list of promotable operators and neg is promoted around config/i386/i386.md:16904). This omission can cause RAT stalls in tight loops. Successfully bootstrapped and checked with x86_64-unknown-linux-gnu. Could someone please review the change? Thanks, Teresa 2011-11-02 Teresa Johnson tejohn...@google.com * config/i386/predicates.md (promotable_binary_operator): Add minus to the list of promotable operators. Index: config/i386/predicates.md === --- config/i386/predicates.md (revision 180696) +++ config/i386/predicates.md (working copy) @@ -1162,7 +1162,7 @@ ;; Return true if OP is a binary operator that can be promoted to wider mode. (define_predicate promotable_binary_operator - (ior (match_code plus,and,ior,xor,ashift) + (ior (match_code plus,minus,and,ior,xor,ashift) (and (match_code mult) (match_test TARGET_TUNE_PROMOTE_HIMODE_IMUL -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: RFC: PATCH to adjust warning flags for C++
On 11/02/2011 05:40 AM, Paolo Bonzini wrote: Is this a C++-only warning? Also, how did you test the patch? It is, but the flag is accepted and ignored by the C front end. I tested it with a bootstrap. Jason
Re: CFT: [build] Move libgcc_tm_file to toplevel libgcc
Paolo Bonzini bonz...@gnu.org writes: On 08/16/2011 04:59 AM, Rainer Orth wrote: None of them uses any of those macros, so I think we're safe. Yes, I checked the same now. Looks like we're good. Here's the rebased version of the patch I'm about to check in, after regtesting on i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu, i386-apple-darwin9.8.0, and powerpc-apple-darwin9.8.0. Rainer 2011-08-06 Rainer Orth r...@cebitec.uni-bielefeld.de Paolo Bonzini bonz...@gnu.org gcc: * configure.ac (libgcc_tm_file_list, libgcc_tm_include_list): Remove. * configure: Regenerate. * Makefile.in (libgcc_tm_file_list, libgcc_tm_include_list): Remove. (TM_H): Remove libgcc_tm.h, $(libgcc_tm_file_list). (libgcc_tm.h, cs-libgcc_tm.h): Remove. (clean): Remove libgcc_tm.h * mkconfig.sh: Don't include libgcc_tm.h in tm.h. * config.gcc (libgcc_tm_file): Remove. (arm*-*-linux*): Remove libgcc_tm_file for arm*-*-linux-*eabi. (arm*-*-uclinux*): Remove libgcc_tm_file for arm*-*-uclinux*eabi. (arm*-*-eabi*, arm*-*-symbianelf*): Remove libgcc_tm_file. (avr-*-rtems*): Likewise. (avr-*-*): Likewise. (frv-*-elf): Likewise. (frv-*-*linux*): Likewise. (h8300-*-rtems*): Likewise. (h8300-*-elf*): Likewise. (i[34567]86-*-darwin*): Likewise. (x86_64-*-darwin*): Likewise. (rx-*-elf*): Likewise. (tic6x-*-elf): Likewise. (tic6x-*-uclinux): Likewise. (i[34567]86-*-linux*, x86_64-*-linux*): Likewise. libgcc: * configure.ac (tm_file_): New variable. Determine from tm_file. (tm_file, tm_defines): Substitute. * configure: Regenerate. * mkheader.sh: New file. * Makefile.in (clean): Remove libgcc_tm.h. ($(objects)): Depend on libgcc_tm.h. (libgcc_tm_defines, libgcc_tm_file): New variables. (libgcc_tm.h, libgcc_tm.stamp): New targets. ($(libgcc-objects), $(libgcc-s-objects), $(libgcc-eh-objects)) ($(libgcov-objects), $(libunwind-objects), $(libunwind-s-objects)) ($(extra-parts)): Depend on libgcc_tm.h. * config.host (tm_defines, tm_file): New variable. (arm*-*-linux*): Set tm_file for arm*-*-linux-*eabi. (arm*-*-uclinux*): Set tm_file for arm*-*-uclinux*eabi. (arm*-*-eabi*, arm*-*-symbianelf*): Set tm_file. (avr-*-rtems*): Likewise. (avr-*-*): Likewise. (frv-*-elf): Likewise. (frv-*-*linux*): Likewise. (h8300-*-rtems*): Likewise. (h8300-*-elf*): Likewise. (i[34567]86-*-darwin*): Likewise. (x86_64-*-darwin*): Likewise. (rx-*-elf): Likewise. (tic6x-*-uclinux): Likewise. (tic6x-*-elf): Likewise. (i[34567]86-*-linux*, x86_64-*-linux*): Likewise. * config/alpha/gthr-posix.c: Include libgcc_tm.h. * config/i386/cygming-crtbegin.c: Likewise. * config/i386/cygming-crtend.c: Likewise. * config/ia64/fde-vms.c: Likewise. * config/ia64/unwind-ia64.c: Likewise. * config/libbid/bid_gcc_intrinsics.h: Likewise. * config/rs6000/darwin-fallback.c: Likewise. * config/stormy16/lib2funcs.c: Likewise. * config/xtensa/unwind-dw2-xtensa.c: Likewise. * crtstuff.c: Likewise. * dfp-bit.h: Likewise. * emutls.c: Likewise. * fixed-bit.c: Likewise. * fp-bit.c: Likewise. * generic-morestack-thread.c: Likewise. * generic-morestack.c: Likewise. * libgcc2.c: Likewise. * libgcov.c: Likewise. * unwind-dw2-fde-dip.c: Likewise. * unwind-dw2-fde.c: Likewise. * unwind-dw2.c: Likewise. * unwind-sjlj.c: Likewise. # HG changeset patch # Parent b3e4db3f4854862cc04a6abb156278761b85bae7 Move libgcc_tm_file to toplevel libgcc diff --git a/gcc/Makefile.in b/gcc/Makefile.in --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -490,8 +490,6 @@ md_file=$(srcdir)/config/@md_file@ tm_file_list=@tm_file_list@ tm_include_list=@tm_include_list@ tm_defines=@tm_defines@ -libgcc_tm_file_list=@libgcc_tm_file_list@ -libgcc_tm_include_list=@libgcc_tm_include_list@ tm_p_file_list=@tm_p_file_list@ tm_p_include_list=@tm_p_include_list@ build_xm_file_list=@build_xm_file_list@ @@ -790,8 +788,7 @@ CONFIG_H = config.h $(host_xm_file_lis TCONFIG_H = tconfig.h $(xm_file_list) TM_P_H= tm_p.h$(tm_p_file_list) GTM_H = tm.h $(tm_file_list) insn-constants.h -TM_H = $(GTM_H) libgcc_tm.h $(libgcc_tm_file_list) insn-flags.h \ - $(OPTIONS_H) +TM_H = $(GTM_H) insn-flags.h $(OPTIONS_H) # Variables for version information. BASEVER := $(srcdir)/BASE-VER # 4.x.y @@ -1598,7 +1595,6 @@ config.h: cs-config.h ; @true bconfig.h: cs-bconfig.h ; @true tconfig.h: cs-tconfig.h ; @true tm.h: cs-tm.h ; @true -libgcc_tm.h: cs-libgcc_tm.h ; @true tm_p.h:
Re: RFC: PATCH to adjust warning flags for C++
On 11/02/2011 02:47 PM, Jason Merrill wrote: Is this a C++-only warning? Also, how did you test the patch? It is, but the flag is accepted and ignored by the C front end. Then please adjust libcpp/configure.ac too; otherwise the patch is okay to fix bootstrap. It can be reverted later if c++0x-compat is made less stringent. Paolo
Re: [PATCH] strlenopt improvements
Jakub Jelinek ja...@redhat.com writes:
Anyway, in the other gcc.dg/strlenopt-* testcases for USE_GNU I was using
the convention that the name ended with g (i.e. strlenopt-22g.c) and
the test would start with:
/* This test needs runtime that provides stpcpy function. */
/* { dg-do run { target *-*-linux* } } */
instead of just
/* { dg-do run } */
This isn't right either: e.g. Solaris 11 does have stpcpy, as do systems
with a non-Linux kernel, but using *glibc. If there are more than one or
two instances of this, this needs an effective-target keyword, along the
lines of target-supports.exp (check_mkfifo_available).
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] strlenopt improvements
On Wed, Nov 02, 2011 at 02:55:54PM +0100, Rainer Orth wrote:
Jakub Jelinek ja...@redhat.com writes:
Anyway, in the other gcc.dg/strlenopt-* testcases for USE_GNU I was using
the convention that the name ended with g (i.e. strlenopt-22g.c) and
the test would start with:
/* This test needs runtime that provides stpcpy function. */
/* { dg-do run { target *-*-linux* } } */
instead of just
/* { dg-do run } */
This isn't right either: e.g. Solaris 11 does have stpcpy, as do systems
with a non-Linux kernel, but using *glibc. If there are more than one or
two instances of this, this needs an effective-target keyword, along the
lines of target-supports.exp (check_mkfifo_available).
Feel free to change it, it isn't too important to me, all it would buy
us is additional testing of generic optimizations on a tiny bit more
targets.
Some strlenopt-*f.c tests also need __*_chk functions, either just those,
or those and stpcpy.
Jakub
Re: [build] Move gthr to toplevel libgcc
Paolo Bonzini bonz...@gnu.org writes:
Ok with a couple of changes:
gcc:
* gthr-posix.h, gthr-single.h, gthr.h: Move to ../libgcc.
Move gthr-posix.h to config/
* config/m32r/linux.h (SUBTARGET_CPP_SPEC): Don't define _PTHREADS
if -pthread.
* config/mn10300/linux.h (CPP_SPEC): Likewise.
* config/netbsd.h (NETBSD_CPP_SPEC): Likewise.
* config/sh/linux.h (SUBTARGET_CPP_SPEC): Likewise.
* config/sol2.h (CPP_SUBTARGET_SPEC): Likewise.
Don't commit these, not yet at least (well, for Solaris it's your choice).
* config.host (thread_header, thread_dir): New variables.
Set it depending on target_thread_file.
Move to configure.ac, and remove the indirection on thread_dir (i.e. just
set thread_header).
Here's the updated and rebased version of the patch I'm about to commit,
after regtesting on i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-unknown-linux-gnu, i386-apple-darwin9.8.0, and
powerpc-apple-darwin9.8.0.
Thanks.
Rainer
2011-08-06 Rainer Orth r...@cebitec.uni-bielefeld.de
gcc:
* gthr-single.h, gthr.h: Move to ../libgcc.
* gthr-aix.h: Move to ../libgcc/config/rs6000.
* gthr-dce.h: Move to ../libgcc/config/pa.
* gthr-lynx.h: Move to ../libgcc/config.
* gthr-mipssde.h: Move to ../libgcc/config/mips.
* gthr-posix.h: Move to ../libgcc/config.
* gthr-rtems.h: Likewise.
* gthr-tpf.h: Move to ../libgcc/config/s390.
* gthr-vxworks.h: Move to ../libgcc/config.
* gthr-win32.h: Move to ../libgcc/config/i386.
* configure.ac (gthread_flags): Remove
(gthr-default.h): Don't create.
(thread_file): Don't substitute.
* configure: Regenerate.
* Makefile.in (GCC_THREAD_FILE): Remove.
(GTHREAD_FLAGS): Remove.
(libgcc.mvars): Remove GTHREAD_FLAGS.
* config/t-vxworks (EXTRA_HEADERS): Remove.
gcc/po:
* EXCLUDES (gthr-aix.h, gthr-dce.h, gthr-posix.c, gthr-posix.h)
(gthr-rtems.h, gthr-single.h, gthr-solaris.h, gthr-vxworks.h)
(gthr-win32.h, gthr.h): Remove.
libgcc:
* gthr-single.h, gthr.h: New files.
* config/gthr-lynx.h, config/gthr-posix.h., config/gthr-rtems.h,
config/gthr-vxworks.h, config/i386/gthr-win32.h,
config/mips/gthr-mipssde.h, config/pa/gthr-dce.h,
config/rs6000/gthr-aix.h, config/s390/gthr-tpf.h: New files.
* config/i386/gthr-win32.c: Include gthr-win32.h.
* configure.ac (thread_header): New variable.
Set it depending on target_thread_file.
(gthr-default.h): Link from $thread_header.
* configure: Regenerate.
* Makefile.in (LIBGCC2_CFLAGS): Remove $(GTHREAD_FLAGS).
libgfortran:
* Makefile.am (AM_CPPFLAGS): Add
-I$(srcdir)/$(MULTISRCTOP)../libgcc, -I$(MULTIBUILDTOP)../libgcc.
* Makefile.in: Regenerate.
* acinclude.m4 (LIBGFOR_CHECK_GTHR_DEFAULT): Remove.
* configure.ac (LIBGFOR_CHECK_GTHR_DEFAULT): Likewise.
* configure: Regenerate.
* config.h.in: Regenerate.
libobjc:
* Makefile.in (INCLUDES): Add -I$(MULTIBUILDTOP)../libgcc.
* configure.ac (target_thread_file, HAVE_GTHR_DEFAULT): Remove.
* configure: Regenerate.
* config.h.in: Regenerate.
libstdc++-v3:
* acinclude.m4 (GLIBCXX_CONFIGURE): Determine and substitute
toplevel_builddir.
(GLIBCXX_ENABLE_THREADS): Remove glibcxx_thread_h,
HAVE_GTHR_DEFAULT, enable_thread.
(GLIBCXX_CHECK_GTHREADS): Reflect gthr move to libgcc.
* include/Makefile.am (thread_host_headers): Remove
${host_builddir}/gthr-tpf.h.
(${host_builddir}/gthr.h): Reflect gthr move to libgcc.
Use $.
(${host_builddir}/gthr-single.h): Likewise.
(${host_builddir}/gthr-posix.h): Likewise.
(${host_builddir}/gthr-tpf.h): Remove.
(${host_builddir}/gthr-default.h): Likewise.
* configure, config.h.in: Regenerate.
* Makefile.in, doc/Makefile.in, include/Makefile.in,
libsupc++/Makefile.in, po/Makefile.in, python/Makefile.in,
src/Makefile.intestsuite/Makefile.in: Regenerate.
# HG changeset patch
# Parent cbf2f0be2fab363976fac5e57a96f8bc4ae75f52
Move gthr to toplevel libgcc
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -532,9 +532,7 @@ lang_opt_files=@lang_opt_files@ $(srcdir
lang_specs_files=@lang_specs_files@
lang_tree_files=@lang_tree_files@
target_cpu_default=@target_cpu_default@
-GCC_THREAD_FILE=@thread_file@
OBJC_BOEHM_GC=@objc_boehm_gc@
-GTHREAD_FLAGS=@gthread_flags@
extra_modes_file=@extra_modes_file@
extra_opt_files=@extra_opt_files@
host_hook_obj=@out_host_hook_obj@
@@ -1806,7 +1804,6 @@ libgcc-support: libgcc.mvars stmp-int-hd
libgcc.mvars: config.status Makefile specs xgcc$(exeext)
: tmp-libgcc.mvars
echo GCC_CFLAGS =
Re: [Patch, i386] Add minus to list of promotable operators
Hello! Currently gcc will promote from QI/HI mode to SI mode various operators but not minus. It will however promote a neg followed by an add (add is in the current list of promotable operators and neg is promoted around config/i386/i386.md:16904). This omission can cause RAT stalls in tight loops. 2011-11-02 Teresa Johnson tejohn...@google.com * config/i386/predicates.md (promotable_binary_operator): Add minus to the list of promotable operators. OK for mainline. Thanks, Uros.
Re: [PING] Re: [PATCH] Fix PR46556 (poor address generation)
On Wed, 2 Nov 2011, William J. Schmidt wrote:
On Wed, 2011-11-02 at 12:55 +0100, Richard Guenther wrote:
On Sun, 30 Oct 2011, William J. Schmidt wrote:
Ping.
On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
OK, I've removed the pointer-arithmetic case from expand, to be handled
later by straight-line strength reduction. Here's the patch to deal
with just the specific pattern of PR46556 (which will also eventually be
handled by strength reduction, but not as quickly).
(FYI, I've been thinking through the strength reduction pass, and my
plan is to stage in some of the easiest cases first, hopefully for 4.7,
and gradually add the more complex pieces. Explicit multiplies in the
IL with known constants can be done pretty easily. More complexity is
added when the multiplier is a variable, when conditional increments are
present, and when multiplies are hidden in addressing expressions.)
The present patch was bootstrapped and regression-tested on
powerpc64-linux. OK for trunk?
Hmmm ...
Thanks,
Bill
2011-10-24 Bill Schmidt wschm...@linux.vnet.ibm.com
gcc:
PR rtl-optimization/46556
* expr.c (restructure_base_and_offset): New function.
(expand_expr_real_1): Replace result of get_inner_reference
with result of restructure_base_and_offset when applicable.
* Makefile.in (expr.o): Update dependencies.
gcc/testsuite:
PR rtl-optimization/46556
* gcc.dg/tree-ssa-pr46556-1.c: New testcase.
* gcc.dg/tree-ssa-pr46556-2.c: Likewise.
* gcc.dg/tree-ssa-pr46556-3.c: Likewise.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+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], p-b[n]);
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 2 expand
} } */
+/* { dg-final { scan-rtl-dump-times const_int 128 1 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\)
\\\[ 1 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+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], p-b[n]);
+ if (n 12)
+foo (p-a[n], p-c[n], p-b[n]);
+ else if (n 3)
+foo (p-b[n], p-a[n], p-c[n]);
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 6 expand
} } */
+/* { dg-final { scan-rtl-dump-times const_int 128 3 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\)
\\\[ 3 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c (revision 0)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+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], p-b[n]);
+ if (n 3)
+{
+ foo (p-a[n], p-c[n], p-b[n]);
+ if (n 12)
+ foo (p-b[n], p-a[n], p-c[n]);
+}
+}
+
+/* { dg-final { scan-rtl-dump-times \\(mem/s:SI \\(plus: 6 expand
} } */
+/* { dg-final { scan-rtl-dump-times const_int 128 3 expand } } */
+/* { dg-final { scan-rtl-dump-times const_int 64 \\\[0x40\\\]\\)\\)
\\\[ 3 expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/expr.c
===
--- gcc/expr.c (revision 180378)
+++ gcc/expr.c (working copy)
@@ -56,6 +56,7 @@ along with GCC; see the file COPYING3. If not see
#include ssaexpand.h
#include
Re: [PATCH] Fix errors in expand_atomic_store.
On 11/01/2011 04:48 PM, Richard Henderson wrote: On 11/01/2011 01:20 PM, David Miller wrote: Unfortunately, this is not true. Otherwise we could change the 32-bit default code generation to v9 from v7 under Linux. For v7, pa-risc, and sh, we originally allowed the test_and_set and lock_release patterns to do non-obvious things with 0/1 constants. My proposal is to *not* carry that over to the __atomic patterns. The PA and SH targets have already switched to use kernel helpers, and no longer rely on this hack. The only one left is Sparc v7. C++11 and C1x atomics do have an atomic_flag object which implements test _and_set and clear on a flag, and the standard requires that these *are* lock free . I was hoping to avoid introducing new routines just for that object and using the store and exchange since they are basically the same thing. If this is going to be a big issue, then maybe we should reverse my decision to combine their functionality and add __atomic_test_and_set and __atomic_clear to the __atomic library stable... Im not fond of that since its just a subclass of exchange and store... is it their weirdness on those targets you are concerned with? I could argue that those weirdnesses are only going to show up on targets which dont have other support anyway... hmm. As I make that argument, it also occurs to me how it can break. If atomic_flag HAS to be lockfree, it possible that there is another object the same size which is not lock free, and if I try to exchange (1) or store(0) into that object, the test_and-set or clear routine would be invoked and in a lock-free way.. which is going to break that object.. sigh. OK, I think i need to revert my position and introduce __atomic_test_and_set() and __atomic_clear(). bah. I'll work on that today. btw, how did that patch pass __sync_release tests? expand_builtin_sync_lock_release calls the __atomic_store expander now with 0... oh, its probably doing a compare_and_swap loop... in any case, the sync_lock_release expander would have to be put back in place. Andrew
Re: [RFC][cxx-mem-model] mem_signal_fence
On 11/01/2011 11:57 AM, Richard Henderson wrote: Any comments on the expectation, or implementation of signal-fence below? Should I make the distinction between the memory models here at all? I think the expectation is that signal_fence is identical to thread_fence, except the compiler doesn't actually issue the hardware fence instruction. Just the barrier-ness to the compiler as well as any data dependencies the memory order imposes needs to be maintained. Since we don't have any directional barriers yet, I guess anything other than RELAXED needs to be a full barrier to the compiler. someday when I have been energetic, we may get directional barriers and then we'll do something different. Thats my understanding anyway At minimum there's another typo in the ifdef section; we really need to minimize those... And good job at that! :-) These are paths that have not been tested until someone implements the rtl patterns... so any typo's would need to have been caught in the patch review :-) I never claimed to understand the intricacies of RTL pattern machinery that well... Andrew
Re: New port: Renesas RL78
Index: configure.ac +# Dereferencing -1 is a compile-time error This (those lines) look a little cryptic (and lack punctuation ;) Wild improvement guess: Too small 'int'?. No, the compiler specifically tests for unaligned accesses and gives a compile-time error, at Renesas's requrest. The chip can't do unaligned accesses correctly, but it doesn't fault - it just silently accesses the wrong memory. So the compiler errors instead. Also spotted a: Index: libgcc/config/rl78/trampoline.S \ No newline at end of file Wouldn't some tools behave better if the asm files had ELF decorations on the functions? Hmmm... perhaps, but this code is from an internal port that already has gdb, and the gdb engineer hasn't complained yet, and he's usually the one that points those out to me ;-) Also spotted some +#if 1 and + /*print_simple_rtl (file, op);*/ and I'll fix those. +#if DEBUG0 and +#if DEBUG_PEEP and +#define DEBUG_ALLOC 0 These are intentional, and left in for future debugging. There are other ports like that.
[cxx-mem-model] use alignment when available to determine lock-free ness
Lock free routines are not guaranteed to work if they are not aligned
properly. Until now, the __atmoic_is_lock_free property has simply
relied on the size of an object to determine lockfreeness. This works
when you assume a certain alignment.
The library takes generic pointers and with structure packing and such,
alignment is not guaranteed. This means its possible to have a 4 byte
object which is lock free, and another which is not. Up until now I've
simply punted on it and claimed it was undefined if not properly
aligned. By adding the address of the object to the function, it easy
enough to check alignment at runtime, as well as at compile time,
usually. The library will need this in the future so might as well take
care of it now.
Simply adds an optional parameter to __atomic_{is_always}_lock_free
which is used to check alignment against the size parameter. NULL as
the object pointer produces the same behaviour as today, lockfreeness
based on proper alignment for an integral value of the specified size.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Andrew
gcc
* builtins.c (fold_builtin_atomic_always_lock_free): Add object param
and check alignment if present.
(expand_builtin_atomic_always_lock_free): Expect 2nd argument.
(fold_builtin_atomic_is_lock_free): Expect 2nd argument.
(expand_builtin_atomic_is_lock_free): Expect 2nd argument.
(fold_builtin_1): Remove LOCK_FREE builtins.
(fold_builtin_2): Add LOCK_FREE builtins.
* sync-builtins.def (BUILT_IN_ATOMIC_{IS,ALWAYS}_LOCK_FREE): Add param.
* builtin-types.def (BT_FN_BOOL_SIZE): Remove.
(BT_FN_BOOL_SIZE_CONST_VPTR): Add.
fortran
* types.def (BT_FN_BOOL_SIZE): Remove.
(BT_FN_BOOL_SIZE_CONST_VPTR): Add.
libstdc++-v3
* include/std/atomic (is_lock_free): Add object pointer to
__atomic_is_lock_free.
* include/bits/atomic_base.h (LOCKFREE_PROP): Add 0 for object ptr.
(is_lock_free): Add object pointer to __atomic_is_lock_free.
testsuite
* gcc.dg/atomic-lockfree-aux.c: Add extra lock-free parameter.
* gcc.dg/atomic-invalid.c: Add extra lock-free parameter.
* gcc.dg/atomic-lockfree.c: Add extra lock-free parameter.
Index: gcc/builtins.c
===
*** gcc/builtins.c (revision 180699)
--- gcc/builtins.c (working copy)
*** expand_builtin_atomic_fetch_op (enum mac
*** 5448,5502
return ret;
}
! /* Return true if size ARG is always lock free on this architecture. */
static tree
! fold_builtin_atomic_always_lock_free (tree arg)
{
int size;
enum machine_mode mode;
! if (TREE_CODE (arg) != INTEGER_CST)
return NULL_TREE;
/* Check if a compare_and_swap pattern exists for the mode which represents
the required size. The pattern is not allowed to fail, so the existence
of the pattern indicates support is present. */
- size = INTVAL (expand_normal (arg)) * BITS_PER_UNIT;
- mode = mode_for_size (size, MODE_INT, 0);
-
if (can_compare_and_swap_p (mode))
return integer_one_node;
else
return integer_zero_node;
}
! /* Return true if the first argument to call EXP represents a size of
!object than will always generate lock-free instructions on this target.
!Otherwise return false. */
static rtx
expand_builtin_atomic_always_lock_free (tree exp)
{
tree size;
! tree arg = CALL_EXPR_ARG (exp, 0);
! if (TREE_CODE (arg) != INTEGER_CST)
{
! error (non-constant argument to __atomic_always_lock_free);
return const0_rtx;
}
! size = fold_builtin_atomic_always_lock_free (arg);
if (size == integer_one_node)
return const1_rtx;
return const0_rtx;
}
! /* Return a one or zero if it can be determined that size ARG is lock free on
!this architecture. */
static tree
! fold_builtin_atomic_is_lock_free (tree arg)
{
! tree always = fold_builtin_atomic_always_lock_free (arg);
/* If it isnt always lock free, don't generate a result. */
if (always == integer_one_node)
--- 5448,5539
return ret;
}
! /* Return true if (optional) argument ARG1 of size ARG0 is always lock free on
!this architecture. If ARG1 is NULL, use typical alignment for size ARG0.
*/
!
static tree
! fold_builtin_atomic_always_lock_free (tree arg0, tree arg1)
{
int size;
enum machine_mode mode;
+ unsigned int mode_align, type_align;
! if (TREE_CODE (arg0) != INTEGER_CST)
return NULL_TREE;
+ size = INTVAL (expand_normal (arg0)) * BITS_PER_UNIT;
+ mode = mode_for_size (size, MODE_INT, 0);
+ mode_align = GET_MODE_ALIGNMENT (mode);
+
+ /* If a pointer is provided, check that alignment matches OK. Otherwise a
+ zero must be provided to indicate normal alignment for an object size.
Re: [cxx-mem-model] use alignment when available to determine lock-free ness
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
Simply adds an optional parameter to __atomic_{is_always}_lock_free
which is used to check alignment against the size parameter. NULL as
the object pointer produces the same behaviour as today, lockfreeness
based on proper alignment for an integral value of the specified size.
Why a pointer to the object? Are you really going to check the real
object alignment in the library __atomic_lock_free?
Seems to me that another integer argument does just as well:
__atomic_is_always_lock_free (sizeof(T), __alignof(T))
r~
Re: [PATCH] Fix errors in expand_atomic_store.
On 11/02/2011 07:18 AM, Andrew MacLeod wrote: OK, I think i need to revert my position and introduce __atomic_test_and_set() and __atomic_clear(). bah. I'll work on that today. I don't think you do. We already have the __sync functions, and we should just use those. What we need is a preprocessor flag that tells you that you need to use those older sync routines. r~
Re: [PATCH] Fix errors in expand_atomic_store.
On 11/02/2011 11:25 AM, Richard Henderson wrote: On 11/02/2011 07:18 AM, Andrew MacLeod wrote: OK, I think i need to revert my position and introduce __atomic_test_and_set() and __atomic_clear(). bah. I'll work on that today. I don't think you do. We already have the __sync functions, and we should just use those. actually, that should be sufficinent. What we need is a preprocessor flag that tells you that you need to use those older sync routines. why? its only for the atomic_flag object that those routines are even used, so the C++ or C1x implementation of atomic_flag can just use the existing __sync routines. Since they are defined by the standard as being required to be lock free, I dont need to worry about them in the library which is what I was thinking. I'd just change store and exchange to not try to use those patterns, and then use the sync patterns in implementing atomic_flag. They would be documented as required for that functionality. that should work shouldnt it? Andrew
Re: [PR50878, PATCH] Fix for verify_dominators in -ftree-tail-merge
On 11/01/2011 10:43 AM, Richard Guenther wrote:
On Mon, Oct 31, 2011 at 9:19 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 10/30/2011 10:54 AM, Richard Guenther wrote:
On Sun, Oct 30, 2011 at 9:27 AM, Tom de Vries tom_devr...@mentor.com
wrote:
On 10/30/2011 09:20 AM, Tom de Vries wrote:
Richard,
I have a fix for PR50878.
Sorry, with patch this time.
Ok for now, but see Davids mail and the complexity issue with iteratively
updating dominators.
I'm not sure which mail you mean.
The one I CCed you on, which complained about iterative dominator fixing
taking 70% of the compile-time in some GCC testsuite test.
It seems to me that we know exactly what to update
and how, and we should do that (well, if we need up-to-date dominators,
re-computing them once in the pass would be ok).
Indeed, in this example we know exactly what to update and how. However,
PR50908
popped up, and there that's not the case anymore.
Consider the following cfg, where A is the direct dominator of I:
A
/ \
B \
/ \ \
C D
/| |\
E F
|\ /|
| x |
|/ \|
G H
\ /
I
Say E and F are duplicates, and F is removed. The cfg then looks like
this:
A
/ \
B \
/ \ \
C D
/ \ / \
E
/ \
G H
\ /
I
E is now the new direct dominator of I.
The patch for PR50878 did not address this example, since it uses the set of
bbs
directly dominated by the (single) predecessor of bb1 and bb2.
The new patch calculates the updated dominator info by taking the nearest
common
dominator (A) of bb1 (F) and bb2 (E), and getting the set of bbs immediately
dominated by it. Part of this set is now directly dominated by bb2.
Ideally we would have a means to determine which bbs in the set are now
directly dominated by bb2, and call set_immediate_dominator for those bbs,
but
we don't, so instead we let iterate_fix_dominators figure it out.
Additionally, the patch makes sure it updates dominator info before updating
the
vuses, this fixes a latent bug.
The patch fixes both PR50908 and PR50878.
Bootstrapped and reg-tested on x86_64 and i686, and build and reg-tested on
ARM
and MIPS.
Ok for trunk?
Ok, but please add testcases for all the bugs you fixed. This helps adding
test
coverage for these cases.
Committed attached test-cases.
Thanks,
- Tom
2011-11-01 Tom de Vries t...@codesourcery.com
PR tree-optimization/50908
* gcc.dg/pr50908.c: New test.
* gcc.dg/pr50908-2.c: Same.
* gcc.dg/pr50908-3.c: Same.
Index: gcc/testsuite/gcc.dg/pr50908-2.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/pr50908-2.c (revision 0)
@@ -0,0 +1,80 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -ftree-tail-merge } */
+
+typedef struct rtx_def *rtx;
+enum debug_info_levels
+{
+ ARM_FLOAT_ABI_SOFT, ARM_FLOAT_ABI_SOFTFP, ARM_FLOAT_ABI_HARD
+};
+struct gcc_options
+{
+ int x_target_flags;
+};
+extern struct gcc_options global_options;
+extern int arm_arch_thumb2;
+enum rtx_code
+{
+ UNSPEC, UNSPEC_VOLATILE, ADDR_VEC, SET, CLOBBER, CALL, RETURN,
+SIMPLE_RETURN, EH_RETURN, TRAP_IF, CONST_INT, CONST_FIXED, CONST_DOUBLE,
+CONST_VECTOR, CONST_STRING, CONST, PC, REG, SCRATCH, SUBREG,
+STRICT_LOW_PART, CONCAT, CONCATN, MEM, LABEL_REF, SYMBOL_REF, CC0,
+IF_THEN_ELSE, COMPARE, PLUS, MINUS, NEG, MULT, SS_MULT, US_MULT, DIV,
+SS_DIV, US_DIV, MOD, UDIV, UMOD, AND, IOR, XOR, NOT, ASHIFT, ROTATE,
+ASHIFTRT, LSHIFTRT, ROTATERT, PRE_DEC, PRE_INC, POST_DEC, POST_INC,
+PRE_MODIFY, POST_MODIFY, NE, EQ, GE, GT, LE, LT, GEU, GTU, LEU, LTU,
+UNORDERED, ORDERED, UNEQ, UNGE, UNGT, UNLE, UNLT, LTGT, SIGN_EXTEND,
+ZERO_EXTEND, TRUNCATE, FLOAT_EXTEND, FLOAT_TRUNCATE, FLOAT, FIX,
+UNSIGNED_FLOAT, UNSIGNED_FIX, SIGN_EXTRACT, ZERO_EXTRACT, HIGH, LO_SUM,
+VEC_MERGE, VEC_SELECT, VEC_CONCAT, VEC_DUPLICATE, SS_PLUS, US_PLUS,
+SS_MINUS, SS_NEG, US_NEG, SS_ABS, SS_ASHIFT, US_ASHIFT, US_MINUS,
+SS_TRUNCATE, US_TRUNCATE, FMA, VAR_LOCATION, DEBUG_IMPLICIT_PTR,
+ENTRY_VALUE, DEBUG_PARAMETER_REF, LAST_AND_UNUSED_RTX_CODE
+};
+union rtunion_def
+{
+};
+struct rtx_def
+{
+ enum rtx_code code:16;
+}
+builtin_info_type;
+enum constraint_num
+{
+ CONSTRAINT__UNKNOWN =
+0, CONSTRAINT_f, CONSTRAINT_t, CONSTRAINT_v, CONSTRAINT_w, CONSTRAINT_x,
+CONSTRAINT_y, CONSTRAINT_z, CONSTRAINT_l, CONSTRAINT_h, CONSTRAINT_j,
+CONSTRAINT_Pj, CONSTRAINT_PJ, CONSTRAINT_k, CONSTRAINT_b, CONSTRAINT_c,
+CONSTRAINT_I, CONSTRAINT_J, CONSTRAINT_K, CONSTRAINT_L, CONSTRAINT_M,
+CONSTRAINT_N, CONSTRAINT_O, CONSTRAINT_Pa,
Re: resent2 [PATCH] Fix ICE in redirect_jump, at jump.c:1497 PR50496
On 10/31/11 10:11, Eric Botcazou wrote: I'm suggesting a new patch, as attached. Before reload_completed, we directly return 0 upon nlabel == NULL, which should be identical with old behavior, while asserting fail if after reload (where we assume the simple_return/return distinction is required). This should ensure better that, if a post-prologue case of redirecting to the exit block ever happens we will more easily know (by some future PR :P) Bootstrapped and tested on i686, and cross tested on ARM using QEMU. Eric, is this approach okay? Don't you want epilogue_completed instead of reload_completed? Otherwise, yes, the approach is fine with me, but wait for Bernd's input. That looks good to me too. Bernd
[PATCH] Fix PR48217
This fixes PR48217, the failure to decode '\\'' from COLLECT_GCC_OPTIONS
in lto-wrapper.
LTO bootstrap regtest running on x86_64-unknown-linux-gnu.
Richard.
2011-11-02 Richard Guenther rguent...@suse.de
PR lto/48217
* lto-wrapper.c (get_options_from_collect_gcc_options): Properly
decode an encoded literal '.
Index: trunk/gcc/lto-wrapper.c
===
*** trunk.orig/gcc/lto-wrapper.c2011-11-02 16:07:20.0 +0100
--- trunk/gcc/lto-wrapper.c 2011-11-02 16:48:15.0 +0100
*** get_options_from_collect_gcc_options (co
*** 300,338
struct cl_decoded_option
**decoded_options,
unsigned int *decoded_options_count)
{
char *argv_storage;
const char **argv;
! int i, j, argc;
- /* Count arguments, account for the program name. */
- argc = 2;
- for (j = 0; collect_gcc_options[j] != '\0'; ++j)
- if (collect_gcc_options[j] == '\'')
- ++argc;
- if (argc % 2 != 0)
- fatal (malformed COLLECT_GCC_OPTIONS);
-
- /* Copy the options to a argv-like array. */
- argc /= 2;
- argv = (const char **) xmalloc ((argc + 2) * sizeof (char *));
- argv[0] = collect_gcc;
argv_storage = xstrdup (collect_gcc_options);
! for (i = 1, j = 0; argv_storage[j] != '\0'; ++j)
{
if (argv_storage[j] == '\'')
{
! argv[i++] = argv_storage[++j];
! while (argv_storage[j] != '\'')
! ++j;
! argv_storage[j] = '\0';
}
}
! argv[i] = NULL;
decode_cmdline_options_to_array (argc, (const char **)argv,
lang_mask,
decoded_options, decoded_options_count);
! free (argv);
}
/* Append OPTION to the options array DECODED_OPTIONS with size
--- 300,347
struct cl_decoded_option
**decoded_options,
unsigned int *decoded_options_count)
{
+ struct obstack argv_obstack;
char *argv_storage;
const char **argv;
! int j, k, argc;
argv_storage = xstrdup (collect_gcc_options);
! obstack_init (argv_obstack);
! obstack_ptr_grow (argv_obstack, collect_gcc);
!
! for (j = 0, k = 0; argv_storage[j] != '\0'; ++j)
{
if (argv_storage[j] == '\'')
{
! obstack_ptr_grow (argv_obstack, argv_storage[k]);
! ++j;
! do
! {
! if (argv_storage[j] == '\0')
! fatal (malformed COLLECT_GCC_OPTIONS);
! else if (strncmp (argv_storage[j], '\\'', 4) == 0)
! {
! argv_storage[k++] = '\'';
! j += 4;
! }
! else if (argv_storage[j] == '\'')
! break;
! else
! argv_storage[k++] = argv_storage[j++];
! }
! while (1);
! argv_storage[k++] = '\0';
}
}
!
! obstack_ptr_grow (argv_obstack, NULL);
! argc = obstack_object_size (argv_obstack) / sizeof (void *) - 1;
! argv = XOBFINISH (argv_obstack, const char **);
decode_cmdline_options_to_array (argc, (const char **)argv,
lang_mask,
decoded_options, decoded_options_count);
! obstack_free (argv_obstack, NULL);
}
/* Append OPTION to the options array DECODED_OPTIONS with size
Re: [cxx-mem-model] use alignment when available to determine lock-free ness
On 11/02/2011 11:22 AM, Richard Henderson wrote:
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
Simply adds an optional parameter to __atomic_{is_always}_lock_free
which is used to check alignment against the size parameter. NULL as
the object pointer produces the same behaviour as today, lockfreeness
based on proper alignment for an integral value of the specified size.
Why a pointer to the object? Are you really going to check the real
object alignment in the library __atomic_lock_free?
Seems to me that another integer argument does just as well:
__atomic_is_always_lock_free (sizeof(T), __alignof(T))
Well that could be an option. I'm just thinking about how the C1x call
works. its 'is_lock_free (object *)' (which is more or less what
c++ is as well.)
The standards are very specific that it is individual object specific,
and that objects of the same size may not share the lock free property.
I was thinking of when someone uses a slice of memory that is say 4
bytes. 1 in 4 of those are aligned properly at runtime :-) The library
can simply check the address passed into it an say, yeah, thats aligned,
use the lock-free routine.
Im guessing thats their intent, it seems reasonable...
if you are passing a second value in, alignof(T) is more limiting than
an actual object pointer, so I figure just let the library decide what
to do with it..
Andrew
Re: [PATCH] Fix errors in expand_atomic_store.
On 11/02/2011 08:44 AM, Andrew MacLeod wrote: that should work shouldnt it? Yes, so long as the atomic_flag object only wants one memory model. Which I suppose it does for implementing a mutex. r~
Re: New port: Renesas RL78
On Wed, 2 Nov 2011, DJ Delorie wrote: - unsigned int __max_iter = 100; + unsigned int __max_iter = 65536U; Doesn't that need to be 65535U for your purpose? Index: libgcc/config/rl78/lib2shift.c === --- libgcc/config/rl78/lib2shift.c(revision 0) +++ libgcc/config/rl78/lib2shift.c(revision 0) @@ -0,0 +1,103 @@ +/* Shift functions for the GCC support library for the Renesas RL78 processors. + Copyright (C) 2011 Free Software Foundation, Inc. + Contributed by Red Hat. + + This file is part of GCC. + + GCC is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3, or (at your option) + any later version. + + GCC is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GCC; see the file COPYING3. If not see + http://www.gnu.org/licenses/. */ Should have the runtime license exception. +FPBIT = fp-bit.c +$(gcc_objdir)/fp-bit.c: $(gcc_srcdir)/config/fp-bit.c + echo '#define FLOAT' $@ + cat $(gcc_srcdir)/config/fp-bit.c$@ + +DPBIT = dp-bit.c +$(gcc_objdir)/dp-bit.c: $(gcc_srcdir)/config/fp-bit.c + cat $(gcc_srcdir)/config/fp-bit.c$@ This should not be needed; just using t-fdpbit should suffice for almost all targets. \ No newline at end of file As already noted, avoid this. +static int register_sizes[] = const? There are a lot of functions and variables without comments explaining them and their parameters. (If a function just implements a standard hook, a comment identifying which hook suffices without needing to explain the parameters of that hook again.) + if (letter == 'q' || letter == 'Q') + error (q/Q modifiers invalid for symbol referencs); referencs should be reference or references or similar. I think this should call output_operand_lossage not error, so that it becomes an error or an ICE as appropriate depending on whether the source of the error is the machine description or an asm. + if (letter == 'q' || letter == 'Q') + error (q/Q modifiers invalid for symbol referencs); Likewise. I don't see updates to md.texi, contrib.texi or contrib/config-list.mk. (As regards the last, you should also check that the back end does build cleanly starting from a current native trunk compiler used to build a cross compiler configured with --enable-werror-always, on both 32-bit and 64-bit hosts if possible. contrib/config-list.mk is used for automatic checks of that sort of thing across all targets.) I think the target-independent changes outside the back end (the ones that are meant as separate bug fixes required by the port) should be posted in separate messages, each with its own rationale. The web site changes listed in sourcebuild.texi, Back End, will also be needed. -- Joseph S. Myers jos...@codesourcery.com
Re: New port: Renesas RL78
On Wed, 2 Nov 2011, DJ Delorie wrote: Index: configure.ac +# Dereferencing -1 is a compile-time error This (those lines) look a little cryptic (and lack punctuation ;) Wild improvement guess: Too small 'int'?. No, the compiler specifically tests for unaligned accesses and gives a compile-time error, at Renesas's requrest. The chip can't do unaligned accesses correctly, but it doesn't fault - it just silently accesses the wrong memory. So the compiler errors instead. That's not permitted by standard C for code that might not be executed. The standard GCC practice if you can determine at compile time that a given path will result in undefined behavior at runtime but don't want to deduce that this path is unreachable is to generate an abort and output an informative notice with inform (). This is done when float is passed to va_arg, for example, or for calling a function through a function pointer cast to an incompatible type. (I don't see what actually generates the error, since there are only two calls to error () in the port, both of which I've commented on separately.) -- Joseph S. Myers jos...@codesourcery.com
Re: [cxx-mem-model] use alignment when available to determine lock-free ness
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
gcc
* builtins.c (fold_builtin_atomic_always_lock_free): Add object param
and check alignment if present.
(expand_builtin_atomic_always_lock_free): Expect 2nd argument.
(fold_builtin_atomic_is_lock_free): Expect 2nd argument.
(expand_builtin_atomic_is_lock_free): Expect 2nd argument.
(fold_builtin_1): Remove LOCK_FREE builtins.
(fold_builtin_2): Add LOCK_FREE builtins.
* sync-builtins.def (BUILT_IN_ATOMIC_{IS,ALWAYS}_LOCK_FREE): Add param.
* builtin-types.def (BT_FN_BOOL_SIZE): Remove.
(BT_FN_BOOL_SIZE_CONST_VPTR): Add.
fortran
* types.def (BT_FN_BOOL_SIZE): Remove.
(BT_FN_BOOL_SIZE_CONST_VPTR): Add.
libstdc++-v3
* include/std/atomic (is_lock_free): Add object pointer to
__atomic_is_lock_free.
* include/bits/atomic_base.h (LOCKFREE_PROP): Add 0 for object ptr.
(is_lock_free): Add object pointer to __atomic_is_lock_free.
testsuite
* gcc.dg/atomic-lockfree-aux.c: Add extra lock-free parameter.
* gcc.dg/atomic-invalid.c: Add extra lock-free parameter.
* gcc.dg/atomic-lockfree.c: Add extra lock-free parameter.
Ok.
r~
Re: [cxx-mem-model] use alignment when available to determine lock-free ness
On 11/02/2011 12:28 PM, Richard Henderson wrote: On 11/02/2011 07:59 AM, Andrew MacLeod wrote: + /* Parameters at this point are usually cast to void *, so check for that +and look past the cast. */ + if (TREE_CODE (arg1) == NOP_EXPR POINTER_TYPE_P (ttype) + VOID_TYPE_P (TREE_TYPE (ttype))) + arg1 = TREE_OPERAND (arg1, 0); + + ttype = TREE_TYPE (arg1); + gcc_assert (POINTER_TYPE_P (ttype)); + + /* Get the underlying type of the object. */ + ttype = TREE_TYPE (ttype); + type_align = TYPE_ALIGN (ttype); I take that back. Does this really work? It certainly doesn't seem like it would work in SSA mode. You'd need to look back to the def. it did in my simply trials as I figured this out in the debugger :-) i only did basic tests. OK, Is there a simple way to get to the def? what happens to the alignment of something if its say 'char *' type and its cast to an (int *) oir something with more strict alignment... or will the compiler complain about that? Andrew
Re: [PR50672, PATCH] Fix ice triggered by -ftree-tail-merge: verify_ssa failed: no immediate_use list
On 10/18/2011 11:06 AM, Tom de Vries wrote:
On 10/17/2011 01:51 PM, Richard Guenther wrote:
On Sun, Oct 16, 2011 at 12:05 PM, Tom de Vries tom_devr...@mentor.com
wrote:
On 10/14/2011 12:00 PM, Richard Guenther wrote:
On Fri, Oct 14, 2011 at 1:12 AM, Tom de Vries tom_devr...@mentor.com
wrote:
On 10/12/2011 02:19 PM, Richard Guenther wrote:
On Wed, Oct 12, 2011 at 8:35 AM, Tom de Vries vr...@codesourcery.com
wrote:
Richard,
I have a patch for PR50672.
When compiling the testcase from the PR with -ftree-tail-merge, the
scenario is
as follows:
We start out tail_merge_optimize with blocks 14 and 20, which are
alike, but not
equal, since they have different successors:
...
# BLOCK 14 freq:690
# PRED: 25 [61.0%] (false,exec)
if (wD.2197_57(D) != 0B)
goto bb 15;
else
goto bb 16;
# SUCC: 15 [78.4%] (true,exec) 16 [21.6%] (false,exec)
# BLOCK 20 freq:2900
# PRED: 29 [100.0%] (fallthru) 31 [100.0%] (fallthru)
# .MEMD.2447_209 = PHI .MEMD.2447_125(29), .MEMD.2447_129(31)
if (wD.2197_57(D) != 0B)
goto bb 5;
else
goto bb 6;
# SUCC: 5 [85.0%] (true,exec) 6 [15.0%] (false,exec)
...
In the first iteration, we merge block 5 with block 15 and block 6 with
block
16. After that, the blocks 14 and 20 are equal.
In the second iteration, the blocks 14 and 20 are merged, by
redirecting the
incoming edges of block 20 to block 14, and removing block 20.
Block 20 also contains the definition of .MEMD.2447_209. Removing the
definition
delinks the vuse of .MEMD.2447_209 in block 5:
...
# BLOCK 5 freq:6036
# PRED: 20 [85.0%] (true,exec)
# PT = nonlocal escaped
D.2306_58 = thisD.2200_10(D)-D.2156;
# .MEMD.2447_132 = VDEF .MEMD.2447_209
# USE = anything
# CLB = anything
drawLineD.2135 (D.2306_58, wD.2197_57(D), gcD.2198_59(D));
goto bb 17;
# SUCC: 17 [100.0%] (fallthru,exec)
...
And block 5 is retained and block 15 is discarded?
Indeed.
After the pass, when executing the TODO_update_ssa_only_virtuals, we
update the
drawLine call in block 5 using rewrite_update_stmt, which calls
maybe_replace_use for the vuse operand.
However, maybe_replace_use doesn't have an effect since the old vuse
and the new
vuse happen to be the same (rdef == use), so SET_USE is not called and
the vuse
remains delinked:
...
if (rdef rdef != use)
SET_USE (use_p, rdef);
...
The patch fixes this by forcing SET_USE for delinked uses.
That isn't the correct fix. Whoever unlinks the vuse (by removing its
definition) has to replace it with something valid, which is either the
bare symbol .MEM, or the VUSE associated with the removed VDEF
(thus, as unlink_stmt_vdef does).
Another try. For each deleted bb, we call unlink_stmt_vdef for the
statements,
and replace the .MEM phi uses with the bare .MEM symbol.
Bootstrapped and reg-tested on x86_64.
Ok for trunk?
Better. For
+
+ FOR_EACH_IMM_USE_STMT (use_stmt, iter, res)
+ {
+ FOR_EACH_IMM_USE_ON_STMT (use_p, iter)
+ SET_USE (use_p, SSA_NAME_VAR (res));
+ }
you can use mark_virtual_phi_result_for_renaming (phi) instead.
+ for (i = gsi_last_bb (bb); !gsi_end_p (i); gsi_prev_nondebug (i))
+unlink_stmt_vdef (gsi_stmt (i));
is that actually necessary? That is, isn't the block that follows a
deleted block always starting with a virtual PHI?
Block 20 is deleted. Block 5 follows the deleted block 20. Block 5 does not
start with a virtual PHI.
If not it should
be enough to walk to the first stmt that uses a virtual operand
and similar to the PHI case replace all its uses with the bare
symbol.
I think we need to handle the exposed uses (meaning outside the block) of
vdefs
in each deleted block. The only vdef that can have exposed uses is the last
vdef
in the block. So we should find the last vdef (gimple with gimple_vdef or
virtual PHI) and handle the related uses.
Bootstrapped and regtested on x86_64. OK for trunk?
Hmmm. I can see that this will fail when the block has a store
but not a virtual PHI node, thus, when renaming does not reach
a bare .MEM symbol walking the use-def chain from the VUSE
of the store. What release_last_vdef should do is trigger a rename
of subsequent VUSEs in successors of the deleted block. Which
requires you to do something like
static void
rename_last_vdef (basic_block bb)
{
+ gimple_stmt_iterator i;
+
+ for (i = gsi_last_bb (bb); !gsi_end_p (i); gsi_prev_nondebug (i))
+{
+ gimple stmt = gsi_stmt (i);
+ if (gimple_vdef (stmt) == NULL_TREE)
+ continue;
+
+ mark_virtual_operand_for_renaming (gimple_vdef (stmt));
return;
}
+ for (i = gsi_start_phis (bb); !gsi_end_p (i); gsi_next (i))
+{
+ gimple phi = gsi_stmt (i);
+ tree res = gimple_phi_result (phi);
+
+ if (is_gimple_reg (res))
+ continue;
+
+ mark_virtual_phi_result_for_renaming (phi);
+ return;
+}
}
[trans-mem] merge from trunk @ 180744
Nothing major to report. There seems to be some top-level makefile problem passing _GLIBCXX_USE_INT128 down to libstdc++-v3 for the -m32 multilib. Richard is looking at this. Otherwise, everything working as before. I will now generate a patchset by subsystem for everyone's perusal.
Re: [google] Enable loop unroll/peel notes under -fopt-info
On Tue, Nov 1, 2011 at 2:53 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Nov 1, 2011 at 1:46 AM, Teresa Johnson tejohn...@google.com wrote:
This patch is for google-main only.
Tested with bootstrap and regression tests.
Print unroll and peel factors along with loop source position under
-fopt-info.
Teresa
2011-10-31 Teresa Johnson tejohn...@google.com
* common.opt (fopt-info): Disable -fopt-info by default.
* loop-unroll.c (report_unroll_peel): New function.
(unroll_and_peel_loops): Call record_loop_exits for later use.
(peel_loops_completely): Print the loop source position in dump
info and emit note under -fopt-info.
(decide_unroll_and_peeling): Ditto.
(decide_peel_once_rolling): Record peel factor for use in note
emission.
(decide_peel_completely): Ditto.
* cfgloop.c (get_loop_location): New function.
* cfgloop.h (get_loop_location): Ditto.
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Emit note
under -fopt-info.
Index: tree-ssa-loop-ivcanon.c
===
--- tree-ssa-loop-ivcanon.c (revision 180437)
+++ tree-ssa-loop-ivcanon.c (working copy)
@@ -52,6 +52,7 @@
#include flags.h
#include tree-inline.h
#include target.h
+#include diagnostic.h
/* Specifies types of loops that may be unrolled. */
@@ -443,6 +444,17 @@
fprintf (dump_file, Unrolled loop %d completely by factor %d.\n,
loop-num, (int) n_unroll);
+ if (flag_opt_info = OPT_INFO_MIN)
+ {
+ location_t locus;
+ locus = gimple_location (cond);
+
+ inform (locus, Completely Unroll loop by %d (execution count
%d, const iterations %d),
+ (int) n_unroll,
+ (int) loop-header-count,
+ (int) TREE_INT_CST_LOW(niter));
+ }
+
And this is exactly what I mean with code-duplication.
Yes, we agree with you and we will improve it after this.
Two lines above
we already have Unroled loop %d completely by factor %d, not only
do you duplicate some diagnostic printing about this fact, you
put in useless info (complete unroll by N of a loop executing M (?! that's
surely N as well) times,
M!=N. M is used to indicate how hot the loop is.
David
const iterations O (?! that's surely N as well ...).
Richard.
Re: [cxx-mem-model] use alignment when available to determine lock-free ness
On 11/02/2011 09:30 AM, Andrew MacLeod wrote: it did in my simply trials as I figured this out in the debugger :-) i only did basic tests. OK, Is there a simple way to get to the def? You should know. You wrote most of that stuff. what happens to the alignment of something if its say 'char *' type and its cast to an (int *) oir something with more strict alignment... or will the compiler complain about that? The compiler certainly won't complain. I guess the absolute best thing is to look at the ptr_info_def of the SSA name. In theory this will have been solved for you. r~
Re: New port: Renesas RL78
DJ Delorie d...@redhat.com writes: Index: libgcc/config.host === --- libgcc/config.host(revision 180758) +++ libgcc/config.host(working copy) @@ -683,12 +683,16 @@ rs6000-ibm-aix5.1.* | powerpc-ibm-aix5.1 tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-ibm-ldouble ;; rs6000-ibm-aix[56789].* | powerpc-ibm-aix[56789].*) md_unwind_header=rs6000/aix-unwind.h tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-ibm-ldouble ;; +rl78-*-elf) + extra_parts=crtbegin.o crtend.o This is unnecessary with my just applied series of libgcc patches: it's the default for all *-*-elf targets. Index: libgcc/config/rl78/t-rl78 [...] +FPBIT = fp-bit.c +$(gcc_objdir)/fp-bit.c: $(gcc_srcdir)/config/fp-bit.c + echo '#define FLOAT' $@ + cat $(gcc_srcdir)/config/fp-bit.c$@ + +DPBIT = dp-bit.c +$(gcc_objdir)/dp-bit.c: $(gcc_srcdir)/config/fp-bit.c + cat $(gcc_srcdir)/config/fp-bit.c$@ This is not only unnecessary, as Joseph already noted, but doesn't work for quite some time since fp-bit.c has been moved to libgcc. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [google] Enable loop unroll/peel notes under -fopt-info
Ok for google/main.
1) may be better to omit the const iteration count for complete unroll message
2) Instead of dumping loop header count, is it better to dump
pre-header count -- it gives an idea of how often the loop is entered.
The loop header count can be derived from loop average iteration and
preheader count.
thanks,
David
On Mon, Oct 31, 2011 at 5:46 PM, Teresa Johnson tejohn...@google.com wrote:
This patch is for google-main only.
Tested with bootstrap and regression tests.
Print unroll and peel factors along with loop source position under
-fopt-info.
Teresa
2011-10-31 Teresa Johnson tejohn...@google.com
* common.opt (fopt-info): Disable -fopt-info by default.
* loop-unroll.c (report_unroll_peel): New function.
(unroll_and_peel_loops): Call record_loop_exits for later use.
(peel_loops_completely): Print the loop source position in dump
info and emit note under -fopt-info.
(decide_unroll_and_peeling): Ditto.
(decide_peel_once_rolling): Record peel factor for use in note
emission.
(decide_peel_completely): Ditto.
* cfgloop.c (get_loop_location): New function.
* cfgloop.h (get_loop_location): Ditto.
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Emit note
under -fopt-info.
Index: tree-ssa-loop-ivcanon.c
===
--- tree-ssa-loop-ivcanon.c (revision 180437)
+++ tree-ssa-loop-ivcanon.c (working copy)
@@ -52,6 +52,7 @@
#include flags.h
#include tree-inline.h
#include target.h
+#include diagnostic.h
/* Specifies types of loops that may be unrolled. */
@@ -443,6 +444,17 @@
fprintf (dump_file, Unrolled loop %d completely by factor %d.\n,
loop-num, (int) n_unroll);
+ if (flag_opt_info = OPT_INFO_MIN)
+ {
+ location_t locus;
+ locus = gimple_location (cond);
+
+ inform (locus, Completely Unroll loop by %d (execution count
%d, const iterations %d),
+ (int) n_unroll,
+ (int) loop-header-count,
+ (int) TREE_INT_CST_LOW(niter));
+ }
+
return true;
}
Index: loop-unroll.c
===
--- loop-unroll.c (revision 180437)
+++ loop-unroll.c (working copy)
@@ -34,6 +34,7 @@
#include hashtab.h
#include recog.h
#include target.h
+#include diagnostic.h
/* This pass performs loop unrolling and peeling. We only perform these
optimizations on innermost loops (with single exception) because
@@ -152,6 +153,30 @@
basic_block);
static rtx get_expansion (struct var_to_expand *);
+static void
+report_unroll_peel(struct loop *loop, location_t locus)
+{
+ struct niter_desc *desc;
+ int niters = 0;
+
+ desc = get_simple_loop_desc (loop);
+
+ if (desc-const_iter)
+ niters = desc-niter;
+ else if (loop-header-count)
+ niters = expected_loop_iterations (loop);
+
+ inform (locus, %s%s loop by %d (execution count %d, %s iterations %d),
+ loop-lpt_decision.decision == LPT_PEEL_COMPLETELY ?
+ Completely : ,
+ loop-lpt_decision.decision == LPT_PEEL_SIMPLE ?
+ Peel : Unroll,
+ loop-lpt_decision.times,
+ (int)loop-header-count,
+ desc-const_iter?const:average,
+ niters);
+}
+
/* Unroll and/or peel (depending on FLAGS) LOOPS. */
void
unroll_and_peel_loops (int flags)
@@ -160,6 +185,8 @@
bool check;
loop_iterator li;
+ record_loop_exits();
+
/* First perform complete loop peeling (it is almost surely a win,
and affects parameters for further decision a lot). */
peel_loops_completely (flags);
@@ -234,16 +261,18 @@
{
struct loop *loop;
loop_iterator li;
+ location_t locus;
/* Scan the loops, the inner ones first. */
FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
{
loop-lpt_decision.decision = LPT_NONE;
+ locus = get_loop_location(loop);
if (dump_file)
- fprintf (dump_file,
- \n;; *** Considering loop %d for complete peeling ***\n,
- loop-num);
+ fprintf (dump_file, \n;; *** Considering loop %d for complete
peeling at BB %d from %s:%d ***\n,
+ loop-num, loop-header-index, LOCATION_FILE(locus),
+ LOCATION_LINE(locus));
loop-ninsns = num_loop_insns (loop);
@@ -253,6 +282,11 @@
if (loop-lpt_decision.decision == LPT_PEEL_COMPLETELY)
{
+ if (flag_opt_info = OPT_INFO_MIN)
+ {
+ report_unroll_peel(loop, locus);
+ }
+
peel_loop_completely (loop);
#ifdef ENABLE_CHECKING
verify_dominators (CDI_DOMINATORS);
@@ -268,14 +302,18 @@
{
struct loop *loop;
loop_iterator li;
+ location_t locus;
/* Scan the loops, inner ones first. */
Re: [cxx-mem-model] use alignment when available to determine lock-free ness
On 11/02/2011 12:37 PM, Richard Henderson wrote: On 11/02/2011 09:30 AM, Andrew MacLeod wrote: it did in my simply trials as I figured this out in the debugger :-) i only did basic tests. OK, Is there a simple way to get to the def? You should know. You wrote most of that stuff. HA. years ago. I have a 6 month term memory. Now I have to go look it up :-) Andrew
Re: -fdump-go-spec option does not handle redefinitions
Uros Bizjak ubiz...@gmail.com writes:
#defines with arguments are not working at all. Please consider
following testcase:
You're right: this approach doesn't work for preprocessor macros with
arguments. Making those work via this approach would be much much
harder.
Please note missing struct terminfos define, so I understand that
TC[GS]ETS is unknown, but FIOCLEX should be fully defined by
preceeding definitions.
Fortunately, the value of FIOCLEX is irrelevant. And as you say, this
approach can't work for TCGETS anyhow.
So let's take a different approach. This patch drops the use of TCGETS
and TCSETS entirely. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 39e671bf216d libgo/go/exp/terminal/terminal.go
--- a/libgo/go/exp/terminal/terminal.go Wed Nov 02 08:58:28 2011 -0700
+++ b/libgo/go/exp/terminal/terminal.go Wed Nov 02 09:42:23 2011 -0700
@@ -17,7 +17,6 @@
import (
os
syscall
- unsafe
)
// State contains the state of a terminal.
@@ -28,7 +27,7 @@
// IsTerminal returns true if the given file descriptor is a terminal.
func IsTerminal(fd int) bool {
var termios syscall.Termios
- _, _, e := syscall.Syscall6(syscall.SYS_IOCTL, uintptr(fd), uintptr(syscall.TCGETS), uintptr(unsafe.Pointer(termios)), 0, 0, 0)
+ e := syscall.Tcgetattr(fd, termios)
return e == 0
}
@@ -37,14 +36,14 @@
// restored.
func MakeRaw(fd int) (*State, os.Error) {
var oldState State
- if _, _, e := syscall.Syscall6(syscall.SYS_IOCTL, uintptr(fd), uintptr(syscall.TCGETS), uintptr(unsafe.Pointer(oldState.termios)), 0, 0, 0); e != 0 {
+ if e := syscall.Tcgetattr(fd, oldState.termios); e != 0 {
return nil, os.Errno(e)
}
newState := oldState.termios
newState.Iflag ^= syscall.ISTRIP | syscall.INLCR | syscall.ICRNL | syscall.IGNCR | syscall.IXON | syscall.IXOFF
newState.Lflag ^= syscall.ECHO | syscall.ICANON | syscall.ISIG
- if _, _, e := syscall.Syscall6(syscall.SYS_IOCTL, uintptr(fd), uintptr(syscall.TCSETS), uintptr(unsafe.Pointer(newState)), 0, 0, 0); e != 0 {
+ if e := syscall.Tcsetattr(fd, syscall.TCSANOW, newState); e != 0 {
return nil, os.Errno(e)
}
@@ -54,7 +53,7 @@
// Restore restores the terminal connected to the given file descriptor to a
// previous state.
func Restore(fd int, state *State) os.Error {
- _, _, e := syscall.Syscall6(syscall.SYS_IOCTL, uintptr(fd), uintptr(syscall.TCSETS), uintptr(unsafe.Pointer(state.termios)), 0, 0, 0)
+ e := syscall.Tcsetattr(fd, syscall.TCSANOW, state.termios)
return os.Errno(e)
}
@@ -63,18 +62,18 @@
// returned does not include the \n.
func ReadPassword(fd int) ([]byte, os.Error) {
var oldState syscall.Termios
- if _, _, e := syscall.Syscall6(syscall.SYS_IOCTL, uintptr(fd), uintptr(syscall.TCGETS), uintptr(unsafe.Pointer(oldState)), 0, 0, 0); e != 0 {
+ if e := syscall.Tcgetattr(fd, oldState); e != 0 {
return nil, os.Errno(e)
}
newState := oldState
newState.Lflag ^= syscall.ECHO
- if _, _, e := syscall.Syscall6(syscall.SYS_IOCTL, uintptr(fd), uintptr(syscall.TCSETS), uintptr(unsafe.Pointer(newState)), 0, 0, 0); e != 0 {
+ if e := syscall.Tcsetattr(fd, syscall.TCSANOW, newState); e != 0 {
return nil, os.Errno(e)
}
defer func() {
- syscall.Syscall6(syscall.SYS_IOCTL, uintptr(fd), uintptr(syscall.TCSETS), uintptr(unsafe.Pointer(oldState)), 0, 0, 0)
+ syscall.Tcsetattr(fd, syscall.TCSANOW, oldState)
}()
var buf [16]byte
diff -r 39e671bf216d libgo/go/syscall/libcall_posix.go
--- a/libgo/go/syscall/libcall_posix.go Wed Nov 02 08:58:28 2011 -0700
+++ b/libgo/go/syscall/libcall_posix.go Wed Nov 02 09:42:23 2011 -0700
@@ -377,3 +377,9 @@
tv.Usec = Timeval_usec_t(nsec % 1e9 / 1e3)
return
}
+
+//sysnb Tcgetattr(fd int, p *Termios) (errno int)
+//tcgetattr(fd int, p *Termios) int
+
+//sys Tcsetattr(fd int, actions int, p *Termios) (errno int)
+//tcsetattr(fd int, actions int, p *Termios) int
Re: Go patch committed: Update Go library
Ian Lance Taylor i...@google.com writes: This patch updates the Go library to the most recent weekly release. I think the only potential portability issues here are the use of the ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is portable, but it might be. All go and libgo execution tests are failing for me with this patch on x86_64-unknown-linux-gnu (CentOS 5.5, I think): output is: /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `inotify_init1' /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `fallocate' /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `sync_file_range' collect2: error: ld returned 1 exit status FAIL: go.go-torture/execute/array-1.go compilation, -O0 Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
RE: AVX generic mode tuning discussion.
We would like to propose changing AVX generic mode tuning to generate 128-bit AVX instead of 256-bit AVX. You indicate a 3% reduction on bulldozer with avx256. How does avx128 compare to -mno-avx -msse4.2? We see these % differences going from SSE42 to AVX128 to AVX256 on Bulldozer with -mtune=generic -Ofast. (Positive is improvement, negative is degradation) Bulldozer: AVX128/SSE42 AVX256/AVX-128 410.bwaves -1.4% -1.4% 416.gamess -1.1% 0.0% 433.milc 0.5% -2.4% 434.zeusmp 9.7% -2.1% 435.gromacs 5.1% 0.5% 436.cactusADM 8.2% -23.8% 437.leslie3d 8.1% 0.4% 444.namd 3.6% 0.0% 447.dealII -1.4% -0.4% 450.soplex -0.4% -0.4% 453.povray 0.0% -1.5% 454.calculix 15.7% -8.3% 459.GemsFDTD 4.9% 1.4% 465.tonto 1.3% -0.6% 470.lbm 0.9% 0.3% 481.wrf 7.3% -3.6% 482.sphinx3 5.0% -9.8% SPECFP 3.8% -3.2% Will the next AMD generation have a useable avx256? I'm not keen on the idea of generic mode being tune for a single processor revision that maybe shouldn't actually be using avx at all. We see a substantial gain in several SPECFP benchmarks going from SSE42 to AVX128 on Bulldozer. IMHO, accomplishing even a 5% gain in an individual benchmark takes a hardware company several man months. The loss with AVX256 for Bulldozer is much more significant than the gain for SandyBridge. While the general trend in the industry is a move toward AVX256, for now we would be disadvantaging Bulldozer with this choice. We have several customers who use -mtune=generic and it is default, unless a user explicitly overrides it with -mtune=native. They are the ones who want to experiment with latest ISA using gcc, but want to keep their ISA selection and tuning agnostic on x86/64. IMHO, it is with these customers in mind that generic was introduced in the first place. Since stage 1 closure is around the corner, just wanted to ping to see if the maintainers have made up their mind on this one. AVX-128 is an improvement over SSE42 for Bulldozer and AVX-256 wipes out pretty much all of that gain in generic mode. Until there is a convergence on AVX-256 for x86/64, we would like to propose having generic generate avx-128 by default and have a user override to avx-256 manually when known to benefit performance. Did somebody spend the time analyzing why CactusADM shows so much of a difference? With the recent improvements in vectorizing for AVX, did you re-do the measurements with a recent trunk? I don't think disabling avx-256 by default is a good idea until we understand why these numbers happen and are convinced we cannot fix this by proper cost modeling. We have observed cases where AVX-256 bit code is slower than AVX-128 bit code on Bulldozer. This is because internally the front end, data paths etc for Bulldozer are designed for optimal AVX 128-bit. Throwing densely packed 256-bit code at the pipeline can congest the front end causing stalls and hence slowdowns. We expect the behavior of cactus, calculix and sphinx, which are the 3 benchmarks with the biggest avx-256 gaps, to be in the same vein. In general, the hardware design engineers recommend running AVX 128-bit code on Bulldozer. Given the underlying hardware design, software tuning can't really change the results here. Any further analysis of cactus would be a cycle sink at our end and we may not even be able to discuss the details on a public mailing list. x86/64 has not yet converged on avx-256 and generic mode should reflect that. Posting the re-measurements on trunk for cactus, calculix and sphinx on Bulldozer: AVX128/SSE42AVX256/AVX-128 436.cactusADM 10% -30% 454.calculix14.7% -6% 482.sphinx3 7% -9% All positive % above are improvements, all negative % are degradations. I will post re-measurements for all of Spec with latest trunk as soon as I have them. Thoughts? Thanks, Harsha
Re: building binutils from same directory as gcc
On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote: On 11/01/2011 04:51 PM, Mike Stump wrote: On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote: On 10/30/2011 01:51 PM, Gerald Pfeifer wrote: Why not just declare that building from the same directory is not support and have one simple set of instructions that always works, as opposed to this ought to work with snapshots but not with direct checkouts? That's right. Is there ever any advantage to building in-srcdir? Yes. You can do configure make make install. Huh? Ah, yes, yet another advantage, one can also do: ./configure make make install :-) I do realize that you may not choose to value the feature, but that doesn't mean that everyone has the same valuation you have.
Re: building binutils from same directory as gcc
On 11/02/2011 05:11 PM, Mike Stump wrote: On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote: On 11/01/2011 04:51 PM, Mike Stump wrote: On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote: On 10/30/2011 01:51 PM, Gerald Pfeifer wrote: Why not just declare that building from the same directory is not support and have one simple set of instructions that always works, as opposed to this ought to work with snapshots but not with direct checkouts? That's right. Is there ever any advantage to building in-srcdir? Yes. You can do configure make make install. Huh? Ah, yes, yet another advantage, one can also do: ./configure make make install Of course. That's what building in-srcdir means. :-) I do realize that you may not choose to value the feature, but that doesn't mean that everyone has the same valuation you have. Sure, but that doesn't answer the question, which was is there ever any advantage to building in-srcdir? The answer Yes: one can build in srcdir doesn't quite do it! Andrew.
[C++ Patch] PR 50956
Hi,
this should restore -Wcast-qual to the 3.4.x (!) behavior, more or less.
The diff seems large but the new code is essentially in the last 5
lines. When fixing this issue the most subtle existing testcase to get
right, IMHO, is c-c++-common/Wcast-qual-1.c. Duplicate warnings should
not be an issue because, in input, the valid_p parameter of
build_const_cast_1 essentially plays the role of c_cast_p afterwards and
all the following check_for_casting_away_constness calls are protected
by !c_cast_p.
Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/
/cp
2011-11-02 Paolo Carlini paolo.carl...@oracle.com
PR c++/50956
* typeck.c (build_const_cast_1): Fix -Wcast-qual for false
comp_ptr_ttypes_const.
/testsuite
2011-11-02 Paolo Carlini paolo.carl...@oracle.com
PR c++/50956
* g++.dg/warn/Wcast-qual2.C: New.
Index: testsuite/g++.dg/warn/Wcast-qual2.C
===
--- testsuite/g++.dg/warn/Wcast-qual2.C (revision 0)
+++ testsuite/g++.dg/warn/Wcast-qual2.C (revision 0)
@@ -0,0 +1,4 @@
+// PR c++/50956
+// { dg-options -Wcast-qual }
+
+void* p = (void*)txt; // { dg-warning cast }
Index: cp/typeck.c
===
--- cp/typeck.c (revision 180778)
+++ cp/typeck.c (working copy)
@@ -6345,34 +6345,41 @@ build_const_cast_1 (tree dst_type, tree expr, tsub
return error_mark_node;
}
- if ((TYPE_PTR_P (src_type) || TYPE_PTRMEM_P (src_type))
- comp_ptr_ttypes_const (dst_type, src_type))
+ if (TYPE_PTR_P (src_type) || TYPE_PTRMEM_P (src_type))
{
- if (valid_p)
+ if (comp_ptr_ttypes_const (dst_type, src_type))
{
- *valid_p = true;
- /* This cast is actually a C-style cast. Issue a warning if
-the user is making a potentially unsafe cast. */
- check_for_casting_away_constness (src_type, dst_type, CAST_EXPR,
- complain);
+ if (valid_p)
+ {
+ *valid_p = true;
+ /* This cast is actually a C-style cast. Issue a warning if
+the user is making a potentially unsafe cast. */
+ check_for_casting_away_constness (src_type, dst_type,
+ CAST_EXPR, complain);
+ }
+ if (reference_type)
+ {
+ expr = cp_build_addr_expr (expr, complain);
+ expr = build_nop (reference_type, expr);
+ return convert_from_reference (expr);
+ }
+ else
+ {
+ expr = decay_conversion (expr);
+ /* build_c_cast puts on a NOP_EXPR to make the result not an
+lvalue. Strip such NOP_EXPRs if VALUE is being used in
+non-lvalue context. */
+ if (TREE_CODE (expr) == NOP_EXPR
+ TREE_TYPE (expr) == TREE_TYPE (TREE_OPERAND (expr, 0)))
+ expr = TREE_OPERAND (expr, 0);
+ return build_nop (dst_type, expr);
+ }
}
- if (reference_type)
- {
- expr = cp_build_addr_expr (expr, complain);
- expr = build_nop (reference_type, expr);
- return convert_from_reference (expr);
- }
- else
- {
- expr = decay_conversion (expr);
- /* build_c_cast puts on a NOP_EXPR to make the result not an
-lvalue. Strip such NOP_EXPRs if VALUE is being used in
-non-lvalue context. */
- if (TREE_CODE (expr) == NOP_EXPR
- TREE_TYPE (expr) == TREE_TYPE (TREE_OPERAND (expr, 0)))
- expr = TREE_OPERAND (expr, 0);
- return build_nop (dst_type, expr);
- }
+ else if (valid_p
+ !at_least_as_qualified_p (TREE_TYPE (dst_type),
+ TREE_TYPE (src_type)))
+ check_for_casting_away_constness (src_type, dst_type, CAST_EXPR,
+ complain);
}
if (complain tf_error)
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner berg...@vnet.ibm.com wrote:
+/* Fills in the label name that should be used for a 476 link stack thunk.
*/
+
+void
+get_ppc476_thunk_name (char name[32])
+{
+ gcc_assert (TARGET_LINK_STACK);
+
+ if (HAVE_GAS_HIDDEN)
+ sprintf (name, __ppc476.get_thunk);
+ else
+ ASM_GENERATE_INTERNAL_LABEL (name, LPPC476_, 0);
+}
+
+/* This function emits the simple thunk routine that is used to preserve
+ the link stack on the 476 cpu. */
+
+static void
+rs6000_code_end (void)
+{
+ char name[32];
+ tree decl;
+
+ if (!TARGET_LINK_STACK)
+ return;
+
+ get_ppc476_thunk_name (name);
+
+ decl = build_decl (BUILTINS_LOCATION, FUNCTION_DECL, get_identifier (name),
+ build_function_type_list (void_type_node, NULL_TREE));
+ DECL_RESULT (decl) = build_decl (BUILTINS_LOCATION, RESULT_DECL,
+ NULL_TREE, void_type_node);
+ TREE_PUBLIC (decl) = 1;
+ TREE_STATIC (decl) = 1;
+
+ if (HAVE_GAS_HIDDEN)
+ {
+ DECL_COMDAT_GROUP (decl) = DECL_ASSEMBLER_NAME (decl);
+ targetm.asm_out.unique_section (decl, 0);
+ switch_to_section (get_named_section (decl, NULL, 0));
+ DECL_WEAK (decl) = 1;
+ ASM_WEAKEN_DECL (asm_out_file, decl, name, 0);
+ targetm.asm_out.globalize_label (asm_out_file, name);
+ targetm.asm_out.assemble_visibility (decl, VISIBILITY_HIDDEN);
+ ASM_DECLARE_FUNCTION_NAME (asm_out_file, name, decl);
+ }
+ else
+ {
+ switch_to_section (text_section);
+ ASM_OUTPUT_LABEL (asm_out_file, name);
+ }
+
+ DECL_INITIAL (decl) = make_node (BLOCK);
+ current_function_decl = decl;
+ init_function_start (decl);
+ first_function_block_is_cold = false;
+ /* Make sure unwind info is emitted for the thunk if needed. */
+ final_start_function (emit_barrier (), asm_out_file, 1);
+
+ fputs (\tblr\n, asm_out_file);
+
+ final_end_function ();
+ init_insn_lengths ();
+ free_after_compilation (cfun);
+ set_cfun (NULL);
+ current_function_decl = NULL;
The two new functions have mistakes because I did not realize the
semantics of HAVE_GAS_HIDDEN. HAVE_GAS_HIDDEN is not a macro to be
tested at runtime, but a macro tested at compile time.
if (HAVE_GAS_HIDDEN)
should be
#ifdef HAVE_GAS_HIDDEN
Please correct.
Thanks, David
Re: building binutils from same directory as gcc
On Nov 2, 2011, at 10:17 AM, Andrew Haley wrote: Sure, but that doesn't answer the question, which was is there ever any advantage to building in-srcdir? The answer Yes: one can build in srcdir doesn't quite do it! Well, unstated in that is that one doesn't have to manually create an object directory. Also, unstated in that, is that to build a random package, one doesn't have to read the documentation to configure and build it, they can just build it. and it will just work. These are the advantages. It used to be the case, a long time ago, that building software was a random hodge-podge of weird random commands, the situation has been improving over the years to standardize on a few small incantations that work. The configure make make install, was the command standardized on, right after make make install. It is like explaining the advantage of a red stop light being red. It is red, because all stop lights are red. This is nicely circular. The reason _why_ is have a standard, isn't just to make the light red, it is so that all users of all stop lights expect it to be red, and if it weren't bad things would happen. We make ./configure make make install work, because our users expect it to work, and there is no reason to break that assumption.
Re: [C++ Patch] PR 50956
OK. Jason
Re: [C++ Patch] PR 50956
... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want to break it again, better doing the below too. Seems obvious, by itself. Paolo. // 2011-11-02 Paolo Carlini paolo.carl...@oracle.com PR c++/50956 * builtins.c (fold_builtin_memchr): Fix cast. Index: builtins.c === --- builtins.c (revision 180778) +++ builtins.c (working copy) @@ -8427,7 +8427,7 @@ fold_builtin_memchr (location_t loc, tree arg1, tr if (target_char_cast (arg2, c)) return NULL_TREE; - r = (char *) memchr (p1, c, tree_low_cst (len, 1)); + r = (const char *) memchr (p1, c, tree_low_cst (len, 1)); if (r == NULL) return build_int_cst (TREE_TYPE (arg1), 0);
[C++11 Patch] NSMI and aggregate type
Hi,
I tried GCC trunk to test the non static member initializer, and noticed a
bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50965
I noticed that the reason is that Some code path test if the test is an
aggregate type before running the constructors.
But in C++11 the definition of aggregate type has changed to exclude the types
with NSMI.
Hence the patch.
It means that code like that in the test
A a2 = { 24 };
Are not allowed.
Please CC me
--
OlivierFrom c799ec19b7f9c68f4721c4c5979c4707dad1bc61 Mon Sep 17 00:00:00 2001
From: Olivier Goffart ogoff...@kde.org
Date: Wed, 2 Nov 2011 17:42:48 +0100
Subject: [PATCH] Fix NSMI with brace initializer
Code like this:
struct A {
int i = 42;
};
int main() {
A a{};
std::cout a.i std::endl;
}
would show 0
After investigating, I noticed that this is due to the change of meaning
of aggregate type.
Which means that you cannot initialize A with {10} anymore.
I don't know if it is intended by the standard, but it is the case.
---
gcc/cp/class.c |2 +-
gcc/cp/cp-tree.h|5 +++--
gcc/testsuite/g++.dg/cpp0x/nsdmi1.C |6 +++---
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 41d182a..72ea9b6 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -3083,7 +3083,7 @@ check_field_decls (tree t, tree *access_decls,
/* Now it can only be a FIELD_DECL. */
- if (TREE_PRIVATE (x) || TREE_PROTECTED (x))
+ if (TREE_PRIVATE (x) || TREE_PROTECTED (x) || DECL_INITIAL (x))
CLASSTYPE_NON_AGGREGATE (t) = 1;
/* If at least one non-static data member is non-literal, the whole
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index ac42e0e..effe18c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3205,8 +3205,9 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
/* [dcl.init.aggr]
- An aggregate is an array or a class with no user-declared
- constructors, no private or protected non-static data members, no
+ An aggregate is an array or a class with no user-provided
+ constructors, no brace-or-equal-initializers for non-static data
+ members, no private or protected non-static data members, no
base classes, and no virtual functions.
As an extension, we also treat vectors as aggregates. Keep these
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi1.C b/gcc/testsuite/g++.dg/cpp0x/nsdmi1.C
index f6381d0..159c16d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nsdmi1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi1.C
@@ -31,8 +31,8 @@ int main()
{
A a1;
if (a1.i != 42) return 1;
- A a2 = { 24 };
- if (a2.i != 24) return 2;
+ A a2{};
+ if (a2.i != 42) return 2;
A a3[1];
if (a3[0].i != 42) return 3;
@@ -43,7 +43,7 @@ int main()
Cint,3 c1;
if (c1.m != 3) return 5;
- Cint,3 c2 { 5 };
+ Cint,5 c2 {};
if (c2.m != 5) return 6;
Dint,3 d1;
--
1.7.7.1
Re: Go patch committed: Update Go library
Rainer Orth r...@cebitec.uni-bielefeld.de writes: All go and libgo execution tests are failing for me with this patch on x86_64-unknown-linux-gnu (CentOS 5.5, I think): output is: /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `inotify_init1' /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `fallocate' /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li bgo/.libs/libgo.so: undefined reference to `sync_file_range' collect2: error: ld returned 1 exit status FAIL: go.go-torture/execute/array-1.go compilation, -O0 I assume that CentOS 5.5 uses some version of glibc before version 2.6. The three functions you mention are not supported in older versions of glibc. Fortunately, they are not called anywhere else in the library, so this patch takes the easy way out and simply removes them. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r c0c039af2298 libgo/go/syscall/libcall_linux.go --- a/libgo/go/syscall/libcall_linux.go Wed Nov 02 09:48:33 2011 -0700 +++ b/libgo/go/syscall/libcall_linux.go Wed Nov 02 10:32:33 2011 -0700 @@ -186,8 +186,9 @@ //sys Faccessat(dirfd int, path string, mode uint32, flags int) (errno int) //faccessat(dirfd int, pathname *byte, mode int, flags int) int -//sys Fallocate(fd int, mode uint32, off int64, len int64) (errno int) -//fallocate(fd int, mode int, offset Offset_t, len Offset_t) int +// FIXME: Only in glibc 2.10 and later. +// //sys Fallocate(fd int, mode uint32, off int64, len int64) (errno int) +// //fallocate(fd int, mode int, offset Offset_t, len Offset_t) int //sys Fchmodat(dirfd int, path string, mode uint32, flags int) (errno int) //fchmodat(dirfd int, pathname *byte, mode Mode_t, flags int) int @@ -223,8 +224,9 @@ //sysnb InotifyInit() (fd int, errno int) //inotify_init() int -//sysnb InotifyInit1(flags int) (fd int, errno int) -//inotify_init1(flags int) int +// FIXME: Only in glibc 2.9 and later. +// //sysnb InotifyInit1(flags int) (fd int, errno int) +// //inotify_init1(flags int) int //sysnb InotifyRmWatch(fd int, watchdesc uint32) (success int, errno int) //inotify_rm_watch(fd int, wd uint32) int @@ -298,8 +300,9 @@ // //sys Statfs(path string, buf *Statfs_t) (errno int) // //statfs(path *byte, buf *Statfs_t) int -//sys SyncFileRange(fd int, off int64, n int64, flags int) (errno int) -//sync_file_range(fd int, off Offset_t, n Offset_t, flags uint) int +// FIXME: Only in glibc 2.6 and later. +// //sys SyncFileRange(fd int, off int64, n int64, flags int) (errno int) +// //sync_file_range(fd int, off Offset_t, n Offset_t, flags uint) int // FIXME: mksysinfo Sysinfo_t // //sysnb Sysinfo(info *Sysinfo_t) (errno int)
Re: New port: Renesas RL78
deduce that this path is unreachable is to generate an abort and output an informative notice with inform (). Hmmm... I'll see if I can catch it early enough to do something more meaningful, then. (I don't see what actually generates the error, since there are only two Actually, it's in binutils. GCC passes along the unaligned absolute address, which causes an error.
Re: Go patch committed: Update Go library
On 11/02/2011 10:54 AM, Ian Lance Taylor wrote:
Rainer Orthr...@cebitec.uni-bielefeld.de writes:
All go and libgo execution tests are failing for me with this patch on
x86_64-unknown-linux-gnu (CentOS 5.5, I think):
output is:
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `inotify_init1'
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `fallocate'
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `sync_file_range'
collect2: error: ld returned 1 exit status
FAIL: go.go-torture/execute/array-1.go compilation, -O0
I assume that CentOS 5.5 uses some version of glibc before version 2.6.
The three functions you mention are not supported in older versions of
glibc. Fortunately, they are not called anywhere else in the library,
so this patch takes the easy way out and simply removes them.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
On Linux you also have iopl and ioperm which are x86 only.
On MIPS we fail because of those. I was going to create a patch to move
those two to libcall_linux_{386,amd64}.go. An alternative would be to
remove them too.
David Daney
Re: [PATCH,PR50763] Follow-up patch to fix i686 bootstrap failure
On 10/26/2011 10:38 AM, Richard Guenther wrote:
On Tue, Oct 25, 2011 at 2:15 PM, Tom de Vries tom_devr...@mentor.com wrote:
Richard,
I have a patch for the i686 bootstrap problem reported in PR50763 comment 10.
pr50763-2.c looks like this before tail_merge_optimize:
...
std_canonical_va_list_type (union tree_node * typeD.1608)
{
_BoolD.1576 pretmp.6D.2739;
union tree_node * pretmp.5D.2738;
_BoolD.1576 pretmp.4D.2737;
union tree_node * pretmp.3D.2736;
intD.6 D.2734;
_BoolD.1576 D.2733;
union tree_node * D.2725;
intD.6 D.2722;
intD.6 D.2717;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# VUSE .MEMD.2730_12(D)
D.2717_4 = typeD.1608_3(D)-baseD.1605.codeD.1597;
if (D.2717_4 != 0)
goto bb 3;
else
goto bb 4;
# SUCC: 3 [50.0%] (true,exec) 4 [50.0%] (false,exec)
# BLOCK 3 freq:5000
# PRED: 2 [50.0%] (true,exec)
# VUSE .MEMD.2730_12(D)
# PT = anything
typeD.1608_5 = typeD.1608_3(D)-typedD.1606.typeD.1600;
goto bb 6;
# SUCC: 6 [100.0%] (fallthru,exec)
# BLOCK 4 freq:5000
# PRED: 2 [50.0%] (false,exec)
# VUSE .MEMD.2730_12(D)
# PT = anything
typeD.1608_6 = typeD.1608_3(D)-typedD.1606.typeD.1600;
# VUSE .MEMD.2730_12(D)
D.2722_7 = typeD.1608_6-baseD.1605.codeD.1597;
if (D.2722_7 != 0)
goto bb 5;
else
goto bb 7;
# SUCC: 5 [50.0%] (true,exec) 7 [50.0%] (false,exec)
# BLOCK 7 freq:2500
# PRED: 4 [50.0%] (false,exec)
goto bb 6;
# SUCC: 6 [100.0%] (fallthru)
# BLOCK 5 freq:2500
# PRED: 4 [50.0%] (true,exec)
# SUCC: 6 [100.0%] (fallthru,exec)
# BLOCK 6 freq:1
# PRED: 3 [100.0%] (fallthru,exec) 7 [100.0%] (fallthru) 5 [100.0%]
(fallthru,exec)
# PT = anything
# typeD.1608_1 = PHI typeD.1608_5(3), typeD.1608_3(D)(7), typeD.1608_6(5)
# VUSE .MEMD.2730_12(D)
# PT = anything
D.2725_9 = typeD.1608_1-type_commonD.1607.main_variantD.1604;
D.2733_15 = D.2725_9 != 0B;
D.2734_14 = (intD.6) D.2733_15;
# VUSE .MEMD.2730_12(D)
return D.2734_14;
# SUCC: EXIT [100.0%]
}
...
tail_merge_optimize discovers that block 3 and 5 are identical, and removes
block 5.
In replace_block_by, we end up with phi_vuse1 == NULL_TREE and
phi_vuse2 == .MEMD.2730_12(D).
After the original fix to PR50763, this forces us to update the vuses, while
that is not necessary.
Attached patch fixes this problem by determining more precisely when the
vuses
need to be updated.
bootstrapped and reg-tested on x86_64 and i686.
OK for trunk?
Ok.
Committed additional testcase from duplicate PR50854.
Thanks,
- Tom
2011-11-02 Tom de Vries t...@codesourcery.com
PR tree-optimization/50763
* g++.dg/pr50763-3.C: New test.
Index: gcc/testsuite/g++.dg/pr50763-3.C
===
--- /dev/null (new file)
+++ gcc/testsuite/g++.dg/pr50763-3.C (revision 0)
@@ -0,0 +1,57 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-options -O2 -ftree-tail-merge } */
+
+class v2d {
+public:
+ double x;
+ double y;
+};
+
+class v3d {
+public:
+ double x;
+ v3d() {}
+ v3d(const v2d cr2Dv) {}
+};
+
+class e2d {
+protected:
+ v2d _Min;
+ v2d _Max;
+public:
+ int cop2d(const v2d rPnt) const;
+ v2d clp2d(const v2d rPnt) const;
+};
+
+inline int e2d::cop2d(const v2d rPnt) const {
+ int bRet = 1;
+ if (rPnt.x _Min.x) bRet = 0;
+ else if (rPnt.x _Max.x) bRet = 0;
+ else if (rPnt.y _Max.y) bRet = 0;
+ return bRet;
+}
+
+inline v2d e2d::clp2d(const v2d rPnt) const {
+ v2d sRet = rPnt;
+ if (rPnt.x _Min.x) sRet.x = _Min.x;
+ if (rPnt.y _Min.y) sRet.y = _Min.y;
+ if (rPnt.x _Max.x) sRet.x = _Max.x;
+ if (rPnt.y _Max.y) sRet.y = _Max.y;
+ return sRet;
+}
+
+class sExt {
+protected:
+ e2d _Dom;
+ long eval() const;
+ long evalPoint(const v2d crUV, v3d rPnt) const;
+};
+
+long sExt::evalPoint(const v2d crUV, v3d rPnt) const {
+ v3d sUV = crUV;
+ if (!_Dom.cop2d(crUV)) {
+ sUV = _Dom.clp2d(crUV);
+ }
+ eval();
+}
Re: Go patch committed: Update Go library
Ian Lance Taylor i...@google.com writes: I assume that CentOS 5.5 uses some version of glibc before version 2.6. Right: $ /lib/libc.so.6 GNU C Library stable release version 2.5, by Roland McGrath et al. The three functions you mention are not supported in older versions of glibc. Fortunately, they are not called anywhere else in the library, so this patch takes the easy way out and simply removes them. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Fine, thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Go patch committed: Update Go library
David Daney david.da...@cavium.com writes:
On MIPS we fail because of those. I was going to create a patch to
move those two to libcall_linux_{386,amd64}.go. An alternative would
be to remove them too.
Moving them sounds good to me. libgo already has a framework for
architecture specific system calls. It doesn't have a framework for
glibc version.
Ian
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On 2 Nov 2011, at 17:18, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner berg...@vnet.ibm.com
wrote:
+/* Fills in the label name that should be used for a 476 link
stack thunk. */
+
+void
+get_ppc476_thunk_name (char name[32])
+{
+ gcc_assert (TARGET_LINK_STACK);
+
+ if (HAVE_GAS_HIDDEN)
+sprintf (name, __ppc476.get_thunk);
+ else
+ASM_GENERATE_INTERNAL_LABEL (name, LPPC476_, 0);
+}
+
+/* This function emits the simple thunk routine that is used to
preserve
+ the link stack on the 476 cpu. */
+
+static void
+rs6000_code_end (void)
+{
+ char name[32];
+ tree decl;
+
+ if (!TARGET_LINK_STACK)
+return;
+
+ get_ppc476_thunk_name (name);
+
+ decl = build_decl (BUILTINS_LOCATION, FUNCTION_DECL,
get_identifier (name),
+build_function_type_list (void_type_node,
NULL_TREE));
+ DECL_RESULT (decl) = build_decl (BUILTINS_LOCATION, RESULT_DECL,
+ NULL_TREE, void_type_node);
+ TREE_PUBLIC (decl) = 1;
+ TREE_STATIC (decl) = 1;
+
+ if (HAVE_GAS_HIDDEN)
+{
+ DECL_COMDAT_GROUP (decl) = DECL_ASSEMBLER_NAME (decl);
+ targetm.asm_out.unique_section (decl, 0);
+ switch_to_section (get_named_section (decl, NULL, 0));
+ DECL_WEAK (decl) = 1;
+ ASM_WEAKEN_DECL (asm_out_file, decl, name, 0);
+ targetm.asm_out.globalize_label (asm_out_file, name);
+ targetm.asm_out.assemble_visibility (decl, VISIBILITY_HIDDEN);
+ ASM_DECLARE_FUNCTION_NAME (asm_out_file, name, decl);
+}
+ else
+{
+ switch_to_section (text_section);
+ ASM_OUTPUT_LABEL (asm_out_file, name);
+}
+
+ DECL_INITIAL (decl) = make_node (BLOCK);
+ current_function_decl = decl;
+ init_function_start (decl);
+ first_function_block_is_cold = false;
+ /* Make sure unwind info is emitted for the thunk if needed. */
+ final_start_function (emit_barrier (), asm_out_file, 1);
+
+ fputs (\tblr\n, asm_out_file);
+
+ final_end_function ();
+ init_insn_lengths ();
+ free_after_compilation (cfun);
+ set_cfun (NULL);
+ current_function_decl = NULL;
The two new functions have mistakes because I did not realize the
semantics of HAVE_GAS_HIDDEN. HAVE_GAS_HIDDEN is not a macro to be
tested at runtime, but a macro tested at compile time.
if (HAVE_GAS_HIDDEN)
should be
#ifdef HAVE_GAS_HIDDEN
also in macho_branch_islands () :
if (TARGET_LINK_STACK)
{
char name[32];
get_ppc64_thunk_name (name);
strcat (tmp_buf, :\n\tmflr r0\n\tbl );
strcat (tmp_buf, name);
strcat (tmp_buf, \n);
strcat (tmp_buf, label);
strcat (tmp_buf, _pic:\n\tmflr r11\n);
}
else
which breaks bootstrap for darwin - I'm not sure why you have an entry
here (this is mach-o-specific code)
- I doubt there will ever be a mach-o implementation with a PPC476 -
but, in any case the call to get_ppc64_thunk_name needs wrapping
somehow.
cheers
Iain
Re: [google] AddressSanitizer for gcc, first attempt. (issue 5272048)
The invoke.texi change looks fine. The ChangeLog entry needs some work. http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main File ChangeLog.google-main (right): http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main#newcode6 ChangeLog.google-main:6: 1 2011-11-02 Kostya Serebryany k...@google.com 2 Introduce a new option -fasan which enables 3 AddressSanitizer, a fast memory error detector: 4 http://code.google.com/p/address-sanitizer. 5 The current implementation handles only heap accesses. 6 Not quite. A ChangeLog entry needs to have a rigid structure. For every file and function changed, you need to state what changed. The entry below this one is not really a good example. ChangeLog entries never describe how the patch works or what it provides. See examples in gcc/ChangeLog. See http://www.gnu.org/prep/standards/standards.html#Style-of-Change-Logs for details. http://codereview.appspot.com/5272048/
Re: [C++ Patch] PR 50956
On 11/02/2011 01:45 PM, Paolo Carlini wrote: ... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want to break it again, better doing the below too. Seems obvious, by itself. Yep. Jason
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
also in macho_branch_islands () :
if (TARGET_LINK_STACK)
{
char name[32];
get_ppc64_thunk_name (name);
strcat (tmp_buf, :\n\tmflr r0\n\tbl );
strcat (tmp_buf, name);
strcat (tmp_buf, \n);
strcat (tmp_buf, label);
strcat (tmp_buf, _pic:\n\tmflr r11\n);
}
else
which breaks bootstrap for darwin - I'm not sure why you have an entry
here (this is mach-o-specific code)
- I doubt there will ever be a mach-o implementation with a PPC476 -
but, in any case the call to get_ppc64_thunk_name needs wrapping
somehow.
How is it failing for you? And what are your configure options so
I can try and recreate the error?
If it's similar to what Alan saw but for get_ppc64_thunk_name, namely:
rs6000.c:27968:1: error: 'void rs6000_code_end()' defined but not used
[-Werror=unused-function]
cc1plus: all warnings being treated as errors
Does the following fix it for you?
Index: config/rs6000/rs6000-protos.h
===
--- config/rs6000/rs6000-protos.h (revision 180786)
+++ config/rs6000/rs6000-protos.h (working copy)
@@ -173,7 +173,7 @@ extern void rs6000_emit_eh_reg_restore (
extern const char * output_isel (rtx *);
extern void rs6000_call_indirect_aix (rtx, rtx, rtx);
extern void rs6000_aix_asm_output_dwarf_table_ref (char *);
-extern void get_ppc476_thunk_name (char name[32]);
+extern void get_ppc476_thunk_name (char name[32]) ATTRIBUTE_UNUSED;
/* Declare functions in rs6000-c.c */
Peter
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On Wed, 2011-11-02 at 13:18 -0400, David Edelsohn wrote:
The two new functions have mistakes because I did not realize the
semantics of HAVE_GAS_HIDDEN. HAVE_GAS_HIDDEN is not a macro to be
tested at runtime, but a macro tested at compile time.
I'm sorry, I didn't realize that either. Does the following fix
your problem?
Peter
* config/rs6000/rs6000.c (USE_HIDDEN_LINKONCE): New define.
(get_ppc476_thunk_name): Use it.
(rs6000_code_end): Likewise.
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 180786)
+++ config/rs6000/rs6000.c (working copy)
@@ -27949,6 +27949,12 @@ rs6000_save_toc_in_prologue_p (void)
return (cfun cfun-machine cfun-machine-save_toc_in_prologue);
}
+#ifdef HAVE_GAS_HIDDEN
+# define USE_HIDDEN_LINKONCE 1
+#else
+# define USE_HIDDEN_LINKONCE 0
+#endif
+
/* Fills in the label name that should be used for a 476 link stack thunk. */
void
@@ -27956,7 +27962,7 @@ get_ppc476_thunk_name (char name[32])
{
gcc_assert (TARGET_LINK_STACK);
- if (HAVE_GAS_HIDDEN)
+ if (USE_HIDDEN_LINKONCE)
sprintf (name, __ppc476.get_thunk);
else
ASM_GENERATE_INTERNAL_LABEL (name, LPPC476_, 0);
@@ -27983,7 +27989,7 @@ rs6000_code_end (void)
TREE_PUBLIC (decl) = 1;
TREE_STATIC (decl) = 1;
- if (HAVE_GAS_HIDDEN)
+ if (USE_HIDDEN_LINKONCE)
{
DECL_COMDAT_GROUP (decl) = DECL_ASSEMBLER_NAME (decl);
targetm.asm_out.unique_section (decl, 0);
[v3] Fix libstdc++/50880 in a better way
Hi,
tested x86_64-linux, committed to mainline.
Paolo.
//
2011-11-02 Richard B. Kreckel krec...@ginac.de
Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/50880
* include/std/complex (__complex_acosh): Fix in a better way,
use Kahan's formula.
* include/tr1/complex (__complex_acosh): Likewise.
Index: include/std/complex
===
--- include/std/complex (revision 180785)
+++ include/std/complex (working copy)
@@ -1686,14 +1686,9 @@
std::complex_Tp
__complex_acosh(const std::complex_Tp __z)
{
- std::complex_Tp __t((__z.real() - __z.imag())
- * (__z.real() + __z.imag()) - _Tp(1.0),
- _Tp(2.0) * __z.real() * __z.imag());
- __t = std::sqrt(__t);
- if (__z.real() _Tp())
- __t = -__t;
-
- return std::log(__t + __z);
+ // Kahan's formula.
+ return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
++ std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
}
#if _GLIBCXX_USE_C99_COMPLEX_TR1
Index: include/tr1/complex
===
--- include/tr1/complex (revision 180785)
+++ include/tr1/complex (working copy)
@@ -185,14 +185,9 @@
std::complex_Tp
__complex_acosh(const std::complex_Tp __z)
{
- std::complex_Tp __t((__z.real() - __z.imag())
- * (__z.real() + __z.imag()) - _Tp(1.0),
- _Tp(2.0) * __z.real() * __z.imag());
- __t = std::sqrt(__t);
- if (__z.real() _Tp())
- __t = -__t;
-
- return std::log(__t + __z);
+ // Kahan's formula.
+ return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
++ std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
}
#if _GLIBCXX_USE_C99_COMPLEX_TR1
Re: [C++ Patch] PR 50956
On 11/02/2011 07:26 PM, Jason Merrill wrote: On 11/02/2011 01:45 PM, Paolo Carlini wrote: ... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want to break it again, better doing the below too. Seems obvious, by itself. Yep. Great, all done. Note for the accidental reader: it's indeed obvious, but only if you are used to the C++ memchr, the two overloads. For the targets (many outside Linux) not providing those (via libc hooks) I would not have broken the bootstrap ;) Paolo.
Re: New port: Renesas RL78
On Wed, 2 Nov 2011, DJ Delorie wrote: Index: configure.ac +# Dereferencing -1 is a compile-time error This (those lines) look a little cryptic (and lack punctuation ;) Wild improvement guess: Too small 'int'?. No, the compiler specifically tests for unaligned accesses and gives a compile-time error, at Renesas's requrest. The chip can't do unaligned accesses correctly, but it doesn't fault - it just silently accesses the wrong memory. So the compiler errors instead. Ah. All validity issues aside, then Dereferencing unaligned pointers yields a compile-time error or pointers with unknown alignment would be much less cryptic: the Dereferencing -1 just sounds like *(char *) -1 or a cut brgds, H-P
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On 2 Nov 2011, at 18:34, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
also in macho_branch_islands () :
if (TARGET_LINK_STACK)
{
char name[32];
get_ppc64_thunk_name (name);
strcat (tmp_buf, :\n\tmflr r0\n\tbl );
strcat (tmp_buf, name);
strcat (tmp_buf, \n);
strcat (tmp_buf, label);
strcat (tmp_buf, _pic:\n\tmflr r11\n);
}
else
which breaks bootstrap for darwin - I'm not sure why you have an
entry
here (this is mach-o-specific code)
- I doubt there will ever be a mach-o implementation with a PPC476 -
but, in any case the call to get_ppc64_thunk_name needs wrapping
somehow.
How is it failing for you? And what are your configure options so
I can try and recreate the error?
/GCC/gcc-live-trunk/gcc/config/rs6000/rs6000.c: In function ‘void
macho_branch_islands()’:
/GCC/gcc-live-trunk/gcc/config/rs6000/rs6000.c:25074:34: error:
‘get_ppc64_thunk_name’ was not declared in this scope
make[3]: *** [rs6000.o] Error 1
make[3]: *** Waiting for unfinished jobs
/GCC/gcc-live-trunk/configure --prefix=/GCC/gcc-4-7-tempi --
target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --
build=powerpc-apple-darwin9 --enable-version-specific-runtime-libs --
enable-checking=yes --with-libiconv-prefix=/usr --with-system-zlib --
with-gmp=/GCC/multiprec-math/ppc --with-mpfr=/GCC/multiprec-math/ppc
--with-mpc=/GCC/multiprec-math/ppc --enable-languages=c,c+
+,fortran,ada,objc,obj-c++,lto
etc..
===
Hmm .. I wonder if this is just a temporary glitch because of the move
of files to libgcc.
I'll investigate a bit further later...
If it's similar to what Alan saw but for get_ppc64_thunk_name, namely:
rs6000.c:27968:1: error: 'void rs6000_code_end()' defined but not used
[-Werror=unused-function]
cc1plus: all warnings being treated as errors
Does the following fix it for you?
Index: config/rs6000/rs6000-protos.h
===
--- config/rs6000/rs6000-protos.h (revision 180786)
+++ config/rs6000/rs6000-protos.h (working copy)
@@ -173,7 +173,7 @@ extern void rs6000_emit_eh_reg_restore (
extern const char * output_isel (rtx *);
extern void rs6000_call_indirect_aix (rtx, rtx, rtx);
extern void rs6000_aix_asm_output_dwarf_table_ref (char *);
-extern void get_ppc476_thunk_name (char name[32]);
+extern void get_ppc476_thunk_name (char name[32]) ATTRIBUTE_UNUSED;
/* Declare functions in rs6000-c.c */
We do include this in tm_p.h
$ more ../gcc-4-7-trunk-build/gcc/tm_p.h
#ifndef GCC_TM_P_H
#define GCC_TM_P_H
#ifdef IN_GCC
# include config/rs6000/rs6000-protos.h
# include config/darwin-protos.h
# include tm-preds.h
#endif
#endif /* GCC_TM_P_H */
.. but not in tm.h
Iain
Re: [google] AddressSanitizer for gcc, first attempt. (issue 5272048)
OK for google/main with the nits below. http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main File ChangeLog.google-main (right): http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main#newcode1 ChangeLog.google-main:1: 2011-11-02 Kostya Serebryany k...@google.com 1 2011-11-02 Kostya Serebryany k...@google.com Need blank line below the datestamp. http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main#newcode3 ChangeLog.google-main:3: AddressSanitizer, a fast memory error detector: 2 Introduce a new option -fasan which enables 3 AddressSanitizer, a fast memory error detector: Not strictly accepted, but it is common to add some verbiage of this nature when adding major features. OK. http://codereview.appspot.com/5272048/
Re: New port: Renesas RL78
Ah. All validity issues aside, then Dereferencing unaligned pointers yields a compile-time error or pointers with unknown alignment would be much less cryptic: the Dereferencing -1 just sounds like *(char *) -1 or a cut Good point.
Re: New port: Renesas RL78
Nobody has asked the obvious question: why does libssp use *(int *)(-1) = 0; in the first place?
Re: Use of vector instructions in memmov/memset expanding
Hi,
I am going to benchmark the following hunk separately tonight. It is
independent change.
Rth, Vladimir: there are obviously several options how to make GCC use SSE for
64bit loads/stores in 32bit codegen (and 128bit loads/stores in 128bit
codegen). What do you think is best variant here?
(an alternative would be to make move patterns to preffer SSE variant in this
case or change RA order to iterate through SSE first, but at least with pre-IRA
this used to lead to bad decisions making RA to place value in SSE despite the
fact it is used in arithmetic that can't be done with SSE).
Honza
@@ -15266,6 +15363,38 @@ ix86_expand_move (enum machine_mode mode, rtx
operands[])
}
else
{
+ if (mode == DImode
+ !TARGET_64BIT
+ TARGET_SSE2
+ MEM_P (op0)
+ MEM_P (op1)
+ !push_operand (op0, mode)
+ can_create_pseudo_p ())
+ {
+ rtx temp = gen_reg_rtx (V2DImode);
+ emit_insn (gen_sse2_loadq (temp, op1));
+ emit_insn (gen_sse_storeq (op0, temp));
+ return;
+ }
+ if (mode == DImode
+ !TARGET_64BIT
+ TARGET_SSE
+ !MEM_P (op1)
+ GET_MODE (op1) == V2DImode)
+ {
+ emit_insn (gen_sse_storeq (op0, op1));
+ return;
+ }
+ if (mode == TImode
+ TARGET_AVX2
+ MEM_P (op0)
+ !MEM_P (op1)
+ GET_MODE (op1) == V4DImode)
+ {
+ op0 = convert_to_mode (V2DImode, op0, 1);
+ emit_insn (gen_vec_extract_lo_v4di (op0, op1));
+ return;
+ }
if (MEM_P (op0)
(PUSH_ROUNDING (GET_MODE_SIZE (mode)) != GET_MODE_SIZE (mode)
|| !push_operand (op0, mode))
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote: Hmm .. I wonder if this is just a temporary glitch because of the move of files to libgcc. Note that I just hit a problem with the libgcc move. We need: Index: libgcc/config/rs6000/t-ppccomm === --- libgcc/config/rs6000/t-ppccomm (revision 180786) +++ libgcc/config/rs6000/t-ppccomm (working copy) @@ -7,7 +7,7 @@ LIB2ADD_ST += \ $(srcdir)/config/rs6000/crtresfpr.S \ $(srcdir)/config/rs6000/crtsavgpr.S \ $(srcdir)/config/rs6000/crtresgpr.S \ - $(srcdir)/config/rs6000/crtresxfpr.S + $(srcdir)/config/rs6000/crtresxfpr.S \ $(srcdir)/config/rs6000/crtresxgpr.S \ $(srcdir)/config/rs6000/e500crtres32gpr.S \ $(srcdir)/config/rs6000/e500crtres64gpr.S \ @@ -21,7 +21,7 @@ LIB2ADD_ST += \ $(srcdir)/config/rs6000/e500crtsav64gprctr.S \ $(srcdir)/config/rs6000/e500crtsavg32gpr.S \ $(srcdir)/config/rs6000/e500crtsavg64gpr.S \ - $(srcdir)/config/rs6000/e500crtsavg64gprctr.S + $(srcdir)/config/rs6000/e500crtsavg64gprctr.S \ $(srcdir)/config/rs6000/eabi.S I'm continuing my build to see if there's anything more that falls out from that...or my patch :(. I'll investigate a bit further later... So you didn't start your build from scratch? I'll keep my fingers crossed that a fresh build fixing things for you. Otherwise, let me know what you find. Peter
Re: [C++ Patch] PR 50956
Another bootstrap issue: In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0: /home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In function ‘unsigned char* ustrchr(const unsigned char*, int)’: /home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h:782:55: error: cast from type ‘const char*’ to type ‘unsigned char*’ casts away qualifiers [-Werror=cast-qual]
[CRIS] Convert CRIS to constraints.md
Hello. As subject suggests. Regression tested on cris-axis-elf. Comments? OK to install? * config/cris/constraints.md: New file. * config/cris/cris.h (REG_CLASS_FROM_LETTER, CONSTRAINT_LEN, CRIS_CONST_OK_FOR_LETTER_P, CONST_OK_FOR_CONSTRAINT_P, CONST_DOUBLE_OK_FOR_LETTER_P, EXTRA_MEMORY_CONSTRAINT, EXTRA_CONSTRAINT, EXTRA_CONSTRAINT_Q, EXTRA_CONSTRAINT_R, EXTRA_CONSTRAINT_T, EXTRA_CONSTRAINT_S, EXTRA_CONSTRAINT_U): Remove. * config/cris/cris.c: Incule tm-constrs.h. (cris_print_operand): Use satisfies_constraint_O. (cris_normal_notice_update_cc, cris_rtx_costs): Use satisfies_constraint_I. (cris_address_cost): Use satisfies_constraint_L. * config/cris/cris.md: Include constraints.md. (*mov_sidemode, *mov_sidesisf, *mov_sidemode_mem, *mov_sidesisf_mem, *clear_sidemode, *ext_sideqihi, *ext_sidemodesi, *op_sidemode, *op_swap_sidemode, *extopqihi_side, *extopmodesi_side, *extopqihi_swap_side, *extopmodesi_swap_side): Use satisfies_constraint_N and satisfies_constraint_J. (moversideqi movemsideqi mover2side peephole2): Use satisfies_constraint_N and satisfies_constraint_J. (andu peephole2): Use satisfies_constraint_I and satisfies_constraint_O. Index: gcc/config/cris/cris.md === --- gcc/config/cris/cris.md (revision 180776) +++ gcc/config/cris/cris.md (working copy) @@ -242,6 +242,7 @@ (define_code_attr roCC [(lt pl) (ge m ;; Operand and operator predicates. (include predicates.md) +(include constraints.md) ;; Test insns. @@ -650,8 +651,8 @@ (define_insn *mov_sidemode (!CONST_INT_P (operands[2]) || INTVAL (operands[2]) 127 || INTVAL (operands[2]) -128 - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'N') - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'J'))) + || satisfies_constraint_N (operands[2]) + || satisfies_constraint_J (operands[2]))) return #; if (which_alternative == 4) return movem [%3=%2%S1],%0; @@ -677,8 +678,8 @@ (define_insn *mov_sidesisf (!CONST_INT_P (operands[2]) || INTVAL (operands[2]) 127 || INTVAL (operands[2]) -128 - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'N') - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'J'))) + || satisfies_constraint_N (operands[2]) + || satisfies_constraint_J (operands[2]))) return #; if (which_alternative 3) return move.%s0 [%3=%1%S2],%0; @@ -796,8 +797,8 @@ (define_insn *mov_sidemode_mem (!CONST_INT_P (operands[1]) || INTVAL (operands[1]) 127 || INTVAL (operands[1]) -128 - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'N') - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'J'))) + || satisfies_constraint_N (operands[1]) + || satisfies_constraint_J (operands[1]))) return #; if (which_alternative == 1 || which_alternative == 5) return #; @@ -830,8 +831,8 @@ (define_insn *mov_sidesisf_mem (!CONST_INT_P (operands[1]) || INTVAL (operands[1]) 127 || INTVAL (operands[1]) -128 - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'N') - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'J'))) + || satisfies_constraint_N (operands[1]) + || satisfies_constraint_J (operands[1]))) return #; if (which_alternative == 1 || which_alternative == 7 @@ -903,8 +904,8 @@ (define_insn *clear_sidemode (!CONST_INT_P (operands[1]) || INTVAL (operands[1]) 127 || INTVAL (operands[1]) -128 - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'N') - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'J'))) + || satisfies_constraint_N (operands[1]) + || satisfies_constraint_J (operands[1]))) return #; if (which_alternative == 4) return clearm [%2=%1%S0]; @@ -1246,8 +1247,8 @@ (define_insn *ext_sideqihi (!CONST_INT_P (operands[2]) || INTVAL (operands[2]) 127 || INTVAL (operands[2]) -128 - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'N') - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'J'))) + || satisfies_constraint_N (operands[2]) + || satisfies_constraint_J (operands[2]))) return #; if (which_alternative == 4) return mov%e4.%m4 [%3=%2%S1],%0; @@ -1270,8 +1271,8 @@ (define_insn *ext_sidemodesi (!CONST_INT_P (operands[2]) || INTVAL (operands[2]) 127 || INTVAL (operands[2]) -128 - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'N') - || CRIS_CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'J'))) + || satisfies_constraint_N (operands[2]) + ||
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
I'm going to try this
$ svn diff -x -p gcc/config/rs6000/rs6000.c
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 180788)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -25071,7 +25071,7 @@ macho_branch_islands (void)
if (TARGET_LINK_STACK)
{
char name[32];
- get_ppc64_thunk_name (name);
+ get_ppc476_thunk_name (name);
strcat (tmp_buf, :\n\tmflr r0\n\tbl );
strcat (tmp_buf, name);
strcat (tmp_buf, \n);
Oh my, I'm not sure how that got through. :( Oh, as you
said, that is TARGET_MACHO which I can't really test.
Sorry about that.
@@ -27956,10 +27956,11 @@ get_ppc476_thunk_name (char name[32])
{
gcc_assert (TARGET_LINK_STACK);
- if (HAVE_GAS_HIDDEN)
+#if defined(HAVE_GAS_HIDDEN)
sprintf (name, __ppc476.get_thunk);
- else
+#else
ASM_GENERATE_INTERNAL_LABEL (name, LPPC476_, 0);
+#endif
}
...
Instead of that, see my patch to fix David's AIX problem:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00198.html
Peter
Re: [C++ Patch] PR 50956
On 11/02/2011 08:12 PM, Jason Merrill wrote: Another bootstrap issue: In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0: /home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In function ‘unsigned char* ustrchr(const unsigned char*, int)’: /home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h:782:55: error: cast from type ‘const char*’ to type ‘unsigned char*’ casts away qualifiers [-Werror=cast-qual] Argh, I'll fix it momentarily. Paolo.
Re: Use of vector instructions in memmov/memset expanding
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 2c53423..6ce240a 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -561,10 +561,14 @@ struct processor_costs ix86_size_cost = {/* costs for
tuning for size */
COSTS_N_BYTES (2), /* cost of FABS instruction. */
COSTS_N_BYTES (2), /* cost of FCHS instruction. */
COSTS_N_BYTES (2), /* cost of FSQRT instruction. */
- {{rep_prefix_1_byte, {{-1, rep_prefix_1_byte}}},
+ {{{rep_prefix_1_byte, {{-1, rep_prefix_1_byte}}},
I do think we will want sse_unrolled_loop (and perhaps sse_loop, I don't know)
algorithms added to enable the SSE codegen: there are chips that do support SSE
but internally split the wide moves into word sized chunks and thus benefits
are minimal and setup costs won't pay back. So we do not want to default to
SSE codegen whenever possible, just when it is supposed to pay back.
I wonder what we will want to do then with -mno-sse (and i.e. for linux kernel
where
one can not implicitely use SSE). Probably making
sse_unrolled_loop-unrolled_loop
transition is easiest for this quite rare case even if some of other algorithm
may
turn out to be superrior.
+ if (align = 8 desired_alignment 8)
+{
+ rtx label = ix86_expand_aligntest (destptr, 8, false);
+ destmem = adjust_automodify_address_nv (destmem, SImode, destptr, 0);
+ emit_insn (gen_strset (destptr, destmem, gen_lowpart (SImode, value)));
+ emit_insn (gen_strset (destptr, destmem, gen_lowpart (SImode, value)));
+ ix86_adjust_counter (count, 8);
+ emit_label (label);
+ LABEL_NUSES (label) = 1;
+}
+ gcc_assert (desired_alignment = 16);
No vector move because promoted vector value is not computed, yet? (it would
make sense to bypass it to keep hot path for small blocks SSE free).
case unrolled_loop:
need_zero_guard = true;
- size_needed = GET_MODE_SIZE (Pmode) * (TARGET_64BIT ? 4 : 2);
+ /* Use SSE instructions, if possible. */
+ move_mode = TARGET_SSE ? (align_unknown ? DImode : V4SImode) : Pmode;
+ unroll_factor = 4;
Where did go the logic dropping unroll factor to 2 for 32bit integer loops?
This is
important otherwise se starve the RA.
@@ -21897,9 +22254,41 @@ ix86_expand_movmem (rtx dst, rtx src, rtx count_exp,
rtx align_exp,
LABEL_NUSES (label) = 1;
}
+ /* We haven't updated addresses, so we'll do it now.
+ Also, if the epilogue seems to be big, we'll generate a loop (not
+ unrolled) in it. We'll do it only if alignment is unknown, because in
+ this case in epilogue we have to perform memmove by bytes, which is very
+ slow. */
The unrolled epilogue does at most one byte wide move, while the rolled does at
most
4*16. Given that the odds are that the blocks are small, are you sure this is
not
causing performance problems?
@@ -21983,11 +22402,21 @@ promote_duplicated_reg (enum machine_mode mode, rtx
val)
static rtx
promote_duplicated_reg_to_size (rtx val, int size_needed, int desired_align,
int align)
{
- rtx promoted_val;
+ rtx promoted_val = NULL_RTX;
- if (TARGET_64BIT
- (size_needed 4 || (desired_align align desired_align 4)))
-promoted_val = promote_duplicated_reg (DImode, val);
+ if (size_needed 8 || (desired_align align desired_align 8))
+{
+ gcc_assert (TARGET_SSE);
+ if (TARGET_64BIT)
+ promoted_val = promote_duplicated_reg (V2DImode, val);
+ else
+ promoted_val = promote_duplicated_reg (V4SImode, val);
Hmm, it would seem more natural to turn this into V8QImode since it is really
vector of 4 duplicated bytes. This will avoid some TARGET_64BIT tess bellow.
Also AMD chips are very slow on integer-SSE moves. How the final promotion
sequence looks there?
diff --git a/gcc/cse.c b/gcc/cse.c
index ae67685..3b6471d 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -4616,7 +4616,10 @@ cse_insn (rtx insn)
to fold switch statements when an ADDR_DIFF_VEC is used. */
|| (GET_CODE (src_folded) == MINUS
GET_CODE (XEXP (src_folded, 0)) == LABEL_REF
- GET_CODE (XEXP (src_folded, 1)) == LABEL_REF)))
+ GET_CODE (XEXP (src_folded, 1)) == LABEL_REF))
+ /* Don't propagate vector-constants, as for now no architecture
+supports vector immediates. */
+ !vector_extensions_used_for_mode (mode))
This seems quite dubious. The instruction pattern representing the move should
refuse the constants via its condition or predicates.
The i386 specific bits seems quite good to me now and ready for mainline with
the above comments addressed. It may make your life easier if you tried to
make version that does not need any of the middle end changes - I think it is
possible, the middle end changes are mostly about expanding memcpy/memset w/o
loops at all. This can be handled incrementally after your current patch gets
to
Re: [PATCH, rs6000] Preserve link stack for 476 cpus
On Wed, 2011-11-02 at 14:05 -0500, Peter Bergner wrote: On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote: Hmm .. I wonder if this is just a temporary glitch because of the move of files to libgcc. Note that I just hit a problem with the libgcc move. We need: Index: libgcc/config/rs6000/t-ppccomm === --- libgcc/config/rs6000/t-ppccomm(revision 180786) +++ libgcc/config/rs6000/t-ppccomm(working copy) @@ -7,7 +7,7 @@ LIB2ADD_ST += \ $(srcdir)/config/rs6000/crtresfpr.S \ $(srcdir)/config/rs6000/crtsavgpr.S \ $(srcdir)/config/rs6000/crtresgpr.S \ -$(srcdir)/config/rs6000/crtresxfpr.S +$(srcdir)/config/rs6000/crtresxfpr.S \ $(srcdir)/config/rs6000/crtresxgpr.S \ $(srcdir)/config/rs6000/e500crtres32gpr.S \ $(srcdir)/config/rs6000/e500crtres64gpr.S \ @@ -21,7 +21,7 @@ LIB2ADD_ST += \ $(srcdir)/config/rs6000/e500crtsav64gprctr.S \ $(srcdir)/config/rs6000/e500crtsavg32gpr.S \ $(srcdir)/config/rs6000/e500crtsavg64gpr.S \ -$(srcdir)/config/rs6000/e500crtsavg64gprctr.S +$(srcdir)/config/rs6000/e500crtsavg64gprctr.S \ $(srcdir)/config/rs6000/eabi.S I'm continuing my build to see if there's anything more that falls out from that...or my patch :(. Hmmm, more fallout from the libgcc move. I think I'm just going to use an older checkout to test with until the libgcc fallout gets fixed. ... xgcc: error: ecrti.S: No such file or directory xgcc: fatal error: no input files compilation terminated. make[5]: *** [ecrti.o] Error 1 make[5]: Leaving directory `/home/bergner/gcc/build/gcc-mainline-476-dje/powerpc64-linux/32/libgcc' ... Peter
libgo now builds fine on alpha-pc-linux-gnu (+ results)
On Wed, Nov 2, 2011 at 5:50 PM, Ian Lance Taylor i...@google.com wrote: #defines with arguments are not working at all. Please consider following testcase: You're right: this approach doesn't work for preprocessor macros with arguments. Making those work via this approach would be much much harder. Please note missing struct terminfos define, so I understand that TC[GS]ETS is unknown, but FIOCLEX should be fully defined by preceeding definitions. Fortunately, the value of FIOCLEX is irrelevant. And as you say, this approach can't work for TCGETS anyhow. So let's take a different approach. This patch drops the use of TCGETS and TCSETS entirely. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian, with your latest fixes libgo builds fine on alpha-pc-linux-gnu. http, rpc and websocket tests that fail previously [1] now run OK, but there are a bunch of new failures: PASS: asn1 PASS: big PASS: bufio PASS: bytes PASS: cmath PASS: csv ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 426: 26952 Segmentation fault ./a.out -test.short -test.timeout=$timeout $@ FAIL: exec gmake[2]: *** [exec/check] Error 1 PASS: expvar PASS: flag PASS: fmt PASS: gob PASS: html PASS: http PASS: image PASS: io PASS: json PASS: log PASS: math PASS: mail PASS: mime PASS: net PASS: os PASS: patch PASS: path PASS: rand PASS: reflect PASS: regexp PASS: rpc PASS: runtime PASS: scanner PASS: smtp PASS: sort PASS: strconv PASS: strings PASS: sync PASS: syslog PASS: tabwriter PASS: template PASS: time PASS: unicode PASS: url PASS: utf16 PASS: utf8 PASS: websocket PASS: xml ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 426: 5164 Segmentation fault ./a.out -test.short -test.timeout=$timeout $@ FAIL: archive/tar gmake[2]: *** [archive/tar/check] Error 1 panic: runtime error: invalid memory address or nil pointer dereference ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 426: 5316 Aborted ./a.out -test.short -test.timeout=$timeout $@ FAIL: archive/zip gmake[2]: *** [archive/zip/check] Error 1 PASS: compress/bzip2 PASS: compress/flate PASS: compress/gzip PASS: compress/lzw PASS: compress/zlib PASS: container/heap PASS: container/list PASS: container/ring PASS: crypto/aes PASS: crypto/bcrypt PASS: crypto/blowfish PASS: crypto/cast5 PASS: crypto/cipher PASS: crypto/des PASS: crypto/dsa PASS: crypto/ecdsa PASS: crypto/elliptic PASS: crypto/hmac PASS: crypto/md4 PASS: crypto/md5 PASS: crypto/ocsp PASS: crypto/openpgp PASS: crypto/rand PASS: crypto/rc4 PASS: crypto/ripemd160 PASS: crypto/rsa PASS: crypto/sha1 PASS: crypto/sha256 PASS: crypto/sha512 PASS: crypto/subtle PASS: crypto/tls PASS: crypto/twofish PASS: crypto/x509 PASS: crypto/xtea PASS: crypto/openpgp/armor PASS: crypto/openpgp/elgamal PASS: crypto/openpgp/packet PASS: crypto/openpgp/s2k PASS: debug/dwarf PASS: debug/elf PASS: debug/macho PASS: debug/pe PASS: encoding/ascii85 PASS: encoding/base32 PASS: encoding/base64 PASS: encoding/binary PASS: encoding/git85 PASS: encoding/hex PASS: encoding/pem PASS: exp/ebnf PASS: exp/norm PASS: exp/spdy PASS: exp/sql PASS: exp/ssh PASS: exp/terminal PASS: exp/template/html PASS: go/ast PASS: go/parser PASS: go/printer PASS: go/scanner PASS: go/token PASS: hash/adler32 PASS: hash/crc32 PASS: hash/crc64 PASS: hash/fnv PASS: http/cgi PASS: http/fcgi PASS: image/draw PASS: image/jpeg PASS: image/png PASS: image/tiff PASS: image/ycbcr PASS: index/suffixarray PASS: io/ioutil PASS: mime/multipart PASS: net/textproto PASS: old/netchan PASS: old/regexp PASS: old/template PASS: os/user PASS: os/signal PASS: path/filepath PASS: regexp/syntax PASS: rpc/jsonrpc PASS: sync/atomic PASS: template/parse PASS: testing/quick PASS: testing/script [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00457.html Uros.
Re: [C++ Patch] PR 50956
On 11/02/2011 08:44 PM, Paolo Carlini wrote:
On 11/02/2011 08:12 PM, Jason Merrill wrote:
Another bootstrap issue:
In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In
function ‘unsigned char* ustrchr(const unsigned char*, int)’:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h:782:55:
error: cast from type ‘const char*’ to type ‘unsigned char*’ casts
away qualifiers [-Werror=cast-qual]
Argh, I'll fix it momentarily.
By the way, I have no idea why I didn't see it, only Fortran includes
that header in the *libcpp* directory? Anyway, I'm proceeding to
bootstrap the attached.
Paolo.
/
Index: internal.h
===
--- internal.h (revision 180785)
+++ internal.h (working copy)
@@ -770,16 +770,16 @@ ustrlen (const unsigned char *s1)
return strlen ((const char *)s1);
}
-static inline unsigned char *
+static inline const unsigned char *
uxstrdup (const unsigned char *s1)
{
- return (unsigned char *) xstrdup ((const char *)s1);
+ return (const unsigned char *) xstrdup ((const char *)s1);
}
-static inline unsigned char *
+static inline const unsigned char *
ustrchr (const unsigned char *s1, int c)
{
- return (unsigned char *) strchr ((const char *)s1, c);
+ return (const unsigned char *) strchr ((const char *)s1, c);
}
static inline int
Re: [C++ Patch] PR 50956
this actually.
Paolo.
/
Index: internal.h
===
--- internal.h (revision 180785)
+++ internal.h (working copy)
@@ -739,8 +739,8 @@
static inline int ustrncmp (const unsigned char *, const unsigned char *,
size_t);
static inline size_t ustrlen (const unsigned char *);
-static inline unsigned char *uxstrdup (const unsigned char *);
-static inline unsigned char *ustrchr (const unsigned char *, int);
+static inline const unsigned char *uxstrdup (const unsigned char *);
+static inline const unsigned char *ustrchr (const unsigned char *, int);
static inline int ufputs (const unsigned char *, FILE *);
/* Use a const char for the second parameter since it is usually a literal. */
@@ -770,16 +770,16 @@
return strlen ((const char *)s1);
}
-static inline unsigned char *
+static inline const unsigned char *
uxstrdup (const unsigned char *s1)
{
- return (unsigned char *) xstrdup ((const char *)s1);
+ return (const unsigned char *) xstrdup ((const char *)s1);
}
-static inline unsigned char *
+static inline const unsigned char *
ustrchr (const unsigned char *s1, int c)
{
- return (unsigned char *) strchr ((const char *)s1, c);
+ return (const unsigned char *) strchr ((const char *)s1, c);
}
static inline int
[SPARC] Fix PR target/50945
This is a fallout of the consolidation patch for floating-point insns. When
the regular and no_fpu patterns for movdf were merged, the r/ro alternative of
the latter pattern was merged with the r/rFo alternative of the former. This
was presumably intended, but the associated splitter wasn't changed, so the
r/F case breaks with -mno-fpu/-msoft-float.
Fixed thusly. The patch also reindents some contraints (and a reindentation
patch is also attached for the 4.6 branch so as to make comparisons easier).
Bootstrapped/regtested on SPARC/Solaris, applied on mainline (and 4.6 branch).
2011-11-02 Eric Botcazou ebotca...@adacore.com
PR target/50945
* config/sparc/sparc.md (movsf_insn): Reindent constraints.
(movdf_insn_sp32): Likewise. Remove redundant G constraint.
(movdf_insn_sp64): Likewise.
(DFmode splitter): Do not test TARGET_FPU.
(movtf_insn_sp32): Reindent constraints.
(movtf_insn_sp32_no_fpu): Likewise.
(movtf_insn_sp64): Likewise.
(movtf_insn_sp64_hq): Likewise.
(movtf_insn_sp64_no_fpu): Likewise.
2011-11-02 Eric Botcazou ebotca...@adacore.com
* gcc.target/sparc/2002-1.c: New test.
--
Eric Botcazou
Index: config/sparc/sparc.md
===
--- config/sparc/sparc.md (revision 180732)
+++ config/sparc/sparc.md (working copy)
@@ -2041,8 +2041,8 @@ (define_expand movsf
})
(define_insn *movsf_insn
- [(set (match_operand:SF 0 nonimmediate_operand =d,d,f, *r,*r,*r,*r, f, f,*r, m, m)
- (match_operand:SF 1 input_operand G,C,f,*rR, Q, S, f,*r, m, m, f,*rG))]
+ [(set (match_operand:SF 0 nonimmediate_operand =d,d,f, *r,*r,*r,*r, f,f,*r,m, m)
+ (match_operand:SF 1 input_operand G,C,f,*rR, Q, S, f,*r,m, m,f,*rG))]
(register_operand (operands[0], SFmode)
|| register_or_zero_or_all_ones_operand (operands[1], SFmode))
{
@@ -2138,8 +2138,8 @@ (define_expand movdf
})
(define_insn *movdf_insn_sp32
- [(set (match_operand:DF 0 nonimmediate_operand =b,b,e,e,*r, f, e,T,W,U,T, f, *r, o,o)
-(match_operand:DF 1 input_operand G,C,e,e, f,*r,W#F,G,e,T,U,o#F,*roGF,*rG,f))]
+ [(set (match_operand:DF 0 nonimmediate_operand =b,b,e,e,*r, f, e,T,W,U,T, f, *r, o,o)
+ (match_operand:DF 1 input_operand G,C,e,e, f,*r,W#F,G,e,T,U,o#F,*roF,*rG,f))]
! TARGET_ARCH64
(register_operand (operands[0], DFmode)
|| register_or_zero_or_all_ones_operand (operands[1], DFmode))
@@ -2166,7 +2166,7 @@ (define_insn *movdf_insn_sp32
(define_insn *movdf_insn_sp64
[(set (match_operand:DF 0 nonimmediate_operand =b,b,e,*r, e, e,W, *r,*r, m,*r)
-(match_operand:DF 1 input_operand G,C,e, e,*r,W#F,e,*rG, m,*rG, F))]
+ (match_operand:DF 1 input_operand G,C,e, e,*r,W#F,e,*rG, m,*rG, F))]
TARGET_ARCH64
(register_operand (operands[0], DFmode)
|| register_or_zero_or_all_ones_operand (operands[1], DFmode))
@@ -2191,9 +2191,8 @@ (define_insn *movdf_insn_sp64
(define_split
[(set (match_operand:DF 0 register_operand )
(match_operand:DF 1 const_double_operand ))]
- TARGET_FPU
-(GET_CODE (operands[0]) == REG
-SPARC_INT_REG_P (REGNO (operands[0])))
+ REG_P (operands[0])
+SPARC_INT_REG_P (REGNO (operands[0]))
! const_zero_operand (operands[1], GET_MODE (operands[0]))
reload_completed
[(clobber (const_int 0))]
@@ -2378,8 +2377,8 @@ (define_expand movtf
})
(define_insn *movtf_insn_sp32
- [(set (match_operand:TF 0 nonimmediate_operand =b,e,o,U,r)
- (match_operand:TF 1 input_operandG,oe,GeUr,o,roG))]
+ [(set (match_operand:TF 0 nonimmediate_operand =b, e, o,U, r)
+ (match_operand:TF 1 input_operand G,oe,GeUr,o,roG))]
TARGET_FPU
! TARGET_ARCH64
(register_operand (operands[0], TFmode)
@@ -2392,8 +2391,8 @@ (define_insn *movtf_insn_sp32
;; when -mno-fpu.
(define_insn *movtf_insn_sp32_no_fpu
- [(set (match_operand:TF 0 nonimmediate_operand =o,U,o,r,o)
- (match_operand:TF 1 input_operandG,o,U,roG,r))]
+ [(set (match_operand:TF 0 nonimmediate_operand =o,U,o, r,o)
+ (match_operand:TF 1 input_operand G,o,U,roG,r))]
! TARGET_FPU
! TARGET_ARCH64
(register_operand (operands[0], TFmode)
@@ -2402,8 +2401,8 @@ (define_insn *movtf_insn_sp32_no_fpu
[(set_attr length 4)])
(define_insn *movtf_insn_sp64
- [(set (match_operand:TF 0 nonimmediate_operand =b,e,o,r)
-(match_operand:TF 1 input_operandG,oe,Ger,roG))]
+ [(set (match_operand:TF 0 nonimmediate_operand =b, e, o, r)
+ (match_operand:TF 1 input_operand G,oe,Ger,roG))]
TARGET_FPU
TARGET_ARCH64
! TARGET_HARD_QUAD
@@ -2413,8 +2412,8 @@ (define_insn *movtf_insn_sp64
[(set_attr length 2)])
(define_insn *movtf_insn_sp64_hq
- [(set (match_operand:TF 0 nonimmediate_operand =b,e,e,m,o,r)
-(match_operand:TF 1 input_operandG,e,m,e,rG,roG))]
+ [(set (match_operand:TF 0 nonimmediate_operand =b
Re: [C++ Patch] PR 50810
I'm checking in this variant of your patch; mostly it just adds
-Wno-narrowing to the warning options used to build GCC, though there
are a few wording tweaks as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6b5380306428a3e618027b3fc7a319ae2c520b35
Author: Jason Merrill ja...@redhat.com
Date: Tue Nov 1 11:56:30 2011 -0400
PR c++/50810
gcc/c-family
* c-opts.c (c_common_handle_option): Enable -Wnarrowing as part
of -Wall; include -Wnarrowing in -Wc++0x-compat; adjust default
Wnarrowing for C++0x and C++98.
* c.opt ([Wnarrowing]): Update.
gcc/cp
* typeck2.c (check_narrowing): Adjust OPT_Wnarrowing diagnostics.
(digest_init_r): Call check_narrowing irrespective of the C++ dialect.
* decl.c (check_initializer): Likewise.
* semantics.c (finish_compound_literal): Likewise.
gcc/
* configure.ac: Add -Wno-narrowing to warning options.
libcpp/
* configure.ac: Add -Wno-narrowing to warning options.
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index b56aec7..465bce3 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -406,6 +406,7 @@ c_common_handle_option (size_t scode, const char *arg, int value,
warn_reorder = value;
warn_cxx0x_compat = value;
warn_delnonvdtor = value;
+ warn_narrowing = value;
}
cpp_opts-warn_trigraphs = value;
@@ -436,6 +437,10 @@ c_common_handle_option (size_t scode, const char *arg, int value,
cpp_opts-warn_cxx_operator_names = value;
break;
+case OPT_Wc__0x_compat:
+ warn_narrowing = value;
+ break;
+
case OPT_Wdeprecated:
cpp_opts-cpp_warn_deprecated = value;
break;
@@ -997,10 +1002,17 @@ c_common_post_options (const char **pfilename)
if (warn_implicit_function_declaration == -1)
warn_implicit_function_declaration = flag_isoc99;
- /* If we're allowing C++0x constructs, don't warn about C++0x
- compatibility problems. */
if (cxx_dialect == cxx0x)
-warn_cxx0x_compat = 0;
+{
+ /* If we're allowing C++0x constructs, don't warn about C++98
+ identifiers which are keywords in C++0x. */
+ warn_cxx0x_compat = 0;
+
+ if (warn_narrowing == -1)
+ warn_narrowing = 1;
+}
+ else if (warn_narrowing == -1)
+warn_narrowing = 0;
if (flag_preprocess_only)
{
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 438b8b0..0d7dc88 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -494,8 +494,8 @@ C ObjC C++ ObjC++ Warning
Warn about use of multi-character character constants
Wnarrowing
-C ObjC C++ ObjC++ Warning Var(warn_narrowing) Init(1)
--Wno-narrowing In C++0x mode, ignore ill-formed narrowing conversions within { }
+C ObjC C++ ObjC++ Warning Var(warn_narrowing) Init(-1)
+Warn about narrowing conversions within { } that are ill-formed in C++11
Wnested-externs
C ObjC Var(warn_nested_externs) Warning
diff --git a/gcc/configure b/gcc/configure
index 3b0b39b..35dbdd8 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -6394,11 +6394,12 @@ fi
# * 'long long'
# * variadic macros
# * overlong strings
+# * C++11 narrowing conversions in { }
# So, we only use -pedantic if we can disable those warnings.
loose_warn=
save_CFLAGS=$CFLAGS
-for option in -W -Wall -Wwrite-strings -Wcast-qual; do
+for option in -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual; do
as_acx_Woption=`$as_echo acx_cv_prog_cc_warning_$option | $as_tr_sh`
{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether $CC supports $option 5
diff --git a/gcc/configure.ac b/gcc/configure.ac
index dd6cf2f..9196996 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -329,10 +329,11 @@ GCC_STDINT_TYPES
# * 'long long'
# * variadic macros
# * overlong strings
+# * C++11 narrowing conversions in { }
# So, we only use -pedantic if we can disable those warnings.
ACX_PROG_CC_WARNING_OPTS(
- m4_quote(m4_do([-W -Wall -Wwrite-strings -Wcast-qual])), [loose_warn])
+ m4_quote(m4_do([-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual])), [loose_warn])
ACX_PROG_CC_WARNING_OPTS(
m4_quote(m4_do([-Wstrict-prototypes -Wmissing-prototypes])),
[c_loose_warn])
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 860556c..edbc783 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5538,7 +5538,7 @@ check_initializer (tree decl, tree init, int flags, tree *cleanup)
else
{
init = reshape_init (type, init, tf_warning_or_error);
- if (cxx_dialect = cxx0x SCALAR_TYPE_P (type))
+ if (SCALAR_TYPE_P (type))
check_narrowing (type, init);
}
}
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index d76df51..a80aec6 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2369,7 +2369,7 @@ finish_compound_literal (tree type, tree compound_literal,
check_array_initializer (NULL_TREE, type, compound_literal))
return error_mark_node;
compound_literal = reshape_init (type, compound_literal, complain);
- if
Re: C++ PATCH to add -std=c++11 ??
And a few more diagnostic tweaks:
commit 2839df54ee49e6ba454d3ad842bc0018f3b29162
Author: Jason Merrill ja...@redhat.com
Date: Wed Nov 2 15:01:37 2011 -0400
* parser.c (cp_parser_decl_specifier_seq): Change C++0x to
C++11 in warnings.
(cp_lexer_get_preprocessor_token): Likewise.
(cp_parser_binary_expression): Likewise.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 63f9262..e543e87 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -744,7 +744,7 @@ cp_lexer_get_preprocessor_token (cp_lexer *lexer, cp_token *token)
/* Warn about the C++0x keyword (but still treat it as
an identifier). */
warning (OPT_Wc__0x_compat,
- identifier %qE will become a keyword in C++0x,
+ identifier %qE is a keyword in C++11,
token-u.value);
/* Clear out the C_RID_CODE so we don't warn about this
@@ -7198,8 +7198,8 @@ cp_parser_binary_expression (cp_parser* parser, bool cast_p,
!parser-greater_than_is_operator_p)
{
if (warning_at (token-location, OPT_Wc__0x_compat,
- %% operator will be treated as
- two right angle brackets in C++0x))
+ %% operator is treated as
+ two right angle brackets in C++11))
inform (token-location,
suggest parentheses around %% expression);
}
@@ -10528,7 +10528,7 @@ cp_parser_decl_specifier_seq (cp_parser* parser,
/* Complain about `auto' as a storage specifier, if
we're complaining about C++0x compatibility. */
warning_at (token-location, OPT_Wc__0x_compat, %auto%
- will change meaning in C++0x; please remove it);
+ changes meaning in C++11; please remove it);
/* Set the storage class anyway. */
cp_parser_set_storage_class (parser, decl_specs, RID_AUTO,
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto1.C b/gcc/testsuite/g++.dg/cpp0x/auto1.C
index 9e274b6..f5c0ea6 100644
--- a/gcc/testsuite/g++.dg/cpp0x/auto1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/auto1.C
@@ -1,8 +1,8 @@
-// { dg-options -std=c++98 -Wc++0x-compat }
+// { dg-options -std=c++98 -Wc++11-compat }
-// Test warning for use of auto in C++98 mode with C++0x
+// Test warning for use of auto in C++98 mode with C++11
// compatibility warnings
void f()
{
- auto int x = 5; // { dg-warning will change meaning }
+ auto int x = 5; // { dg-warning changes meaning }
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/bracket3.C b/gcc/testsuite/g++.dg/cpp0x/bracket3.C
index 4ef7a0e..f86aa04 100644
--- a/gcc/testsuite/g++.dg/cpp0x/bracket3.C
+++ b/gcc/testsuite/g++.dg/cpp0x/bracket3.C
@@ -1,10 +1,10 @@
-// { dg-options -std=c++98 -Wc++0x-compat }
+// { dg-options -std=c++98 -Wc++11-compat }
templateint N struct X {};
-X1 2 x; // { dg-warning will be treated as|suggest parentheses }
+X1 2 x; // { dg-warning is treated as|suggest parentheses }
// From cp/parser.c
typedef int Y;
template int V struct Foo {};
-FooY () 5 r; // { dg-warning will be treated as|suggest parentheses }
+FooY () 5 r; // { dg-warning is treated as|suggest parentheses }
diff --git a/gcc/testsuite/g++.dg/cpp0x/warn_cxx0x.C b/gcc/testsuite/g++.dg/cpp0x/warn_cxx0x.C
index 5ad9b61..5c5eeff 100644
--- a/gcc/testsuite/g++.dg/cpp0x/warn_cxx0x.C
+++ b/gcc/testsuite/g++.dg/cpp0x/warn_cxx0x.C
@@ -1,6 +1,6 @@
-// { dg-options -std=gnu++98 -Wc++0x-compat }
-int static_assert; // { dg-warning will become a keyword }
-int nullptr; // { dg-warning will become a keyword }
+// { dg-options -std=gnu++98 -Wc++11-compat }
+int static_assert; // { dg-warning is a keyword }
+int nullptr; // { dg-warning is a keyword }
void foo()
{
Massive breakage with your libgcc patches
From: Rainer Orth r...@cebitec.uni-bielefeld.de Date: Wed, 2 Nov 2011 13:37:33 +0100 Rainer Orth r...@cebitec.uni-bielefeld.de writes: The next patch in the series moves crtstuff.c, extra_parts, EXTRA_PARTS, EXTRA_MULTILIB_PARTS and referenced files to libgcc. This will avoid errors due to inconsistencies in extra_parts between gcc and libgcc in the future. Much of this is pretty mechanical, but given that I cannot test most of the platforms, there are likely to be mistakes in the process. Given Joseph's approval, I'm about to check in the following rebased version of the patch, after regtesting on i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu, i386-apple-darwin9.8.0, and powerpc-apple-darwin9.8.0. For big changes such as this, please test on a cross configuration as well. For cris-elf, a patch in the range 180770:180778 supposedly yours, cause massive testsuite failures on the form of not finding functions in libgcc at link-time. From gcc.log: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1-lib.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O0-isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -lm -o /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/complex-1.x0(timeout = 300) /tmp/ccAbw5Fs.o: In function `main_test': complex-1.c:(.text+0x9e): undefined reference to `__nesf2' complex-1.c:(.text+0xb8): undefined reference to `__nesf2' complex-1.c:(.text+0xfa): undefined reference to `__nesf2' complex-1.c:(.text+0x114): undefined reference to `__nesf2' complex-1.c:(.text+0x142): undefined reference to `__nesf2' /tmp/ccAbw5Fs.o:complex-1.c:(.text+0x162): more undefined references to `__nesf2' follow brgds, H-P
Re: [SPARC] Fix PR target/50945
From: Eric Botcazou ebotca...@adacore.com Date: Wed, 2 Nov 2011 21:07:15 +0100 This is a fallout of the consolidation patch for floating-point insns. When the regular and no_fpu patterns for movdf were merged, the r/ro alternative of the latter pattern was merged with the r/rFo alternative of the former. This was presumably intended, but the associated splitter wasn't changed, so the r/F case breaks with -mno-fpu/-msoft-float. Fixed thusly. The patch also reindents some contraints (and a reindentation patch is also attached for the 4.6 branch so as to make comparisons easier). Bootstrapped/regtested on SPARC/Solaris, applied on mainline (and 4.6 branch). Thanks for fixing this Eric.
