RE: CR16 Port addition
PING 3: For review Hi, Please review the attached patch and you can view the explanations for the earlier communication below. NOTE: From now on , Jayant (jayant.so...@kpitcummins.com) will be posting the patches related to CR16. Please feel free to contact him if you need any information related to the patches posted. Thanks in advance, Sumanth G, PUNE (India). = Begin Message == -Original Message- From: Sumanth Gundapaneni Sent: Monday, May 30, 2011 6:57 PM To: 'Joseph Myers' Cc: gcc-patches@gcc.gnu.org; r...@redhat.com; Jayant R. Sonar Subject: RE: CR16 Port addition Hi Joseph and Richard, Thanks for your time in reviewing the CR16 port and once again I am grateful for your valuable suggestions. Please find attached the patch cr16-gcc.patch which contains modifications as suggested by Joseph in his previous mail. For your kind information, I am providing the recent posts regarding CR16 patches. Initial post : http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01676.html Second post : http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00803.html Third post : http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00624.html Fourth post : http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01441.html Please review the patch and let me know if there should be any modifications in it. Joseph, please go through my explanation for your comments. Please remove the remaining top level configure changes from the patch. The top level configure changes have been removed as advised. Now you seem to have a stray change to the generated file libstdc++-v3/configure. Again, you can probably just eliminate this The configure changes in libtsdc++-v3 are removed too and you can find the same in the updated patch. and make the code in unwind-dw2-* use those macros, instead of having separate copies of the files. A new file unwind-helper.h file is created in libgcc/config/cr16 directory as per your suggestion and defined a few macros in this newly defined file which are getting called from gcc/unwind-dw2.c. Please review the same and do let me know for further modifications, if any. We have identified issues related to exception handling using prints in unwind code and will debug the same to a greater extent in near future with further development of GNU based tools. Since you first submitted the port, a file contrib/config-list.mk cr16-elf is added to config-list.mk file. gcc/ChangeLog: -- 2011-05-28 Sumanth G sumanth.gundapan...@kpitcummins.com Jayant R Sonar jayant.so...@kpitcummins.com * config.gcc: Add cr16-* support. * doc/extend.texi: Document cr16 extensions. * doc/install.texi: Document cr16 install. * doc/invoke.texi: Document cr16 options. * doc/md.texi: Document cr16 constraints. * config/cr16/cr16.c: New file. * config/cr16/cr16.h: New file. * config/cr16/cr16.md: New file. * config/cr16/cr16.opt: New file. * config/cr16/cr16-libgcc.s: New file. * config/cr16/cr16-protos.h: New file. * config/cr16/divmodhi3.c: New file. * config/cr16/predicates.md: New file. * config/cr16/constraints.md: New file. * config/cr16/t-cr16: New file. libgcc/ChangeLog: - 2011-05-28 Sumanth G sumanth.gundapan...@kpitcummins.com Jayant R Sonar jayant.so...@kpitcummins.com * config.host: Add National Semiconductor CR16 target (cr16-*-*). * config/cr16/crti.S: New file. * config/cr16/crtlibid.S: New file. * config/cr16/crtn.S: New file. * config/cr16/t-cr16: New file. * config/cr16/unwind-helper.h: New file. contrib/ChangeLog: -- 2011-05-28 Sumanth G sumanth.gundapan...@kpitcummins.com Jayant R Sonar jayant.so...@kpitcummins.com * config-list.mk: Add National Semiconductor CR16 target. Thanks in advance, Sumanth G, PUNE (India). = End Message ==
Re: [patch tree-optimization]: [3 of 3]: Boolify compares more
Hello,
This patch removes from tree-vrp the use of TRUTH-bitwise expression codes. Also
it merges the handling for boolean compatible and non-boolean typed
bitwise-binary
expressions.
Additional it adds primitive checks for bitwise-not expression on
boolean-compatible
types.
In substitute_and_fold the scan-direction of statements within a BB is
controlled now
by its do_dce flag. This provides better results in vrp-pass.
ChangeLog gcc
2011-07-15 Kai Tietz kti...@redhat.com
* tree-ssa-propagate.c (substitute_and_fold): Use
do_dce flag to deside, if BB's statements are scanned
in last to first, or first to last order.
* tree-vrp.c (extract_range_from_binary_expr):
Remove TRUTH-binary checks. And unify bitwise-binary
cases.
(register_edge_assert_for_1): Add handling boolean-compatible
typed BIT_IOR_EXPR and BIT_NOT_EXPR.
(extract_range_from_unary_expr): Add support for 1-bit
integral typed BIT_NOT_EXPR expression.
(extract_range_from_assignment): Remove TRUTH-binary checks.
Add handling for 1-bit integral typed BIT_NOT_EXPR expression.
(build_assert_expr_for): Likewise.
(register_edge_assert_for_1): Likewise.
(simplify_stmt_using_ranges): Likewise.
(ssa_name_get_inner_ssa_name_p): New helper function.
(ssa_name_get_cast_to_p): New helper function.
(simplify_truth_ops_using_ranges): Handle prefixed
cast instruction for result. Remove TRUTH-binary checks.
Add handling for 1-bit integral typed BIT_NOT_EXPR expression.
and BIT_NOT_EXPR.
Add handling for one bit
ChangeLog gcc/testsuite
2011-07-15 Kai Tietz kti...@redhat.com
* gcc.dg/tree-ssa/vrp47.c: Test no longer needs
dom dump.
Bootstrapped and regression tested for all standard languages (plus
Ada Obj-C++) on x86_64-pc-linux-gnu. Ok for apply?
Regards,
Kai
Index: gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
===
--- gcc.orig/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c 2011-07-13
12:57:46.869620200 +0200
+++ gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c 2011-07-13
22:29:53.221967000 +0200
@@ -4,7 +4,7 @@
jumps when evaluating an condition. VRP is not able to optimize
this. */
/* { dg-do compile { target { ! mips*-*-* s390*-*-* avr-*-*
mn10300-*-* } } } */
-/* { dg-options -O2 -fdump-tree-vrp -fdump-tree-dom } */
+/* { dg-options -O2 -fdump-tree-vrp } */
/* { dg-options -O2 -fdump-tree-vrp -fdump-tree-dom -march=i586 {
target { i?86-*-* ilp32 } } } */
int h(int x, int y)
@@ -36,13 +36,10 @@ int f(int x)
0 or 1. */
/* { dg-final { scan-tree-dump-times \[xy\]\[^ \]* != 0 vrp1 } } */
-/* This one needs more copy propagation that only happens in dom1. */
-/* { dg-final { scan-tree-dump-times x\[^ \]* y 1 dom1 } } */
-/* { dg-final { scan-tree-dump-times x\[^ \]* y 1 vrp1 { xfail
*-*-* } } } */
+/* { dg-final { scan-tree-dump-times x\[^ \]* y 1 vrp1 } } */
/* These two are fully simplified by VRP. */
/* { dg-final { scan-tree-dump-times x\[^ \]* \[|\] y 1 vrp1 } } */
/* { dg-final { scan-tree-dump-times x\[^ \]* \\^ 1 1 vrp1 } } */
/* { dg-final { cleanup-tree-dump vrp\[0-9\] } } */
-/* { dg-final { cleanup-tree-dump dom\[0-9\] } } */
Index: gcc/gcc/tree-ssa-propagate.c
===
--- gcc.orig/gcc/tree-ssa-propagate.c 2011-07-13 12:57:46.870620200 +0200
+++ gcc/gcc/tree-ssa-propagate.c2011-07-13 22:29:53.253971100 +0200
@@ -979,6 +979,9 @@ replace_phi_args_in (gimple phi, ssa_pro
DO_DCE is true if trivially dead stmts can be removed.
+ If DO_DCE is true, the statements within a BB are walked from
+ last to first element. Otherwise we scan from first to last element.
+
Return TRUE when something changed. */
bool
@@ -1059,9 +1062,10 @@ substitute_and_fold (ssa_prop_get_value_
for (i = gsi_start_phis (bb); !gsi_end_p (i); gsi_next (i))
replace_phi_args_in (gsi_stmt (i), get_value_fn);
- /* Propagate known values into stmts. Do a backward walk to expose
-more trivially deletable stmts. */
- for (i = gsi_last_bb (bb); !gsi_end_p (i);)
+ /* Propagate known values into stmts. Do a backward walk if
+ do_dce is true. In some case it exposes
+more trivially deletable stmts to walk backward. */
+ for (i = (do_dce ? gsi_last_bb (bb) : gsi_start_bb (bb));
!gsi_end_p (i);)
{
bool did_replace;
gimple stmt = gsi_stmt (i);
@@ -1070,7 +1074,10 @@ substitute_and_fold (ssa_prop_get_value_
gimple_stmt_iterator oldi;
oldi = i;
- gsi_prev (i);
+ if (do_dce)
+ gsi_prev (i);
+ else
+ gsi_next (i);
/* Ignore ASSERT_EXPRs. They are used by VRP to generate
range information for names and they are discarded
Index: gcc/gcc/tree-vrp.c
Re: Remove NetWare support
On 07/14/2011 08:40 PM, Rainer Orth wrote: I've got a preliminary NetWare removal patch ready (yet untested), but have a couple of questions: * Given that there's a considerable amount of NetWare support still in src, toplevel support has to stay. On the other hand, the reference in config/elf.m4 is only used for the LTO plugin and can go, I believe. * The i386 port has some code that seems to be NetWare-specific, namely KEEP_AGGREGATE_RETURN_POINTER, ix86_keep_aggregate_return_pointer and the callee_pop_aggregate_return attribute. I'm uncertain if all this can go now. * There are references to config/i386/netware.h in gcc/po/*.po. Do I need to do anything about this when netware.h is removed? Since Netware is an x86-only port, I'll leave approval to x86 maintainers. Paolo
Re: [PATCH] widening_mul: Do cost check when propagating mult into plus/minus expressions
On 07/14/2011 11:40 AM, Richard Guenther wrote: (look how the vectorizer for example uses new target hooks instead of generating vectorized RTL and then using rtx_cost). But wouldn't we then end up with just a bunch of special purpose tree_cost functions again?! Then we would again be doomed to duplicate rtx_cost logic on a different IR what has already been considered to be a bad idea. -Andreas-
Re: [Patch, Fortran] Allocate + CAF library
On 07/11/2011 08:16 PM, Daniel Carrera wrote:
This patch improves support for the ALLOCATE statement when using the
coarray library. Specifically, it adds support for the stat= and
errmsg= attributes:
Thanks for the patch - and sorry for the slow review.
Some comments below.
Index: gcc/fortran/trans-stmt.c
===
+ /* ERRMSG= */
+ errmsg = null_pointer_node;
+ errlen = build_int_cst (gfc_charlen_type_node, 0);
+ if (code-expr2)
+ {
[...]
+ errlen = gfc_get_expr_charlen (code-expr2);
+ errmsg = gfc_build_addr_expr (pchar_type_node, se.expr);
+ }
While build_int_cst is not terribly expensive, it also does not come for
free (cf. tree.c); thus, please move the code from before the if into
an else.
+ /* GOTO destinations. */
+ label_errmsg = gfc_build_label_decl (NULL_TREE);
+ label_finish = gfc_build_label_decl (NULL_TREE);
There seems to be a goto missing. For
integer, allocatable :: AA, BB[:], CC
integer :: stat
allocate(CC, AA, stat=stat)
one gets (-fdump-tree-original):
cc = D.1563; /* end of allocation of CC. */
if (stat.0 != 0) goto L.1;
if ((logical(kind=4)) __builtin_expect (aa != 0B, 0))
else
/* Allocate AA. */
If you try
allocate(BB[*], AA, stat=stat)
instead you do not get the if (stat.0 != 0) goto L.1;
Or in English: Assuming one has stat=variable: If you do not have
coarrays, as soon as one allocation fails, one jumps at the end of the
block and the stat variable contains a nonzero value.
If the coarray allocation fails, one continues with other allocations
and thus may end up with stat == 0 although (at least) one (coarray)
allocation has failed.
+ if (status != NULL_TREE)
+ gfc_add_expr_to_block (block,
+fold_build2_loc (input_location, MODIFY_EXPR, status_type,
+ status, build_int_cst (status_type, 0)));
Indent is wrong (should be two spaces, is more as a left over from
removing the { ... }).
+ This function follows the following pseudo-code:
[...]
+ newmem = _caf_register ( size, regtype, NULL,stat, NULL, NULL);
+ if (newmem == NULL)
+ {
+if (!stat requested)
+ runtime_error (Allocation would exceed memory limit);
+ }
+ return newmem;
The if (newmem == NULL) part is not present in the patch - an error is
already printed in _caf_register and thus the check has been removed.
However, the comment has not been updated.
Additionally, you could replace the last two NULLs by errmsg/errmsg_len.
+gfc_allocate_using_lib (stmtblock_t * block, tree size, tree status,
+ tree errmsg, tree errlen)
[...]
+ /* Set the optional status variable to zero. */
+ if (status != NULL_TREE)
+ gfc_add_expr_to_block (block,
+fold_build2_loc (input_location, MODIFY_EXPR, status_type,
+ status, build_int_cst (status_type, 0)));
[...]
+ gfc_add_modify (block, res,
+ fold_convert (prvoid_type_node,
+ build_call_expr_loc (input_location,
+gfor_fndecl_caf_register, 6,
The stat variable is already set in the registering function - no need
to set it to zero before the call.
Tobias
Re: CFT: Move unwinder to toplevel libgcc
Steve, I have successfully bootstrapped and tested the toplevel libgcc patch on IA64 HP-UX. When trying to build IA64 Linux the bootstrap failed with: great, thanks. /bin/sh /wsp/sje/gcc_git/src/gcc/libgcc/../mkinstalldirs ./wsp/sje/gcc_git/build-ia64-debian-linux-gnu-gcc/obj_gcc/./gcc/xgcc -B/wsp/sje/gcc_git/build-ia64-debian-linux-gnu-gcc/obj_gcc/./gcc/ -B/wsp/sje/gcc_git/gcc-ia64-debian-linux-gnu-gcc/ia64-debian-linux-gnu/bin/ -B/wsp/sje/gcc_git/gcc-ia64-debian-linux-gnu-gcc/ia64-debian-linux-gnu/lib/ -isystem /wsp/sje/gcc_git/gcc-ia64-debian-linux-gnu-gcc/ia64-debian-linux-gnu/include -isystem /wsp/sje/gcc_git/gcc-ia64-debian-linux-gnu-gcc/ia64-debian-linux-gnu/sys-include -O2 -g -O2 -DIN_GCC -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -DUSE_GAS_SYMVER -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,-h,libunwind.so.7 -Wl,-z,text -Wl,-z,defs -o /libunwind.so.7.tmp -g -O2 -B./ -lc rm -f / if [ -f /libunwind.so.7 ]; then mv -f /libunwind.so.7 /libunwind.so.7.backup; else true; fi mv /libunwind.so.7.tmp /libunwind.so.7 ln -s libunwind.so.7 / /wsp/sje/gcc_git/gcc-ia64-debian-linux-gnu-gcc/ia64-debian-linux-gnu/bin/ld: cannot open output file /libunwind.so.7.tmp: Permission denied collect2: error: ld returned 1 exit status [...] It looks like a prefix is missing somewhere since it is trying to access /libunwind.so. This may be something messed up in my build area again but I did run autoconf in libgcc so I am not sure what is going on. I'll dig around some more but I thought I would see if this looks familiar to you. It didn't, but I now see what's going on: gcc/config.gcc has *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* | *-*-kopensolaris*-gnu) [...] tmake_file=t-slibgcc-elf-ver t-linux t-slibgcc-elf-ver has the whole shebang necessary to build versioned ELF shared libraries, among others SHLIB_DIR which is missing above. This should be dealt with by using tmake_file=$tmake_file t-slibgcc t-slibgcc-elf-ver in libgcc/config.host. t-linux adds SHLIB_MAPFILES += $(srcdir)/config/libgcc-glibc.ver but there's more SHLIB_* related stuff in the regular gcc/config ia64 t-* files used on ia64*-*-linux*: ia64/t-ia64:SHLIB_MAPFILES += $(srcdir)/config/ia64/libgcc-ia64.ver t-libunwind:SHLIB_LC = -lunwind -lc ia64/t-glibc:SHLIB_MAPFILES += $(srcdir)/config/ia64/libgcc-glibc.ver This seems all so involved and entangled with the t-slibgcc* stuff that it's probably best to keep out of this patch. I'll try to come up with something over the week, either fixing up this patch that it should handle things correctly or splitting it out into its own, either together with the rest of SHLIB_* handling or separate and on top of that. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[RFC] Avoid unnecessary futex_wake syscalls when all threads are busy waiting
Hi!
If lock contention is high, but all locks are held for relatively short time
and no threads actually goes into futex_wait, we still completely
unnecessarily do lots of futex_wake syscalls.
On Linux with futex, our mutexes have 3 states:
0 - unlocked
1 - locked, uncontended
2 - locked, contended
When the initial atomic 0 - 1 change fails, gomp_mutex_slow is called and
from that point onwards the lock is changed into state 2 and handled as
contended, until it is unlocked. State 2 in particular means that
gomp_mutex_unlock will do a futex_wake on it.
The following patch changes it, so that when 0 - 1 change fails, because
the mutex is already in state 1, it will do the userland spinning. If the
spinning times out with no change, it will enter state 2, futex_wait and
continue as before, while if during the spinning the lock became 0, it will
try to change it again atomically from 0 - 1. If that succeeds, it
returns, if it fails because another thread made it into 1, it will do the
spinning again, and any time the mutex becomes 2, it will fall thru into the
old loop. The advantage of this is that if no thread needed to go to sleep,
no futex_wakes will be done.
Additionally I've improved the old loop, from
do
{
int oldval = __sync_val_compare_and_swap (mutex, 1, 2);
if (oldval != 0)
do_wait (mutex, 2);
}
while (!__sync_bool_compare_and_swap (mutex, 0, 2));
into:
while ((oldval = __sync_lock_test_and_set (mutex, 2)))
do_wait (mutex, 2);
which should have the advantage that there is just one atomic insn instead
of two. While __sync_lock_test_and_set isn't a full barrier on all targets,
I hope it doesn't matter, because the inline caller has already done one
__sync_val_compare_and_swap which is a full barrier.
Tested with libgomp testsuite and looked at performance numbers of Sho's
omp_fib.c and libgomp.c/sort-1.c, unfortunately the differences looked to be
in the noise. But, e.g. on omp_fib.c strace -f shows that the number of
futex FUTEX_WAKE syscalls went down a lot (from ~ 75000 for omp_fib 32 down
to ~ 50 with the default wait policy, of course for OMP_WAIT_POLICY=passive
it remained roughly the same).
Any comments? Can anyone see meassurable differences on some benchmark?
2011-07-15 Jakub Jelinek ja...@redhat.com
* config/linux/wait.h (do_spin): New inline, largely copied
from do_wait, just don't do futex_wait here, instead return true if
it should be done.
(do_wait): Implement using do_spin.
* config/linux/mutex.h (gomp_mutex_lock_slow): Add an int argument
to prototype.
(gomp_mutex_lock): Use __sync_val_compare_and_swap instead of
__sync_bool_compare_and_swap, pass the oldval to
gomp_mutex_lock_slow.
* config/linux/mutex.c (gomp_mutex_lock_slow): Add oldval argument.
If all mutex contenders are just spinning and not sleeping, don't
change state to 2 unnecessarily. Optimize the loop when state has
already become 2 to use just one atomic operation per loop instead
of two.
* config/linux/ia64/mutex.h (gomp_mutex_lock_slow): Add an int argument
to prototype.
(gomp_mutex_lock): Use __sync_val_compare_and_swap instead of
__sync_bool_compare_and_swap, pass the oldval to
gomp_mutex_lock_slow.
--- libgomp/config/linux/wait.h.jj 2011-02-15 15:26:05.0 +0100
+++ libgomp/config/linux/wait.h 2011-07-15 09:56:14.0 +0200
@@ -44,7 +44,7 @@ extern long int gomp_futex_wait, gomp_fu
#include futex.h
-static inline void do_wait (int *addr, int val)
+static inline int do_spin (int *addr, int val)
{
unsigned long long i, count = gomp_spin_count_var;
@@ -52,10 +52,16 @@ static inline void do_wait (int *addr, i
count = gomp_throttled_spin_count_var;
for (i = 0; i count; i++)
if (__builtin_expect (*addr != val, 0))
- return;
+ return 0;
else
cpu_relax ();
- futex_wait (addr, val);
+ return 1;
+}
+
+static inline void do_wait (int *addr, int val)
+{
+ if (do_spin (addr, val))
+futex_wait (addr, val);
}
#ifdef HAVE_ATTRIBUTE_VISIBILITY
--- libgomp/config/linux/mutex.h.jj 2009-08-05 11:47:08.0 +0200
+++ libgomp/config/linux/mutex.h2011-07-15 09:29:04.0 +0200
@@ -1,4 +1,4 @@
-/* Copyright (C) 2005, 2009 Free Software Foundation, Inc.
+/* Copyright (C) 2005, 2009, 2011 Free Software Foundation, Inc.
Contributed by Richard Henderson r...@redhat.com.
This file is part of the GNU OpenMP Library (libgomp).
@@ -38,11 +38,12 @@ static inline void gomp_mutex_init (gomp
*mutex = 0;
}
-extern void gomp_mutex_lock_slow (gomp_mutex_t *mutex);
+extern void gomp_mutex_lock_slow (gomp_mutex_t *mutex, int);
static inline void gomp_mutex_lock (gomp_mutex_t *mutex)
{
- if (!__sync_bool_compare_and_swap (mutex, 0, 1))
-gomp_mutex_lock_slow (mutex);
+ int oldval = __sync_val_compare_and_swap (mutex, 0, 1);
+ if
Re: Avoid overriding LIB_THREAD_LDFLAGS_SPEC on Solaris 8 (PR target/49541)
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Installed on mainline, will backport to the 4.6 branch after testing.
Here's the 4.6 branch version I've just installed after
i386-pc-solaris2.8 and sparc-sun-solaris2.8 testing by Eric and myself.
Rainer
2011-07-15 Rainer Orth r...@cebitec.uni-bielefeld.de
Backport from mainline:
2011-07-13 Rainer Orth r...@cebitec.uni-bielefeld.de
PR target/49541
* config/sol2.h (LIB_SPEC): Simplify.
Move LIB_THREAD_LDFLAGS_SPEC ...
(LINK_SPEC): ... here.
diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -132,10 +132,8 @@ along with GCC; see the file COPYING3.
#define LIB_SPEC \
%{compat-bsd:-lucb -lsocket -lnsl -lelf -laio} \
%{!symbolic:\
- %{pthreads|pthread: \
-LIB_THREAD_LDFLAGS_SPEC -lpthread LIB_TLS_SPEC } \
- %{!pthreads:%{!pthread:%{threads: \
- LIB_THREAD_LDFLAGS_SPEC -lthread}}} \
+ %{pthreads|pthread:-lpthread LIB_TLS_SPEC } \
+ %{!pthreads:%{!pthread:%{threads:-lthread}}} \
%{p|pg:-ldl} -lc}
#undef ENDFILE_SPEC
@@ -185,6 +183,7 @@ along with GCC; see the file COPYING3.
%{static:-dn -Bstatic} \
%{shared:-G -dy %{!mimpure-text:-z text}} \
%{symbolic:-Bsymbolic -G -dy -z text} \
+ %{pthreads|pthread|threads: LIB_THREAD_LDFLAGS_SPEC } \
%(link_arch) \
%{Qy:} %{!Qn:-Qy}
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: C6X port 11/11: Testcases
On 05/10/11 17:51, Bernd Schmidt wrote:
This contains the testsuite changes for the C6X port.
Committed this version. No one commented about the changes outside
gcc.target/tic6x, but I think they are reasonably obvious. I'm open to
suggestions for other names for the check_effective_target functions.
Bernd
Index: gcc/testsuite/gcc.target/tic6x/weak-call.c
===
--- gcc/testsuite/gcc.target/tic6x/weak-call.c (revision 0)
+++ gcc/testsuite/gcc.target/tic6x/weak-call.c (revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* { dg-final { scan-assembler-not call\[\\t ]*.s.\[\\t ]*.f } } */
+/* { dg-final { scan-assembler-not call\[\\t ]*.s.\[\\t ]*.g } } */
+
+extern void f () __attribute__ ((weak));
+extern void g () __attribute__ ((weak)) __attribute__ ((noinline));
+
+void g ()
+{
+}
+
+int main ()
+{
+ f ();
+ g ();
+}
Index: gcc/testsuite/gcc.target/tic6x/builtin-math-7.c
===
--- gcc/testsuite/gcc.target/tic6x/builtin-math-7.c (revision 0)
+++ gcc/testsuite/gcc.target/tic6x/builtin-math-7.c (revision 0)
@@ -0,0 +1,94 @@
+/* Copyright (C) 2009 Free Software Foundation.
+
+ Verify that folding of complex mul and div work correctly.
+ TI C6X specific version, reduced by two tests that fails due to the
+ use of implicit -freciprocal-math.
+
+ Origin: Kaveh R. Ghazi, August 13, 2009. */
+
+/* { dg-do run } */
+/* { dg-options -O2 } */
+/* { dg-add-options ieee } */
+
+extern void link_error(int);
+
+/* Evaluate this expression at compile-time. */
+#define COMPILETIME_TESTIT(TYPE,X,OP,Y,RES) do { \
+ if ((_Complex TYPE)(X) OP (_Complex TYPE)(Y) != (_Complex TYPE)(RES)) \
+link_error(__LINE__); \
+} while (0)
+
+/* Use this error function for cases which only evaluate at
+ compile-time when optimizing. */
+#ifdef __OPTIMIZE__
+# define ERROR_FUNC(X) link_error(X)
+#else
+# define ERROR_FUNC(X) __builtin_abort()
+#endif
+
+/* Evaluate this expression at compile-time using static initializers. */
+#define STATICINIT_TESTIT(TYPE,X,OP,Y,RES) do { \
+ static const _Complex TYPE foo = (_Complex TYPE)(X) OP (_Complex TYPE)(Y); \
+ if (foo != (_Complex TYPE)(RES)) \
+ERROR_FUNC (__LINE__); \
+} while (0)
+
+/* Evaluate this expression at runtime. */
+#define RUNTIME_TESTIT(TYPE,X,OP,Y,RES) do { \
+ volatile _Complex TYPE foo; \
+ foo = (_Complex TYPE)(X); \
+ foo OP##= (_Complex TYPE)(Y); \
+ if (foo != (_Complex TYPE)(RES)) \
+__builtin_abort(); \
+} while (0)
+
+/* Evaluate this expression at compile-time and runtime. */
+#define TESTIT(TYPE,X,OP,Y,RES) do { \
+ STATICINIT_TESTIT(TYPE,X,OP,Y,RES); \
+ COMPILETIME_TESTIT(TYPE,X,OP,Y,RES); \
+ RUNTIME_TESTIT(TYPE,X,OP,Y,RES); \
+} while (0)
+
+/* Either the real or imaginary parts should be infinity. */
+#define TEST_ONE_PART_INF(VAL) do { \
+ static const _Complex double foo = (VAL); \
+ if (! __builtin_isinf(__real foo) ! __builtin_isinf(__imag foo)) \
+ERROR_FUNC (__LINE__); \
+ if (! __builtin_isinf(__real (VAL)) ! __builtin_isinf(__imag (VAL))) \
+__builtin_abort(); \
+} while (0)
+
+int main()
+{
+ /* Test some regular finite values. */
+ TESTIT (double, 3.+4.i, *, 2, 6+8i);
+ TESTIT (double, 3.+4.i, /, 2, 1.5+2i);
+ TESTIT (int, 3+4i, *, 2, 6+8i);
+ TESTIT (int, 3+4i, /, 2, 1+2i);
+
+ TESTIT (double, 3.+4.i, *, 2+5i, -14+23i);
+ TESTIT (int, 3+4i, *, 2+5i, -14+23i);
+ TESTIT (int, 30+40i, /, 5i, 8-6i);
+ TESTIT (int, 14+6i, /, 7+3i, 2);
+ TESTIT (int, 8+24i, /, 4+12i, 2);
+
+ /* Test for accuracy. */
+ COMPILETIME_TESTIT (double,
+ (1 + __DBL_EPSILON__ + 1i),
+ *,
+ (1 - __DBL_EPSILON__ + 1i),
+
-4.93038065763132378382330353301741393545754021943139377981e-32+2i);
+
+ /* This becomes (NaN + iInf). */
+#define VAL1 ((_Complex double)__builtin_inf() * 1i)
+
+ /* Test some C99 Annex G special cases. */
+ TEST_ONE_PART_INF ((VAL1) * (VAL1));
+ TEST_ONE_PART_INF ((_Complex double)1 / (_Complex double)0);
+ TEST_ONE_PART_INF ((VAL1) / (_Complex double)1);
+
+ RUNTIME_TESTIT (double, 1, /, VAL1, 0);
+ STATICINIT_TESTIT (double, 1, /, VAL1, 0);
+
+ return 0;
+}
Index: gcc/testsuite/gcc.target/tic6x/fpcmp.c
===
--- gcc/testsuite/gcc.target/tic6x/fpcmp.c (revision 0)
+++ gcc/testsuite/gcc.target/tic6x/fpcmp.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target ti_c67x } */
+/* { dg-options -O2 } */
+/* { dg-final { scan-assembler-times cmpeq.p 4 } } */
+
+double gedf (double x, double y)
+{
+ return x = y;
+}
+
+double ledf (double x, double y)
+{
+ return x = y;
+}
+
+float gesf (float x, float y)
+{
+ return x = y;
+}
+
+float lesf (float x, float y)
+{
+ return x = y;
+}
Index: gcc/testsuite/gcc.target/tic6x/tic6x.exp
Re: [RFC] Avoid unnecessary futex_wake syscalls when all threads are busy waiting
On 07/15/2011 11:37 AM, Jakub Jelinek wrote: While __sync_lock_test_and_set isn't a full barrier on all targets, I hope it doesn't matter, because the inline caller has already done one __sync_val_compare_and_swap which is a full barrier. Why not take the occasion to add the __sync_swap extension that clang added already? Paolo
Re: [RFC] Avoid unnecessary futex_wake syscalls when all threads are busy waiting
On Fri, Jul 15, 2011 at 12:02:06PM +0200, Paolo Bonzini wrote: On 07/15/2011 11:37 AM, Jakub Jelinek wrote: While __sync_lock_test_and_set isn't a full barrier on all targets, I hope it doesn't matter, because the inline caller has already done one __sync_val_compare_and_swap which is a full barrier. Why not take the occasion to add the __sync_swap extension that clang added already? I think Andrew and Aldy are already extending all the __sync_* builtins to have extra argument with required barrier behavior bits for C++ memory model. Jakub
Re: [Patch, Fortran] Allocate + CAF library
On 07/15/2011 10:03 AM, Tobias Burnus wrote:
+ /* ERRMSG= */
+ errmsg = null_pointer_node;
+ errlen = build_int_cst (gfc_charlen_type_node, 0);
+ if (code-expr2)
+ {
[...]
+ errlen = gfc_get_expr_charlen (code-expr2);
+ errmsg = gfc_build_addr_expr (pchar_type_node, se.expr);
+ }
While build_int_cst is not terribly expensive, it also does not come for
free (cf. tree.c); thus, please move the code from before the if into
an else.
Ok. Fixed.
+ /* GOTO destinations. */
+ label_errmsg = gfc_build_label_decl (NULL_TREE);
+ label_finish = gfc_build_label_decl (NULL_TREE);
There seems to be a goto missing. For
integer, allocatable :: AA, BB[:], CC
integer :: stat
allocate(CC, AA, stat=stat)
one gets (-fdump-tree-original):
cc = D.1563; /* end of allocation of CC. */
if (stat.0 != 0) goto L.1;
if ((logical(kind=4)) __builtin_expect (aa != 0B, 0))
else
/* Allocate AA. */
If you try
allocate(BB[*], AA, stat=stat)
instead you do not get the if (stat.0 != 0) goto L.1;
Or in English: Assuming one has stat=variable: If you do not have
coarrays, as soon as one allocation fails, one jumps at the end of the
block and the stat variable contains a nonzero value.
If the coarray allocation fails, one continues with other allocations
and thus may end up with stat == 0 although (at least) one (coarray)
allocation has failed.
This is strange. The problem is definitely in the following if branch in
gfc_trans_array:
if (code-expr1 || code-expr2)
{
/* The coarray library already sets the errmsg. */
if (gfc_option.coarray == GFC_FCOARRAY_LIB
gfc_expr_attr (expr).codimension)
tmp = build1_v (GOTO_EXPR, label_finish);
else
tmp = build1_v (GOTO_EXPR, label_errmsg);
...
}
You see what I'm trying to do here. If the current expression is a
coarray and we are using the coarray lib, the library has already set
the errmsg and we do not want to set it again. That's why there are two
goto destinations. Schematically, it's like this:
label_errmsg:
if (stat != 0) *errmsg = Compiler's default message.;
label_finish:
if (stat != 0) ... write user's stat variable ...;
I other words, the code example that you posted should have two
different GOTO targets. If you are using MPI then BB should be pointing
at label_finish and AA should be pointing at label_errmsg. And if you
are not using MPI, then both should be pointing at label_errmsg.
I'll need some time to think about why this is not working the way I expect.
+ if (status != NULL_TREE)
+ gfc_add_expr_to_block (block,
+ fold_build2_loc (input_location, MODIFY_EXPR, status_type,
+ status, build_int_cst (status_type, 0)));
Indent is wrong (should be two spaces, is more as a left over from
removing the { ... }).
Fixed.
+ This function follows the following pseudo-code:
[...]
+ newmem = _caf_register ( size, regtype, NULL,stat, NULL, NULL);
+ if (newmem == NULL)
+ {
+ if (!stat requested)
+ runtime_error (Allocation would exceed memory limit);
+ }
+ return newmem;
The if (newmem == NULL) part is not present in the patch - an error is
already printed in _caf_register and thus the check has been removed.
However, the comment has not been updated.
Additionally, you could replace the last two NULLs by errmsg/errmsg_len.
Fixed.
+gfc_allocate_using_lib (stmtblock_t * block, tree size, tree status,
+ tree errmsg, tree errlen)
[...]
+ /* Set the optional status variable to zero. */
+ if (status != NULL_TREE)
+ gfc_add_expr_to_block (block,
+ fold_build2_loc (input_location, MODIFY_EXPR, status_type,
+ status, build_int_cst (status_type, 0)));
[...]
+ gfc_add_modify (block, res,
+ fold_convert (prvoid_type_node,
+ build_call_expr_loc (input_location,
+ gfor_fndecl_caf_register, 6,
The stat variable is already set in the registering function - no need
to set it to zero before the call.
Fixed. I tried to clean up the residual code inherited from
allocate_with_status but I missed that part.
Anyway, I'll go think about the GOTOs and figure out what went wrong
there...
Cheers,
Daniel.
--
I'm not overweight, I'm undertall.
Re: C6X port 11/11: Testcases
On Fri, Jul 15, 2011 at 2:44 AM, Bernd Schmidt ber...@codesourcery.com wrote: On 05/10/11 17:51, Bernd Schmidt wrote: This contains the testsuite changes for the C6X port. Committed this version. No one commented about the changes outside gcc.target/tic6x, but I think they are reasonably obvious. I'm open to suggestions for other names for the check_effective_target functions. I think this caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49757 -- H.J.
Re: C6X port 11/11: Testcases
On 07/15/11 14:06, H.J. Lu wrote:
On Fri, Jul 15, 2011 at 2:44 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 05/10/11 17:51, Bernd Schmidt wrote:
This contains the testsuite changes for the C6X port.
Committed this version. No one commented about the changes outside
gcc.target/tic6x, but I think they are reasonably obvious. I'm open to
suggestions for other names for the check_effective_target functions.
I think this caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49757
Fixed.
Bernd
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 176310)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -32,6 +32,10 @@
* gcc.dg/torture/pr37868.c: Skip on tic6x.
* gcc.dg/torture/builtin-math-7.c: Likewise.
+ PR testsuite/49757
+ * gcc/testsuite/gcc.target/tic6x/builtins/c6x-builtins.exp: Return if
+ not testing tic6x-*-*.
+
2011-07-14 Andrew Pinski pins...@gmail.com
PR tree-opt/49309
Index: gcc/testsuite/gcc.target/tic6x/builtins/c6x-builtins.exp
===
--- gcc/testsuite/gcc.target/tic6x/builtins/c6x-builtins.exp(revision
176310)
+++ gcc/testsuite/gcc.target/tic6x/builtins/c6x-builtins.exp(working copy)
@@ -19,6 +19,10 @@
load_lib gcc-dg.exp
+if { ![istarget tic6x-*-*] } then {
+ return
+}
+
dg-init
gcc-dg-runtest [lsort [glob $srcdir/$subdir/*.c]]
dg-finish
Re: [Patch, Fortran] Allocate + CAF library
On 07/15/2011 12:58 PM, Daniel Carrera wrote:
+ label_errmsg = gfc_build_label_decl (NULL_TREE);
+ label_finish = gfc_build_label_decl (NULL_TREE);
There seems to be a goto missing.
This is strange. The problem is definitely in the following if branch
in gfc_trans_array:
if (code-expr1 || code-expr2)
{
Side remark: One actually only needs to take care whether there is a
STAT=. If there is only an ERRMSG=, the code is unreachable as without
STAT= one gets a run-time error, when an error occurs - and if no error
occurs, ERRMSG= is not modified. Thus, one could reduce the code size by
checking only for code-expr1.
/* The coarray library already sets the errmsg. */
if (gfc_option.coarray == GFC_FCOARRAY_LIB
gfc_expr_attr (expr).codimension)
tmp = build1_v (GOTO_EXPR, label_finish);
else
tmp = build1_v (GOTO_EXPR, label_errmsg);
OK, I understand now why. It is a bit convoluted - and it is due to an
existing bug in GCC. All (allocatable) coarrays - including
(allocatable) scalar coarrays are arrays - and arrays are handled in
gfc_array_allocate.
The code to jump over the next items to the final or error label is only
checked in the !gfc_array_allocate loop.
Thus:
- The code for jumping to the label needs to be either in an else
branch or moved out of if branch.
- In the if branch, you can remove all coarray additions - and add a
gcc_assert() to make sure that indeed no coarray enters there.
Seemingly, the if (stat !=0) goto ... for arrays never worked - not
in GCC 4.1, 4.3, 4.4, 4.6 nor in 4.7.
Tobias
PS: Another bug I found when looking at this patch is PR 49775, it is
related to the code, but an independent issue. I think it will probably
better to place it into a different patch. I was wondering whether you
could/would/want to do it after this patch; it should be straight forward.
[v3] libstdc++/49745 (review required for the gthr-posix.h changes)
Hi,
this is what I did in terms of implementing Jon's and Jakub's
suggestions: many thanks to both of you!
The patch should be in general quite conservative and safe, in
particular, the gthr-posix.h changes, which I cannot approve myself,
touch bits only used by libstdc++-v3 + the macro avoiding the
unconditional inclusion of unistd.h, which, according to Jakub's
analysis, should be required only by objc.
I built and tested c++ and its lib and built all languages. Ok?
Thanks,
Paolo.
///
/gcc
2011-07-15 Paolo Carlini paolo.carl...@oracle.com
Jakub Jelinek ja...@redhat.com
Jonathan Wakely jwakely@gmail.com
PR libstdc++/49745
* gthr-posix.h: Do not include unistd.h unconditionally; use
_GTHREADS_ASSUME_POSIX_TIMEOUTS instead of _POSIX_TIMEOUTS.
/libstdc++-v3
2011-07-15 Paolo Carlini paolo.carl...@oracle.com
Jakub Jelinek ja...@redhat.com
PR libstdc++/49745
* acinclude.m4 ([GLIBCXX_CHECK_GTHREADS]): Check separately for
_POSIX_TIMEOUTS and define _GTHREADS_ASSUME_POSIX_TIMEOUTS.
* libstdc++-v3/libsupc++/guard.cc: Include unistd.h.
* testsuite/17_intro/headers/c++1998/49745.cc: New.
* configure: Regenerate.
* config.h.in: Likewise.
Index: libstdc++-v3/libsupc++/guard.cc
===
--- libstdc++-v3/libsupc++/guard.cc (revision 176310)
+++ libstdc++-v3/libsupc++/guard.cc (working copy)
@@ -35,6 +35,7 @@
defined(_GLIBCXX_ATOMIC_BUILTINS_4)
defined(_GLIBCXX_HAVE_LINUX_FUTEX)
# include climits
# include syscall.h
+# include unistd.h
# define _GLIBCXX_USE_FUTEX
# define _GLIBCXX_FUTEX_WAIT 0
# define _GLIBCXX_FUTEX_WAKE 1
Index: libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc
===
--- libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc(revision 0)
+++ libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc(revision 0)
@@ -0,0 +1,22 @@
+// { dg-do compile }
+
+// Copyright (C) 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
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library 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 this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+// libstdc++/49745
+#include iostream
+int truncate = 0;
Index: libstdc++-v3/acinclude.m4
===
--- libstdc++-v3/acinclude.m4 (revision 176310)
+++ libstdc++-v3/acinclude.m4 (working copy)
@@ -3155,6 +3155,22 @@
ac_save_CXXFLAGS=$CXXFLAGS
CXXFLAGS=$CXXFLAGS -fno-exceptions -I${toplevel_srcdir}/gcc
+ AC_MSG_CHECKING([for _POSIX_TIMEOUTS = 0 in unistd.h])
+
+ AC_TRY_COMPILE([#include unistd.h],
+[
+ #if !defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS 0
+ #error
+ #endif
+], [ac_assume_posix_timeouts=yes], [ac_assume_posix_timeouts=no])
+
+ AC_MSG_RESULT([$ac_assume_posix_timeouts])
+
+ if test x$ac_assume_posix_timeouts = xyes; then
+AC_DEFINE(_GTHREADS_ASSUME_POSIX_TIMEOUTS, 1,
+ [Define if _POSIX_TIMEOUT is defined = 0 by unistd.h.])
+ fi
+
target_thread_file=`$CXX -v 21 | sed -n 's/^Thread model: //p'`
case $target_thread_file in
posix)
@@ -3163,7 +3179,10 @@
AC_MSG_CHECKING([for gthreads library])
- AC_TRY_COMPILE([#include gthr.h],
+ AC_TRY_COMPILE([
+ #include gthr.h
+ #include unistd.h
+ ],
[
#ifndef __GTHREADS_CXX0X
#error
Index: gcc/gthr-posix.h
===
--- gcc/gthr-posix.h(revision 176310)
+++ gcc/gthr-posix.h(working copy)
@@ -1,7 +1,7 @@
/* Threads compatibility routines for libgcc2 and libobjc. */
/* Compile this one with gcc. */
/* Copyright (C) 1997, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
- 2008, 2009, 2010 Free Software Foundation, Inc.
+ 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
This file is part of GCC.
@@ -39,7 +39,10 @@
#endif
#include pthread.h
+
+#if defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)
#include unistd.h
+#endif
typedef pthread_t __gthread_t;
typedef pthread_key_t __gthread_key_t;
@@ -100,11 +103,9 @@
__gthrw3(pthread_mutex_lock)
__gthrw3(pthread_mutex_trylock)
-#ifdef _POSIX_TIMEOUTS
-#if _POSIX_TIMEOUTS = 0
+#ifdef
Re: PATCH [5/n] X32: Supprot 32bit address
On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com wrote: TARGET_MEM_REF only works on ptr_mode. That means base and index parts of x86 address operand in x32 mode may be in ptr_mode. This patch supports 32bit base and index parts in x32 mode. OK for trunk? Thanks. H.J. --- 2011-07-09 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_simplify_base_index_disp): New. (ix86_decompose_address): Support 32bit address in x32 mode. (ix86_legitimate_address_p): Likewise. (ix86_fixup_binary_operands): Likewise. Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or maybe also LEGITIMIZE_RELOAD_ADDRESS) ? Uros.
Re: [patch] Fix PR tree-optimization/49038
Ira Rosen wrote: * gcc.dg/vect/pr49038.c: New test. Index: testsuite/gcc.dg/vect/pr49038.c === --- testsuite/gcc.dg/vect/pr49038.c (revision 0) +++ testsuite/gcc.dg/vect/pr49038.c (revision 0) @@ -0,0 +1,38 @@ +#include sys/mman.h +#include stdio.h + +#define COUNT 320 +#define MMAP_SIZE 0x1 +#define ADDRESS 0x112200 +#define TYPE unsigned short This test fails on spu-elf, and presumably all other targets that don't have mmap (or sys/mman.h) ... Can the test be restricted to those targets that actually support that OS feature? Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [PATCH] New IPA-CP with real function cloning
Hi,
On Thu, Jul 14, 2011 at 11:28:32PM +0200, Jan Hubicka wrote:
Well, technically they survive until after inlining (because of
indirect inlining which also derives information from the lattices
corresponding to node-inlined_to node. Results of arithmetic
functions are not going to be accessed during inlining when compiling
any reasonable program but...
Hmm, this sounds bad. We should move it to GTY then incrementally. I however
though that indirect inlining looks only at jump functions, not at lattices?
You are right, that is however basically an omission of mine - it was
supposed to handle the case below but I do not look into the
lattices. I will fix that later.
Nevertheless, the calls to ipa_cst_from_jfunc from
ipa-inline-analyzis.c do access the values of lattices. Potentially
all of them. So I will GTY lattices too.
Thanks,
Martin
/* Verify that simple indirect calls are inlined even without early
inlining.. */
/* { dg-do compile } */
/* { dg-options -O3 -fdump-ipa-inline -fno-early-inlining } */
extern void non_existent(int);
int __attribute__ ((noinline,noclone)) get_input(void)
{
return 1;
}
static void hooray ()
{
non_existent (1);
}
void hip2 (void (*g)())
{
non_existent (2);
g ();
}
static void
__attribute__ ((noinline))
hip1 (void (*f)(void (*)()), void (*g)())
{
non_existent (2);
f (g);
}
int main (int argc, int *argv[])
{
int i;
for (i = 0; i get_input (); i++)
hip1 (hip2, hooray);
return 0;
}
/* { dg-final { scan-ipa-dump hooray\[^\\n\]*inline copy in main inline }
} */
/* { dg-final { scan-ipa-dump hip2\[^\\n\]*inline copy in main inline } }
*/
/* { dg-final { cleanup-ipa-dump inline } } */
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com wrote: TARGET_MEM_REF only works on ptr_mode. That means base and index parts of x86 address operand in x32 mode may be in ptr_mode. This patch supports 32bit base and index parts in x32 mode. OK for trunk? Thanks. H.J. --- 2011-07-09 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_simplify_base_index_disp): New. (ix86_decompose_address): Support 32bit address in x32 mode. (ix86_legitimate_address_p): Likewise. (ix86_fixup_binary_operands): Likewise. Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or maybe also LEGITIMIZE_RELOAD_ADDRESS) ? It is because ix86_decompose_address is also called from: predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); -- H.J.
Re: DOC patch: about gengtype plugins
2011/7/6 Basile Starynkevitch bas...@starynkevitch.net: * doc/plugins.texi (Building GCC plugins): gengtype needs its gtype.state Replace than in the patch with as. I assume it passes make info? OK with that change, thank you. -- Laurynas
Re: [v3] libstdc++/49745 (review required for the gthr-posix.h changes)
On 07/15/2011 08:47 AM, Paolo Carlini wrote: The patch should be in general quite conservative and safe, in particular, the gthr-posix.h changes, which I cannot approve myself, touch bits only used by libstdc++-v3 + the macro avoiding the unconditional inclusion of unistd.h, which, according to Jakub's analysis, should be required only by objc. I'm a little uncomfortable with defining a macro in libstdc++ to be used by the gthr files in gcc. I would lean more toward a gthr-posix-conf.h generated by GCC configure. Jason
Re: [PATCH] New IPA-CP with real function cloning - updated version
Thanks, however, I'm not confident committing this on Friday when I'm going to be offline until Monday noon :-) Moreover, I already have a I will be flying back to Europe, so you even can't push responsibility to me :) newer version that should handle aliases to thunks. The changes since the yesterday's version are: - initialize_node_lattices asserting node has body - propagate_constants_accross_call more sensible with regard to thunks (and aliases). - gather_caller_stats and has_undead_caller_from_outside_scc_p (hooks to cgraph_for_node_and_aliases) are careful about aliases to thunks too. - all cgraph_function_or_thunk_node turned into cgraph_function_node because we should be propagating across these calls fine now. All these changes are only in ipa-cp.c so only that file is verbatim below now (and a traditional context diff in an attachment). I have bootstrapped and profiledbootstrapped and tested a very similar patch on x86_64-linux, bootstrap and profiledbootstrap of exactly this patch underway. I hope this will be OK for trunk on Monday too if both pass. These changes seems fine. I declare the patch OK on Monday then ;)) Honza
Re: [v3] libstdc++/49745 (review required for the gthr-posix.h changes)
On 07/15/2011 03:36 PM, Jason Merrill wrote: I'm a little uncomfortable with defining a macro in libstdc++ to be used by the gthr files in gcc. I would lean more toward a gthr-posix-conf.h generated by GCC configure. For sure, I gonna need some help for that... or maybe Jakub can do it? Paolo.
Re: [v3] libstdc++/49745 (review required for the gthr-posix.h changes)
On Fri, Jul 15, 2011 at 09:36:48AM -0400, Jason Merrill wrote: On 07/15/2011 08:47 AM, Paolo Carlini wrote: The patch should be in general quite conservative and safe, in particular, the gthr-posix.h changes, which I cannot approve myself, touch bits only used by libstdc++-v3 + the macro avoiding the unconditional inclusion of unistd.h, which, according to Jakub's analysis, should be required only by objc. I'm a little uncomfortable with defining a macro in libstdc++ to be used by the gthr files in gcc. I would lean more toward a gthr-posix-conf.h generated by GCC configure. gthr-posix.h already uses other macros defined by other library headers, like _LIBOBJC. gthr-posix-conf.h looks like an overkill to me, but if e.g. libstdc++ headers defined a 0/1 macro always (_GTHREAD_USE_TIMEDLOCK 0 would mean don't define it, _GTHREAD_USE_TIMEDLOCK 1 would mean you can safely assume timedlock is available, and not presence of that macro would lead to inclusion of unistd.h and deciding itself based on _POSIX_TIMEOUTS: #ifndef _GTHREAD_USE_TIMEDLOCK #include unistd.h #ifdef _POSIX_TIMEOUTS #if _POSIX_TIMEOUTS = 0 #define _GTHREAD_USE_TIMEDLOCK 1 #else #define _GTHREAD_USE_TIMEDLOCK 0 #else #define _GTHREAD_USE_TIMEDLOCK 0 #endif and use #if _GTHREAD_USE_TIMEDLOCK ... #endif then when gthr.h is used outside of libstdc++ it wouldn't depend on libstdc++ configury. Jakub
Re: [v3] libstdc++/49745 (review required for the gthr-posix.h changes)
Hi,
gthr-posix.h already uses other macros defined by other library
headers, like _LIBOBJC. gthr-posix-conf.h looks like an overkill to me,
but if e.g. libstdc++ headers defined a 0/1 macro always
(_GTHREAD_USE_TIMEDLOCK 0 would mean don't define it, _GTHREAD_USE_TIMEDLOCK 1
would mean you can safely assume timedlock is available, and not presence
of that macro would lead to inclusion of unistd.h and deciding itself
based on _POSIX_TIMEOUTS:
#ifndef _GTHREAD_USE_TIMEDLOCK
#includeunistd.h
#ifdef _POSIX_TIMEOUTS
#if _POSIX_TIMEOUTS= 0
#define _GTHREAD_USE_TIMEDLOCK 1
#else
#define _GTHREAD_USE_TIMEDLOCK 0
#else
#define _GTHREAD_USE_TIMEDLOCK 0
#endif
and use
#if _GTHREAD_USE_TIMEDLOCK
...
#endif
I'm finishing testing the below. Appears to work well, so far...
Paolo.
/gcc
2011-07-15 Paolo Carlini paolo.carl...@oracle.com
Jakub Jelinek ja...@redhat.com
Jonathan Wakely jwakely@gmail.com
PR libstdc++/49745
* gthr-posix.h: Do not include unistd.h unconditionally; use
_GTHREADS_USE_MUTEX_TIMEDLOCK instead of _POSIX_TIMEOUTS.
/libstdc++-v3
2011-07-15 Paolo Carlini paolo.carl...@oracle.com
Jakub Jelinek ja...@redhat.com
PR libstdc++/49745
* acinclude.m4 ([GLIBCXX_CHECK_GTHREADS]): Check separately for
_POSIX_TIMEOUTS and define _GTHREADS_USE_MUTEX_TIMEDLOCK.
* libstdc++-v3/libsupc++/guard.cc: Include unistd.h.
* testsuite/17_intro/headers/c++1998/49745.cc: New.
* configure: Regenerate.
* config.h.in: Likewise.
Index: libstdc++-v3/libsupc++/guard.cc
===
--- libstdc++-v3/libsupc++/guard.cc (revision 176310)
+++ libstdc++-v3/libsupc++/guard.cc (working copy)
@@ -35,6 +35,7 @@
defined(_GLIBCXX_ATOMIC_BUILTINS_4)
defined(_GLIBCXX_HAVE_LINUX_FUTEX)
# include climits
# include syscall.h
+# include unistd.h
# define _GLIBCXX_USE_FUTEX
# define _GLIBCXX_FUTEX_WAIT 0
# define _GLIBCXX_FUTEX_WAKE 1
Index: libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc
===
--- libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc(revision 0)
+++ libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc(revision 0)
@@ -0,0 +1,22 @@
+// { dg-do compile { target *-*-linux* } }
+
+// Copyright (C) 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
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library 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 this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+// libstdc++/49745
+#include iostream
+int truncate = 0;
Index: libstdc++-v3/acinclude.m4
===
--- libstdc++-v3/acinclude.m4 (revision 176310)
+++ libstdc++-v3/acinclude.m4 (working copy)
@@ -3155,6 +3155,22 @@
ac_save_CXXFLAGS=$CXXFLAGS
CXXFLAGS=$CXXFLAGS -fno-exceptions -I${toplevel_srcdir}/gcc
+ AC_MSG_CHECKING([check whether it can be safely assumed that mutex_timedlock
is available])
+
+ AC_TRY_COMPILE([#include unistd.h],
+[
+ #if !defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS 0
+ #error
+ #endif
+], [ac_gthread_use_mutex_timedlock=1], [ac_gthread_use_mutex_timedlock=0])
+
+ AC_DEFINE_UNQUOTED(_GTHREAD_USE_MUTEX_TIMEDLOCK,
$ac_gthread_use_mutex_timedlock,
+ [Define to 1 if mutex_timedlock is available.])
+
+ if test $ac_gthread_use_mutex_timedlock = 1 ; then res_mutex_timedlock=yes ;
+ else res_mutex_timedlock=no ; fi
+ AC_MSG_RESULT([$res_mutex_timedlock])
+
target_thread_file=`$CXX -v 21 | sed -n 's/^Thread model: //p'`
case $target_thread_file in
posix)
@@ -3163,7 +3179,10 @@
AC_MSG_CHECKING([for gthreads library])
- AC_TRY_COMPILE([#include gthr.h],
+ AC_TRY_COMPILE([
+ #include gthr.h
+ #include unistd.h
+ ],
[
#ifndef __GTHREADS_CXX0X
#error
Index: gcc/gthr-posix.h
===
--- gcc/gthr-posix.h(revision 176310)
+++ gcc/gthr-posix.h(working copy)
@@ -1,7 +1,7 @@
/* Threads compatibility routines for libgcc2 and libobjc. */
/* Compile this one with gcc. */
/* Copyright (C) 1997, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
- 2008, 2009, 2010 Free Software Foundation, Inc.
+ 2008, 2009,
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com wrote: TARGET_MEM_REF only works on ptr_mode. That means base and index parts of x86 address operand in x32 mode may be in ptr_mode. This patch supports 32bit base and index parts in x32 mode. OK for trunk? Thanks. H.J. --- 2011-07-09 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_simplify_base_index_disp): New. (ix86_decompose_address): Support 32bit address in x32 mode. (ix86_legitimate_address_p): Likewise. (ix86_fixup_binary_operands): Likewise. Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or maybe also LEGITIMIZE_RELOAD_ADDRESS) ? It is because ix86_decompose_address is also called from: predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); Yes, but you should legitimize the address created by reload before it enters into predicates. So, the questions are: + (set (reg:SI 40 r11) +(plus:SI (plus:SI (mult:SI (reg:SI 1 dx) + (const_int 8)) + (subreg:SI (plus:DI (reg/f:DI 7 sp) + (const_int CONST1)) 0)) +(const_int CONST2))) + + We translate it into + + (set (reg:SI 40 r11) +(plus:SI (plus:SI (mult:SI (reg:SI 1 dx) + (const_int 8)) + (reg/f:SI 7 sp)) +(const_int [CONST1 + CONST2]))) If the first form of the address is not OK (it does not represent the hardware operation), then it should not enter into the insn stream. This means, that it should be fixed (legitimized) to second form by appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should fix it, since the incorrect address is generated by IRA/reload). After this operation, various predicates, based on ix86_decompose_address will start to work, since they will decompose valid memory addresses. Uros.
New Swedish PO file for 'gcc' (version 4.6.1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-4.6.1.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [RFC] More compact (100x) -g3 .debug_macinfo (take 2)
On Wed, Jul 13, 2011 at 07:00:53PM +0200, Jakub Jelinek wrote:
The patch below implements that slight change, in particular the 4
suffixes from the op names were dropped, DW_MACINFO_GNU_*_indirect
have DW_FORM_udata and DW_FORM_strp arguments now (i.e. DWARF_OFFSET_SIZE
large) and DW_MACINFO_GNU_transparent_include has DW_FORM_sec_offset
argument (i.e. again 4 bytes long for 32-bit DWARF and 8 bytes long for
64-bit DWARF). GCC assures that no merging will happen between
.debug_macinfo chunks with 32-bit and 64-bit DWARF by adding the byte size
in the comdat GROUP name. I think that's cleaner than hardcoding
4 bytes and not optimizing anything on MIPS.
The newly added opcodes:
DW_MACINFO_GNU_define_indirect 0xe0
This opcode has two arguments, one is uleb128 lineno and the
other is offset size long byte offset into .debug_str. Except
for the encoding of the string it is similar to DW_MACINFO_define.
DW_MACINFO_GNU_undef_indirect 0xe1
This opcode has two arguments, one is uleb128 lineno and the
other is offset size long byte offset into .debug_str. Except
for the encoding of the string it is similar to DW_MACINFO_undef.
DW_MACINFO_GNU_transparent_include 0xe2
This opcode has a single argument, a offset size long byte offset into
.debug_macinfo. It instructs the debug info consumer that
this opcode during reading should be replaced with the sequence
of .debug_macinfo opcodes from the mentioned offset, up to
a terminating 0 opcode (not including that 0).
DW_MACINFO_GNU_define_opcode0xe3
This is an opcode for future extensibility through which
a debugger could skip unknown opcodes. It has 3 arguments:
1 byte opcode number, uleb128 count of arguments and
a count bytes long array, with a DW_FORM_* code how the
argument is encoded.
DW_MACINFO_GNU_define_opcode 0, 0 []
DW_MACINFO_GNU_define_opcode DW_MACINFO_define, 2 [DW_FORM_udata,
DW_FORM_string]
DW_MACINFO_GNU_define_opcode DW_MACINFO_undef, 2 [DW_FORM_udata,
DW_FORM_string]
DW_MACINFO_GNU_define_opcode DW_MACINFO_start_file, 2 [DW_FORM_udata,
DW_FORM_udata]
DW_MACINFO_GNU_define_opcode DW_MACINFO_end_file, 1 [DW_FORM_udata]
DW_MACINFO_GNU_define_opcode DW_MACINFO_GNU_define_indirect, 2 [DW_FORM_udata,
DW_FORM_strp]
DW_MACINFO_GNU_define_opcode DW_MACINFO_GNU_undef_indirect, 2 [DW_FORM_udata,
DW_FORM_strp]
DW_MACINFO_GNU_define_opcode DW_MACINFO_GNU_transparent_include, 1
[DW_FORM_sec_offset]
DW_MACINFO_GNU_define_opcode DW_MACINFO_GNU_define_opcode, 2 [DW_FORM_data1,
DW_FORM_block]
DW_MACINFO_GNU_define_opcode DW_MACINFO_vendor_ext, 2 [DW_FORM_udata,
DW_FORM_string]
2011-07-15 Jakub Jelinek ja...@redhat.com
* dwarf2.h (DW_MACINFO_lo_user, DW_MACINFO_hi_user): Add.
(DW_MACINFO_GNU_define_indirect, DW_MACINFO_GNU_undef_indirect,
DW_MACINFO_GNU_transparent_include, DW_MACINFO_GNU_define_opcode):
Add.
* dwarf2out.c (dwarf2out_undef): Remove redundant semicolon.
(htab_macinfo_hash, htab_macinfo_eq, output_macinfo_op): New
functions.
(output_macinfo): Use them. If !dwarf_strict and .debug_str is
mergeable, optimize longer strings using
DW_MACINFO_GNU_{define,undef}_indirect and if HAVE_COMDAT and ELF,
optimize longer sequences of define/undef ops from headers
using DW_MACINFO_GNU_transparent_include.
--- include/dwarf2.h.jj 2011-06-23 10:14:06.0 +0200
+++ include/dwarf2.h2011-07-13 11:39:49.0 +0200
@@ -877,7 +877,13 @@ enum dwarf_macinfo_record_type
DW_MACINFO_undef = 2,
DW_MACINFO_start_file = 3,
DW_MACINFO_end_file = 4,
-DW_MACINFO_vendor_ext = 255
+DW_MACINFO_lo_user = 0xe0,
+DW_MACINFO_GNU_define_indirect = 0xe0,
+DW_MACINFO_GNU_undef_indirect = 0xe1,
+DW_MACINFO_GNU_transparent_include = 0xe2,
+DW_MACINFO_GNU_define_opcode = 0xe3,
+DW_MACINFO_hi_user = 0xfe,
+DW_MACINFO_vendor_ext = 0xff
};
/* @@@ For use with GNU frame unwind information. */
--- gcc/dwarf2out.c.jj 2011-07-12 17:59:01.0 +0200
+++ gcc/dwarf2out.c 2011-07-13 17:04:17.0 +0200
@@ -20383,17 +20383,117 @@ dwarf2out_undef (unsigned int lineno ATT
macinfo_entry e;
e.code = DW_MACINFO_undef;
e.lineno = lineno;
- e.info = xstrdup (buffer);;
+ e.info = xstrdup (buffer);
VEC_safe_push (macinfo_entry, gc, macinfo_table, e);
}
}
+/* Routines to manipulate hash table of CUs. */
+static hashval_t
+htab_macinfo_hash (const void *of)
+{
+ const macinfo_entry *const entry =
+(const macinfo_entry *) of;
+
+ return htab_hash_string (entry-info);
+}
+
+static int
+htab_macinfo_eq (const void *of1, const void *of2)
+{
+ const macinfo_entry *const entry1 = (const macinfo_entry *) of1;
+ const macinfo_entry *const entry2 = (const macinfo_entry *) of2;
+
+ return !strcmp (entry1-info,
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 8:25 AM, Uros Bizjak ubiz...@gmail.com wrote: On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu hongjiu...@intel.com wrote: TARGET_MEM_REF only works on ptr_mode. That means base and index parts of x86 address operand in x32 mode may be in ptr_mode. This patch supports 32bit base and index parts in x32 mode. OK for trunk? Thanks. H.J. --- 2011-07-09 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_simplify_base_index_disp): New. (ix86_decompose_address): Support 32bit address in x32 mode. (ix86_legitimate_address_p): Likewise. (ix86_fixup_binary_operands): Likewise. Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or maybe also LEGITIMIZE_RELOAD_ADDRESS) ? It is because ix86_decompose_address is also called from: predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); Yes, but you should legitimize the address created by reload before it enters into predicates. So, the questions are: + (set (reg:SI 40 r11) + (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) + (const_int 8)) + (subreg:SI (plus:DI (reg/f:DI 7 sp) + (const_int CONST1)) 0)) + (const_int CONST2))) + + We translate it into + + (set (reg:SI 40 r11) + (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) + (const_int 8)) + (reg/f:SI 7 sp)) + (const_int [CONST1 + CONST2]))) If the first form of the address is not OK (it does not represent the hardware operation), then it should not enter into the insn stream. This means, that it should be fixed (legitimized) to second form by appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should fix it, since the incorrect address is generated by IRA/reload). After this operation, various predicates, based on ix86_decompose_address will start to work, since they will decompose valid memory addresses. IRA/.RELOAD isn't prepared to deal with it and it just ICEs. I opened a few GCC bugs on this. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 is one of them. That is why I went this route. -- H.J.
[4.6] Obsolete NetWare support
As discussed, here's the patch that obsoletes NetWare x86 on the 4.6
branch.
Tested by configuring/building on i386-pc-solaris2.11 with --target
i386-pc-netware. As expected, without --enable-obsolete, the build
fails in gcc, with --enable-obsolete, it continues.
Ok for the 4.6 branch?
Rainer
2011-07-15 Rainer Orth r...@cebitec.uni-bielefeld.de
* config.gcc: Obsolete i[3456x]86-*-netware*.
diff --git a/gcc/config.gcc b/gcc/config.gcc
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -240,6 +240,7 @@ case ${target} in
| crx-* \
| i[34567]86-*-interix3* \
| i[34567]86-*-netbsd*\
+ | i[3456x]86-*-netware* \
| i[34567]86-*-pe \
| m68hc11-*-* \
| m6811-*-* \
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC] Avoid unnecessary futex_wake syscalls when all threads are busy waiting
On 07/15/2011 02:37 AM, Jakub Jelinek wrote: Any comments? Can anyone see meassurable differences on some benchmark? 2011-07-15 Jakub Jelinek ja...@redhat.com * config/linux/wait.h (do_spin): New inline, largely copied from do_wait, just don't do futex_wait here, instead return true if it should be done. (do_wait): Implement using do_spin. * config/linux/mutex.h (gomp_mutex_lock_slow): Add an int argument to prototype. (gomp_mutex_lock): Use __sync_val_compare_and_swap instead of __sync_bool_compare_and_swap, pass the oldval to gomp_mutex_lock_slow. * config/linux/mutex.c (gomp_mutex_lock_slow): Add oldval argument. If all mutex contenders are just spinning and not sleeping, don't change state to 2 unnecessarily. Optimize the loop when state has already become 2 to use just one atomic operation per loop instead of two. * config/linux/ia64/mutex.h (gomp_mutex_lock_slow): Add an int argument to prototype. (gomp_mutex_lock): Use __sync_val_compare_and_swap instead of __sync_bool_compare_and_swap, pass the oldval to gomp_mutex_lock_slow. I think that even if the only measurable difference is a reduction in the number of syscalls, that's still an improvement. The patch is ok. r~
[wwwdocs, 4.6] Announce NetWare obsoletion, removal
Corresponding the the NetWare obsoletion and removal (upcoming, currently being tested) patches, here's the wwwdocs change. Ok? Rainer 2011-07-15 Rainer Orth r...@cebitec.uni-bielefeld.de * htdocs/gcc-4.6/changes.html: Document Netware x86 obsoletion. * htdocs/gcc-4.7/changes.html: Document NetWare x86 removal. Index: htdocs/gcc-4.6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/changes.html,v retrieving revision 1.131 diff -u -p -r1.131 changes.html --- htdocs/gcc-4.6/changes.html 27 Jun 2011 09:46:57 - 1.131 +++ htdocs/gcc-4.6/changes.html 15 Jul 2011 15:29:34 - @@ -91,6 +91,7 @@ ul liInterix (codei[34567]86-*-interix3*/code)/li + liNetWare x86 (codei[3456x]86-*-netware*/code)/li liGeneric ARM PE (codearm-*-pe*/code other than codearm*-wince-pe*/code)/li liMCore PE (codemcore-*-pe*/code)/li Index: htdocs/gcc-4.7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.22 diff -u -p -r1.22 changes.html --- htdocs/gcc-4.7/changes.html 15 Jul 2011 09:48:15 - 1.22 +++ htdocs/gcc-4.7/changes.html 15 Jul 2011 15:29:34 - @@ -46,6 +46,9 @@ liThe ARM port's code-mwords-little-endian/code option has been deprecated. It will be removed in a future release./li + +liSupport has been removed for the NetWare x86 configuration +obsoleted in GCC 4.6./li /ul h2General Optimizer Improvements/h2 -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch] Fix PR target/48220 for the SPARC
On 07/14/2011 02:42 PM, Eric Botcazou wrote: PR target/48220 * doc/md.texi (Standard Names): Document window_save. * cfgexpand.c (expand_debug_parm_decl): New function extracted from expand_debug_expr and expand_debug_source_expr. If the target has a window_save instruction, adjust the ENTRY_VALUE_EXP. (expand_debug_expr) SSA_NAME: Call expand_debug_parm_decl if the SSA_NAME_VAR is a parameter. (expand_debug_source_expr) PARM_DECL: Call expand_debug_parm_decl. * var-tracking.c (parm_reg_t): New type and associated vector type. (windowed_parm_regs): New variable. (adjust_insn): If the target has a window_save instruction and this is the instruction, make its effect on parameter registers explicit. (next_non_note_insn_var_location): New function. (emit_notes_in_bb): Use it instead of NEXT_INSN throughout. (vt_add_function_parameter): If the target has a window_save insn, adjust the incoming RTL and record that in windowed_parm_regs. (vt_finalize): Free windowed_parm_regs. Ok. r~
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu hjl.to...@gmail.com wrote: TARGET_MEM_REF only works on ptr_mode. That means base and index parts of x86 address operand in x32 mode may be in ptr_mode. This patch supports 32bit base and index parts in x32 mode. OK for trunk? Thanks. H.J. --- 2011-07-09 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_simplify_base_index_disp): New. (ix86_decompose_address): Support 32bit address in x32 mode. (ix86_legitimate_address_p): Likewise. (ix86_fixup_binary_operands): Likewise. Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or maybe also LEGITIMIZE_RELOAD_ADDRESS) ? It is because ix86_decompose_address is also called from: predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (op, parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts); Yes, but you should legitimize the address created by reload before it enters into predicates. So, the questions are: + (set (reg:SI 40 r11) + (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) + (const_int 8)) + (subreg:SI (plus:DI (reg/f:DI 7 sp) + (const_int CONST1)) 0)) + (const_int CONST2))) + + We translate it into + + (set (reg:SI 40 r11) + (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) + (const_int 8)) + (reg/f:SI 7 sp)) + (const_int [CONST1 + CONST2]))) If the first form of the address is not OK (it does not represent the hardware operation), then it should not enter into the insn stream. This means, that it should be fixed (legitimized) to second form by appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should fix it, since the incorrect address is generated by IRA/reload). After this operation, various predicates, based on ix86_decompose_address will start to work, since they will decompose valid memory addresses. IRA/.RELOAD isn't prepared to deal with it and it just ICEs. I opened a few GCC bugs on this. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 is one of them. That is why I went this route. Hm, but it crashed in postreload pass since the address was not in the legitimate form. This is exactly what LEGITIMIZE_RELOAD_ADDRESS fixes. Did you try to go this route? Uros.
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 9:01 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu hjl.to...@gmail.com wrote:
TARGET_MEM_REF only works on ptr_mode. That means base and index parts
of x86 address operand in x32 mode may be in ptr_mode. This patch
supports 32bit base and index parts in x32 mode. OK for trunk?
Thanks.
H.J.
---
2011-07-09 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c (ix86_simplify_base_index_disp): New.
(ix86_decompose_address): Support 32bit address in x32 mode.
(ix86_legitimate_address_p): Likewise.
(ix86_fixup_binary_operands): Likewise.
Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or
maybe also LEGITIMIZE_RELOAD_ADDRESS) ?
It is because ix86_decompose_address is also called from:
predicates.md: ok = ix86_decompose_address (op, parts);
predicates.md: ok = ix86_decompose_address (op, parts);
predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts);
predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts);
predicates.md: ok = ix86_decompose_address (XEXP (op, 0), parts);
Yes, but you should legitimize the address created by reload before it
enters into predicates.
So, the questions are:
+ (set (reg:SI 40 r11)
+ (plus:SI (plus:SI (mult:SI (reg:SI 1 dx)
+ (const_int 8))
+ (subreg:SI (plus:DI (reg/f:DI 7 sp)
+ (const_int CONST1)) 0))
+ (const_int CONST2)))
+
+ We translate it into
+
+ (set (reg:SI 40 r11)
+ (plus:SI (plus:SI (mult:SI (reg:SI 1 dx)
+ (const_int 8))
+ (reg/f:SI 7 sp))
+ (const_int [CONST1 + CONST2])))
If the first form of the address is not OK (it does not represent the
hardware operation), then it should not enter into the insn stream.
This means, that it should be fixed (legitimized) to second form by
appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should
fix it, since the incorrect address is generated by IRA/reload). After
this operation, various predicates, based on ix86_decompose_address
will start to work, since they will decompose valid memory addresses.
IRA/.RELOAD isn't prepared to deal with it and it just ICEs. I opened
a few GCC bugs on this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
is one of them. That is why I went this route.
Hm, but it crashed in postreload pass since the address was not in the
legitimate form. This is exactly what LEGITIMIZE_RELOAD_ADDRESS
fixes. Did you try to go this route?
It ran into various ICEs like:
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o m.s -mx32 -std=gnu99
-O2 -fPICm.i
m.i: In function \u2018__kernel_rem_pio2\u2019:
m.i:18:1: error: insn does not satisfy its constraints:
(insn 108 106 186 3 (set (reg:SI 40 r11 [207])
(plus:SI (plus:SI (mult:SI (reg:SI 1 dx [205])
(const_int 8 [0x8]))
(subreg:SI (plus:DI (reg/f:DI 7 sp)
(const_int 208 [0xd0])) 0))
(const_int -160 [0xff60]))) m.i:3 251 {*lea_1_x32}
(nil))
m.i:18:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [m.s] Error 1
H.J.
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com wrote:
If the first form of the address is not OK (it does not represent the
hardware operation), then it should not enter into the insn stream.
This means, that it should be fixed (legitimized) to second form by
appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should
fix it, since the incorrect address is generated by IRA/reload). After
this operation, various predicates, based on ix86_decompose_address
will start to work, since they will decompose valid memory addresses.
IRA/.RELOAD isn't prepared to deal with it and it just ICEs. I opened
a few GCC bugs on this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
is one of them. That is why I went this route.
Hm, but it crashed in postreload pass since the address was not in the
legitimate form. This is exactly what LEGITIMIZE_RELOAD_ADDRESS
fixes. Did you try to go this route?
It ran into various ICEs like:
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o m.s -mx32 -std=gnu99
-O2 -fPIC m.i
m.i: In function \u2018__kernel_rem_pio2\u2019:
m.i:18:1: error: insn does not satisfy its constraints:
(insn 108 106 186 3 (set (reg:SI 40 r11 [207])
(plus:SI (plus:SI (mult:SI (reg:SI 1 dx [205])
(const_int 8 [0x8]))
(subreg:SI (plus:DI (reg/f:DI 7 sp)
(const_int 208 [0xd0])) 0))
(const_int -160 [0xff60]))) m.i:3 251 {*lea_1_x32}
(nil))
m.i:18:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [m.s] Error 1
Yes, this is an example from PR I am referring to. Did you try to
define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
Uros.
Re: AMD bdver2 enablement.
On Mon, 11 Jul 2011, harsha.jaga...@amd.com wrote: Is it OK to commit to trunk? Please also think of updating the release notes for GCC 4.7. :-) Gerald
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com wrote:
If the first form of the address is not OK (it does not represent the
hardware operation), then it should not enter into the insn stream.
This means, that it should be fixed (legitimized) to second form by
appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should
fix it, since the incorrect address is generated by IRA/reload). After
this operation, various predicates, based on ix86_decompose_address
will start to work, since they will decompose valid memory addresses.
IRA/.RELOAD isn't prepared to deal with it and it just ICEs. I opened
a few GCC bugs on this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
is one of them. That is why I went this route.
Hm, but it crashed in postreload pass since the address was not in the
legitimate form. This is exactly what LEGITIMIZE_RELOAD_ADDRESS
fixes. Did you try to go this route?
It ran into various ICEs like:
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o m.s -mx32
-std=gnu99
-O2 -fPIC m.i
m.i: In function \u2018__kernel_rem_pio2\u2019:
m.i:18:1: error: insn does not satisfy its constraints:
(insn 108 106 186 3 (set (reg:SI 40 r11 [207])
(plus:SI (plus:SI (mult:SI (reg:SI 1 dx [205])
(const_int 8 [0x8]))
(subreg:SI (plus:DI (reg/f:DI 7 sp)
(const_int 208 [0xd0])) 0))
(const_int -160 [0xff60]))) m.i:3 251 {*lea_1_x32}
(nil))
m.i:18:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [m.s] Error 1
Yes, this is an example from PR I am referring to. Did you try to
define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
I will take a look.
Thanks.
--
H.J.
[PATCH, MELT] Add PRE_GENERICIZE callback support in MELT
Hello, The following patch add support for PLUGIN_PRE_GENERICIZE callback. The add_sysdata_pre_genericize patch add a field (sysdata_pre_genericize) in initial system data, allowing to register a closure to be called on PLUGIN_PRE_GENERICIZE event. This patch must be first applied and a make warmelt-upgrade must be run in order to regenerate generated melt files. The add_pre_genericize_hook patch add a function (in melt-runtime.c) to be called on PLUGIN_PRE_GENERICIZE, which call the closure sysdata_pre_genericize defined by the users. Thanks Pierre Vittet 2011-07-15 Pierre Vittet pier...@pvittet.com * melt-runtime.h (enum FSYDAT*): Add a FSYSDAT_PRE_GENERICIZE field. * melt/warmelt-first.melt (class_system_data): add a sysdata_pre_genericize field. Index: gcc/melt/warmelt-first.melt === --- gcc/melt/warmelt-first.melt (revision 176032) +++ gcc/melt/warmelt-first.melt (working copy) @@ -441,6 +441,8 @@ don't instanciate this class!}# sysdata_stdout ;raw file for stdout sysdata_stderr ;raw file for stderr sysdata_dumpfile ;raw file for dump_file + sysdata_pre_genericize ;closure to be called for PLUGIN_PRE_GENERICIZE: + ;look at gcc/c-decl.c. sysdata_unit_starter ;closure to be called at ;compilation unit start sysdata_unit_finisher;closure to be called at Index: gcc/melt-runtime.h === --- gcc/melt-runtime.h (revision 176032) +++ gcc/melt-runtime.h (working copy) @@ -2324,6 +2324,7 @@ enum FSYSDAT_STDOUT, /* raw boxed file for stdout */ FSYSDAT_STDERR, /* raw boxed file for stderr */ FSYSDAT_DUMPFILE,/* raw boxed file for dump_file */ + FSYSDAT_PRE_GENERICIZE, /* closure for PLUGIN_PRE_GENERICIZE */ FSYSDAT_UNIT_STARTER,/* closure for start of compilation unit */ FSYSDAT_UNIT_FINISHER,/* closure for start of compilation unit */ FSYSDAT_OPTION_SET, /* closure to set options */ 2011-07-15 Pierre Vittet pier...@pvittet.com * melt-runtime.c (melt_really_initialize): Register a new Callback to PLUGIN_PRE_GENERICIZE. (melt_pre_genericize_callback): New function, use field sysdata_pre_genericize to transmit the callbacks. 2011-07-15 Pierre Vittet pier...@pvittet.com * melt-runtime.c (melt_really_initialize): Register a new Callback to PLUGIN_PRE_GENERICIZE. (melt_pre_genericize_callback): New function, use field sysdata_pre_genericize to transmit the callbacks.
[libcpp PATCH] Use source_location where it is due
Hello,
This is a [I believe obvious] cleanup patch that was done while
looking at libcpp. It just uses the source_location typedef in some
function declarations in lieu of unsigned int.
Tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
* directives.c (struct if_stack): Use source_location as type
here.
* include/cpplib.h (struct cpp_callbacks)include, define, undef,
indent, def_pragma, used_define, used_undef: Properly use
source_location as parameter type, rather than unsigned int.
---
libcpp/directives.c |2 +-
libcpp/include/cpplib.h | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libcpp/directives.c b/libcpp/directives.c
index f18c1d6..04db855 100644
--- a/libcpp/directives.c
+++ b/libcpp/directives.c
@@ -32,7 +32,7 @@ along with this program; see the file COPYING3. If not see
struct if_stack
{
struct if_stack *next;
- linenum_type line; /* Line where condition started. */
+ source_location line;/* Line where condition started. */
const cpp_hashnode *mi_cmacro;/* macro name for #ifndef around entire file */
bool skip_elses; /* Can future #else / #elif be skipped? */
bool was_skipping; /* If were skipping on entry. */
diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
index 98fa4bb..a295267 100644
--- a/libcpp/include/cpplib.h
+++ b/libcpp/include/cpplib.h
@@ -491,12 +491,12 @@ struct cpp_callbacks
void (*file_change) (cpp_reader *, const struct line_map *);
void (*dir_change) (cpp_reader *, const char *);
- void (*include) (cpp_reader *, unsigned int, const unsigned char *,
+ void (*include) (cpp_reader *, source_location, const unsigned char *,
const char *, int, const cpp_token **);
- void (*define) (cpp_reader *, unsigned int, cpp_hashnode *);
- void (*undef) (cpp_reader *, unsigned int, cpp_hashnode *);
- void (*ident) (cpp_reader *, unsigned int, const cpp_string *);
- void (*def_pragma) (cpp_reader *, unsigned int);
+ void (*define) (cpp_reader *, source_location, cpp_hashnode *);
+ void (*undef) (cpp_reader *, source_location, cpp_hashnode *);
+ void (*ident) (cpp_reader *, source_location, const cpp_string *);
+ void (*def_pragma) (cpp_reader *, source_location);
int (*valid_pch) (cpp_reader *, const char *, int);
void (*read_pch) (cpp_reader *, const char *, int, const char *);
missing_header_cb missing_header;
@@ -513,8 +513,8 @@ struct cpp_callbacks
/* Callbacks for when a macro is expanded, or tested (whether
defined or not at the time) in #ifdef, #ifndef or defined. */
- void (*used_define) (cpp_reader *, unsigned int, cpp_hashnode *);
- void (*used_undef) (cpp_reader *, unsigned int, cpp_hashnode *);
+ void (*used_define) (cpp_reader *, source_location, cpp_hashnode *);
+ void (*used_undef) (cpp_reader *, source_location, cpp_hashnode *);
/* Called before #define and #undef or other macro definition
changes are processed. */
void (*before_define) (cpp_reader *);
--
Dodji
Re: [RFC] More compact (100x) -g3 .debug_macinfo (take 2)
On 07/15/2011 08:42 AM, Jakub Jelinek wrote:
The newly added opcodes:
DW_MACINFO_GNU_define_indirect0xe0
This opcode has two arguments, one is uleb128 lineno and the
other is offset size long byte offset into .debug_str. Except
for the encoding of the string it is similar to DW_MACINFO_define.
DW_MACINFO_GNU_undef_indirect 0xe1
This opcode has two arguments, one is uleb128 lineno and the
other is offset size long byte offset into .debug_str. Except
for the encoding of the string it is similar to DW_MACINFO_undef.
DW_MACINFO_GNU_transparent_include0xe2
This opcode has a single argument, a offset size long byte offset into
.debug_macinfo. It instructs the debug info consumer that
this opcode during reading should be replaced with the sequence
of .debug_macinfo opcodes from the mentioned offset, up to
a terminating 0 opcode (not including that 0).
DW_MACINFO_GNU_define_opcode 0xe3
This is an opcode for future extensibility through which
a debugger could skip unknown opcodes. It has 3 arguments:
1 byte opcode number, uleb128 count of arguments and
a count bytes long array, with a DW_FORM_* code how the
argument is encoded.
I do like the new opcodes.
Elsewhere you described transparent_include as also saving state
about defined opcodes around the include. Do you want to either
describe that or drop it?
+ case DW_MACINFO_define:
+ case DW_MACINFO_undef:
+#ifdef OBJECT_FORMAT_ELF
+ if (!dwarf_strict
+HAVE_COMDAT_GROUP
+VEC_length (macinfo_entry, files) != 1
+i 0
+i + 1 length
+VEC_index (macinfo_entry, macinfo_table, i - 1)-code == 0)
+ {
+ char linebuf[sizeof (HOST_WIDE_INT) * 3 + 1];
+ unsigned char checksum[16];
+ struct md5_ctx ctx;
I'd like to see this broken out into some functions, and avoid
as much code as possible within ifdefs. Perhaps
some_function (...)
{
#ifndef OBJECT_FORMAT_ELF
return;
#endif
// everything else
}
I think it also doesn't help review that there are no comments
at all, and a preponderance of description-less variable names
like ref and ref2.
r~
Re: [PATCH, MELT] Add PRE_GENERICIZE callback support in MELT
Le 15 juil. 2011 à 18:17, Pierre Vittet a écrit : Hello, The following patch add support for PLUGIN_PRE_GENERICIZE callback. The add_sysdata_pre_genericize patch add a field (sysdata_pre_genericize) in initial system data, allowing to register a closure to be called on PLUGIN_PRE_GENERICIZE event. This patch must be first applied and a make warmelt-upgrade must be run in order to regenerate generated melt files. The add_pre_genericize_hook patch add a function (in melt-runtime.c) to be called on PLUGIN_PRE_GENERICIZE, which call the closure sysdata_pre_genericize defined by the users. Thanks Pierre Vittet add_sysdata_pre_genericize-176032.ChangeLogadd_sysdata_pre_genericize-176032.diffadd_pre_genericize_hook-176032.ChangeLogadd_pre_genericize_hook-176032.ChangeLog~ Great ! You forgot to attach the patch for melt-runtime.c (there is only the changelog) I know your performing some simple static analysis, mostly based on matching some c source code patterns (check that there is a if (fopen_result) just after a fopen. Is there a particular reason to do that as a pass (so at the gimple level) rather that doing it just after the function has been parsed (eg upon PLUGIN_PRE_GENERICIZE) ?
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com wrote:
If the first form of the address is not OK (it does not represent the
hardware operation), then it should not enter into the insn stream.
This means, that it should be fixed (legitimized) to second form by
appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should
fix it, since the incorrect address is generated by IRA/reload). After
this operation, various predicates, based on ix86_decompose_address
will start to work, since they will decompose valid memory addresses.
IRA/.RELOAD isn't prepared to deal with it and it just ICEs. I opened
a few GCC bugs on this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
is one of them. That is why I went this route.
Hm, but it crashed in postreload pass since the address was not in the
legitimate form. This is exactly what LEGITIMIZE_RELOAD_ADDRESS
fixes. Did you try to go this route?
It ran into various ICEs like:
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o m.s -mx32
-std=gnu99
-O2 -fPIC m.i
m.i: In function \u2018__kernel_rem_pio2\u2019:
m.i:18:1: error: insn does not satisfy its constraints:
(insn 108 106 186 3 (set (reg:SI 40 r11 [207])
(plus:SI (plus:SI (mult:SI (reg:SI 1 dx [205])
(const_int 8 [0x8]))
(subreg:SI (plus:DI (reg/f:DI 7 sp)
(const_int 208 [0xd0])) 0))
(const_int -160 [0xff60]))) m.i:3 251 {*lea_1_x32}
(nil))
m.i:18:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [m.s] Error 1
Yes, this is an example from PR I am referring to. Did you try to
define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
They make things even more complex. ix86_simplify_base_index_disp
is called after reload is done since we can do this translation safely
only on hard registers, not on pseudo registers.
--
H.J.
Re: Remove NetWare support
Paolo Bonzini bonz...@gnu.org writes:
On 07/14/2011 08:40 PM, Rainer Orth wrote:
I've got a preliminary NetWare removal patch ready (yet untested), but
have a couple of questions:
* Given that there's a considerable amount of NetWare support still in
src, toplevel support has to stay. On the other hand, the reference
in config/elf.m4 is only used for the LTO plugin and can go, I
believe.
* The i386 port has some code that seems to be NetWare-specific, namely
KEEP_AGGREGATE_RETURN_POINTER, ix86_keep_aggregate_return_pointer and
the callee_pop_aggregate_return attribute. I'm uncertain if all this
can go now.
* There are references to config/i386/netware.h in gcc/po/*.po. Do I
need to do anything about this when netware.h is removed?
Since Netware is an x86-only port, I'll leave approval to x86 maintainers.
Ok. Here's the final patch. In the meantime, I've found that the
callee_pop_aggregate_return attribute is used for Windows targets, so
I'm only removing the netware reference in extend.texi.
After this patch, the only netware references in-tree are from toplevel
configure.ac (still needed for the netware support in src), config.sub
(from upstream), and gcc/po/*.po for config/i386/netware.h.
Bootstrapped without regressions on i386-pc-solaris2.10 and
x86_64-unknown-linux-gnu.
Ok for mainline?
Rainer
diff --git a/config/elf.m4 b/config/elf.m4
--- a/config/elf.m4
+++ b/config/elf.m4
@@ -1,4 +1,4 @@
-dnl Copyright (C) 2010 Free Software Foundation, Inc.
+dnl Copyright (C) 2010, 2011 Free Software Foundation, Inc.
dnl This file is free software, distributed under the terms of the GNU
dnl General Public License. As a special exception to the GNU General
dnl Public License, this file may be distributed as part of a program
@@ -14,7 +14,7 @@ AC_REQUIRE([AC_CANONICAL_TARGET])
target_elf=no
case $target in
*-darwin* | *-aix* | *-cygwin* | *-mingw* | *-aout* | *-*coff* | \
- *-msdosdjgpp* | *-netware* | *-vms* | *-wince* | *-*-pe* | \
+ *-msdosdjgpp* | *-vms* | *-wince* | *-*-pe* | \
alpha*-dec-osf* | *-interix* | hppa[[12]]*-*-hpux*)
target_elf=no
;;
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -27,7 +27,7 @@ LIST = alpha-linux-gnu alpha-freebsd6 al
i486-freebsd4 i686-freebsd6 i686-kfreebsd-gnu \
i686-netbsdelf9 i686-knetbsd-gnu i686-openbsd i686-openbsd3.0 \
i686-elf i686-kopensolaris-gnu i686-symbolics-gnu i686-pc-msdosdjgpp \
- i686-lynxos i586-netwareOPT-with-ld=SCRIPTSnwld i686-nto-qnx \
+ i686-lynxos i686-nto-qnx \
i686-rtems i686-solaris2.10 i686-wrs-vxworks \
i686-wrs-vxworksae \
i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \
@@ -72,7 +72,7 @@ LOGFILES = $(patsubst %,log/%-make.out,$
all: $(LOGFILES)
config: $(LIST)
-.PHONY: make-log-dir make-script-dir all config
+.PHONY: make-log-dir all config
empty=
@@ -81,14 +81,7 @@ empty=
make-log-dir: ../gcc/MAINTAINERS
mkdir log
-# The 'ix86-netware --with-ld=nwld' configuration needs a nwld executable to
-# configure. See PR47104.
-make-script-dir:
- mkdir scripts
- echo ld $* scripts/nwld
- chmod u+x scripts/nwld
-
-$(LIST): make-log-dir make-script-dir
+$(LIST): make-log-dir
-mkdir $@
(cd $@ \
../../gcc/configure \
diff --git a/gcc/config.gcc b/gcc/config.gcc
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1364,25 +1364,6 @@ i[34567]86-*-lynxos*)
gnu_ld=yes
gas=yes
;;
-i[3456x]86-*-netware*)
- tm_file=${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h tm-dwarf2.h
i386/netware.h
- tmake_file=${tmake_file} i386/t-netware
- extra_objs=netware.o
- extra_options=${extra_options} i386/netware.opt
- case /${with_ld} in
- */nwld)
- extra_objs=$extra_objs nwld.o
- tm_file=${tm_file} i386/nwld.h
- tmake_file=${tmake_file} i386/t-nwld t-slibgcc-dummy
- ;;
- esac
- case x${enable_threads} in
- x | xyes | xposix) thread_file='posix';;
- xnks) thread_file='nks';;
- xno) ;;
- *) echo 'Unknown thread configuration for NetWare' 2; exit 1;;
- esac
- ;;
i[34567]86-*-nto-qnx*)
tm_file=${tm_file} i386/att.h dbxelf.h tm-dwarf2.h elfos.h i386/unix.h
i386/nto.h
extra_options=${extra_options} i386/nto.opt
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -31431,8 +31431,7 @@ ix86_md_asm_clobbers (tree outputs ATTRI
return clobbers;
}
-/* Implements target vector targetm.asm.encode_section_info. This
- is not used by netware. */
+/* Implements target vector targetm.asm.encode_section_info. */
static void ATTRIBUTE_UNUSED
ix86_encode_section_info (tree decl, rtx rtl, int first)
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
--- a/gcc/config/i386/i386.h
+++
Re: C6X FP testcase fixes
On Jul 15, 2011, at 4:09 AM, Bernd Schmidt wrote: This fixes a number of testsuite failures on C6X for targets with floating point hardware. The hardware has the following quirks: * Divide is implemented using reciprocals; TI requested a default of -freciprocal-math * Multiply, comparison and conversion instructions treat denormal inputs as zero. Ok? Ok. I'm hoping someone might have a more elegant way to handle gcc/testsuite/gcc.c-torture/execute/ieee/mzero2.c. I don't have any specific suggestion, which is why I'm approving it. If someone has of a better way to handle it, feel free to check in a better version. :-) Watch for reviews by fp-type people... I'd defer to them...
[MELT] Several build fix
Hello, Here is a little patch that fix build on my red hat system. It should work for both the plugin and the branch version (although i could not generate the new plugin because upgrade-warmelt require unifdef that i don't have on my system, so the plugin version has not been tested directly from the branch source tarball). Please check if it still work for you, i may have broken things ! (this includes @Basile Do not read this until you're back from your vacation. I've corrected the bug dealing with unfound c sources files to build existing module so files I have also added a -Wno-error switch in the check-melt-runtime so that it doesn't break the whole build (as it uses -Werror by default on my system). But this should be only a temporary workaround, as you noticed some days warmelt-ana-simple detects bugs in the runtime, and this should be corrected. There is mostly meltgc_* functions that do no declare a MELT_ENTERFRAME. I don't really understand why and when there is a need for such, so i let you correct that. When it's done, do not forget to remove the -Wno-error switch. The plugin version should now be a little bit more configurable thanks to variable ?= value assignements. In particular, we can use a custom gcc and not the one in PATH, and add some library includes thanks to LIBS_INCLUDEFLAGS (useful when ppl is not in the default include directory for example). I will now try to patch the trunk to build twice and install gengtype when plugins are available. build.diff Description: Binary data build.Changelog Description: Binary data
Re: [MELT] Several build fix
Le 15 juil. 2011 à 19:25, Romain Geissler a écrit : Please check if it still work for you, i may have broken things ! Please try with clean installs (ie install gcc in a whole new directory for the branch or remove any previous melt related files for a plugin install). (this includes This patch includes the previous one dealing with build issues from Pierre Vittet.
RE: [PING] [PATCH, libstdc++-v3] Add newlib specific ctype_members.cc
Hi Paolo, -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Yufeng Zhang Sent: 01 July 2011 18:00 To: 'Paolo Carlini' Cc: gcc-patches@gcc.gnu.org; libstd...@gcc.gnu.org Subject: RE: [PING] [PATCH, libstdc++-v3] Add newlib specific ctype_members.cc Hi Paolo, Thank you for the review. Ping for: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00440.html personally, I have only minor comments, like only 2011 as Copyright year for new files, and please also regtest on a gnu-linux system. I've updated the Copyright year and removed the regenerated file from the patch. The updated patch is attached. I've also run the regtest on x86_64-linux-gnu. Before going ahead, however, you should send the patch also to the libstdc++ mailing list (this is the rule for v3 patches) and make sure the other maintainers don't have further comments. Wait, say, at least a couple of days. Sorry for missing the rule previously. I sent the patch to the libstdc++ mailing list yesterday; see http://gcc.gnu.org/ml/libstdc++/2011-06/msg00091.html I've also added the mailing list to the CC list. I'll wait a few days to see if there is any more comment. There is no more comment received. I wonder if it is OK to get the patch committed. I have write after approval to GCC, but I'm not sure if that applies to libstdc++-v3 or not. If you think the patch is OK, can you please help me commit it? If you think I can/shall commit it by myself, please let me know. Thanks, Yufeng P.S. I have re-verified the patch on the tip of the trunk today.
Re: [PING] [PATCH, libstdc++-v3] Add newlib specific ctype_members.cc
On 07/15/2011 07:30 PM, Yufeng Zhang wrote: There is no more comment received. I wonder if it is OK to get the patch committed. What else? I thought you had already committed it ;) Paolo.
Re: C6X port 11/11: Testcases
On Jul 15, 2011, at 2:44 AM, Bernd Schmidt wrote: Committed this version. No one commented about the changes outside gcc.target/tic6x, but I think they are reasonably obvious. I'm open to suggestions for other names for the check_effective_target functions. They look fine. For gcc.dg/torture/builtin-math-7.c, I'd prefer a 1 line comment on why skipping it. Something short and sweet, no denorms or some such. This lets people that fall into the same conceptual category as you quickly discover that and also skip.
Re: Remove NetWare support
On 07/15/2011 10:19 AM, Rainer Orth wrote: After this patch, the only netware references in-tree are from toplevel configure.ac (still needed for the netware support in src), config.sub (from upstream), and gcc/po/*.po for config/i386/netware.h. Bootstrapped without regressions on i386-pc-solaris2.10 and x86_64-unknown-linux-gnu. Ok for mainline? Ok by me. r~
Re: [RFC] More compact (100x) -g3 .debug_macinfo (take 2)
Jakub == Jakub Jelinek ja...@redhat.com writes: Jakub The patch below implements that slight change, in particular the Jakub 4 suffixes from the op names were dropped, Jakub DW_MACINFO_GNU_*_indirect have DW_FORM_udata and DW_FORM_strp Jakub arguments now (i.e. DWARF_OFFSET_SIZE large) and Jakub DW_MACINFO_GNU_transparent_include has DW_FORM_sec_offset Jakub argument (i.e. again 4 bytes long for 32-bit DWARF and 8 bytes Jakub long for 64-bit DWARF). GCC assures that no merging will happen Jakub between .debug_macinfo chunks with 32-bit and 64-bit DWARF by Jakub adding the byte size in the comdat GROUP name. I think that's Jakub cleaner than hardcoding 4 bytes and not optimizing anything on Jakub MIPS. The .debug_macinfo section doesn't have any header describing its contents. How would a consumer know which offset size to use? Tom
[committed] Fix invalid SImode constant int generated by PA backend
This fixes ICE in combine caused by an invalid constant for SImode.
We should have been using gen_int_mode. A similar fix was applied
on arm a few months ago.
This is a regression caused by my rewrite of casesi a few years ago.
Other uses of GEN_INT in pa.md need to be reviewed. I think there
are a few more uses that need to be changed.
Tested on hppa64-hp-hpux11.11. Committed to 4.5, 4.6 and trunk.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2011-07-15 John David Anglin dave.ang...@nrc-cnrc.gc.ca
PR target/49723
* config/pa/pa.md (casesi): Use gen_int_mode instead of GEN_INT.
Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 176272)
+++ config/pa/pa.md (working copy)
@@ -6913,7 +6913,7 @@
{
rtx index = gen_reg_rtx (SImode);
- operands[1] = GEN_INT (-INTVAL (operands[1]));
+ operands[1] = gen_int_mode (-INTVAL (operands[1]), SImode);
if (!INT_14_BITS (operands[1]))
operands[1] = force_reg (SImode, operands[1]);
emit_insn (gen_addsi3 (index, operands[0], operands[1]));
Re: [RFC] More compact (100x) -g3 .debug_macinfo (take 2)
On Fri, Jul 15, 2011 at 12:15:48PM -0600, Tom Tromey wrote: Jakub == Jakub Jelinek ja...@redhat.com writes: Jakub The patch below implements that slight change, in particular the Jakub 4 suffixes from the op names were dropped, Jakub DW_MACINFO_GNU_*_indirect have DW_FORM_udata and DW_FORM_strp Jakub arguments now (i.e. DWARF_OFFSET_SIZE large) and Jakub DW_MACINFO_GNU_transparent_include has DW_FORM_sec_offset Jakub argument (i.e. again 4 bytes long for 32-bit DWARF and 8 bytes Jakub long for 64-bit DWARF). GCC assures that no merging will happen Jakub between .debug_macinfo chunks with 32-bit and 64-bit DWARF by Jakub adding the byte size in the comdat GROUP name. I think that's Jakub cleaner than hardcoding 4 bytes and not optimizing anything on Jakub MIPS. The .debug_macinfo section doesn't have any header describing its contents. How would a consumer know which offset size to use? The same way as it knows how to interpret the second operands of DW_MACINFO_start_file. They aren't meaningful without knowing what .debug_line section they refer to. For .debug_line, you need to remember DW_AT_stmt_list of the CU that refers to the .debug_macinfo section through DW_AT_macro_info, and you'd remember whether the referencing CU is 32-bit DWARF or 64-bit DWARF. And the producer would need to arange that DW_MACINFO_GNU_transparent_include referenced chunks have the same properties (i.e. same offset size, and, if they use DW_MACINFO_start_file, also the same .debug_line). Jakub
Re: [libcpp PATCH] Use source_location where it is due
Dodji == Dodji Seketeli do...@redhat.com writes: Dodji libcpp/ Dodji * directives.c (struct if_stack): Use source_location as type Dodji here. Dodji * include/cpplib.h (struct cpp_callbacks)include, define, undef, Dodji indent, def_pragma, used_define, used_undef: Properly use Dodji source_location as parameter type, rather than unsigned int. Ok. Tom
Re: [RFC] More compact (100x) -g3 .debug_macinfo (take 2)
Jakub == Jakub Jelinek ja...@redhat.com writes: The .debug_macinfo section doesn't have any header describing its contents. How would a consumer know which offset size to use? Jakub The same way as it knows how to interpret the second operands of Jakub DW_MACINFO_start_file. Ok, duh. I updated my gdb patch. I can send it if you want. Tom
Re: [Patch, Fortran] Allocate + CAF library
On 07/15/2011 02:16 PM, Tobias Burnus wrote:
if (code-expr1 || code-expr2)
{
Side remark: One actually only needs to take care whether there is a
STAT=. If there is only an ERRMSG=, the code is unreachable as without
STAT= one gets a run-time error, when an error occurs - and if no error
occurs, ERRMSG= is not modified. Thus, one could reduce the code size by
checking only for code-expr1.
Ok.
/* The coarray library already sets the errmsg. */
if (gfc_option.coarray == GFC_FCOARRAY_LIB
gfc_expr_attr (expr).codimension)
tmp = build1_v (GOTO_EXPR, label_finish);
else
tmp = build1_v (GOTO_EXPR, label_errmsg);
OK, I understand now why. It is a bit convoluted - and it is due to an
existing bug in GCC. All (allocatable) coarrays - including
(allocatable) scalar coarrays are arrays - and arrays are handled in
gfc_array_allocate.
The code to jump over the next items to the final or error label is only
checked in the !gfc_array_allocate loop.
Thus:
- The code for jumping to the label needs to be either in an else
branch or moved out of if branch.
- In the if branch, you can remove all coarray additions - and add a
gcc_assert() to make sure that indeed no coarray enters there.
There are two if-branches and I'm not sure which one you are talking
about. But let me tell you what I think we should do and you can tell me
if we are on the same page:
I think we should move the entire if (code-expr1 ...) block outside
the if (!gfc_array_allocate) block. In other words, I propose this:
if (!gfc_array_allocate (se, expr, stat, errmsg, errlen))
{
... allocate scalar ...
}
if (code-expr1)
{
/* The coarray library already sets the errmsg. */
if (gfc_option.coarray == GFC_FCOARRAY_LIB
gfc_expr_attr (expr).codimension)
tmp = build1_v (GOTO_EXPR, label_finish);
else
tmp = build1_v (GOTO_EXPR, label_errmsg);
...
}
My thinking is that this error checking applies equally whether the we
use gfc_array_allocate or not. If we call gfc_array_allocate we still
have stat, we still have errmsg, and we still may or may not call the
coarray library. And I see nothing inside gfc_array_allocate that covers
stat= and errmsg=.
What do you think?
Seemingly, the if (stat !=0) goto ... for arrays never worked - not in
GCC 4.1, 4.3, 4.4, 4.6 nor in 4.7.
That would make sense if arrays always went into gfc_array_allocate. In
that case, I think that my proposed change above would fix the problem.
PS: Another bug I found when looking at this patch is PR 49775, it is
related to the code, but an independent issue. I think it will probably
better to place it into a different patch. I was wondering whether you
could/would/want to do it after this patch; it should be straight forward.
Yes, I'd like to do that next. It's very much related to what I've been
doing lately. I think I even remember noticing that the code deallocated
the previous array and was wondering why it did that.
Cheers,
Daniel.
--
I'm not overweight, I'm undertall.
Re: [v3] libstdc++/49745 (review required for the gthr-posix.h changes)
This is OK. Jason
Re: PATCH to support running the G++ testsuite in C++0x mode
On 07/13/2011 04:28 PM, Jason Merrill wrote:
I'm using --tool_opts to pass the extra -std=c++0x argument to the
compiler. Previously in my own testing I've used
--target_board=unix/-std=c++0x, but that is problematic because options
from --target_board come after options from dg-options, leading to
spurious failures on tests that explicitly specify -std=c++98. I also
considered using the --additional_options flag which lib/g++.exp tries
to support, but it doesn't work (runtest.exp treats any --a* as --all)
and in any case is redundant with --tool_opts.
Unfortunately, a bug in dejagnu means that --tool_opts breaks multilib
support; see the URL in the patch and GCC bug 49741. So I've
resurrected --additional_options, renamed to --extra_opts because
runtest.exp will let that through.
Applying to trunk.
commit 15b873c04c2fdeee0b988c89c54bc2183f92a2ac
Author: Jason Merrill ja...@redhat.com
Date: Wed Jul 13 18:13:56 2011 -0400
* Makefile.in (check-c++): Move check-gcc-c++0x after
check-target-libstdc++-v3.
gcc/
* Makefile.in ($(lang_checks_parallelized)): Allow --extra_opts
rather than --tool_opts.
gcc/cp/
* Make-lang.in (check-c++0x): Use --extra_opts instead of--tool_opts.
gcc/testsuite/
* lib/g++.exp (${tool}_option_help, ${tool}_option_proc): Restore.
Use --extra_opts instead of --additional_options.
diff --git a/Makefile.in b/Makefile.in
index 506d26e..0d40358 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -40157,7 +40157,7 @@ check-gcc-c++0x:
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS) \
(cd gcc $(MAKE) $(GCC_FLAGS_TO_PASS) check-c++0x);
-check-c++: check-gcc-c++ check-gcc-c++0x check-target-libstdc++-v3
+check-c++: check-gcc-c++ check-target-libstdc++-v3 check-gcc-c++0x
.PHONY: check-gcc-fortran check-fortran
check-gcc-fortran:
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 0fded4e..47e14fa 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -5019,7 +5019,7 @@ check_p_subdirs=$(wordlist 1,$(words $(check_$*_parallelize)),$(check_p_numbers)
# For parallelized check-% targets, this decides whether parallelization
# is desirable (if -jN is used and RUNTESTFLAGS doesn't contain anything
-# but optional --target_board or --tool_opts arguments). If it is desirable,
+# but optional --target_board or --extra_opts arguments). If desirable,
# recursive make is run with check-parallel-$lang{,1,2,3,4,5} etc. goals,
# which can be executed in parallel, as they are run in separate directories.
# check-parallel-$lang{1,2,3,4,5} etc. goals invoke runtest with the longest
@@ -5036,7 +5036,7 @@ check_p_subdirs=$(wordlist 1,$(words $(check_$*_parallelize)),$(check_p_numbers)
# to lang_checks_parallelized variable and define check_$lang_parallelize
# variable (see above check_gcc_parallelize description).
$(lang_checks_parallelized): check-% : site.exp
- @if [ -z $(filter-out --target_board=%,$(filter-out --tool_opts%,$(RUNTESTFLAGS))) ] \
+ @if [ -z $(filter-out --target_board=%,$(filter-out --extra_opts%,$(RUNTESTFLAGS))) ] \
[ $(filter -j, $(MFLAGS)) = -j ]; then \
$(MAKE) TESTSUITEDIR=$(TESTSUITEDIR) RUNTESTFLAGS=$(RUNTESTFLAGS) \
check-parallel-$* \
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index b9251a4..ad466b2 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -151,7 +151,7 @@ c++.srcman: doc/g++.1
check-c++ : check-g++
# Run the testsute in C++0x mode.
check-c++0x:
- $(MAKE) RUNTESTFLAGS=$(RUNTESTFLAGS) --tool_opts=-std=gnu++0x \
+ $(MAKE) RUNTESTFLAGS=$(RUNTESTFLAGS) --extra_opts,-std=gnu++0x \
TESTSUITEDIR=$(TESTSUITEDIR).c++0x check-g++
check-c++-subtargets : check-g++-subtargets
# List of targets that can use the generic check- rule and its // variant.
diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp
index 81c4398..9e269b1 100644
--- a/gcc/testsuite/lib/g++.exp
+++ b/gcc/testsuite/lib/g++.exp
@@ -307,3 +307,34 @@ proc g++_target_compile { source dest type options } {
return $result
}
+
+#
+# ${tool}_option_help
+#
+# Changed additional to extra because runtest.exp treats --a* as --all.
+#
+# This shouldn't be necessary at all; it should be entirely redundant with
+# --tool_opts, except that --tool_opts currently breaks multilib: see
+# http://lists.gnu.org/archive/html/dejagnu/2002-10/msg7.html
+
+proc ${tool}_option_help { } {
+send_user --extra_opts,OPTIONS\t\tUse OPTIONS to compile the testcase files. OPTIONS should be comma-separated.\n
+}
+
+#
+# ${tool}_option_proc
+#
+
+proc ${tool}_option_proc { option } {
+if [regexp ^--extra_opts, $option] {
+ global gpp_compile_options
+ regsub ^--extra_opts, $option option
+ foreach x [split $option ,] {
+ lappend gpp_compile_options additional_flags=$x
+ }
+ verbose -log gpp_compile_options set to $gpp_compile_options
+ return 1
+} else {
+ return 0
+}
+}
[PATCH] Move pr49309.C testcase to libmudflap (PR testsuite/49753)
On Wed, Jul 13, 2011 at 01:37:22PM -0700, Andrew Pinski wrote:
Hi,
The problem here is that the type of the POINTER_PLUS_EXPR is
incorrect and also the non folded version leaks to the IR. This patch
fixes those two problems and fixes the ICE.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
The testcase is wrongly placed and thus fails everywhere. -fmudflap
causes inclusion of headers and gcc/testsuite/ isn't set up to find them.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk and 4.6 as obvious:
2011-07-15 Jakub Jelinek ja...@redhat.com
PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.
* g++.dg/torture/pr49309.C: Remove.
--- libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx.jj 2011-07-15
18:34:03.919420272 +0200
+++ libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx 2011-07-15
18:35:26.377420360 +0200
@@ -0,0 +1,15 @@
+// PR tree-optimization/49309
+// { dg-do compile }
+// { dg-options -fmudflap }
+
+struct A
+{
+ int i;
+
+ A();
+ A(const A);
+};
+
+inline void foo(A a) { a = A(); }
+
+void bar() { foo(A()); }
--- gcc/testsuite/g++.dg/torture/pr49309.C.jj 2011-07-15 18:24:19.759419903
+0200
+++ gcc/testsuite/g++.dg/torture/pr49309.C 2011-01-16 05:42:39.626675592
+0100
@@ -1,14 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options -fmudflap } */
-struct A
-{
- int i;
-
- A();
- A(const A);
-};
-
-inline void foo(A a) { a = A(); }
-
-void bar() { foo(A()); }
-
Jakub
Re: [pph] Add symbol table - Fix remaining asm differences (issue4732043)
Nice solution :)! A few things inline below:
+ /* Read and process the symbol table. */
+ pph_in_symtab (stream);
}
Why read the symbol table last? I would expect that we would read this
first, before reading the bindings, then we don't need to change the
actual pph_in_* functions to delay some of the input as the bindings
read would read a shared cache entry and simply get the already
allocated structure.
@@ -1479,10 +1497,7 @@ pph_in_function_decl (pph_stream *stream, tree fndecl)
DECL_INITIAL (fndecl) = pph_in_tree (stream);
pph_in_lang_specific (stream, fndecl);
DECL_SAVED_TREE (fndecl) = pph_in_tree (stream);
- DECL_STRUCT_FUNCTION (fndecl) = pph_in_struct_function (stream, fndecl);
DECL_CHAIN (fndecl) = pph_in_tree (stream);
- if (DECL_SAVED_TREE (fndecl))
- VEC_safe_push (tree, gc, stream-fns_to_expand, fndecl);
}
(If we read symbol table first we can probably keep this logic as is)
@@ -1282,13 +1320,19 @@ pph_out_tree_header (struct output_block *ob, tree
expr)
static void
pph_out_function_decl (pph_stream *stream, tree fndecl, bool ref_p)
{
+ /* Note that we do not output DECL_STRUCT_FUNCTION here. This is
+ emitted at the end of the PPH file in pph_out_symtab.
+ This way, we will be able to re-instantiate them in the same
+ order when reading the image (the allocation of
+ DECL_STRUCT_FUNCTION has the side effect of generating function
+ sequence numbers (function.funcdef_no). */
pph_out_tree_or_ref_1 (stream, DECL_INITIAL (fndecl), ref_p, 3);
pph_out_lang_specific (stream, fndecl, ref_p);
pph_out_tree_or_ref_1 (stream, DECL_SAVED_TREE (fndecl), ref_p, 3);
- pph_out_struct_function (stream, DECL_STRUCT_FUNCTION (fndecl), ref_p);
pph_out_tree_or_ref_1 (stream, DECL_CHAIN (fndecl), ref_p, 3);
}
(again, i think we should output this normally, but output the symtab
first so that at this point this is just a ref)
+/* Add DECL to the list of symbols that need to be registered with the
+ middle end when reading current_pph_stream. */
+
+void
+pph_add_decl_to_register (tree decl)
+{
+ if (decl)
+ VEC_safe_push (tree, heap, decls_to_register, decl);
+}
should we inline this?
--
This patch is available for review at http://codereview.appspot.com/4732043
Cheers,
Gab
Re: [Patch, Fortran] Add runtime_error function to libgfortran/caf/mpi.c
On 7/9/2011 8:02 AM, Tobias Burnus wrote:
Tobias Burnus wrote:
This patch adds a run-time error function to mpi.c, which gives a
proper error message including the image number. Additionally, it
allows to clean up the error handling, avoiding the duplicated
declaration of strings.
+static void
+runtime_error (int error, const char *message, ...)
+{
+ va_list ap;
+ fprintf (stderr, Fortran runtime error on image %d: , caf_this_image);
+ va_start (ap, message);
+ fprintf (stderr, message, ap);
Did you mean to call vfprintf here? (And I guess the recent patches for
the CAF support need to be changed accordingly as well...)
-Nathan
Re: [RFC] Avoid unnecessary futex_wake syscalls when all threads are busy waiting
Jakub Jelinek wrote: Tested with libgomp testsuite and looked at performance numbers of Sho's omp_fib.c and libgomp.c/sort-1.c, unfortunately the differences looked to be in the noise. But, e.g. on omp_fib.c strace -f shows that the number of futex FUTEX_WAKE syscalls went down a lot (from ~ 75000 for omp_fib 32 down to ~ 50 with the default wait policy, of course for OMP_WAIT_POLICY=passive it remained roughly the same). I have tested the patch on an Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (2x Quad with hypherthreading) with SUSE Linux Enterprise Server 11 (x86_64), PATCHLEVEL = 1 and GNU C Library stable release version 2.11.1. GCC 4.7.0 20110714 [trunk revision 176260] flags: -Ofast -march=native -funroll-loops -flto -fwhole-program Tested with four programs (in different variations) of NANOS's OpenMP task (!) test suite, available at http://nanos.ac.upc.edu/content/barcelona-openmp-task-suite I always did 3 runs with the original libgomp.so and three with the patched one, taking the average of those runs. The columns are: Average run time (old), relative speed up to serial version, average run time (patched), speedup to the serial version, ratio (old)/(patched) in per cent. Thus, the per-cent number is the crucial number - and the higher the better for this patch. FFT and health profit a lot from the patch - especially for with many threads; alignment is in the noise. Taking the % number, summing it up and dividing it by the number of runs gives: 102.2%, which indicates a ~2% performance gain. Thanks for the patch Jakub! Tobias PS: I have repeated the FFT test cases to see how reliable the numbers are. fft 8.500 1.03 8.990 0.97 94.5% Threads 1 (fft.gcc.omp-tasks) fft 5.857 1.50 5.937 1.48 98.7% Threads 2 (fft.gcc.omp-tasks) fft 4.047 2.16 3.940 2.22 102.7% Threads 3 (fft.gcc.omp-tasks) fft 3.490 2.51 3.547 2.47 98.4% Threads 4 (fft.gcc.omp-tasks) fft 3.080 2.84 3.020 2.90 102.0% Threads 5 (fft.gcc.omp-tasks) fft 2.790 3.14 2.773 3.16 100.6% Threads 6 (fft.gcc.omp-tasks) fft 2.670 3.28 2.873 3.05 92.9% Threads 7 (fft.gcc.omp-tasks) fft 2.847 3.08 2.763 3.17 103.0% Threads 8 (fft.gcc.omp-tasks) fft 3.040 2.88 2.730 3.21 111.4% Threads 9 (fft.gcc.omp-tasks) fft 3.010 2.91 2.697 3.25 111.6% Threads 10 (fft.gcc.omp-tasks) fft 3.070 2.85 2.793 3.14 109.9% Threads 11 (fft.gcc.omp-tasks) fft 3.163 2.77 2.850 3.07 111.0% Threads 12 (fft.gcc.omp-tasks) fft 3.480 2.52 2.857 3.07 121.8% Threads 13 (fft.gcc.omp-tasks) fft 3.237 2.71 2.970 2.95 109.0% Threads 14 (fft.gcc.omp-tasks) fft 3.330 2.63 3.003 2.92 110.9% Threads 15 (fft.gcc.omp-tasks) fft 3.517 2.49 3.063 2.86 114.8% Threads 16 (fft.gcc.omp-tasks) fft 9.000 0.97 8.973 0.98 100.3% Threads 1 (fft.gcc.omp-tasks) fft 5.937 1.48 5.853 1.50 101.4% Threads 2 (fft.gcc.omp-tasks) fft 3.970 2.21 3.993 2.19 99.4% Threads 3 (fft.gcc.omp-tasks) fft 3.510 2.50 3.513 2.49 99.9% Threads 4 (fft.gcc.omp-tasks) fft 3.070 2.85 3.033 2.89 101.2% Threads 5 (fft.gcc.omp-tasks) fft 2.793 3.14 2.810 3.12 99.4% Threads 6 (fft.gcc.omp-tasks) fft 2.823 3.10 2.653 3.30 106.4% Threads 7 (fft.gcc.omp-tasks) fft 2.830 3.10 2.777 3.15 101.9% Threads 8 (fft.gcc.omp-tasks) fft 3.017 2.90 2.797 3.13 107.9% Threads 9 (fft.gcc.omp-tasks) fft 2.913 3.01 2.777 3.15 104.9% Threads 10 (fft.gcc.omp-tasks) fft 3.160 2.77 2.807 3.12 112.6% Threads 11 (fft.gcc.omp-tasks) fft 3.193 2.74 2.930 2.99 109.0% Threads 12 (fft.gcc.omp-tasks) fft 3.283 2.67 2.920 3.00 112.4% Threads 13 (fft.gcc.omp-tasks) fft 3.273 2.68 2.997 2.92 109.2% Threads 14 (fft.gcc.omp-tasks) fft 3.317 2.64 3.007 2.91 110.3% Threads 15 (fft.gcc.omp-tasks) fft 3.503 2.50 3.107 2.82 112.8% Threads 16 (fft.gcc.omp-tasks) fft 9.010 0.97 8.577 1.02 105.1% Threads 1 (fft.gcc.omp-tasks-tied) fft 5.690 1.54 5.793 1.51 98.2% Threads 2 (fft.gcc.omp-tasks-tied) fft 3.910 2.24 3.923 2.23 99.7% Threads 3 (fft.gcc.omp-tasks-tied) fft 3.397 2.58 3.617 2.42 93.9% Threads 4 (fft.gcc.omp-tasks-tied) fft 3.133 2.80 3.013 2.91 104.0% Threads 5 (fft.gcc.omp-tasks-tied) fft 2.803 3.12 2.863 3.06 97.9% Threads 6 (fft.gcc.omp-tasks-tied) fft 2.763 3.17 2.637 3.32 104.8% Threads 7 (fft.gcc.omp-tasks-tied) fft 2.627 3.34 2.727 3.21 96.3% Threads 8 (fft.gcc.omp-tasks-tied) fft 2.880 3.04 2.770 3.16 104.0% Threads 9 (fft.gcc.omp-tasks-tied) fft 2.883 3.04 2.753 3.18 104.7% Threads 10
Re: [Patch, Fortran] Add runtime_error function to libgfortran/caf/mpi.c
On 07/15/2011 10:34 PM, Nathan Froyd wrote:
+static void
+runtime_error (int error, const char *message, ...)
+{
+ va_list ap;
+ fprintf (stderr, Fortran runtime error on image %d: , caf_this_image);
+ va_start (ap, message);
+ fprintf (stderr, message, ap);
Did you mean to call vfprintf here? (And I guess the recent patches for
the CAF support need to be changed accordingly as well...)
Yeah, it definitely looks like the last fpritnf should have been a
vfprintf. I am officially submitting the attached patch, with the
ChangeLog below. I am currently compiling and I'll run the test suite.
So if I can get a yay from one of the developers I'll commit after the
test suite is done.
2011-07-15 Daniel Carrera dcarr...@gmail.com
* caf/mpi.c (caf_runtime_error): Change fprintf to vfprintf.
* caf/single.c (caf_runtime_error): Ditto.
Cheers,
Daniel.
--
I'm not overweight, I'm undertall.
diff --git a/libgfortran/caf/mpi.c b/libgfortran/caf/mpi.c
--- a/libgfortran/caf/mpi.c
+++ b/libgfortran/caf/mpi.c
@@ -54,7 +54,7 @@ caf_runtime_error (const char *message,
va_list ap;
fprintf (stderr, Fortran runtime error on image %d: , caf_this_image);
va_start (ap, message);
- fprintf (stderr, message, ap);
+ vfprintf (stderr, message, ap);
va_end (ap);
fprintf (stderr, \n);
diff --git a/libgfortran/caf/single.c b/libgfortran/caf/single.c
--- a/libgfortran/caf/single.c
+++ b/libgfortran/caf/single.c
@@ -48,7 +48,7 @@ caf_runtime_error (const char *message,
va_list ap;
fprintf (stderr, Fortran runtime error: );
va_start (ap, message);
- fprintf (stderr, message, ap);
+ vfprintf (stderr, message, ap);
va_end (ap);
fprintf (stderr, \n);
[RFC] More compact (100x) -g3 .debug_macinfo (take 3)
On Fri, Jul 15, 2011 at 09:22:42AM -0700, Richard Henderson wrote: On 07/15/2011 08:42 AM, Jakub Jelinek wrote: The newly added opcodes: DW_MACINFO_GNU_define_indirect 0xe0 This opcode has two arguments, one is uleb128 lineno and the other is offset size long byte offset into .debug_str. Except for the encoding of the string it is similar to DW_MACINFO_define. DW_MACINFO_GNU_undef_indirect 0xe1 This opcode has two arguments, one is uleb128 lineno and the other is offset size long byte offset into .debug_str. Except for the encoding of the string it is similar to DW_MACINFO_undef. DW_MACINFO_GNU_transparent_include 0xe2 This opcode has a single argument, a offset size long byte offset into .debug_macinfo. It instructs the debug info consumer that this opcode during reading should be replaced with the sequence of .debug_macinfo opcodes from the mentioned offset, up to a terminating 0 opcode (not including that 0). DW_MACINFO_GNU_define_opcode0xe3 This is an opcode for future extensibility through which a debugger could skip unknown opcodes. It has 3 arguments: 1 byte opcode number, uleb128 count of arguments and a count bytes long array, with a DW_FORM_* code how the argument is encoded. I do like the new opcodes. Elsewhere you described transparent_include as also saving state about defined opcodes around the include. Do you want to either describe that or drop it? Ok, so how about this way (as DWARF4 modifications, of course for DWARF5 proposal GNU_ would be gone and the ops would have different codes): 6.3.1 The valid macinfo types are as follows: ... DW_MACINFO_GNU_define_indirect A macro definition. DW_MACINFO_GNU_undef_indirect A macro undefinition. DW_MACINFO_GNU_transparent_include Include a sequence of entries from given offset. DW_MACINFO_GNU_define_opcodeDefine extension opcode and its arguments. 6.3.1.1 All DW_MACINFO_GNU_define_indirect and DW_MACINFO_undef_indirect entries have two operands. The first operand encodes the line number of the source line on which the relevant defining or undefining macro directives appeared. The second operand consists of an offset into a string table contained in the .debug_str section of the object file. In the 32-bit DWARF format, the representation of the operand value is a 4-byte unsigned offset; in the 64-bit DWARF format, it is an 8-byte unsigned offset. Apart from the encoding of the operands these entries are equivalent to DW_MACINFO_define resp. DW_MACINFO_undef. 6.3.1.5 Transparent inclusion of a sequence of entries A DW_MACINFO_GNU_transparent_include entry has one operand, offset into another part of the .debug_macinfo section. In the 32-bit DWARF format, the representation of the operand value is a 4-byte unsigned offset; in the 64-bit DWARF format, it is an 8-byte unsigned offset. This entry instructs the consumer to replace this entry with a sequence of macinfo entries found at the given .debug_macinfo offset, up to, but excluding, the terminating entry with type code 0. This entry type is aimed at sharing duplicate sequences of macinfo entries between macinfo from different compilation units. The producer should ensure that only sequences with matching DWARF format size (either all 32-bit DWARF or all 64-bit DWARF) are merged together, and that either DW_MACINFO_start_file entries aren't in those sequences, or only macinfo entries referencing the same .debug_line section part include the sequence. 6.3.1.6 Defining new opcodes and operands A DW_MACINFO_GNU_define_opcode entry has 2 operands. The first operand is a one byte constant with the type code it defines operand types for, the second operand is a DW_FORM_block encoded array of operand forms. The second operand starts with an unsigned LEB128 encoded number of operands and for each of the operands there is one byte, containing a form encoding how the corresponding operand is encoded. This entry allows to define new vendor extension entry types which consumers will be able to skip over and ignore. Each so defined opcode is valid for subsequent entries until the terminating entry with type code 0, including any sequences included from those entries using DW_MACINFO_GNU_transparent_include. Opcodes defined using this entry in a chain included through DW_MACINFO_GNU_transparent_include isn't valid in the parent sequence after the DW_MACINFO_GNU_transparent_include entry that included it though. 7.22 Macro Information Add DW_MACINFO_lo_user 0xe0 DW_MACINFO_GNU_define_indirect 0xe0 DW_MACINFO_GNU_undef_indirect 0xe1 DW_MACINFO_GNU_transparent_include 0xe2 DW_MACINFO_GNU_define_opcode0xe3 DW_MACINFO_hi_user 0xfe to the table. I'd like to see this
Re: [Patch, Fortran] Add runtime_error function to libgfortran/caf/mpi.c
Daniel Carrera wrote: On 07/15/2011 10:34 PM, Nathan Froyd wrote: + va_start (ap, message); + fprintf (stderr, message, ap); Did you mean to call vfprintf here? Well spotted! Thanks for the report, Nathan! 2011-07-15 Daniel Carrera dcarr...@gmail.com * caf/mpi.c (caf_runtime_error): Change fprintf to vfprintf. * caf/single.c (caf_runtime_error): Ditto. OK. Thanks for the quick patch! Tobias
Re: [pph] Add symbol table - Fix remaining asm differences (issue4732043)
On Fri, Jul 15, 2011 at 16:02, Gabriel Charette gch...@google.com wrote:
+ /* Read and process the symbol table. */
+ pph_in_symtab (stream);
}
Why read the symbol table last?
Because the symbol identifiers need to be placed in the global
bindings, which are not read until later. This was my initial intent,
but this circular dependency made things unpleasant. If the symbol
table is placed first, we don't update the bindings properly and
lookups fail.
There are some improvements that can be done, however: we are not
testing for duplicate symbols in the table (I noticed that sometimes
rest_of_decl_compilation is called more than once for the same decl,
for instance).
+/* Add DECL to the list of symbols that need to be registered with the
+ middle end when reading current_pph_stream. */
+
+void
+pph_add_decl_to_register (tree decl)
+{
+ if (decl)
+ VEC_safe_push (tree, heap, decls_to_register, decl);
+}
should we inline this?
It's accessing file-local data (decls_to_register). Besides, this is
trivial to inline with LTO/LIPO.
Diego.
Re: [Patch, Fortran] Allocate + CAF library
Daniel Carrera wrote:
I propose this:
if (!gfc_array_allocate (se, expr, stat, errmsg, errlen))
{
... allocate scalar ...
}
if (code-expr1)
{
/* The coarray library already sets the errmsg. */
if (gfc_option.coarray == GFC_FCOARRAY_LIB
gfc_expr_attr (expr).codimension)
tmp = build1_v (GOTO_EXPR, label_finish);
else
tmp = build1_v (GOTO_EXPR, label_errmsg);
...
}
Yes, that was what I was thinking of. I hadn't checked whether one could
use exactly the same code or needed a slightly different version, but it
seems as if one can do just as you have written.
[Other PR]
I think I even remember noticing that the code deallocated the
previous array and was wondering why it did that.
I think I saw the code also before in some dump, wondered about it, but
not enough to check the standard, which explicitly prohibits the
(de/re)allocation. (It does so in F2003 and F2008, I have not checked
the wording in F90/F95. Maybe the status back then was undefined?)
Tobias
[Patch, Fortran] PR49624 - fix ICE with invalid pointer remapping
ptr(10,1:) = target was accepted as for the check (10,1:) was seen as
equivalent to the valid (10:, 1:) - although the first dimension is
not a range but an element. (Side note: (10:, 1:) would be wrong as well
as one then needs to have the same rank.)
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2011-07-16 Tobias Burnus bur...@net-b.de
PR fortran/49624
* expr.c (gfc_check_pointer_assign): Fix checking for invalid
pointer bounds.
2011-07-16 Tobias Burnus bur...@net-b.de
PR fortran/49624
* gfortran.dg/pointer_remapping_7.f90: New.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 6db0836..b8eb555 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3286,7 +3286,8 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
upper bounds are present, we may do rank remapping. */
for (dim = 0; dim ref-u.ar.dimen; ++dim)
{
- if (!ref-u.ar.start[dim])
+ if (!ref-u.ar.start[dim]
+ || ref-u.ar.dimen_type[dim] != DIMEN_RANGE)
{
gfc_error (Lower bound has to be present at %L,
lvalue-where);
--- /dev/null 2011-07-15 07:29:58.667884802 +0200
+++ gcc/gcc/testsuite/gfortran.dg/pointer_remapping_7.f90 2011-07-15 23:22:29.0 +0200
@@ -0,0 +1,8 @@
+! { dg-do compile }
+!
+! PR fortran/49624
+!
+ integer, target :: A(100)
+ integer,pointer :: P(:,:)
+ p(10,1:) = A ! { dg-error Lower bound has to be present }
+ end
Re: [PATCH 0/3] Fix PR47654 and PR49649
On Fri, Jul 8, 2011 at 03:32, Richard Guenther rguent...@suse.de wrote:
On Thu, 7 Jul 2011, Sebastian Pop wrote:
Hi,
First there are two cleanup patches independent of the fix:
Start counting nesting level from 0.
Do not compute twice type, lb, and ub.
Then the patch that fixes PR47654:
Fix PR47654: Compute LB and UB of a CLAST expression.
One of the reasons we cannot determine the IV type only from the
polyhedral representation is that as in the testcase of PR47654, we
are asked to generate an induction variable going from 0 to 127. That
could be represented with a char. However the upper bound
expression of the loop generated by CLOOG is min (127, 51*scat_1 + 50)
and that would overflow if we use a char type. To evaluate a type
in which the expression 51*scat_1 + 50 does not overflow, we have to
compute an upper and lower bound for the expression.
To fix the problem exposed by Tobias:
for (i = 0 ; i 2; i++)
for (j = i ; j i + 1; j++)
for (k = j ; k j + 1; k++)
for (m = k ; m k + 1; m++)
for (n = m ; n m + 1; n++)
A[0] += A[n];
I am a little bit afraid that we will increase the type size by an
order of magnitude (or at least one bit) for each nesting level.
instead of computing the lb and ub of scat_1 in 51*scat_1 + 50 based
on the type of scat_1 (that we already code generated when building
the outer loop), we use the polyhedral representation to get an
accurate lb and ub for scat_1.
When translating the substitutions of a user statement using this
precise method, like for example S5 in vect-pr43423.c:
for (scat_1=0;scat_1=min(T_3-1,T_4-1);scat_1++) {
S5(scat_1);
we get a type that is too precise: based on the interval [0,99] we get
the type unsigned char when the type of scat_1 is int, misleading
the vectorizer due to the insertion of spurious casts:
# Access function 0: (int) {(unnamed-unsigned:8) graphite_IV.7_56, +,
1}_3;
#)
affine dependence test not usable: access function not affine or constant.
So we have to keep around the previous code gcc_type_for_clast_* that
computes the type of an expression as the max precision of the
components of that expression, and use that when computing the types
of substitution expressions.
The patches passed together a full bootstrap and test on amd64-linux.
Ok for trunk?
The idea sounds good to me and the middle-end-like looking pieces
look good. I'd appreciate a 2nd look from Tobias.
Tobias, could you please have a look at these patches as well?
Thanks,
Sebastian
[pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
This patch adds an expected checksum for the tests expecting an asm diff.
This way if we were expecting an asm diff, still get one, but a different one,
we know (before this patch we would ignore this, generating an XFAIL as usual,
as the status of having an asm diff itself hadn't changed).
I had to change from using the TCL grep to the bash grep (through an exec call)
as I now need the actual output of the grep call, not only the return value (it
also turns out the return value for TCL grep and bash grep are different; hence
the change in the if statements on the adiff variable)
Gab
2011-07-15 Gabriel Charette gch...@google.com
* g++.dg/pph/c1builtin-integral.cc: Add expected diff checksum.
* g++.dg/pph/c1eabi1.cc: Add expected diff checksum.
* g++.dg/pph/p4eabi1.cc: Add expected diff checksum.
* lib/dg-pph.exp (dg-pph-pos): Expect checksums for pph asm xdiff.
diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
index c2fceec..6887b11 100644
--- a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
+++ b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
@@ -1,2 +1,2 @@
-// pph asm xdiff
+// pph asm xdiff 52758
#include c0builtin-integral.h
diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
index b127f98..3321870 100644
--- a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 36206
#include c0eabi1.h
diff --git a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
index 4247f49..2f0715f 100644
--- a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 15662
#include p4eabi1.h
diff --git a/gcc/testsuite/lib/dg-pph.exp b/gcc/testsuite/lib/dg-pph.exp
index b706f27..1d7deed 100644
--- a/gcc/testsuite/lib/dg-pph.exp
+++ b/gcc/testsuite/lib/dg-pph.exp
@@ -128,12 +128,11 @@ proc dg-pph-pos { subdir test options mapflag suffix } {
verbose -log
# Compare the two assembly files. They should be identical.
-set adiff [diff $bname.s-pph $bname.s+pph]
+set adiff [catch {exec diff $bname.s-pph $bname.s+pph} diff_result]
# The sources mark when they expect the comparison to differ.
-set xdiff [llength [grep $test pph asm xdiff]]
+set xdiff_entry [grep $test pph asm xdiff( )*\[0-9\]*]
+set xdiff [llength $xdiff_entry]
if { $adiff == 0 } {
- fail $nshort $options comparison failure
-} elseif { $adiff == 1 } {
if { $xdiff } {
xpass $nshort $options (assembly comparison)
} else {
@@ -141,11 +140,20 @@ proc dg-pph-pos { subdir test options mapflag suffix } {
}
file_on_host delete $bname.s-pph
file_on_host delete $bname.s+pph
-} else {
+} elseif { $adiff == 1 } {
+verbose -log Diff obtained:\n$diff_result
if { $xdiff } {
- xfail $nshort $options (assembly comparison)
+ set expectedSum [exec tr -d \} [exec cut -f 4 -d\
$xdiff_entry]]
+ set actualSum [exec cut -f 1 -d\ [exec sum $diff_result]]
+ if { $expectedSum == $actualSum } {
+ xfail $nshort $options (assembly comparison)
+ } else {
+ fail $nshort $options (assembly comparison, sums differ:
expected $expectedSum, actual $actualSum)
+ }
} else {
fail $nshort $options (assembly comparison)
}
+} else {
+ fail $nshort $options comparison failure
}
}
--
This patch is available for review at http://codereview.appspot.com/4744043
[pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
Reviewed in person by Lawrence.
Shortened XFAIL message from previous patch.
Also, quick side note, in the first description of this patch I said I used
exec grep, I meant exec diff.
Gab
2011-07-15 Gabriel Charette gch...@google.com
* g++.dg/pph/c1builtin-integral.cc: Add expected diff checksum.
* g++.dg/pph/c1eabi1.cc: Add expected diff checksum.
* g++.dg/pph/p4eabi1.cc: Add expected diff checksum.
* lib/dg-pph.exp (dg-pph-pos): Expect checksums for pph asm xdiff.
diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
index c2fceec..6887b11 100644
--- a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
+++ b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
@@ -1,2 +1,2 @@
-// pph asm xdiff
+// pph asm xdiff 52758
#include c0builtin-integral.h
diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
index b127f98..3321870 100644
--- a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 36206
#include c0eabi1.h
diff --git a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
index 4247f49..2f0715f 100644
--- a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 15662
#include p4eabi1.h
diff --git a/gcc/testsuite/lib/dg-pph.exp b/gcc/testsuite/lib/dg-pph.exp
index b706f27..b285ccf 100644
--- a/gcc/testsuite/lib/dg-pph.exp
+++ b/gcc/testsuite/lib/dg-pph.exp
@@ -128,12 +128,11 @@ proc dg-pph-pos { subdir test options mapflag suffix } {
verbose -log
# Compare the two assembly files. They should be identical.
-set adiff [diff $bname.s-pph $bname.s+pph]
+set adiff [catch {exec diff $bname.s-pph $bname.s+pph} diff_result]
# The sources mark when they expect the comparison to differ.
-set xdiff [llength [grep $test pph asm xdiff]]
+set xdiff_entry [grep $test pph asm xdiff( )*\[0-9\]*]
+set xdiff [llength $xdiff_entry]
if { $adiff == 0 } {
- fail $nshort $options comparison failure
-} elseif { $adiff == 1 } {
if { $xdiff } {
xpass $nshort $options (assembly comparison)
} else {
@@ -141,11 +140,20 @@ proc dg-pph-pos { subdir test options mapflag suffix } {
}
file_on_host delete $bname.s-pph
file_on_host delete $bname.s+pph
-} else {
+} elseif { $adiff == 1 } {
+verbose -log Diff obtained:\n$diff_result
if { $xdiff } {
- xfail $nshort $options (assembly comparison)
+ set expectedSum [exec tr -d \} [exec cut -f 4 -d\
$xdiff_entry]]
+ set actualSum [exec cut -f 1 -d\ [exec sum $diff_result]]
+ if { $expectedSum == $actualSum } {
+ xfail $nshort $options (assembly comparison)
+ } else {
+ fail $nshort $options (assembly comparison, sums
$expectedSum=$actualSum)
+ }
} else {
fail $nshort $options (assembly comparison)
}
+} else {
+ fail $nshort $options comparison failure
}
}
--
This patch is available for review at http://codereview.appspot.com/4744043
Re: [pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
OK with the change below.
Diego.
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp
File gcc/testsuite/lib/dg-pph.exp (right):
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp#newcode131
gcc/testsuite/lib/dg-pph.exp:131: set adiff [catch {exec diff
$bname.s-pph $bname.s+pph} diff_result]
131 set adiff [catch {exec diff $bname.s-pph $bname.s+pph}
diff_result]
You don't need this, if instead of summing the diff you sum
$bname.s+pph. The logic would then be: if there is a difference between
$bname.s-pph and $bname.s+pph, we checksum $bname.s+pph. If the new
checksum is different than the stored one, it means that $bname.s+pph is
different from $bname.s-pph in a different way.
This has the benefit of:
- Being slightly faster.
- Simplifies the generation of checksums. We no longer need to checksum
the difference between the two .s files, we just need to checksum the
.s+pph file
http://codereview.appspot.com/4744043/
Re: [RFC PATCH 0/9] CFG aware dwarf2 cfi generation
On 07/14/2011 04:07 PM, Richard Henderson wrote: This finally brings us to something that can support shrink-wrapping. As mentioned in the description of the last patch, this is 95% of what Bernd had in his last 007-dw2cfg patch, except for the remember/ restore_state stuff. And hopefully with better comments. This is the first version of this that has actually made it into stage3 bootstrap on x86_64, so it isn't well tested yet. This just happens to coincide with the end of my work day, and it's been a while since I've shared state, so I thought I'd post for overnight review. The complete tree is available at git://repo.or.cz/gcc/rth.git rth/cfi-pass I've fixed a few minor bugs (mostly silly typos) and pushed the update to the external repo. All of the x86_64 regressions are fixed except for -freorder-blocks-and-partition vs exception handling. Which is Very Broken at a fundamental level. I guess I'll be re-writing all that next... r~
Re: [pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
On 7/15/11, Gabriel Charette gch...@google.com wrote:
This patch adds an expected checksum for the tests expecting an asm diff.
This way if we were expecting an asm diff, still get one, but a different
one, we know (before this patch we would ignore this, generating an XFAIL as
usual, as the status of having an asm diff itself hadn't changed).
I had to change from using the TCL grep to the bash grep (through an exec
call) as I now need the actual output of the grep call, not only the return
value (it also turns out the return value for TCL grep and bash grep are
different; hence the change in the if statements on the adiff variable)
Gab
2011-07-15 Gabriel Charette gch...@google.com
* g++.dg/pph/c1builtin-integral.cc: Add expected diff checksum.
* g++.dg/pph/c1eabi1.cc: Add expected diff checksum.
* g++.dg/pph/p4eabi1.cc: Add expected diff checksum.
* lib/dg-pph.exp (dg-pph-pos): Expect checksums for pph asm xdiff.
diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
index c2fceec..6887b11 100644
--- a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
+++ b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
@@ -1,2 +1,2 @@
-// pph asm xdiff
+// pph asm xdiff 52758
#include c0builtin-integral.h
diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
index b127f98..3321870 100644
--- a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 36206
#include c0eabi1.h
diff --git a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
index 4247f49..2f0715f 100644
--- a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 15662
#include p4eabi1.h
diff --git a/gcc/testsuite/lib/dg-pph.exp b/gcc/testsuite/lib/dg-pph.exp
index b706f27..1d7deed 100644
--- a/gcc/testsuite/lib/dg-pph.exp
+++ b/gcc/testsuite/lib/dg-pph.exp
@@ -128,12 +128,11 @@ proc dg-pph-pos { subdir test options mapflag suffix }
{
verbose -log
# Compare the two assembly files. They should be identical.
-set adiff [diff $bname.s-pph $bname.s+pph]
+set adiff [catch {exec diff $bname.s-pph $bname.s+pph} diff_result]
# The sources mark when they expect the comparison to differ.
-set xdiff [llength [grep $test pph asm xdiff]]
+set xdiff_entry [grep $test pph asm xdiff( )*\[0-9\]*]
+set xdiff [llength $xdiff_entry]
if { $adiff == 0 } {
- fail $nshort $options comparison failure
-} elseif { $adiff == 1 } {
if { $xdiff } {
xpass $nshort $options (assembly comparison)
} else {
@@ -141,11 +140,20 @@ proc dg-pph-pos { subdir test options mapflag suffix }
{
}
file_on_host delete $bname.s-pph
file_on_host delete $bname.s+pph
-} else {
+} elseif { $adiff == 1 } {
+verbose -log Diff obtained:\n$diff_result
if { $xdiff } {
- xfail $nshort $options (assembly comparison)
+ set expectedSum [exec tr -d \} [exec cut -f 4 -d\
$xdiff_entry]]
+ set actualSum [exec cut -f 1 -d\ [exec sum $diff_result]]
+ if { $expectedSum == $actualSum } {
+ xfail $nshort $options (assembly comparison)
+ } else {
+ fail $nshort $options (assembly comparison, sums differ:
expected
$expectedSum, actual $actualSum)
+ }
} else {
fail $nshort $options (assembly comparison)
}
+} else {
+ fail $nshort $options comparison failure
}
}
--
This patch is available for review at http://codereview.appspot.com/4744043
Needs shortening of message. Otherwise, LGTM.
--
Lawrence Crowl
Re: [pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
On 7/15/11, Lawrence Crowl cr...@google.com wrote:
On 7/15/11, Gabriel Charette gch...@google.com wrote:
This patch adds an expected checksum for the tests expecting an asm diff.
This way if we were expecting an asm diff, still get one, but a different
one, we know (before this patch we would ignore this, generating an XFAIL
as
usual, as the status of having an asm diff itself hadn't changed).
I had to change from using the TCL grep to the bash grep (through an exec
call) as I now need the actual output of the grep call, not only the
return
value (it also turns out the return value for TCL grep and bash grep are
different; hence the change in the if statements on the adiff variable)
Gab
2011-07-15 Gabriel Charette gch...@google.com
* g++.dg/pph/c1builtin-integral.cc: Add expected diff checksum.
* g++.dg/pph/c1eabi1.cc: Add expected diff checksum.
* g++.dg/pph/p4eabi1.cc: Add expected diff checksum.
* lib/dg-pph.exp (dg-pph-pos): Expect checksums for pph asm xdiff.
diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
index c2fceec..6887b11 100644
--- a/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
+++ b/gcc/testsuite/g++.dg/pph/c1builtin-integral.cc
@@ -1,2 +1,2 @@
-// pph asm xdiff
+// pph asm xdiff 52758
#include c0builtin-integral.h
diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
index b127f98..3321870 100644
--- a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 36206
#include c0eabi1.h
diff --git a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
index 4247f49..2f0715f 100644
--- a/gcc/testsuite/g++.dg/pph/p4eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/p4eabi1.cc
@@ -1,5 +1,5 @@
// { dg-options -w -fpermissive }
-// pph asm xdiff
+// pph asm xdiff 15662
#include p4eabi1.h
diff --git a/gcc/testsuite/lib/dg-pph.exp b/gcc/testsuite/lib/dg-pph.exp
index b706f27..1d7deed 100644
--- a/gcc/testsuite/lib/dg-pph.exp
+++ b/gcc/testsuite/lib/dg-pph.exp
@@ -128,12 +128,11 @@ proc dg-pph-pos { subdir test options mapflag suffix
}
{
verbose -log
# Compare the two assembly files. They should be identical.
-set adiff [diff $bname.s-pph $bname.s+pph]
+set adiff [catch {exec diff $bname.s-pph $bname.s+pph}
diff_result]
# The sources mark when they expect the comparison to differ.
-set xdiff [llength [grep $test pph asm xdiff]]
+set xdiff_entry [grep $test pph asm xdiff( )*\[0-9\]*]
+set xdiff [llength $xdiff_entry]
if { $adiff == 0 } {
-fail $nshort $options comparison failure
-} elseif { $adiff == 1 } {
if { $xdiff } {
xpass $nshort $options (assembly comparison)
} else {
@@ -141,11 +140,20 @@ proc dg-pph-pos { subdir test options mapflag suffix
}
{
}
file_on_host delete $bname.s-pph
file_on_host delete $bname.s+pph
-} else {
+} elseif { $adiff == 1 } {
+verbose -log Diff obtained:\n$diff_result
if { $xdiff } {
-xfail $nshort $options (assembly comparison)
+set expectedSum [exec tr -d \} [exec cut -f 4 -d\
$xdiff_entry]]
+set actualSum [exec cut -f 1 -d\ [exec sum $diff_result]]
+if { $expectedSum == $actualSum } {
+xfail $nshort $options (assembly comparison)
+} else {
+fail $nshort $options (assembly comparison, sums differ:
expected
$expectedSum, actual $actualSum)
+}
} else {
fail $nshort $options (assembly comparison)
}
+} else {
+fail $nshort $options comparison failure
}
}
--
This patch is available for review at
http://codereview.appspot.com/4744043
Needs shortening of message. Otherwise, LGTM.
We have crossed the streams. LGTM.
--
Lawrence Crowl
Re: [pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
See below.
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp
File gcc/testsuite/lib/dg-pph.exp (right):
http://codereview.appspot.com/4744043/diff/3001/gcc/testsuite/lib/dg-pph.exp#newcode131
gcc/testsuite/lib/dg-pph.exp:131: set adiff [catch {exec diff
$bname.s-pph $bname.s+pph} diff_result]
I actually prefer checksum on the diff itself:
It's less affected by merges (in particular the merge timestamp doesn't
show up in the diff, so unless a merge from trunk changes the actual
assembly, the diff is the same as before)
Also, the generation of checksums is not harder this way, I made it so
the tests' output tells you what the expected/actual sums are when they
differ, so no need to generate them by hand.
http://codereview.appspot.com/4744043/
Re: Use of vector instructions in memmov/memset expanding
New algorithm for move-mode selection is implemented for move_by_pieces, store_by_pieces. x86-specific ix86_expand_movmem and ix86_expand_setmem are also changed in similar way, x86 cost-models parameters are slightly changed to support this. This implementation checks if array's alignment is known at compile time and chooses expanding algorithm and move-mode according to it. Can you give some sumary of changes you made? It would make it a lot easier to review if it was broken up int the generic changes (with rationaly why they are needed) and i386 backend changes that I could review then. From first pass through the patch I don't quite see the need for i.e. adding new move patterns when we can output all kinds of SSE moves already. Will look more into the patch to see if I can come up with useful comments. Honza
Re: [pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
On Fri, Jul 15, 2011 at 19:21, gch...@google.com wrote: It's less affected by merges (in particular the merge timestamp doesn't show up in the diff, so unless a merge from trunk changes the actual assembly, the diff is the same as before) Ah, good point. Also, the generation of checksums is not harder this way, I made it so the tests' output tells you what the expected/actual sums are when they differ, so no need to generate them by hand. OK, in that case go ahead. Diego.
Re: [RFC PATCH 0/9] CFG aware dwarf2 cfi generation
On 07/15/2011 04:24 PM, Bernd Schmidt wrote: What's wrong with -freorder-blocks-and-partition? Something preexisting, or introduced with these changes? Pre-existing. The .gcc_except_table format includes a encoded displacement from a call site to a handler. We cannot represent this displacement when the handler and the call site are in different sections. There is a weak attempt at fixing up this situation in except.c, convert_to_eh_region_ranges, but (1) the exception data is not updated, and more importantly, (2) the code that is generated violates the constraints that are assumed for the exception_receiver and nonlocal_goto_receiver named patterns. In particular, targets like alpha and mips that want to re-compute the GP from some kind of pc-relative relocation will compute the wrong GP. The problem appears in the dwarf2 pass only because of (1), in that when we validate that all extended basic blocks have had unwind info propagated into them, we find that there are blocks that are unvisited. All this cross-segment fixup stuff should have been handled in pass_partition_blocks, not delayed until it's too late to do the right thing. And of course pass_partition_blocks is... well, let's just say it's due for a bit of maintenance. r~
bb-reorder maintenance [1/n]
A simple conversion of reallocated array into a VEC.
More of the subroutines should actually use this VEC
rather than iterating over all blocks and edges, but
this patch only touches the direct users of the data
that became the VEC.
Tested on x86_64-linux and committed.
r~
* bb-reorder.c (find_rarely_executed_basic_blocks_and_crossing_edges):
Replace all three arguments by returning a VEC of edges.
(add_labels_and_missing_jumps): Accept a VEC of edges, not bare
pointers and counts.
(fix_edges_for_rarely_executed_code): Merge ...
(rest_of_handle_partition_blocks): ... into...
(partition_hot_cold_basic_blocks): ... here. Return todo items if
any work was performed.
(pass_partition_blocks): Clear todo_flags_finish.
diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c
index 6d2aedb..c35e762 100644
--- a/gcc/bb-reorder.c
+++ b/gcc/bb-reorder.c
@@ -182,15 +182,6 @@ static void connect_traces (int, struct trace *);
static bool copy_bb_p (const_basic_block, int);
static int get_uncond_jump_length (void);
static bool push_to_next_round_p (const_basic_block, int, int, int, gcov_type);
-static void find_rarely_executed_basic_blocks_and_crossing_edges (edge **,
- int *,
- int *);
-static void add_labels_and_missing_jumps (edge *, int);
-static void add_reg_crossing_jump_notes (void);
-static void fix_up_fall_thru_edges (void);
-static void fix_edges_for_rarely_executed_code (edge *, int);
-static void fix_crossing_conditional_branches (void);
-static void fix_crossing_unconditional_branches (void);
/* Check to see if bb should be pushed into the next round of trace
collections or not. Reasons for pushing the block forward are 1).
@@ -1219,16 +1210,14 @@ get_uncond_jump_length (void)
/* Find the basic blocks that are rarely executed and need to be moved to
a separate section of the .o file (to cut down on paging and improve
- cache locality). */
+ cache locality). Return a vector of all edges that cross. */
-static void
-find_rarely_executed_basic_blocks_and_crossing_edges (edge **crossing_edges,
- int *n_crossing_edges,
- int *max_idx)
+static VEC(edge, heap) *
+find_rarely_executed_basic_blocks_and_crossing_edges (void)
{
+ VEC(edge, heap) *crossing_edges = NULL;
basic_block bb;
edge e;
- int i;
edge_iterator ei;
/* Mark which partition (hot/cold) each basic block belongs in. */
@@ -1243,7 +1232,6 @@ find_rarely_executed_basic_blocks_and_crossing_edges
(edge **crossing_edges,
/* Mark every edge that crosses between sections. */
- i = 0;
FOR_EACH_BB (bb)
FOR_EACH_EDGE (e, ei, bb-succs)
{
@@ -1252,77 +1240,61 @@ find_rarely_executed_basic_blocks_and_crossing_edges
(edge **crossing_edges,
BB_PARTITION (e-src) != BB_PARTITION (e-dest))
{
e-flags |= EDGE_CROSSING;
- if (i == *max_idx)
- {
- *max_idx *= 2;
- *crossing_edges = XRESIZEVEC (edge, *crossing_edges, *max_idx);
- }
- (*crossing_edges)[i++] = e;
+ VEC_safe_push (edge, heap, crossing_edges, e);
}
else
e-flags = ~EDGE_CROSSING;
}
- *n_crossing_edges = i;
+
+ return crossing_edges;
}
/* If any destination of a crossing edge does not have a label, add label;
- Convert any fall-through crossing edges (for blocks that do not contain
- a jump) to unconditional jumps. */
+ Convert any easy fall-through crossing edges to unconditional jumps. */
static void
-add_labels_and_missing_jumps (edge *crossing_edges, int n_crossing_edges)
+add_labels_and_missing_jumps (VEC(edge, heap) *crossing_edges)
{
- int i;
- basic_block src;
- basic_block dest;
- rtx label;
- rtx barrier;
- rtx new_jump;
+ size_t i;
+ edge e;
- for (i=0; i n_crossing_edges; i++)
+ FOR_EACH_VEC_ELT (edge, crossing_edges, i, e)
{
- if (crossing_edges[i])
- {
- src = crossing_edges[i]-src;
- dest = crossing_edges[i]-dest;
+ basic_block src = e-src;
+ basic_block dest = e-dest;
+ rtx label, barrier, new_jump;
- /* Make sure dest has a label. */
+ if (dest == EXIT_BLOCK_PTR)
+ continue;
- if (dest (dest != EXIT_BLOCK_PTR))
- {
- label = block_label (dest);
+ /* Make sure dest has a label. */
+ label = block_label (dest);
- /* Make sure source block ends with a jump. If the
-source block does not end with a jump it might end
-with a call_insn; this case will be handled in
-fix_up_fall_thru_edges function. */
+ /* Nothing to do for non-fallthru edges. */
+ if (src == ENTRY_BLOCK_PTR)
+ continue;
+
C++ PATCH to enable checking with aggressive GC tuning
This patch adds 'make check-g++-strict-gc' for running the C++ testsuite
with aggressive GC tuning for catching GC issues that might otherwise
lie undetected for a while. And it fixes several current issues that I
found using it: the GTY markings I had put in except.c had no effect
because I hadn't added it to the list of files to scan, and we can't GC
after a function (lambda or template instantiation) in the middle of an
expression.
I'm not adding this to any other targets, as some current tests take a
very long time to run in this mode.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 20bdb0b4a32912673c5802dc3803434547165faf
Author: Jason Merrill ja...@redhat.com
Date: Fri Jul 15 10:59:31 2011 -0400
* Make-lang.in (check-g++-strict-gc): New.
(cp/except.o): Depend on gt-cp-except.h
* except.c: Include gt-cp-except.h.
* config-lang.in (gtfiles): Add cp/except.c.
* decl2.c (mark_used): Adjust constexpr condition, set
function_depth around template instantiation.
* parser.c (cp_parser_lambda_body): Set function_depth.
* semantics.c (maybe_add_lambda_conv_op): Likewise.
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index ad466b2..21145b2 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -153,6 +153,10 @@ check-c++ : check-g++
check-c++0x:
$(MAKE) RUNTESTFLAGS=$(RUNTESTFLAGS) --extra_opts,-std=gnu++0x \
TESTSUITEDIR=$(TESTSUITEDIR).c++0x check-g++
+# Run the testsuite with garbage collection at every opportunity.
+check-g++-strict-gc:
+ $(MAKE) RUNTESTFLAGS=$(RUNTESTFLAGS) --extra_opts,--param,ggc-min-heapsize=0,--param,ggc-min-expand=0 \
+ TESTSUITEDIR=$(TESTSUITEDIR).gc check-g++
check-c++-subtargets : check-g++-subtargets
# List of targets that can use the generic check- rule and its // variant.
lang_checks += check-g++
@@ -309,7 +313,7 @@ cp/ptree.o: cp/ptree.c $(CXX_TREE_H) $(TM_H)
cp/rtti.o: cp/rtti.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) convert.h \
$(TARGET_H) $(C_PRAGMA_H) gt-cp-rtti.h intl.h
cp/except.o: cp/except.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \
- cp/cfns.h $(TREE_INLINE_H) $(TARGET_H)
+ cp/cfns.h $(TREE_INLINE_H) $(TARGET_H) gt-cp-except.h
cp/expr.o: cp/expr.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) $(TM_P_H)
cp/pt.o: cp/pt.c $(CXX_TREE_H) $(TM_H) cp/decl.h cp/cp-objcp-common.h \
toplev.h $(TREE_INLINE_H) pointer-set.h gt-cp-pt.h vecprim.h intl.h \
diff --git a/gcc/cp/config-lang.in b/gcc/cp/config-lang.in
index 13f2e9c..3ed3d8e 100644
--- a/gcc/cp/config-lang.in
+++ b/gcc/cp/config-lang.in
@@ -30,4 +30,4 @@ compilers=cc1plus\$(exeext)
target_libs=target-libstdc++-v3
-gtfiles=\$(srcdir)/cp/rtti.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.h \$(srcdir)/cp/call.c \$(srcdir)/cp/decl.c \$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c \$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/parser.h \$(srcdir)/cp/parser.c \$(srcdir)/cp/method.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c \$(srcdir)/cp/class.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/cp-lang.c
+gtfiles=\$(srcdir)/cp/rtti.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.h \$(srcdir)/cp/call.c \$(srcdir)/cp/decl.c \$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c \$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/parser.h \$(srcdir)/cp/parser.c \$(srcdir)/cp/method.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c \$(srcdir)/cp/class.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/cp-lang.c \$(srcdir)/cp/except.c
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index e1f9562..f05b0f8 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4231,9 +4231,9 @@ mark_used (tree decl)
if ((decl_maybe_constant_var_p (decl)
|| (TREE_CODE (decl) == FUNCTION_DECL
DECL_DECLARED_CONSTEXPR_P (decl)))
- !DECL_INITIAL (decl)
DECL_LANG_SPECIFIC (decl)
- DECL_TEMPLATE_INSTANTIATION (decl))
+ DECL_TEMPLATE_INFO (decl)
+ !uses_template_parms (DECL_TI_ARGS (decl)))
{
/* Instantiating a function will result in garbage collection. We
must treat this situation as if we were within the body of a
@@ -4327,8 +4327,12 @@ mark_used (tree decl)
times. Maintaining a stack of active functions is expensive,
and the inliner knows to instantiate any functions it might
need. Therefore, we always try to defer instantiation. */
-instantiate_decl (decl, /*defer_ok=*/true,
- /*expl_inst_class_mem_p=*/false);
+{
+ ++function_depth;
+ instantiate_decl (decl,
