Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling
2012/1/17 Jason Merrill ja...@redhat.com: On 01/17/2012 02:41 PM, Kai Tietz wrote: Right, but in second call we get for cplus_decl_attributes's late_attrs (as result of splice_template_attributes) the same value as already stored in decl_p's attributes. Right, but why is it already stored there? Jason The approach to disable cplus_decl_attributes call in do_friend (as we assume that prior grok* function it is calling it already) doesn't work. Eg the tests in g++.dg/ext/attribute-test-[34].C are failing for c++11. do_friend is called here via grokdeclarator for 'fTest' (test 3) and the attributes weren't applied before. So removing here in do_friend the call of cplus_decl_attributes seems wrong. With my orginal patch those tests are passing. Regards, Kai
Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins
On Tue, 17 Jan 2012, Aldy Hernandez wrote: What I have in mind is to abstract out the initialization of TM builtins from gtm-builtins.def (through its inclusion in builtins.def) into a separate function that we can call either in c_define_builtins() from the C-ish front-ends, or from lto_define_builtins (once we encounter a TM builtin and enable flag_tm appropriately). Hm? They are included in builtins.def, that looks appropriate for middle-end builtins. Thus they should be initialized by lto1, too. Are they not? Since flag_tm is NULL, when lto_define_builtins runs, the TM builtins do not get initialized. This is because DEF_TM_BUILTIN is predicated on flag_tm. Ok, so arrange that -fgnu-tm is enabled at link-time as soon as it was enabled in one TU. You can do that alongside handling of OPT_fPIC, etc. in lto-wrapper.c:merge_and_complain. It isn't until streamer_get_builtin_tree() that we realize the object file has a TM builtin. I see. Probably similar issues exist with -fopenmp and the GOMP builtins. Richard.
Re: PR other/51165: add new adress_escapes predicate
On Tue, Jan 17, 2012 at 5:41 PM, Patrick Marlier
patrick.marl...@gmail.com wrote:
On 01/17/2012 08:20 AM, Aldy Hernandez wrote:
On 01/17/12 03:09, Richard Guenther wrote:
On Mon, Jan 16, 2012 at 4:58 PM, Aldy Hernandezal...@redhat.com wrote:
Not really - you handle both ptr and *ptr in the same predicate and
call both address escaped. What I suggested was sth like
I think I confused myself and you by asking the wrong question in the
first
place.
Actually, what I want is to handle VAR_DECL correctly, and your original
suggestion of using may_be_aliased() fits the bill. The other calls to
ptr_deref_may_alias_global_p() were fine because we have an SSA_NAME.
We're now down to a one-liner :).
How about this? All TM memory optimization tests fixed, and no
regressions.
Ok. Note that may_be_aliased (x) is also true if x is an automatic
variable
that has its address taken. You can use is_global_var (x) instead if you
only want to test for global memory.
Richard.
is_global_var is fine. Thanks.
Committed.
I disagree. is_global_var is already tested just above:
if (is_global_var (x))
return !TREE_READONLY (x);
Which make sense since we don't want to log if it is read-only.
So you can do probably the following:
Index: trans-mem.c
===
--- trans-mem.c (revision 183253)
+++ trans-mem.c (working copy)
@@ -1497,8 +1497,6 @@ requires_barrier (basic_block entry_block, tree x,
to needs_to_live_in_memory until we eliminate
lower_sequence_tm altogether. */
needs_to_live_in_memory (x)
- /* X escapes. */
- || is_global_var (x))
True, because needs_to_live_in_memory is true for all global vars already
(and includes all address-taken automatic vars as well, thus may_be_aliased (x),
too).
Richard.
return true;
else
{
Thanks.
Patrick Marlier.
Re: [PATCH] Improve SCEV for array element
On Wed, Jan 18, 2012 at 8:41 AM, Jiangning Liu jiangning@arm.com wrote:
This code change intends to improve scev for array element and reduce the
common sub-expressions in loop, which may be introduced by multiple
reference of expression like a[i]. With this optimization the register
pressure can be reduced in loops.
The problem is originally from a real benchmark, and the test case only
tries to detect the GIMPLE level changes.
Bootstraped on x86-32. OK for trunk?
It's definitely not ok at this stage but at most for next stage1. But ...
ChangeLog:
2012-01-05 Jiangning Liu jiangning@arm.com
* tree-scalar-evolution (interpret_rhs_expr): generate chrec for
array reference.
ChangeLog for testsuite:
2012-01-05 Jiangning Liu jiangning@arm.com
* gcc.dg/scev-1.c: New.
diff --git a/gcc/testsuite/gcc.dg/scev-1.c b/gcc/testsuite/gcc.dg/scev-1.c
new file mode 100644 index 000..28d5c93
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/scev-1.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-optimized } */
+
+int *a_p;
+int a[1000];
+
+f(int k)
+{
+ int i;
+
+ for (i=k; i1000; i+=k) {
+ a_p = a[i];
+ *a_p = 100;
+ }
+}
+
+/* { dg-final { scan-tree-dump-times a 1 optimized } } */
+/* { dg-final { cleanup-tree-dump optimized } } */
diff --git a/gcc/tree-scalar-evolution.c b/gcc/tree-scalar-evolution.c index
2077c8d..de89fc4
--- a/gcc/tree-scalar-evolution.c
+++ b/gcc/tree-scalar-evolution.c
@@ -1712,6 +1712,42 @@ interpret_rhs_expr (struct loop *loop, gimple
at_stmt,
switch (code)
{
case ADDR_EXPR:
+ if (TREE_CODE (TREE_OPERAND (rhs1, 0)) == ARRAY_REF)
This is a very narrow pattern-match. It doesn't allow for a[i].x for example,
even if a[i] is a one-element structure. I think the canonical way of handling
ADDR_EXPR is to use sth like
base = get_inner_reference (TREE_OPERAND (rhs1, 0), ..., offset, ...);
base = build1 (ADDR_EXPR, TREE_TYPE (rhs1), base);
chrec1 = analyze_scalar_evolution (loop, base);
chrec2 = analyze_scalar_evolution (loop, offset);
chrec1 = chrec_convert (type, chrec1, at_stmt);
chrec2 = chrec_convert (TREE_TYPE (offset), chrec2, at_stmt);
res = chrec_fold_plus (type, chrec1, chrec2);
where you probably need to handle scev_not_known when analyzing offset
(which might be NULL). You also need to add bitpos to the base address
(in bytes, of course). Note that the MEM_REF case would naturally work
with this as well.
Richard.
+ {
+ tree array_ref;
+ tree var_decl, base, offset;
+ tree low_bound;
+ tree unit_size;
+ tree index;
+
+ array_ref = TREE_OPERAND (rhs1, 0);
+ var_decl = TREE_OPERAND (array_ref, 0);
+ index = TREE_OPERAND (array_ref, 1);
+
+ low_bound = array_ref_low_bound (array_ref);
+ unit_size = array_ref_element_size (array_ref);
+
+ /* We assume all arrays have sizes that are a multiple of a byte.
+ First subtract the lower bound, if any, in the type of the
+ index, then convert to sizetype and multiply by the size of
+ the array element. */
+ if (! integer_zerop (low_bound))
+ index = fold_build2 (MINUS_EXPR, TREE_TYPE (index),
+ index, low_bound);
+
+ offset = size_binop (MULT_EXPR,
+ fold_convert (sizetype, index),
+ unit_size);
+
+ base = build1 (ADDR_EXPR, TREE_TYPE (rhs1), var_decl);
+ chrec1 = analyze_scalar_evolution (loop, base);
+ chrec2 = analyze_scalar_evolution (loop, offset);
+ chrec1 = chrec_convert (type, chrec1, at_stmt);
+ chrec2 = chrec_convert (TREE_TYPE (offset), chrec2, at_stmt);
+ res = chrec_fold_plus (type, chrec1, chrec2);
+ break;
+ }
+
/* Handle MEM[ptr + CST] which is equivalent to POINTER_PLUS_EXPR.
*/
if (TREE_CODE (TREE_OPERAND (rhs1, 0)) != MEM_REF)
{
Thanks,
-Jiangning
Re: libgo patch committed: Update to weekly.2011-12-22
Ian Lance Taylor i...@google.com writes: The patch introduced a couple of other problems: * There's a warning during libgo configure: * Bootstrap on Solaris 11 is broken: * The IRIX libgo build is broken like this: Thanks a lot. All committed. I hadn't bootstrapped with the fixes before submitting, but doing it now shows a serious problem on Solaris 8 and 9: libgo now makes uses of many C99 math functions, some of which are missing, as can be seen with ldd -r. The situation differs between Solaris/SPARC symbol not found: log2 (.libs/libgo.so) symbol not found: trunc (.libs/libgo.so) and Solaris/x86: symbol not found: acosl (.libs/libgo.so) symbol not found: asinl (.libs/libgo.so) symbol not found: atan2l(.libs/libgo.so) symbol not found: atanl (.libs/libgo.so) symbol not found: cosl (.libs/libgo.so) symbol not found: expl (.libs/libgo.so) symbol not found: expm1l(.libs/libgo.so) symbol not found: ldexpl(.libs/libgo.so) symbol not found: log10l(.libs/libgo.so) symbol not found: log1pl(.libs/libgo.so) symbol not found: log2l (.libs/libgo.so) symbol not found: logl (.libs/libgo.so) symbol not found: sinl (.libs/libgo.so) symbol not found: tanl (.libs/libgo.so) symbol not found: trunc (.libs/libgo.so) The Studio compilers include libsunmath.so.1 which provides those functions (among others), but neither can one rely on the compilers being installed now do they end up in a fixed location. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling
I noticed that the previous patch still had issues about more then one attribute added. The underlying issue seems here that we shouldn't chain attributes simply, but we should merge them. I did full bootstrap for it and ran regression tests for x86_64-unknown-linux-gnu. Ok for apply? Regards, Kai Revised patch: Index: gcc/cp/decl2.c === --- gcc/cp/decl2.c (revision 183106) +++ gcc/cp/decl2.c (working copy) @@ -1200,9 +1200,9 @@ old_attrs = *q; - /* Place the late attributes at the beginning of the attribute + /* Merge the late attributes at the beginning with the attribute list. */ - TREE_CHAIN (tree_last (late_attrs)) = *q; + late_attrs = merge_attributes (late_attrs, *q); *q = late_attrs; if (!DECL_P (*decl_p) *decl_p == TYPE_MAIN_VARIANT (*decl_p))
Bug store_bit_field_1 + patch
Hi,
I've found a bug in store_bit_field_1 for BIG_ENDIAN targets whose words
are HI. The testcase is execute.exp=bitfld-3.c for my target (which is
not public).
It occurs on 4.6.1 release, but seem to be present in trunk (looking at
the code, not executed).
The problem occurs when value is a REG and bitsize BITS_PER_WORD. This
is because wordnum, which is used to get the subword of value, is
incorrectly computed, in BIG_ENDIAN, wrt the number of words needed by
bitsize instead of the number of words needed by the integer mode of the
field, which is the mode used to compute subwords.
For instance, for a 40bit field to be set by a DI reg (with HI words),
the offset of the LSWord of the DI reg should be 3, not 2 as currently
computed.
The following patch seems to solve the issue. Tested on the C testsuite
without any regression (for my target only).
Hope it helps,
Aurélien
--- expmed.c.orig 2012-01-18 11:48:21.0 +0100
+++ expmed.c2012-01-18 11:49:19.0 +0100
@@ -589,7 +589,10 @@
{
/* If I is 0, use the low-order word in both field and target;
if I is 1, use the next to lowest word; and so on. */
- unsigned int wordnum = (backwards ? nwords - i - 1 : i);
+ unsigned int wordnum = (backwards
+ ? GET_MODE_SIZE(fieldmode)/UNITS_PER_WORD
+- i - 1
+ : i);
unsigned int bit_offset = (backwards
? MAX ((int) bitsize - ((int) i + 1)
* BITS_PER_WORD,
Re: Fix checks for !TARGET_MACHO
On Tue, 17 Jan 2012, Tijl Coosemans wrote: TARGET_MACHO is always defined (either 0 or 1) so using #ifndef to test for !TARGET_MACHO is incorrect. Introduced here: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00623.html The i386 case has been tested on i386-freebsd. The compiler now emits calls to __stack_chk_fail_local again when using -fstack-protector -fpic. The rs6000 cases are untested. I don't have commit access, so please commit when approved. 2011-01-10 Tijl Coosemans t...@coosemans.org * config/i386/i386.c: Fix checks for !TARGET_MACHO. * config/rs6000/rs6000.c: Likewise. Reviewers, I volunteer to commit when/if approved. (This fixes an issue I care about. :-) Gerald
Re: [Patch, fortran] PR 51808 Heap allocate binding labels
On 18.01.2012 10:12, Tobias Burnus wrote:
Dear Janne,
the attached patch changes the binding labels that are needed for
bind(C) symbols to be heap allocated rather than, as currently, being
fixed size arrays of size 127 (or 64 in module.c!?).
wonder whether it would have been smarter to use string matching rather
than the manual matching in gfc_match_name_C to obtain longer strings.
(Cf. PR 36275. Different but related binding label issue: PR 38839.)
On the other hand, that's separate issues, deserving patches on their own.
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -2744,14 +2747,16 @@ gfc_iso_c_func_interface (gfc_symbol *sym,
{
/* two args. */
sprintf (name, %s_2, sym-name);
- sprintf (binding_label, %s_2, sym-binding_label);
+ if (sym-binding_label)
+ sprintf (binding_label, %s_2, sym-binding_label);
optional_arg = 1;
I wonder whether one can get rid of all those binding names. I think
they date back to the time when a libgfortran function was called for
ISOCBINDING_ASSOCIATED instead of just generating in trans-intrinsics.c
one (ptr != NULL) or two (ptr != NULL ptr == tgt) pointer comparisons.
I also believe that C_LOC and C_FUNLOC are (now) handled in
trans-intrinsics.c. Thus, you could confirm that no binding name is
needed and remove them.
Otherwise, the patch looks relatively mechnical and is OK.
Tobias
Hello,
We could consider using gfc_get_string (instead of the many strcpy) to
ease memory management.
Mikael
Re: Fix checks for !TARGET_MACHO
On 18 Jan 2012, at 12:26, Gerald Pfeifer wrote: On Tue, 17 Jan 2012, Tijl Coosemans wrote: TARGET_MACHO is always defined (either 0 or 1) so using #ifndef to test for !TARGET_MACHO is incorrect. Introduced here: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00623.html The i386 case has been tested on i386-freebsd. The compiler now emits calls to __stack_chk_fail_local again when using -fstack-protector - fpic. The rs6000 cases are untested. I'll try and fit a test in, in the next couple of days, my ppc machine is in a test-cycle at the moment. equally important is to test that it doesn't mess up anything else - which could be done by building a cross - powerpc-unknown-linux? I don't have commit access, so please commit when approved. 2011-01-10 Tijl Coosemans t...@coosemans.org * config/i386/i386.c: Fix checks for !TARGET_MACHO. * config/rs6000/rs6000.c: Likewise. Reviewers, I volunteer to commit when/if approved. (This fixes an issue I care about. :-) it looks reasonable to me, but I am not able to approve (or reject) it. Iain
Re: Fix checks for !TARGET_MACHO
On Wed, Jan 18, 2012 at 01:26:29PM +0100, Gerald Pfeifer wrote: On Tue, 17 Jan 2012, Tijl Coosemans wrote: TARGET_MACHO is always defined (either 0 or 1) so using #ifndef to test for !TARGET_MACHO is incorrect. Introduced here: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00623.html The i386 case has been tested on i386-freebsd. The compiler now emits calls to __stack_chk_fail_local again when using -fstack-protector -fpic. The rs6000 cases are untested. I don't have commit access, so please commit when approved. 2011-01-10 Tijl Coosemans t...@coosemans.org * config/i386/i386.c: Fix checks for !TARGET_MACHO. * config/rs6000/rs6000.c: Likewise. Reviewers, I volunteer to commit when/if approved. (This fixes an issue I care about. :-) This is ok for trunk. Jakub
[PATCH] Fix different-pointer-size issue
This left-over reportedly breaks casts between different pointer sizes. Removed thus, it has become obsolete. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-01-18 Richard Guenther rguent...@suse.de * tree-ssa.c (useless_type_conversion_p): Remove special-casing of conversions to void *. Index: gcc/tree-ssa.c === --- gcc/tree-ssa.c (revision 183270) +++ gcc/tree-ssa.c (working copy) @@ -1199,10 +1199,6 @@ useless_type_conversion_p (tree outer_ty if (TYPE_ADDR_SPACE (TREE_TYPE (outer_type)) != TYPE_ADDR_SPACE (TREE_TYPE (inner_type))) return false; - - /* If the outer type is (void *), the conversion is not necessary. */ - if (VOID_TYPE_P (TREE_TYPE (outer_type))) - return true; } /* From now on qualifiers on value types do not matter. */
Re: C++ PATCH for c++/51827 (mangling error with PCH and LTO)
On Tue, Jan 17, 2012 at 5:22 PM, Jason Merrill ja...@redhat.com wrote: On 01/17/2012 09:51 AM, Richard Guenther wrote: Sure it works. PCH is just a stage where LTO is not active yet. That makes sense to me. Applied then. Richard. Jason
Re: PR other/51165: add new adress_escapes predicate
So you can do probably the following:
Index: trans-mem.c
===
--- trans-mem.c (revision 183253)
+++ trans-mem.c (working copy)
@@ -1497,8 +1497,6 @@ requires_barrier (basic_block entry_block, tree x,
to needs_to_live_in_memory until we eliminate
lower_sequence_tm altogether. */
needs_to_live_in_memory (x)
- /* X escapes. */
- || is_global_var (x))
True, because needs_to_live_in_memory is true for all global vars already
(and includes all address-taken automatic vars as well, thus may_be_aliased (x),
too).
Sweet. Thanks guys.
Richard, I assume you are OK with this?
Tested on x86-64 Linux.
* trans-mem.c (requires_barrier): Remove call to is_global_var.
Index: trans-mem.c
===
--- trans-mem.c (revision 183272)
+++ trans-mem.c (working copy)
@@ -1496,9 +1496,7 @@ requires_barrier (basic_block entry_bloc
during lower_sequence_tm/gimplification, leave the call
to needs_to_live_in_memory until we eliminate
lower_sequence_tm altogether. */
- needs_to_live_in_memory (x)
- /* X escapes. */
- || is_global_var (x))
+ needs_to_live_in_memory (x))
return true;
else
{
Re: PR other/51165: add new adress_escapes predicate
On Wed, Jan 18, 2012 at 3:00 PM, Aldy Hernandez al...@redhat.com wrote: So you can do probably the following: Index: trans-mem.c === --- trans-mem.c (revision 183253) +++ trans-mem.c (working copy) @@ -1497,8 +1497,6 @@ requires_barrier (basic_block entry_block, tree x, to needs_to_live_in_memory until we eliminate lower_sequence_tm altogether. */ needs_to_live_in_memory (x) - /* X escapes. */ - || is_global_var (x)) True, because needs_to_live_in_memory is true for all global vars already (and includes all address-taken automatic vars as well, thus may_be_aliased (x), too). Sweet. Thanks guys. Richard, I assume you are OK with this? Yes. Richard. Tested on x86-64 Linux.
Re: Go patch committed: Recognize more test lines
Uros Bizjak ubiz...@gmail.com writes: This patch to the Go testsuite driver recognizes a few more test lines in Go tests. I somehow failed to notice these the last time I updated the Go testsuite. This patch includes a couple of changes to make the newly recognized tests pass. Ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Some of the go tests require explicit -mieee compile flag [1]. Is there a way to conditionally pass this flag to the compiler? What does Java do? For Go, like Java, we should turn on the -mieee option by default. Both Go and Java specify the floating point model precisely--Go not as precisely as Java, but it does require denormals to be supported. Unfortunately I'm not sure how to do that. My best idea at the moment is to add a new target hook to common/common-target.def meaning we actually care about floating point. That said, it would be easy enough to handle -mieee to way we handle -minline-all-stringops in libgo/configure.ac and libgo/Makefile.am. That would let us use -mieee when building and testing libgo. But it should really be the default in all cases, not just libgo. Ian
[PATCH] Fix PR49484, gthr requirements update (target maintainers have a looksee)
This fixes PR49484 by protecting __gcov_flush against concurrent
execution. To be able to use the gthread facility I have to
introduce the requirement that __GTHREAD_MUTEX_INIT_FUNCTION
is always available, even if __GTHREAD_MUTEX_INIT is available as
otherwise no dynamic initialization of a mutex is possible.
I have adjusted gthr-posix.h and gthr-single.h only - target
maintainers, please update your ports accordingly in advance.
Boostrap and regtest on x86_64-unknown-linux-gnu is ongoing,
but this looks like something for stage1 anyway.
Richard.
2012-01-18 Richard Guenther rguent...@suse.de
* gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
* gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
(__gthread_mutex_init_function): New function.
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
PR gcov/49484
* libgcov.c: Include gthr.h.
(__gcov_flush_mx): New global variable.
(init_mx, init_mx_once): New functions.
(__gcov_flush): Protect self with a mutex.
(__gcov_fork): Re-initialize mutex after forking.
* unwind-dw2-fde.c: Change condition under which to use
__GTHREAD_MUTEX_INIT_FUNCTION.
Index: libgcc/libgcov.c
===
*** libgcc/libgcov.c(revision 183270)
--- libgcc/libgcov.c(working copy)
*** see the files COPYING3 and COPYING.RUNTI
*** 30,35
--- 30,36
#include coretypes.h
#include tm.h
#include libgcc_tm.h
+ #include gthr.h
#if defined(inhibit_libc)
#define IN_LIBGCOV (-1)
*** __gcov_init (struct gcov_info *info)
*** 705,710
--- 706,730
info-version = 0;
}
+ #ifdef __GTHREAD_MUTEX_INIT
+ ATTRIBUTE_HIDDEN __gthread_mutex_t __gcov_flush_mx = __GTHREAD_MUTEX_INIT;
+ #define init_mx_once()
+ #else
+ __gthread_mutex_t __gcov_flush_mx ATTRIBUTE_HIDDEN;
+
+ static void
+ init_mx (void)
+ {
+ __GTHREAD_MUTEX_INIT_FUNCTION (mx);
+ }
+ static void
+ init_mx_once (void)
+ {
+ static __gthread_once_t once = __GTHREAD_ONCE_INIT;
+ __gthread_once (once, init_mx);
+ }
+ #endif
+
/* Called before fork or exec - write out profile information gathered so
far and reset it to zero. This avoids duplication or loss of the
profile information gathered so far. */
*** __gcov_flush (void)
*** 714,719
--- 734,742
{
const struct gcov_info *gi_ptr;
+ init_mx_once ();
+ __gthread_mutex_lock (__gcov_flush_mx);
+
gcov_exit ();
for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
{
*** __gcov_flush (void)
*** 737,742
--- 760,767
}
}
}
+
+ __gthread_mutex_unlock (__gcov_flush_mx);
}
#endif /* L_gcov */
*** __gcov_ior_profiler (gcov_type *counters
*** 975,982
pid_t
__gcov_fork (void)
{
__gcov_flush ();
! return fork ();
}
#endif
--- 1000,1012
pid_t
__gcov_fork (void)
{
+ pid_t pid;
+ extern __gthread_mutex_t __gcov_flush_mx;
__gcov_flush ();
! pid = fork ();
! if (pid == 0)
! __GTHREAD_MUTEX_INIT_FUNCTION (__gcov_flush_mx);
! return pid;
}
#endif
Index: libgcc/unwind-dw2-fde.c
===
*** libgcc/unwind-dw2-fde.c (revision 183270)
--- libgcc/unwind-dw2-fde.c (working copy)
*** static struct object *seen_objects;
*** 47,57
#ifdef __GTHREAD_MUTEX_INIT
static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
#else
static __gthread_mutex_t object_mutex;
- #endif
- #ifdef __GTHREAD_MUTEX_INIT_FUNCTION
static void
init_object_mutex (void)
{
--- 47,56
#ifdef __GTHREAD_MUTEX_INIT
static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
+ #define init_object_mutex_once()
#else
static __gthread_mutex_t object_mutex;
static void
init_object_mutex (void)
{
*** init_object_mutex_once (void)
*** 64,71
static __gthread_once_t once = __GTHREAD_ONCE_INIT;
__gthread_once (once, init_object_mutex);
}
- #else
- #define init_object_mutex_once()
#endif
/* Called from crtbegin.o to register the unwind info for an object. */
--- 63,68
Index: libgcc/gthr-posix.h
===
*** libgcc/gthr-posix.h (revision 183270)
--- libgcc/gthr-posix.h (working copy)
*** typedef struct timespec __gthread_time_t
*** 63,68
--- 63,69
#define __GTHREAD_HAS_COND1
#define __GTHREAD_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER
+ #define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function
#define __GTHREAD_ONCE_INIT PTHREAD_ONCE_INIT
#if defined(PTHREAD_RECURSIVE_MUTEX_INITIALIZER)
#define __GTHREAD_RECURSIVE_MUTEX_INIT PTHREAD_RECURSIVE_MUTEX_INITIALIZER
*** __gthread_setspecific (__gthread_key_t _
*** 731,736
--- 732,745
}
Re: Cross-build breakage with libstdc++-v3 doc changes
Hans-Peter Nilsson wrote: From: Benjamin Kosnik b...@redhat.com Date: Wed, 18 Jan 2012 00:41:59 +0100 This updates the support for generating epub docs to EPUB3. Using the EPUB3 stylesheets allows the removal of ruby and other tool checks from configure, and generates a much better documentation file. ...or for cross-targets, breakage. Something went wrong with this or subsequent changes; somewhere in the r183262:183268 I've started getting: [snip] checking for /usr/share/xml/docbook/stylesheet/docbook-xsl-ns/epub3/chunk.xsl... configure: error: cannot check for file existence when cross compiling make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/tmp/hpautotest-gcc1/cris-elf/gccobj' make: *** [all] Error 2 Yes, I'm seeing the same problem when building a spu-elf cross-compiler ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [build] Disable dl_iterate_phdr on Solaris 10
On 01/17/2012 10:43 AM, Rainer Orth wrote: Rainer Orthr...@cebitec.uni-bielefeld.de writes: 2012-01-15 Rainer Orthr...@cebitec.uni-bielefeld.de * configure.ac (gcc_cv_target_dl_iterate_phdr): Only check on Solaris 11+. * configure: Regenerate. It helps to actually attach the patch. Ok. Paolo
[Patch ARM] Fix PR50313 and handle PIC addresses properly.
Hi ,
PR50313 is a case where having the 2 patterns pic_load_addr_* and
pic_add_dot_plus_eight/four from expand time becomes a problem as
discussed by Jakub in his comment in the audit trail for PR48308.
There is a separate problem in combine as explained by my comment in
the audit trail for PR48308 and my RFC patch for the same sometime
last week.
What I've done in this case is to take the existing patterns merged
them into a UNIFIED form which means that we can hoist the entire
computation out with any of the loop optimizers rather than piece-meal
hoping to have each one being hoisted correctly. I've had to adjust
the cost of this to be equivalent to that of a memory load ( it's in
fact the cost of a memory load + the cost of an add instruction but
it's good enough for the moment). It's reasonably close enough for
arm_size_rtx_costs, and thumb1_rtx_costs pushes this high enough that
it will warrant a hoist anyway. I've also been conservative in
adjusting cannot_copy_insn_p to disallow copying such insns to prevent
any cases where you might have duplicate labels being generated.
Once this happens the original bug report in PR50313 appears to be
fixed and I've had this survive a bootstrap and regression test on an
A9 board and this has successfully cross-built a version of eglibc
with an ARM v7-a configuration (which is currently undergoing
testing).
There are a few ways by which we can get better code - one is to
replace the load from the constant pool with a movw / movt pair of the
actual differences in which case we'd be able to get performant code
in libraries for this case, the other which as RichardE suggested in a
conversation was to allow the splitter to actually generate the
internal labels in the pic_load_addr and pic_add_dot_plus_eight which
could then mean that the label number is really not reserved until
this complex pattern has been split. I don't think these enhancements
are worth doing so late in stage4 and I do want to backport this patch
as it stands into the 4.6 branch.
OK (and to backport to 4.6 branch ?) if no regressions ?
cheers
Ramana
2012-01-18 Ramana Radhakrishnan ramana.radhakrish...@linaro.org
PR target/50313
* config/arm/arm.c (arm_load_pic_register): Use
gen_pic_load_addr_unified. Delete calls to gen_pic_load_addr_32bit
, gen_pic_add_dot_plus_eight and gen_pic_add_dot_plus_four.
(arm_pic_static_addr): Likewise.
(arm_rtx_costs_1): Adjust cost for UNSPEC_PIC_UNIFIED.
(arm_note_pic_base): Handle UNSPEC_PIC_UNIFIED.
* config/arm/arm.md (UNSPEC_PIC_UNIFIED): Define.
(pic_load_addr_unified): New.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 4c310d4..240434f 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -5578,11 +5578,7 @@ arm_load_pic_register (unsigned long saved_regs
ATTRIBUTE_UNUSED)
if (TARGET_32BIT)
{
- emit_insn (gen_pic_load_addr_32bit (pic_reg, pic_rtx));
- if (TARGET_ARM)
- emit_insn (gen_pic_add_dot_plus_eight (pic_reg, pic_reg, labelno));
- else
- emit_insn (gen_pic_add_dot_plus_four (pic_reg, pic_reg, labelno));
+ emit_insn (gen_pic_load_addr_unified (pic_reg, pic_rtx, labelno));
}
else /* TARGET_THUMB1 */
{
@@ -5595,10 +5591,10 @@ arm_load_pic_register (unsigned long saved_regs
ATTRIBUTE_UNUSED)
thumb_find_work_register (saved_regs));
emit_insn (gen_pic_load_addr_thumb1 (pic_tmp, pic_rtx));
emit_insn (gen_movsi (pic_offset_table_rtx, pic_tmp));
+ emit_insn (gen_pic_add_dot_plus_four (pic_reg, pic_reg, labelno));
}
else
- emit_insn (gen_pic_load_addr_thumb1 (pic_reg, pic_rtx));
- emit_insn (gen_pic_add_dot_plus_four (pic_reg, pic_reg, labelno));
+ emit_insn (gen_pic_load_addr_unified (pic_reg, pic_rtx, labelno));
}
}
@@ -5628,20 +5624,7 @@ arm_pic_static_addr (rtx orig, rtx reg)
UNSPEC_SYMBOL_OFFSET);
offset_rtx = gen_rtx_CONST (Pmode, offset_rtx);
- if (TARGET_32BIT)
-{
- emit_insn (gen_pic_load_addr_32bit (reg, offset_rtx));
- if (TARGET_ARM)
-insn = emit_insn (gen_pic_add_dot_plus_eight (reg, reg, labelno));
- else
-insn = emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
-}
- else /* TARGET_THUMB1 */
-{
- emit_insn (gen_pic_load_addr_thumb1 (reg, offset_rtx));
- insn = emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
-}
-
+ insn = emit_insn (gen_pic_load_addr_unified (reg, offset_rtx, labelno));
return insn;
}
@@ -7648,6 +7631,15 @@ arm_rtx_costs_1 (rtx x, enum rtx_code outer, int* total,
bool speed)
case SET:
return false;
+
+case UNSPEC:
+ /* We cost this as high as our memory costs to allow this to
+be hoisted from loops. */
+ if (XINT (x, 1) ==
Re: [Patch ARM] Fix PR50313 and handle PIC addresses properly.
On Wed, Jan 18, 2012 at 03:03:47PM +, Ramana Radhakrishnan wrote: +;; operand1 is the memory address to go into pic_load_addr_32bit. +;; operand2 is the PIC label to be emitted from pic_add_dot_plus_*. +;; We do this to allow hoisting of the entire c +(define_insn_and_split pic_load_addr_unified + [(set (match_operand:SI 0 s_register_operand =r,r,l) + (unspec:SI [(match_operand:SI 1 mX,mX,mX) + (match_operand:SI 2 )] + UNSPEC_PIC_UNIFIED))] + flag_pic + # + flag_pic What's the reason to duplicate the condition here? If flag_pic isn't non-zero, then the insn wouldn't match, therefore wouldn't be split... Also, while this fixes the testcase, at least if you split it before reload e.g. first scheduling pass might move away the two insns far away from each other, register allocation might decide to spill the pseudo set by the first insn to the stack and the same problem could reappear. That doesn't mean your patch isn't an incremental improvement. + [(set (match_dup 3) (unspec:SI [(match_dup 1)] UNSPEC_PIC_SYM)) + (set (match_dup 0) (unspec:SI [(match_dup 3) (match_dup 4) + (match_dup 2)] UNSPEC_PIC_BASE))] + operands[3] = can_create_pseudo_p () ? gen_reg_rtx (SImode) : operands[0]; + operands[4] = TARGET_THUMB ? GEN_INT (4) : GEN_INT (8); + [(set_attr type load1,load1,load1) + (set_attr pool_range 4096,4096,1024) + (set_attr neg_pool_range 0,4084,0) + (set_attr arch a,t2,t1) + (set_attr length 8,6,4)] +) + Jakub
Re: [PATCH] Fix g++.dg/cpp0x/constexpr-rom.C failure
* g++.dg/cpp0x/constexpr-rom.C: Add -G0 where applicable. It fails on powerpc-apple-darwin9 with FAIL: g++.dg/cpp0x/constexpr-rom.C (test for excess errors) Excess errors: g++: error: unrecognized option '-G' TIA Dominique
Re: [C++ Patch] PR 51225
Hi,
So, the issue here is that fold_non_dependent_expr_sfinae checks
potential_constant_expression, and doesn't fold anything which isn't one.
One approach would be to only guard cxx_constant_value with
require_potential_constant_expression within a template.
Thanks. Thus I tried to implement your suggestion with the below, which
indeed passes testing on x86_64-linux. Is it what you had mind?
Thanks,
Paolo.
/cp
2012-01-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/51225
* typeck2.c (store_init_value): Within a template guard
cxx_constant_value with require_potential_constant_expression.
* pt.c (convert_nontype_argument): Likewise.
/testsuite
2012-01-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/51225
* g++.dg/cpp0x/pr51225.C: New.
Index: testsuite/g++.dg/cpp0x/pr51225.C
===
--- testsuite/g++.dg/cpp0x/pr51225.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr51225.C(revision 0)
@@ -0,0 +1,14 @@
+// PR c++/51225
+// { dg-options -std=c++0x }
+
+templateint struct A {};
+
+templatetypename void foo()
+{
+ Aint(x) a; // { dg-error not declared|invalid type }
+}
+
+templatetypename struct bar
+{
+ static constexpr A1 b = A1(x); // { dg-error not declared }
+};
Index: cp/typeck2.c
===
--- cp/typeck2.c(revision 183273)
+++ cp/typeck2.c(working copy)
@@ -718,8 +718,14 @@ store_init_value (tree decl, tree init, VEC(tree,g
value = fold_non_dependent_expr (value);
value = maybe_constant_init (value);
if (DECL_DECLARED_CONSTEXPR_P (decl))
- /* Diagnose a non-constant initializer for constexpr. */
- value = cxx_constant_value (value);
+ {
+ /* Diagnose a non-constant initializer for constexpr. */
+ if (processing_template_decl
+ !require_potential_constant_expression (value))
+ value = error_mark_node;
+ else
+ value = cxx_constant_value (value);
+ }
const_init = (reduced_constant_expression_p (value)
|| error_operand_p (value));
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl) = const_init;
Index: cp/pt.c
===
--- cp/pt.c (revision 183273)
+++ cp/pt.c (working copy)
@@ -5807,6 +5807,9 @@ convert_nontype_argument (tree type, tree expr, ts
if (complain tf_error)
{
int errs = errorcount, warns = warningcount;
+ if (processing_template_decl
+ !require_potential_constant_expression (expr))
+ return NULL_TREE;
expr = cxx_constant_value (expr);
if (errorcount errs || warningcount warns)
inform (EXPR_LOC_OR_HERE (expr),
Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins
On 01/18/12 03:09, Richard Guenther wrote:
On Tue, 17 Jan 2012, Aldy Hernandez wrote:
What I have in mind is to abstract out the initialization of TM builtins
from
gtm-builtins.def (through its inclusion in builtins.def) into a separate
function that we can call either in c_define_builtins() from the C-ish
front-ends, or from lto_define_builtins (once we encounter a TM builtin
and
enable flag_tm appropriately).
Hm? They are included in builtins.def, that looks appropriate for
middle-end builtins. Thus they should be initialized by lto1, too.
Are they not?
Since flag_tm is NULL, when lto_define_builtins runs, the TM builtins do not
get initialized. This is because DEF_TM_BUILTIN is predicated on flag_tm.
Ok, so arrange that -fgnu-tm is enabled at link-time as soon as it was
enabled in one TU. You can do that alongside handling of OPT_fPIC, etc.
in lto-wrapper.c:merge_and_complain.
The following patch fixes the problem.
OK?
It isn't until streamer_get_builtin_tree() that we realize the object file has
a TM builtin.
I see. Probably similar issues exist with -fopenmp and the GOMP
builtins.
It is my understanding that openmp is lowered before LTO streaming, so
this isn't a problem for it. I manually tested something similar to the
testcase in the patch below (but for openmp) and verified that openmp
does not suffer from this problem.
Thanks for the suggestion.
PR lto/51280
* lto-wrapper.c (run_gcc): Pass -fgnu_tm on.
(merge_and_complain): Same.
Index: testsuite/gcc.dg/lto/trans-mem-3_0.c
===
--- testsuite/gcc.dg/lto/trans-mem-3_0.c(revision 0)
+++ testsuite/gcc.dg/lto/trans-mem-3_0.c(revision 0)
@@ -0,0 +1,8 @@
+/* { dg-lto-options {{-flto}} } */
+/* { dg-lto-do link } */
+
+/* Test that we can build one object file with -fgnu-tm
+ (trans-mem-3_1.c), but do the final link of all objects without
+ -fgnu-tm. */
+
+int i;
Index: testsuite/gcc.dg/lto/trans-mem-3_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-3_1.c(revision 0)
+++ testsuite/gcc.dg/lto/trans-mem-3_1.c(revision 0)
@@ -0,0 +1,18 @@
+/* { dg-options -fgnu-tm } */
+
+extern int i;
+
+main()
+{
+ __transaction_atomic { i = 0; }
+}
+
+#define dummy(func)\
+ __attribute__((noinline,noclone,used)) void func() { asm (); }
+
+dummy(_ITM_beginTransaction)
+dummy(_ITM_commitTransaction)
+dummy(_ITM_WU4)
+dummy(_ITM_WU8)
+dummy(_ITM_registerTMCloneTable)
+dummy(_ITM_deregisterTMCloneTable)
Index: lto-wrapper.c
===
--- lto-wrapper.c (revision 183244)
+++ lto-wrapper.c (working copy)
@@ -403,6 +403,7 @@ merge_and_complain (struct cl_decoded_op
case OPT_fpie:
case OPT_fcommon:
case OPT_fexceptions:
+ case OPT_fgnu_tm:
/* Do what the old LTO code did - collect exactly one option
setting per OPT code, we pick the first we encounter.
??? This doesn't make too much sense, but when it doesn't
@@ -555,6 +556,7 @@ run_gcc (unsigned argc, char *argv[])
case OPT_fpie:
case OPT_fcommon:
case OPT_fexceptions:
+ case OPT_fgnu_tm:
break;
default:
Re: [PATCH] Fix g++.dg/cpp0x/constexpr-rom.C failure
domi...@lps.ens.fr (Dominique Dhumieres) writes: * g++.dg/cpp0x/constexpr-rom.C: Add -G0 where applicable. It fails on powerpc-apple-darwin9 with FAIL: g++.dg/cpp0x/constexpr-rom.C (test for excess errors) Excess errors: g++: error: unrecognized option '-G' That is strange, g.opt is added to extra_options for all powerpc*-*-* in config.gcc. The only target that removes something from extra_options is xstormy16-*-elf. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[PATCH] Fix PR 51505
Hello,
As discussed in Bugzilla, this is the patch implementing Paolo's suggestion
of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes. The code assumes
there is at most one such note per insn. Bootstrapped and tested on
x86-64, ok for trunk?
Andrey
gcc:
2012-01-18 Andrey Belevantsev a...@ispras.ru
PR rtl-optimization/51505
* df-problems.c (df_kill_notes): New parameter live. Update comment.
Remove REG_EQUAL/REG_EQUIV notes referring to dead registers.
(df_note_bb_compute): Update the call to df_kill_notes.
testsuite:
2012-01-18 Andrey Belevantsev a...@ispras.ru
PR rtl-optimization/51505
* gcc.dg/pr51505.c: New test.
diff --git a/gcc/df-problems.c b/gcc/df-problems.c
index 8928454..f9b0bc1 100644
--- a/gcc/df-problems.c
+++ b/gcc/df-problems.c
@@ -2748,10 +2748,12 @@ df_ignore_stack_reg (int regno ATTRIBUTE_UNUSED)
/* Remove all of the REG_DEAD or REG_UNUSED notes from INSN and add
- them to OLD_DEAD_NOTES and OLD_UNUSED_NOTES. */
+ them to OLD_DEAD_NOTES and OLD_UNUSED_NOTES. Remove also
+ REG_EQUAL/REG_EQUIV notes referring to dead pseudos using LIVE
+ as the bitmap of currently live registers. */
static void
-df_kill_notes (rtx insn)
+df_kill_notes (rtx insn, bitmap live)
{
rtx *pprev = REG_NOTES (insn);
rtx link = *pprev;
@@ -2798,6 +2800,45 @@ df_kill_notes (rtx insn)
}
break;
+ case REG_EQUAL:
+ case REG_EQUIV:
+ {
+ /* Remove the notes that refer to dead registers. As we have at most
+ one REG_EQUAL/EQUIV note, all of EQ_USES will refer to this note
+ so we need to purge the complete EQ_USES vector when removing
+ the note using df_notes_rescan. */
+ df_ref *use_rec;
+ bool deleted = false;
+
+ for (use_rec = DF_INSN_EQ_USES (insn); *use_rec; use_rec++)
+ {
+ df_ref use = *use_rec;
+ if (DF_REF_REGNO (use) FIRST_PSEUDO_REGISTER
+ (DF_REF_FLAGS (use) DF_REF_IN_NOTE)
+ ! bitmap_bit_p (live, DF_REF_REGNO (use)))
+ {
+ deleted = true;
+ break;
+ }
+ }
+ if (deleted)
+ {
+ rtx next;
+#ifdef REG_DEAD_DEBUGGING
+ df_print_note (deleting: , insn, link);
+#endif
+ next = XEXP (link, 1);
+ free_EXPR_LIST_node (link);
+ *pprev = link = next;
+ df_notes_rescan (insn);
+ }
+ else
+ {
+ pprev = XEXP (link, 1);
+ link = *pprev;
+ }
+ break;
+ }
default:
pprev = XEXP (link, 1);
link = *pprev;
@@ -3299,7 +3340,7 @@ df_note_bb_compute (unsigned int bb_index,
debug_insn = DEBUG_INSN_P (insn);
bitmap_clear (do_not_gen);
- df_kill_notes (insn);
+ df_kill_notes (insn, live);
/* Process the defs. */
if (CALL_P (insn))
diff --git a/gcc/testsuite/gcc.dg/pr51505.c b/gcc/testsuite/gcc.dg/pr51505.c
new file mode 100644
index 000..dbcd322
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr51505.c
@@ -0,0 +1,19 @@
+/* PR rtl-optimization/51505 */
+/* { dg-do compile } */
+/* { dg-options -O --param max-cse-insns=1 } */
+struct S
+{
+char a[256];
+};
+
+int bar(struct S, char[16]);
+
+void foo ()
+{
+ struct S u, s1, s2;
+ char e[256];
+ char i;
+ e[i] = ~s1.a[i] s2.a[i];
+ if (bar(u, e))
+__builtin_abort ();
+}
Re: [Patch ARM] Fix PR50313 and handle PIC addresses properly.
On 18 January 2012 15:26, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jan 18, 2012 at 03:03:47PM +, Ramana Radhakrishnan wrote: +;; operand1 is the memory address to go into pic_load_addr_32bit. +;; operand2 is the PIC label to be emitted from pic_add_dot_plus_*. +;; We do this to allow hoisting of the entire c +(define_insn_and_split pic_load_addr_unified + [(set (match_operand:SI 0 s_register_operand =r,r,l) + (unspec:SI [(match_operand:SI 1 mX,mX,mX) + (match_operand:SI 2 )] + UNSPEC_PIC_UNIFIED))] + flag_pic + # + flag_pic What's the reason to duplicate the condition here? If flag_pic isn't non-zero, then the insn wouldn't match, therefore wouldn't be split... True - Also, while this fixes the testcase, at least if you split it before reload e.g. first scheduling pass might move away the two insns far away from each other, register allocation might decide to spill the pseudo set by the first insn to the stack and the same problem could reappear. Since this was always being scheduled as a standard load I didn't have expected this to be pulled too far apart from the use - we only schedule loads as though these were off the cache anyway. I will change to get this split after reload to make this as robust as it possibly can be . I will note that the tls patterns also would need a similar overhaul but I don't want to do that till stage1 reopens again. There is another problem with this patch in that I've got the neg_pool_range for ARM and Thumb2 back to front - will change that and then commit. regards, Ramana
Re: libgo patch committed: Update to weekly.2011-12-22
Ian Lance Taylor i...@google.com writes: This also broke bootstrap on x86_64-unknown-linux-gnu (CentOS 5.5): /vol/gcc/src/hg/trunk/local/libgo/go/net/fd_linux.go:40:46: error: reference to undefined identifier 'syscall.EPOLL_CLOEXEC' Thanks. Fixed like so. Bootstrapped on x86_64-unknown-linux-gnu. Committed to mainline. Thanks. Unfortunately, this is not enough: while the build finishes now, all tests fail with /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./libgo/.libs/libgo.so: undefined reference to `epoll_create1' collect2: error: ld returned 1 exit status Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Go patch committed: Multiplex goroutines onto OS threads
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
All tests hang with the default -test.timeout=240.
Thanks for providing access to a Solaris system.
Right now it looks like there is a bug, or at least an incompatibility,
in the 64-bit versions of getcontext and setcontext. It looks like
calling setcontext on the 32-bit version does not change the value of
TLS variables, which is also the case on GNU/Linux. In the 64-bit
version, calling setcontext does change the value of TLS variables.
That is, on the 64-bit version, getcontext preserves the value of TLS
variables and setcontext restores the old value. (Of course it's really
the pointer, not the TLS variables themselves). This incompatibility
has to be a bug, and of course I would prefer that the incompatibility
be resolved in favor of the implementation used on GNU/Linux.
Here is a program which shows the issue. Compile with -pthread. With
-m32 it prints go1: tls == 2. With -m64 it prints go1: tls == 1. The
program is too complex for the problem, but it does show the issue.
Ian
#include errno.h
#include stdio.h
#include stdlib.h
#include limits.h
#include pthread.h
#include ucontext.h
__thread int tls;
static void die (const char *) __attribute__ ((noreturn));
static void
die (const char *msg)
{
perror (msg);
exit (EXIT_FAILURE);
}
static ucontext_t c1;
static void *s1[10];
static ucontext_t c2;
static void *s2[10];
static void swap (ucontext_t *, void *fs[10], ucontext_t *, void *ts[10]);
static void
swap (ucontext_t *fu, void *fs[10], ucontext_t *tu, void *ts[10])
{
swapcontext (fu, tu);
}
static void use_buffer (char *buf) __attribute__ ((noinline));
static void
use_buffer (char *buf)
{
buf[0] = '\0';
}
static void
down (int i, const char *msg, ucontext_t *me, void *mes[10],
ucontext_t *other, void *others[10])
{
char buf[1];
printf (%s %d\n, msg, i);
if (i 0)
{
use_buffer (buf);
swap (me, mes, other, others);
down (i - 1, msg, me, mes, other, others);
}
else
{
printf (i == 0\n);
}
}
static void
go1 (void)
{
printf (go1: tls == %d\n, tls);
down (2, go1, c1, s1, c2, s2);
pthread_exit (NULL);
}
static void
go2 (void)
{
printf (go2: tls == %d\n, tls);
down (2, go2, c2, s2, c1, s1);
pthread_exit (NULL);
}
struct thread_context
{
ucontext_t *u;
void **s;
};
static void *
start_thread (void *context)
{
struct thread_context *tc = (struct thread_context *) context;
int block;
printf (start_thread: tls == %d\n, tls);
tls = 2;
block = 0;
setcontext (tc-u);
die (setcontext);
return NULL;
}
int
main (int argc __attribute__ ((unused)), char **argv __attribute__ ((unused)))
{
pthread_t tid;
int err;
size_t size;
struct thread_context tc;
int block;
tls = 1;
if (getcontext (c1) 0)
die (getcontext);
c2 = c1;
c1.uc_stack.ss_sp = malloc (1024 * 1024 * 1024);
if (c1.uc_stack.ss_sp == NULL)
die (malloc);
c1.uc_stack.ss_flags = 0;
c1.uc_stack.ss_size = 1024 * 1024 * 1024;
c1.uc_link = NULL;
block = 0;
makecontext (c1, go1, 0);
c2.uc_stack.ss_sp = malloc (1024 * 1024 * 1024);
if (c2.uc_stack.ss_sp == NULL)
die (malloc);
c2.uc_stack.ss_flags = 0;
c2.uc_stack.ss_size = 1024 * 1024 * 1024;
c2.uc_link = NULL;
makecontext (c2, go2, 0);
tc.u = c1;
tc.s = s1[0];
err = pthread_create (tid, NULL, start_thread, tc);
if (err != 0)
{
errno = err;
die (pthread_create);
}
err = pthread_join (tid, NULL);
if (err != 0)
{
errno = err;
die (pthread_join);
}
exit (EXIT_SUCCESS);
}
Re: [PATCH] Fix PR 51505
On 01/18/2012 05:41 PM, Andrey Belevantsev wrote: Hello, As discussed in Bugzilla, this is the patch implementing Paolo's suggestion of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes. The code assumes there is at most one such note per insn. Bootstrapped and tested on x86-64, ok for trunk? Andrey gcc: 2012-01-18 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/51505 * df-problems.c (df_kill_notes): New parameter live. Update comment. Remove REG_EQUAL/REG_EQUIV notes referring to dead registers. (df_note_bb_compute): Update the call to df_kill_notes. testsuite: 2012-01-18 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/51505 * gcc.dg/pr51505.c: New test. Ok, thanks for working on this. Paolo
[wwwdocs] List new Fortran options under Fortran section
The attached patch documents the new Fortran options -freal-N-real-M and -finteger-4-integer-8. These options are used for promoting all entities of the first type to entities of the second type. OK to commit? PS: Is there a ChangeLog file for the wwwdoc repository? -- Steve Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.74 diff -c -p -r1.74 changes.html *** changes.html 16 Jan 2012 08:39:01 - 1.74 --- changes.html 18 Jan 2012 18:05:27 - *** well./p/li *** 421,426 --- 421,439 h3 id=fortranFortran/h3 ul + liThe compile options a + href=http://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html#Fortran-Dialect-Options + code-freal-N-real-M/code/a have been added. These options promote + all entities on type codeREAL(N)/code to codeREAL(M)/code, where + codeN/code and codeM/code can be 4 and 8 and, if available, + 10 and 16. + /li + li The compile option a + href=http://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html#Fortran-Dialect-Options + code-finteger-4-integer-8/code/a has been added. This option + promotes all entities of type codeINTEGER(4)/code to + codeINTEGER(8)/code. + /li liThe compile flag a href=http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack_002darrays_007d-254; code-fstack-arrays/code/a has been added, which causes
Re: Go patch committed: Multiplex goroutines onto OS threads
Ian Lance Taylor i...@google.com writes: Rainer Orth r...@cebitec.uni-bielefeld.de writes: All tests hang with the default -test.timeout=240. Thanks for providing access to a Solaris system. Right now it looks like there is a bug, or at least an incompatibility, in the 64-bit versions of getcontext and setcontext. It looks like calling setcontext on the 32-bit version does not change the value of TLS variables, which is also the case on GNU/Linux. In the 64-bit version, calling setcontext does change the value of TLS variables. That is, on the 64-bit version, getcontext preserves the value of TLS variables and setcontext restores the old value. (Of course it's really the pointer, not the TLS variables themselves). This incompatibility has to be a bug, and of course I would prefer that the incompatibility be resolved in favor of the implementation used on GNU/Linux. Here is a program which shows the issue. Compile with -pthread. With -m32 it prints go1: tls == 2. With -m64 it prints go1: tls == 1. The program is too complex for the problem, but it does show the issue. Thanks for the detective work. I'll try to find in the OpenSolaris sources what's going on, at the same time contacting the Solaris engineers about the issue. There's more to the problem, though: on Solaris/SPARC (mayon is a Solaris 11 machine you could use here), both 32 and 64-bit versions of the test program print tls == 2, but many (not all) libgo tests still fail. I also tried the program on IRIX 6.5 (columba, dog slow unfortunately), which doesn't have native TLS. It doesn't go beyond the go1: tls == 2 line, and I had to reduce the stack sizes to 32 MB to allow it to run at all. On Tru64 UNIX (haydn), also using emutls, it does run until the i == 0 line, but doesn't finish. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [C++ Patch] PR 51225
OK. Jason
[PATCH, 4.6, committed] Fix typo in rs6000.md call pattern for AIX
A backport of another patch introduced a cut-and-paste typo in one of
the AIX call patterns, generating a DImode memory operand in 32 bit
mode. Fixed with the following patch.
- David
* config/rs6000/rs6000.md (call_value_indirect_aix32): Fix typo
in mode of operand[4].
Index: rs6000.md
===
--- rs6000.md (revision 183273)
+++ rs6000.md (working copy)
@@ -12241,8 +12241,8 @@
{
operands[3] = gen_reg_rtx (SImode);
- operands[4] = gen_rtx_MEM (DImode,
-gen_rtx_PLUS (DImode, stack_pointer_rtx,
+ operands[4] = gen_rtx_MEM (SImode,
+gen_rtx_PLUS (SImode, stack_pointer_rtx,
GEN_INT (20)));
[PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
Hello! Attached three-liner patch fixes the declaration of BUILT_IN_TM_START (AKA _ITM_beginTransaction) to match its declaration from the libitm.h ABI. This mismatch was the core problem for FAILed libitm.c/mem(cpy|set)-1.c execution tests on x86_32. Following that change, we need to teach _ITM_beginTransaction where to find its first argument, so it can be passed to GTM_begin_transaction. There was some discussion on where to pass arguments to regparm decorated vararg functions. Well, as the ABI is pretty clear - regparm should be ignored in this case, so all function arguments have to be passed in memory, even if that means that the value is kicked to the memory before the call, and pulled back into the register in _ITM_beginTransaction. 2012-01-18 Uros Bizjak ubiz...@gmail.com PR libitm/51830 * builtin-types.def (BT_FN_UINT_UINT_VAR): New. * gtm-builtins.def (BUILT_IN_TM_START): Declare as BT_FN_UINT_UINT_VAR. libitm/ChangeLog: 2012-01-18 Uros Bizjak ubiz...@gmail.com PR libitm/51830 * config/x86/sjlj.S (_ITM_beginTransaction) [!__x86_64__]: Load the first function argument to %eax. The patch touches generic libitm part, so I have tested it on i686-pc-linux-gnu (where it fixes all failures), x86_64-pc-linux-gnu and alphaev68-pc-linux-gnu. OK for mainline? Uros. Index: libitm/config/x86/sjlj.S === --- libitm/config/x86/sjlj.S(revision 183277) +++ libitm/config/x86/sjlj.S(working copy) @@ -79,6 +79,7 @@ ret #else leal4(%esp), %ecx + movl4(%esp), %eax subl$28, %esp cfi_def_cfa_offset(32) movl%ecx, 8(%esp) Index: gcc/builtin-types.def === --- gcc/builtin-types.def (revision 183277) +++ gcc/builtin-types.def (working copy) @@ -498,6 +498,8 @@ BT_VOID, BT_CONST_PTR) DEF_FUNCTION_TYPE_VAR_1 (BT_FN_INT_CONST_STRING_VAR, BT_INT, BT_CONST_STRING) +DEF_FUNCTION_TYPE_VAR_1 (BT_FN_UINT_UINT_VAR, +BT_UINT, BT_UINT) DEF_FUNCTION_TYPE_VAR_2 (BT_FN_INT_FILEPTR_CONST_STRING_VAR, BT_INT, BT_FILEPTR, BT_CONST_STRING) Index: gcc/gtm-builtins.def === --- gcc/gtm-builtins.def(revision 183277) +++ gcc/gtm-builtins.def(working copy) @@ -1,5 +1,5 @@ DEF_TM_BUILTIN (BUILT_IN_TM_START, _ITM_beginTransaction, - BT_FN_UINT_UINT, ATTR_TM_NOTHROW_RT_LIST) + BT_FN_UINT_UINT_VAR, ATTR_TM_NOTHROW_RT_LIST) DEF_TM_BUILTIN (BUILT_IN_TM_COMMIT, _ITM_commitTransaction, BT_FN_VOID, ATTR_TM_NOTHROW_LIST)
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On 01/18/2012 02:26 PM, Uros Bizjak wrote: Hello! Attached three-liner patch fixes the declaration of BUILT_IN_TM_START (AKA _ITM_beginTransaction) to match its declaration from the libitm.h ABI. This mismatch was the core problem for FAILed libitm.c/mem(cpy|set)-1.c execution tests on x86_32. Following that change, we need to teach _ITM_beginTransaction where to find its first argument, so it can be passed to GTM_begin_transaction. There was some discussion on where to pass arguments to regparm decorated vararg functions. Well, as the ABI is pretty clear - regparm should be ignored in this case, so all function arguments have to be passed in memory, even if that means that the value is kicked to the memory before the call, and pulled back into the register in _ITM_beginTransaction. 2012-01-18 Uros Bizjakubiz...@gmail.com PR libitm/51830 * builtin-types.def (BT_FN_UINT_UINT_VAR): New. * gtm-builtins.def (BUILT_IN_TM_START): Declare as BT_FN_UINT_UINT_VAR. libitm/ChangeLog: 2012-01-18 Uros Bizjakubiz...@gmail.com PR libitm/51830 * config/x86/sjlj.S (_ITM_beginTransaction) [!__x86_64__]: Load the first function argument to %eax. The patch touches generic libitm part, so I have tested it on i686-pc-linux-gnu (where it fixes all failures), x86_64-pc-linux-gnu and alphaev68-pc-linux-gnu. OK for mainline? Uros. My main concern here is performance... Indeed, in case of libitm using Hardware Transactional Memory, it could be great to use registers for parameters. I would prefer to remove the variadic function as proposed here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01784.html As Torvald wrote, it was in case for hypothetical future parameters. So I would agree to do: extern uint32_t _ITM_beginTransaction(uint32_t,uint32_t) ITM_REGPARM; At least, it provides a new parameter for future use and do not use the stack for parameters. Other thoughts? Thanks. -- Patrick Marlier.
Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling
I still think the problem is that we're applying the attributes more than once, and we should only apply them once. If we fix that, we don't need to merge them. Jason
Re: libstdc++/51866 too, sorry
Attached patch applied.
2012-01-18 François Dumont fdum...@gcc.gnu.org
Roman Kononov ro...@binarylife.net
PR libstdc++/51866
* include/bits/hashtable.h (_Hashtable::_M_insert(_Arg,
false_type)):
Do not keep a reference to a potentially moved instance.
* testsuite/23_containers/unordered_multiset/insert/51866.cc: New.
* testsuite/23_containers/unordered_multimap/insert/51866.cc: New.
François
On 01/18/2012 12:35 AM, Paolo Carlini wrote:
On 01/17/2012 11:31 PM, Jonathan Wakely wrote:
On 17 January 2012 21:14, François Dumont wrote:
Ok to commit ?
OK, thanks.
Great. Please also double check with the submitters of libstdc++/51845
(ask on the audit trail?) that it's actually fixed by the same patch,
and in case resolve it as duplicate.
Thanks again,
Paolo.
Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h (revision 183164)
+++ include/bits/hashtable.h (working copy)
@@ -1227,7 +1227,7 @@
= this-_M_hash_code(__k);
this-_M_store_code(__new_node, __code);
- // Second, do rehash if necessary.
+ // Second, do rehash if necessary.
if (__do_rehash.first)
_M_rehash(__do_rehash.second, __saved_state);
@@ -1347,21 +1347,24 @@
= _M_rehash_policy._M_need_rehash(_M_bucket_count,
_M_element_count, 1);
- const key_type __k = this-_M_extract()(__v);
- typename _Hashtable::_Hash_code_type __code = this-_M_hash_code(__k);
+ // First compute the hash code so that we don't do anything if it throws.
+ typename _Hashtable::_Hash_code_type __code
+ = this-_M_hash_code(this-_M_extract()(__v));
_Node* __new_node = nullptr;
__try
{
- // First allocate new node so that we don't rehash if it throws.
+ // Second allocate new node so that we don't rehash if it throws.
__new_node = _M_allocate_node(std::forward_Arg(__v));
this-_M_store_code(__new_node, __code);
if (__do_rehash.first)
_M_rehash(__do_rehash.second, __saved_state);
- // Second, find the node before an equivalent one.
- size_type __n = _M_bucket_index(__k, __code);
- _BaseNode* __prev = _M_find_before_node(__n, __k, __code);
+ // Third, find the node before an equivalent one.
+ size_type __bkt = _M_bucket_index(__new_node);
+ _BaseNode* __prev
+ = _M_find_before_node(__bkt, this-_M_extract()(__new_node-_M_v),
+__code);
if (__prev)
{
// Insert after the node before the equivalent one.
@@ -1372,7 +1375,7 @@
// The inserted node has no equivalent in the hashtable. We must
// insert the new node at the beginning of the bucket to preserve
// equivalent elements relative positions.
- _M_insert_bucket_begin(__n, __new_node);
+ _M_insert_bucket_begin(__bkt, __new_node);
++_M_element_count;
return iterator(__new_node);
}
Index: testsuite/23_containers/unordered_multimap/insert/51866.cc
===
--- testsuite/23_containers/unordered_multimap/insert/51866.cc (revision 0)
+++ testsuite/23_containers/unordered_multimap/insert/51866.cc (revision 0)
@@ -0,0 +1,87 @@
+// { dg-options -std=gnu++0x }
+//
+// Copyright (C) 2012 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/.
+
+#include unordered_map
+#include testsuite_hooks.h
+
+struct num
+{
+ int value;
+ num(int n) : value(n) {}
+ num(num const)= default;
+ num operator=(num const) = default;
+ num(num o) : value(o.value)
+ { o.value = -1; }
+ num operator=(num o)
+ {
+if (this != o)
+ {
+ value = o.value;
+ o.value = -1;
+ }
+return *this;
+ }
+};
+
+struct num_hash
+{
+ size_t operator()(num const a) const
+ { return a.value; }
+};
+
+struct num_equal
+{
+ static bool _S_invalid_equal_call;
+ bool operator()(num const a, num const b) const
+ {
+if (a.value == -1 || b.value == -1)
+ _S_invalid_equal_call = true;
+return a.value == b.value;
+ }
+};
+
+bool num_equal::_S_invalid_equal_call = false;
+
+// libstdc++/51866
+void test01()
+{
+ bool test __attribute__((unused)) = true;
+
+ std::unordered_multimapnum, int, num_hash, num_equal mmap;
+
Re: libstdc++/51866 too, sorry
On 01/18/2012 09:27 PM, François Dumont wrote: Attached patch applied. Thanks. Apparently 51845 is an unrelated issue, Jakub has an analysis and a candidate fix. Can you please look into that? Thanks again, Paolo.
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On Wed, Jan 18, 2012 at 8:44 PM, Patrick Marlier patrick.marl...@gmail.com wrote: There was some discussion on where to pass arguments to regparm decorated vararg functions. Well, as the ABI is pretty clear - regparm should be ignored in this case, so all function arguments have to be passed in memory, even if that means that the value is kicked to the memory before the call, and pulled back into the register in _ITM_beginTransaction. My main concern here is performance... Indeed, in case of libitm using Hardware Transactional Memory, it could be great to use registers for parameters. I would prefer to remove the variadic function as proposed here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01784.html Please note that all recent x86 processors implement store forwarding, so passing arguments through memory is mostly a non-issue nowadays. As Torvald wrote, it was in case for hypothetical future parameters. So I would agree to do: extern uint32_t _ITM_beginTransaction(uint32_t,uint32_t) ITM_REGPARM; At least, it provides a new parameter for future use and do not use the stack for parameters. Other thoughts? IMO, whatever the future decision would be, we shouldn't leave one part of the compiler out-of-sync from the other. Proposed patch fixes _current_ situation, where in the future, it is expected that compiler and library changes in sync... Uros.
Re: [Patch, fortran] PR51634 - [OOP] ICE with polymorphic operators
Dear Tobias, Committed as r183287. Thanks for the review. Paul 2012-01-17 Paul Thomaspa...@gcc.gnu.org PR fortran/51634 * trans-expr.c (gfc_conv_procedure_call): Deallocate allocatable components of temporary class arguments. 2012-01-17 Paul Thomaspa...@gcc.gnu.org PR fortran/51634 * gfortran.dg/typebound_operator_12.f03: New. * gfortran.dg/typebound_operator_13.f03: New. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: Cross-build breakage with libstdc++-v3 doc changes
...or for cross-targets, breakage. Something went wrong with
this or subsequent changes; somewhere in the r183262:183268 I've
started getting:
[snip]
checking
for /usr/share/xml/docbook/stylesheet/docbook-xsl-ns/epub3/chunk.xsl...
configure: error: cannot check for file existence when cross
compiling make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/tmp/hpautotest-gcc1/cris-elf/gccobj'
make: *** [all] Error 2
Yes, I'm seeing the same problem when building a spu-elf
cross-compiler ...
Testing this patch, will check it in if passes, sorry.
-benjamin
2012-01-18 Benjamin Kosnik b...@redhat.com
* configure.ac: Move epub checks...
* acinclude (GLIBCXX_CONFIGURE_DOCBOOK): ...here, use
test -f instead of AC_CHECK_FILES.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 9d08178..fd3ba96 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -631,7 +631,7 @@ AC_DEFUN([GLIBCXX_CONFIGURE_TESTSUITE], [
dnl
-dnl Does any necessary configuration of the documentation directory.
+dnl Does any necessary configuration for docbook in the docs directory.
dnl
dnl XSLTPROC must be set before this
dnl
@@ -642,7 +642,7 @@ dnl XSL_STYLE_DIR
dnl
AC_DEFUN([GLIBCXX_CONFIGURE_DOCBOOK], [
-AC_MSG_CHECKING([for stylesheets used in generation of documentation])
+AC_MSG_CHECKING([for docbook stylesheets for documentation creation])
glibcxx_stylesheets=no
if test x${XSLTPROC} = xyes echo 'title/' | xsltproc --noout --nonet --xinclude http://docbook.sourceforge.net/release/xsl-ns/current/xhtml-1_1/docbook.xsl - 2/dev/null; then
glibcxx_stylesheets=yes
@@ -669,6 +669,18 @@ if test x$glibcxx_local_stylesheets = xyes; then
else
glibcxx_stylesheets=no
fi
+
+# Check for epub3 dependencies.
+AC_MSG_CHECKING([for epub3 stylesheets for documentation creation])
+glibcxx_epub_stylesheets=no
+if test x$glibcxx_local_stylesheets = xyes; then
+ if test -f ${XSL_STYLE_DIR}/epub3/chunk.xsl; then
+ glibcxx_epub_stylesheets=yes
+ fi
+fi
+AC_MSG_RESULT($glibcxx_epub_stylesheets)
+AM_CONDITIONAL(BUILD_EPUB, test $glibcxx_epub_stylesheets= yes)
+
])
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 1c62aea..2429f04 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -380,15 +380,6 @@ AM_CONDITIONAL(BUILD_PDF,
test $ac_cv_prog_DBLATEX = yes
test $ac_cv_prog_PDFLATEX = yes)
-# Check for epub dependencies.
-AC_CHECK_FILE(/usr/share/xml/docbook/stylesheet/docbook-xsl-ns/epub3/chunk.xsl,
- ac_cv_file_epub3_a=yes, ac_cv_file_epub3_a=no)
-AC_CHECK_FILE(/usr/share/sgml/docbook/xsl-ns-stylesheets/epub3/chunk.xsl,
- ac_cv_file_epub3_b=yes, ac_cv_file_epub3_b=no)
-AM_CONDITIONAL(BUILD_EPUB,
- test $ac_cv_file_epub3_a = yes ||
- test $ac_cv_file_epub3_b = yes)
-
# Propagate the target-specific source directories through the build chain.
ATOMICITY_SRCDIR=config/${atomicity_dir}
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On Wed, Jan 18, 2012 at 10:16 PM, Patrick Marlier patrick.marl...@gmail.com wrote: IMO, whatever the future decision would be, we shouldn't leave one part of the compiler out-of-sync from the other. Proposed patch fixes _current_ situation, where in the future, it is expected that compiler and library changes in sync... So in order to keep them in sync, this should be also applied to libitm if your solution is chosen (At least to avoid confusion). If the Intel TM-ABI (no idea what's the status of this specification) specifies variadic function and regparm, it should be changed too. Index: libitm.h === --- libitm.h (revision 183273) +++ libitm.h (working copy) @@ -136,7 +136,7 @@ typedef uint64_t _ITM_transactionId_t; /* Transact extern _ITM_transactionId_t _ITM_getTransactionId(void) ITM_REGPARM; -extern uint32_t _ITM_beginTransaction(uint32_t, ...) ITM_REGPARM; +extern uint32_t _ITM_beginTransaction(uint32_t, ...); extern void _ITM_abortTransaction(_ITM_abortReason) ITM_REGPARM ITM_NORETURN; The spec does say that all function should be regparm(2), but I agree that the above is less confusing. The attribute is ignored, but perhaps a comment would clear this confusion even more. Uros.
Re: [wwwdocs] List new Fortran options under Fortran section
Steve Kargl wrote: The attached patch documents the new Fortran options -freal-N-real-M and -finteger-4-integer-8. These options are used for promoting all entities of the first type to entities of the second type. OK to commit? Looks OK to me. Though, I had made the N and M italic at: +code-freal-N-real-M/code/a have been added. These options promote and +codeN/code andcodeM/code can be 4 and 8 and, if available, PS: Is there a ChangeLog file for the wwwdoc repository? No, there is no ChangeLog - and due to using CVS, the commit message (may but) does not need to contain file name as cvs saves the log per file. Tobias
[pph] Refuse to generate PPH with #include_next (issue5558045)
This patch adds a check for #include_next and refuses to generate a
PPH image for files that use it.
Since the discovery of #include_next comes well into the
pre-processing stage (after we've initialized PPH data), we need to
undo what we did and disable PPH. To do that, there is a new function
pph_disable_output() which closes and unlinks the output file. This
needed changes to pph_stream_close() to not bother writing the
encoding buffers.
To decide whether we see the #include_next command in the primary
source file, I exported the function cpp_in_primary_file() from
libcpp.
Finally, the patch adds checks to avoid getting into an infinite loop
when processing includes. Some system files include each other and if
we produce PPH images for both files, we were getting into an infinite
mutually-referential cycle.
libcpp/ChangeLog.pph
* internal.h (cpp_in_primary_file): Move ...
* files.c (cpp_in_primary_file): ... here.
* include/cpplib.h (cpp_in_primary_file): Declare.
gcc/cp/ChangeLog.pph
* pph-core.c (pph_include_handler): If the primary file
uses #include_next, emit a warning and call
pph_disable_output.
(pph_stream_close_1): Factor out of ...
(pph_stream_close): ... here.
(pph_stream_close_no_flush): New.
(pph_streamer_finish): Call pph_writer_finish if
pph_writer_enabled_p returns true.
Call pph_reader_finish if pph_reader_enabled_p returns
true.
* pph-in.c (pph_in_include): Assert that we are not
trying to read STREAM from STREAM.
* pph-out.c (pph_out_line_table_and_includes): Do not
emit a line table reference to STREAM.
(pph_disable_output): New.
* pph-streamer.h (pph_stream_close_no_flush): Declare.
(pph_disable_output): Declare.
gcc/testsuite/ChangeLog.pph
* g++.dg/pph/d0include-next.h: New.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/pph@183291
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/cp/ChangeLog.pph | 20 +
gcc/cp/pph-core.c | 67 +---
gcc/cp/pph-in.c |3 +
gcc/cp/pph-out.c | 24 +-
gcc/cp/pph-streamer.h |2 +
gcc/testsuite/ChangeLog.pph |4 ++
gcc/testsuite/g++.dg/pph/d0include-next.h |6 +++
libcpp/ChangeLog.pph |6 +++
libcpp/files.c|9
libcpp/include/cpplib.h |1 +
libcpp/internal.h |7 ---
11 files changed, 132 insertions(+), 17 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/pph/d0include-next.h
diff --git a/gcc/cp/ChangeLog.pph b/gcc/cp/ChangeLog.pph
index 39ac194..47d9bc04 100644
--- a/gcc/cp/ChangeLog.pph
+++ b/gcc/cp/ChangeLog.pph
@@ -1,3 +1,23 @@
+2012-01-18 Diego Novillo dnovi...@google.com
+
+ * pph-core.c (pph_include_handler): If the primary file
+ uses #include_next, emit a warning and call
+ pph_disable_output.
+ (pph_stream_close_1): Factor out of ...
+ (pph_stream_close): ... here.
+ (pph_stream_close_no_flush): New.
+ (pph_streamer_finish): Call pph_writer_finish if
+ pph_writer_enabled_p returns true.
+ Call pph_reader_finish if pph_reader_enabled_p returns
+ true.
+ * pph-in.c (pph_in_include): Assert that we are not
+ trying to read STREAM from STREAM.
+ * pph-out.c (pph_out_line_table_and_includes): Do not
+ emit a line table reference to STREAM.
+ (pph_disable_output): New.
+ * pph-streamer.h (pph_stream_close_no_flush): Declare.
+ (pph_disable_output): Declare.
+
2012-01-17 Lawrence Crowl cr...@google.com
* pph.h (pph_files_read): New.
diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index f470cfc..e7cf444 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -669,6 +669,21 @@ pph_include_handler (cpp_reader *reader,
fprintf (pph_logfile, %c\n, angle_brackets ? '' : '');
}
+ /* If we find a #include_next directive in the primary file,
+ refuse to generate a PPH image for it. #include_next cannot
+ be resolved from the primary source file, so generating an
+ image for it would cause an infinite self-referential loop
+ in the line table. */
+ if (cpp_in_primary_file (reader)
+ strcmp ((const char *)dname, include_next) == 0)
+{
+ warning_at (loc, OPT_Winvalid_pph, #include_next found in the
+ primary source file. PPH generation disabled for %s,
+ LOCATION_FILE (loc));
+ pph_disable_output ();
+ return true;
+}
+
read_text_file_p = true;
pph_file = query_pph_include_map (name);
if (pph_file != NULL
@@ -1026,10 +1041,15 @@ pph_stream_open (const char *name, const char *mode)
}
-/* Close PPH stream STREAM. */
+/* Close PPH stream STREAM. If
[PATCH] Fix _Hashtable::erase(iterator, iterator) (PR libstdc++/51845)
Hi! As described in the PR, if two argument erase is removing the last element of one bucket (i.e. the one referenced in _M_buckets array for the next bucket) and then at least one element from the following bucket, but not all elements from that next bucket, __is_bucket_begin is initially false and in the second for (;;) iteration, while it is already true, __n_bkt == __bkt and thus _M_remove_bucket_begin doesn't do anything, and following if (__n __n_bkt != __bkt) is false as well (1 0), thus nothing is changed in the _M_buckets array and we end up referencing there a removed element. We might crash if we read it and if we modify it, we usually corrupt malloc data structures. Fixed thusly, if __is_bucket_begin is true, then we know __n is the first item in its bucket and thus __prev_n should be in the _M_buckets array. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2012-01-18 Jakub Jelinek ja...@redhat.com PR libstdc++/51845 * include/bits/hashtable.h (_Hashtable::erase(const_iterator, const_iterator)): Also update _M_buckets[__n_bkt] if __is_bucket_begin. --- libstdc++-v3/include/bits/hashtable.h 2012-01-15 20:59:53.765526939 +0100 +++ libstdc++-v3/include/bits/hashtable.h 2012-01-18 19:49:39.222388730 +0100 @@ -1541,7 +1541,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION __bkt = __n_bkt; } - if (__n __n_bkt != __bkt) + if (__n (__n_bkt != __bkt || __is_bucket_begin)) _M_buckets[__n_bkt] = __prev_n; __prev_n-_M_nxt = __n; return iterator(__n); Jakub
[PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
Hi!
As discussed in the PR, compiling the initfini testcase with the
host compiler and running it is problematic for bootstrap, as
in stage1 we use the host compiler which might use one version of as/ld,
but stage2 is using stage1 compiler as host compiler and might use
a different as/ld. If one of the linkers does support merging of
.init_array and .ctors properly and the other does not, we end up
with comparison failures e.g. because of go1 C++ sources.
The following patch attempts to perform a separate linker check
(grepping objdump of a linked binary) and checks so far glibc version
which is known to support .init_array properly. Perhaps other
C libraries could be added there too (does e.g. Solaris support .init_array
properly, or FreeBSD, other OSes?).
Bootstrapped/regtested on x86_64-linux and i686-linux both with a linker
that does it right and a buggy one.
2012-01-18 Jakub Jelinek ja...@redhat.com
PR bootstrap/50237
* config/initfini-array.h: Guard content of the header
with #ifdef HAVE_INITFINI_ARRAY.
* configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file.
Add initfini-array.h to tm_file here.
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker
test.
* config.gcc: Don't add initfini-array.h to tm_file here.
* configure: Regenerated.
--- gcc/config/initfini-array.h.jj 2011-08-22 08:17:06.0 +0200
+++ gcc/config/initfini-array.h 2012-01-17 16:28:39.219571262 +0100
@@ -19,6 +19,8 @@
along with GCC; see the file COPYING3. If not see
http://www.gnu.org/licenses/. */
+#ifdef HAVE_INITFINI_ARRAY
+
#define USE_INITFINI_ARRAY
#undef INIT_SECTION_ASM_OP
@@ -35,3 +37,5 @@
#define TARGET_ASM_CONSTRUCTOR default_elf_init_array_asm_out_constructor
#undef TARGET_ASM_DESTRUCTOR
#define TARGET_ASM_DESTRUCTOR default_elf_fini_array_asm_out_destructor
+
+#endif
--- gcc/configure.ac.jj 2012-01-13 21:47:35.0 +0100
+++ gcc/configure.ac2012-01-17 16:28:00.461795315 +0100
@@ -1197,8 +1197,6 @@ fi
CFLAGS=$saved_CFLAGS
CXXFLAGS=$saved_CXXFLAGS
-gcc_AC_INITFINI_ARRAY
-
# mkdir takes a single argument on some systems.
gcc_AC_FUNC_MKDIR_TAKES_ONE_ARG
@@ -1271,6 +1269,11 @@ if test x$tmake_file = x
then tmake_file=$cpu_type/t-$cpu_type
fi
+# Support --enable-initfini-array.
+if test x$enable_initfini_array != xno; then
+ tm_file=${tm_file} initfini-array.h
+fi
+
if test x$dwarf2 = xyes
then tm_file=$tm_file tm-dwarf2.h
fi
@@ -2422,6 +2425,8 @@ if test x$gcc_cv_ld_ro_rw_mix = xread-wr
fi
AC_MSG_RESULT($gcc_cv_ld_ro_rw_mix)
+gcc_AC_INITFINI_ARRAY
+
# Check if we have .[us]leb128, and support symbol arithmetic with it.
gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128], gcc_cv_as_leb128,
[elf,2,11,0],,
--- gcc/acinclude.m4.jj 2011-08-26 18:41:44.0 +0200
+++ gcc/acinclude.m42012-01-18 20:41:51.448002554 +0100
@@ -376,119 +376,85 @@ AC_DEFUN([gcc_AC_INITFINI_ARRAY],
AC_CACHE_CHECK(for .preinit_array/.init_array/.fini_array support,
gcc_cv_initfini_array, [dnl
if test x${build} = x${target} test x${build} = x${host}; then
-AC_RUN_IFELSE([AC_LANG_SOURCE([
+case ${target} in
+ ia64-*)
+ AC_RUN_IFELSE([AC_LANG_SOURCE([
#ifndef __ELF__
#error Not an ELF OS
#endif
-#ifdef __ia64__
/* We turn on .preinit_array/.init_array/.fini_array support for ia64
if it can be used. */
static int x = -1;
int main (void) { return x; }
int foo (void) { x = 0; }
int (*fp) (void) __attribute__ ((section (.init_array))) = foo;
-#else
-extern void abort ();
-static int count;
-
-static void
-init1005 ()
-{
- if (count != 0)
-abort ();
- count = 1005;
-}
-void (*const init_array1005[]) ()
- __attribute__ ((section (.init_array.01005), aligned (sizeof (void *
- = { init1005 };
-static void
-fini1005 ()
-{
- if (count != 1005)
-abort ();
-}
-void (*const fini_array1005[]) ()
- __attribute__ ((section (.fini_array.01005), aligned (sizeof (void *
- = { fini1005 };
-
-static void
-ctor1007 ()
-{
- if (count != 1005)
-abort ();
- count = 1007;
-}
-void (*const ctors1007[]) ()
- __attribute__ ((section (.ctors.64528), aligned (sizeof (void *
- = { ctor1007 };
-static void
-dtor1007 ()
-{
- if (count != 1007)
-abort ();
- count = 1005;
-}
-void (*const dtors1007[]) ()
- __attribute__ ((section (.dtors.64528), aligned (sizeof (void *
- = { dtor1007 };
-
-static void
-init65530 ()
-{
- if (count != 1007)
-abort ();
- count = 65530;
-}
-void (*const init_array65530[]) ()
- __attribute__ ((section (.init_array.65530), aligned (sizeof (void *
- = { init65530 };
-static void
-fini65530 ()
-{
- if (count != 65530)
-abort ();
- count = 1007;
-}
-void (*const fini_array65530[]) ()
- __attribute__ ((section (.fini_array.65530), aligned (sizeof (void *
- = { fini65530 };
-
-static void
-ctor65535 ()
-{
- if (count != 65530)
-abort ();
- count = 65535;
-}
-void (*const
[PATCH ARM] Fix PR51835, ARM EABI violation
Hi,
Currently gcc generates code violating ARM EABI when passing arguments to
some floating point
helper functions, which are __aeabi_d2iz/__aeabi_d2uiz. As reported in bug
PR51835.
This patch fixes the issue, with test cases.
It is for trunk and 4.6 branch, and I have checked the output codes
manually.
Is it OK?
Thanks
gcc/ChangeLog:
2012-01-17 Bin Cheng bin.ch...@arm.com
PR target/51835
* config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI
for
__aeabi_d2iz/__aeabi_d2uiz in hard-float abi if only
single-precision
arithmetic is supported in hardware.
gcc/testsuite/ChangeLog:
2012-01-17 Bin Cheng bin.ch...@arm.com
PR target/51835
* testsuite/gcc.target/arm/pr51835.c: New testcase.
Index: gcc/testsuite/gcc.target/arm/pr51835.c
===
--- gcc/testsuite/gcc.target/arm/pr51835.c (revision 0)
+++ gcc/testsuite/gcc.target/arm/pr51835.c (revision 0)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -mfloat-abi=hard -mfpu=fpv4-sp-d16 } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+
+int func1 (double d)
+{
+ return (int)d;
+}
+unsigned int func2 (double d)
+{
+ return (unsigned int)d;
+}
+
+/* { dg-final { scan-assembler-times fmrrd\[\\t \]+r0,\[\\t \]*r1,\[\\t
\]*d0 2 } } */
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 183205)
+++ gcc/config/arm/arm.c(working copy)
@@ -3680,6 +3680,10 @@
add_libcall (libcall_htab,
convert_optab_libfunc (trunc_optab, HFmode, SFmode));
add_libcall (libcall_htab,
+ convert_optab_libfunc (sfix_optab, SImode, DFmode));
+ add_libcall (libcall_htab,
+ convert_optab_libfunc (ufix_optab, SImode, DFmode));
+ add_libcall (libcall_htab,
convert_optab_libfunc (sfix_optab, DImode, DFmode));
add_libcall (libcall_htab,
convert_optab_libfunc (ufix_optab, DImode, DFmode));
Re: [PATCH] Fix PR 51505
On 18.01.2012 21:28, Paolo Bonzini wrote: On 01/18/2012 05:41 PM, Andrey Belevantsev wrote: Ok, thanks for working on this. Installed, do you want this for 4.6/4.5? Andrey
Re: [PATCH] Fix PR 51505
On Thu, Jan 19, 2012 at 11:32:41AM +0400, Andrey Belevantsev wrote: On 18.01.2012 21:28, Paolo Bonzini wrote: On 01/18/2012 05:41 PM, Andrey Belevantsev wrote: Ok, thanks for working on this. Installed, do you want this for 4.6/4.5? If yes, please give it at least a couple of weeks on the trunk. Jakub
