RE: [RFC] Optimization to conditional and/or in ARM back-end

> -Original Message- > From: Andrew Pinski [mailto:pins...@gmail.com] > Sent: Tuesday, November 22, 2011 1:14 PM > To: Jiangning Liu > Cc: gcc-patches@gcc.gnu.org; Richard Guenther; Richard Henderson > Subject: Re: [RFC] Optimization to conditional and/or in ARM back-end > > On Sun, Nov

Re: [PR50764, PATCH] Fix for ICE in maybe_record_trace_start with -fsched2-use-superblocks

On 17/11/11 17:53, Maxim Kuvyrkov wrote: > On 17/11/2011, at 9:58 PM, Tom de Vries wrote: > >> On 11/15/2011 10:07 PM, Maxim Kuvyrkov wrote: >>> On 30/10/2011, at 8:17 AM, Tom de Vries wrote: >>> Richard, I have a tentative fix for PR50764. >>> >>> Richard, >>> >>> Tom's patch is go

[PATCH] PR c++/51143 - Alias template allows class definition

Hello, As reminded in the audit trail of this PR, we shouldn't allow a type definition in an alias template declaration. Fixed thus, bootstrapped and tested on x86_64-unknown-linux-gnu against trunk. gcc/cp PR c++/51143 * parser.c (cp_parser_alias_declaration): Don't allow type

Re: Ping! Re: [RFA/ARM][Patch 02/02]: ARM epilogues in RTL

On Fri, 2011-11-18 at 21:45 +, Ramana Radhakrishnan wrote: > On 5 October 2011 17:04, Sameera Deshpande wrote: > > Ping! > > > > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01855.html > > > This should now be rebased given your other changes to the Thumb2 > epilogues patch or is there a new

Re: [Patch RFA libitm] Deal with __USER_LABEL_PREFIX__ in the asm

On 18 Nov 2011, at 17:36, Richard Henderson wrote: On 11/18/2011 04:00 AM, Iain Sandoe wrote: libitm: * config/x86/sjlj.S (CONCAT1, CONCAT2, SYM): Respond to __USER_LABEL_PREFIX__ for targets that use it. TYPE, SIZE, HIDDEN): New macros to assist on non-elf targets. (_ITM_beginTra

Re: [Patch] make it possible for the target to rename ".tm_clone_table"

On 21 Nov 2011, at 00:17, Richard Henderson wrote: On 11/20/2011 05:34 AM, Iain Sandoe wrote: gcc: * target.def (tm_clone_table_section): New hook. * doc/tm.texi.in (TARGET_ASM_TM_CLONE_TABLE_SECTION): Define. * doc/tm.texi: Regenerate. * varasm.c (dump_tm_clone_pairs): Use targe

RE: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL

On Tue, 2011-11-22 at 01:55 +, Xinyu Qi wrote: > At 2011-11-19 07:11:17,"Ramana Radhakrishnan" > wrote: > > On 10 November 2011 18:07, Sameera Deshpande > > wrote: > > > Please find attached the reworked patch. > > > > OK but for a very small bit . > > > > I'll note that we need to add sup

Re: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL

>> >> Though I don't fully understand this patch, I think it is unnecessary to >> consider turn on Thumb2 for iwmmxt, >> because there is no chip that supports WMMX instructions with thumb2 mode. Xinyu: I seem to have mis-remembered that one of your patches was turning on Thumb2 for wMMX. > > Ra

Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6

Hi, On Tue, Nov 22, 2011 at 07:45:39PM +1300, Maxim Kuvyrkov wrote: > On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote: > > > On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote: > > > >> On 24/09/2011, at 2:19 AM, Martin Jambor wrote: > >> > >>> However, both of these are really 4.8 material and si

Re: Fix PR rtl-optimization/51187

> I saw this also when I looked into __builtin_unreachable in one bug > report at one point on MIPS. See > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054#c1 . Yes, the Debian folks also saw the problem on other architectures. -- Eric Botcazou

[C++ Patch] PR 51196

Hi, as also analyzed in the audit trail, we fail to produce the warning for pointer to member function == 0 (those for assignments and initializations are fine) for targets characterized by TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, for the obvious reason that in cp_build_bi

Re: [PATCH][PING^3] Vectorize conversions directly

Ping. The ARM portion of this patch is still awaiting approval. On 11/08/2011 12:35 PM, Dmitry Plotnikov wrote: Ping. On 10/28/2011 12:22 PM, Dmitry Plotnikov wrote: Here is the patch updated according to recent comments. 2011-10-28 Dmitry Plotnikov gcc/ * tree-cfg.c (verify_gimple_assign_

Re: Re-merge crtstuff.c from the trans-mem branch

Richard Henderson writes: > On 11/21/2011 02:13 PM, Richard Henderson wrote: >> This was actually a merge error on the branch. When crtstuff.c >> moved to libgcc/, Aldy failed to copy the changes. >> >> I've tidied things even a bit more from the branch, with the >> introduction of the USE_TM_C

Re: PR other/51174: handle architectures with no DECL_COMDAT_GROUP

On 11/21/11 18:55, Richard Henderson wrote: On 11/18/2011 01:24 PM, Aldy Hernandez wrote: - if (DECL_COMDAT (new_decl)) + if (DECL_COMDAT (new_decl)&& HAVE_COMDAT_GROUP) DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl)); + else +DECL_COMDAT_GROUP (new_decl) =

Re: Support enforcing use of libgcc_s even with LINK_EH_SPEC

Hi, On Mon, 21 Nov 2011, Jakub Jelinek wrote: > On Mon, Nov 21, 2011 at 05:40:26PM +0100, Rainer Orth wrote: > > 2011-11-20 Rainer Orth > > > > * gcc.c (init_gcc_specs) [USE_SHARED_LIBGCC_FOR_EH]: Always use > > libgcc_s. > > * config/sol2.h [USE_GLD] (USE_SHARED_LIBGCC_FOR_EH): D

Re: [PATCH][PING] Vectorize conversions directly

Sorry , it's taken me a while to get to this. On 28 October 2011 09:22, Dmitry Plotnikov wrote: > > gcc/config/arm/ >    * neon.md (floatv2siv2sf2): New. >      (floatunsv2siv2sf2): New. >      (fix_truncv2sfv2si2): New. >      (fix_truncunsv2sfv2si2): New. >      (floatv4siv4sf2): New. >      (f

[obvious] Fix PR51264

Hi, there's a superfluous break in a switch in tree.c, which together with the object clobbers confuses our warning machinery at -O0, leading to a bootstrap fail for Tom. As we have testcases for that already in PR20681 there's no need in GCCs source base itself to contain something like this.

Re: [Patch RFC Darwin] provide the crt stuff for tm.

On 21 Nov 2011, at 18:54, Richard Henderson wrote: On 11/21/2011 01:17 AM, Iain Sandoe wrote: 1. should I be applying this constructor/destructor pair to shared libraries as well? (the specs need minor amendment) Yes. this is what I applied (r181616)after checking that dylibs, bundles

Re: PR other/51174: handle architectures with no DECL_COMDAT_GROUP

On Tue, Nov 22, 2011 at 8:06 AM, Aldy Hernandez wrote: >> This looks weird -- you're seting D_C_G after H_C_G is false? >> >> We've already done copy_decl anyway -- you should be able to drop the >> else. > David, can you try the following and see if it fixes the problem on your > end? > > Index

Re: [C++ Patch] PR 51196

OK. Jason

Re: [PATCH] PR c++/51143 - Alias template allows class definition

Do we have a test for allowing a class definition in a non-template alias definition? If not, please add that too. OK with that change. Jason

Re: [PATCH] PR c++/51145 - Alias template in elaborated-type-specifier

On 11/21/2011 11:41 AM, Dodji Seketeli wrote: -template class Ptr;//{ dg-error "explicit instantiation|non-class templ|does not decl|anything" } +template class Ptr;//{ dg-error "alias templ|specialization|Ptr|after|class" } You seem to be using | to mean .* here. Let's choose one key phrase

[committed] Add testcase for PR tree-optimization/50765

Hi! This PR got fixed by my recent vectorizable_conversion changes, in particular the truncation of the vec_oprnds[01] vectors on multistep type promotion if copies > 1. Testcase tested on x86_64-linux and i686-linux, checked in as obvious. 2011-11-22 Jakub Jelinek PR tree-optimizati

[PATCH] Fix up VEC_INTERLEAVE_*_EXPR folding and expansion for big endian (PR tree-optimization/51074)

Hi! VEC_INTERLEAVE_*_EXPR trees are unfortunately dependent on BYTES_BIG_ENDIAN, what is HIGH vs. LOW is different based on endianity. The only place that creates these in the IL is: if (BYTES_BIG_ENDIAN) { high_code = VEC_INTERLEAVE_HIGH_EXPR; low

[PATCH] fix DO_STMT comment in cp-tree.def.

Richard, The comment at DO_STMT led me to believe that DO_BODY was the first operand. cp-tree.def: ... ./* Used to represent a 'do' statement. The operands are DO_BODY and DO_COND, respectively. */ DEFTREECODE (DO_STMT, "do_stmt", tcc_statement, 2) .. However, in cp-tree.h we see that DO_BOD

[Patch libitm] minor adjustment to make flags.

Hi, since: libitm_la_LDFLAGS are now correctly applied Darwin no longer gets the "-Wl,- undefined,dynamic_lookup" (which I had mentioned before was surprising me with -no-undefined in libitm_la_LDFLAGS). Anyway, to make weak refs work with Darwin, we need that - and it turns out that other

[Patch testsuite] Use complex floating-point constant in the macro CDBL

Hi, This patch changes the macro CDBL in gcc.dg/compat/compat-common.h to use complex floating-point constant rather than complex integer constant. CDBL is a macro to help construct complex floating-point constants in a number of compat tests. I have been running the compat test against a compi

Add line table and line map debugging routines

I found these useful while debugging the trunk->pph merge that brought in the new macro location tracking features. OK for trunk? We are in stage 3, but these are debugging routines so I figured it should be safe. Tested on x86_64. Diego. * include/line-map.h (linemap_dump): Declare.

Re: [v3] updated atomic configury

On Tue, 22 Nov 2011, Andrew MacLeod wrote: > C currently doesn't have a char16_t and char32_t, so they aren't defined It certainly does have those types, as typedefs defined in for the same types as uint_least16_t and uint_least32_t. And is also required to define ATOMIC_CHAR16_T_LOCK_FREE a

Re: Add line table and line map debugging routines

OK. Jason

Re: [PATCH] __atomic library calls which are external may require some label exporting

On 11/21/2011 09:18 PM, Andrew MacLeod wrote: > PR other/51011 > * tree.h (is_builtin_name): No longer external. > * builtins.c (is_builtin_name): Make static. > * varasm.c (incorporeal_function_p): __sync and __atomic external calls > are not incorporeal and may need

Re: [patch] Handle MUST_NOT_THROW_EXPR in voidify_wrapper_expr.

Here's the patch to add an argument to MUST_NOT_THROW_EXPR. You should be able to just use build_must_not_throw_expr in the tm code. Jason commit 205ca057f90db6c30d1acd64ec796e7d301b3eb8 Author: Jason Merrill Date: Tue Nov 22 10:19:03 2011 -0500 build_must diff --git a/gcc/cp/cp-tree.

Re: [PATCH] PR c++/51143 - Alias template allows class definition

Jason Merrill writes: > Do we have a test for allowing a class definition in a non-template > alias definition? If not, please add that too. Good catch. I have a test for that in the test file. > OK with that change. Thanks. Below is what I have tested and checked in. From: Dodji Seketeli

Re: building trunk fails due to C++

On 11/09/11 14:22:22, Steve Kargl wrote: > > Besides bootstrapping, you could use --disable-libitm or it might also > > work to specify --disable-build-poststage1-with-cxx which also saves you > > from building the C++ compiler if you don't want it. > > Doing a full bootstrap adds 3+ hours on my

[C++ Patch] PR 51265

Hi, this is a 4.6/4.7 Regression (the ICE happens also in C++98 mode with __decltype). The problem manifest itself as unhandled PTRMEM_CST in finish_decltype_type, and I'm avoiding it by just handling it like INTEGER_CST. Is it the correct/best thing to do? Anyway patch passes testing on x8

Re: PATCH RFA: Build stages 2 and 3 with C++

A comment on the documentation: > Index: gcc/doc/install.texi > === > --- gcc/doc/install.texi (revision 176348) > +++ gcc/doc/install.texi (working copy) > @@ -1286,6 +1286,13 @@ will try to guess whether the @code{.ini >

Re: building trunk fails due to C++

Hi, On Tue, 22 Nov 2011, Gary Funck wrote: > It gots much worse, with --enable-checking=all in combination with > --enable-build-poststage1-with-cxx (the default, if c++ is built, > and --enable-bootstrap is asserted). > > In fact, a build started last night on fast server hardware has yet > to

Re: [Patch libitm] minor adjustment to make flags.

On 11/22/2011 07:07 AM, Iain Sandoe wrote: > * Makefile.am (libitm_la_LDFLAGS): Remove "-no-undefined". > * Makefile.in: Regenerate. Ok. r~

Re: PATCH RFA: Build stages 2 and 3 with C++

Gary Funck writes: > A comment on the documentation: > >> Index: gcc/doc/install.texi >> === >> --- gcc/doc/install.texi (revision 176348) >> +++ gcc/doc/install.texi (working copy) >> @@ -1286,6 +1286,13 @@ will try to gue

Re: [PATCH] Fix up VEC_INTERLEAVE_*_EXPR folding and expansion for big endian (PR tree-optimization/51074)

On 11/22/2011 06:30 AM, Jakub Jelinek wrote: > PR tree-optimization/51074 > * fold-const.c (fold_binary_loc): Fix up VEC_INTERLEAVE_*_EXPR > handling for BYTES_BIG_ENDIAN. > * optabs.c (can_vec_perm_for_code_p): Likewise. > > * gcc.dg/vect/pr51074.c: New test. As we

Re: building trunk fails due to C++

On 11/22/11 18:19:55, Michael Matz wrote: > > This particular compilation (insn-emit.c) has been running for > > 5.5 hours. Typically, a full bootstrap (with minimal checks) would > > finish in much less than 30 minutes on this server. > > Yes, don't use --enable-checking=all for bootstraps. =al

Re: [patch] support LTO of transactional memory

On 11/21/11 13:45, Richard Henderson wrote: On 11/21/2011 11:31 AM, Aldy Hernandez wrote: case GIMPLE_DEBUG: +case GIMPLE_TRANSACTION: for (i = 0; i< gimple_num_ops (stmt); i++) { tree op = gimple_op (stmt, i); @@ -145,6 +146,8 @@ output_gimple_stmt (struct outpu

Re: [PR50764, PATCH] Fix for ICE in maybe_record_trace_start with -fsched2-use-superblocks

On 11/22/2011 04:39 AM, Tom de Vries wrote: On 17/11/11 17:53, Maxim Kuvyrkov wrote: On 17/11/2011, at 9:58 PM, Tom de Vries wrote: On 11/15/2011 10:07 PM, Maxim Kuvyrkov wrote: On 30/10/2011, at 8:17 AM, Tom de Vries wrote: Richard, I have a tentative fix for PR50764. Richard, Tom's pat

Re: building trunk fails due to C++

On Tue, Nov 22, 2011 at 12:46, Gary Funck wrote: > On 11/22/11 18:19:55, Michael Matz wrote: >> > This particular compilation (insn-emit.c) has been running for >> > 5.5 hours.  Typically, a full bootstrap (with minimal checks) would >> > finish in much less than 30 minutes on this server. >> >> Y

Re: [PATCH] postreload: Invalidate reg_state info@barrier/volatile insns

> Wouldn't this prevent optimizations in cases like: > > insn 1: r1 = r2 + r3 > insn 2: r4 = r1, r1 dead > insn 3: unspec_volatile > > With the proposal above we would mark r1 with an invalid use when passing > insn 3. But for registers which are already dead we should not do this. You're right.

Re: [v3] updated atomic configury

On 11/22/2011 10:32 AM, Joseph S. Myers wrote: On Tue, 22 Nov 2011, Andrew MacLeod wrote: C currently doesn't have a char16_t and char32_t, so they aren't defined It certainly does have those types, as typedefs defined in for the same types as uint_least16_t and uint_least32_t. And is also

Re: [libitm, build] Clear hardware capabilities on libitm.so with Sun ld

David Miller writes: > From: Rainer Orth > Date: Mon, 21 Nov 2011 14:53:33 +0100 > >> Right now, it is only possible to clear the hardware capabilities >> completely, while the new v2 mapfile syntax supports selectively adding >> and removing capabilities. It is only available in Solaris 11 and

Re: PATCH RFA: Build stages 2 and 3 with C++

On 07/15/11 23:52:46, Ian Lance Taylor wrote: [...] > @@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@ > # the last argument when conflicting --enable arguments are passed. > # * Likewise, we force-disable coverage flags, since the installed > # compiler probably has never heard of

Re: [PATCH] PR50325 store_bit_field: Fix for big endian targets

> OK, I see how the two are different now, but I still don't get why the > current version is right. If we say words are 16 bits for simplicity, > and we're storing VALUE == 0x0001_2345 into a 3-byte BLKmode bitfield, > surely we want to store 0x01_2345 rather than 0x00_0123? Why? If you want th

Re: [patch] Handle MUST_NOT_THROW_EXPR in voidify_wrapper_expr.

On Mon, 2011-11-21 at 14:58 -0800, Richard Henderson wrote: > On 11/21/2011 01:58 PM, Torvald Riegel wrote: > > On Mon, 2011-11-21 at 13:45 -0800, Richard Henderson wrote: > >> On 11/21/2011 01:39 PM, Torvald Riegel wrote: > >>> It still fails when combined > >>> with transaction expressions (noexc

Re: [libitm, build] Clear hardware capabilities on libitm.so with Sun ld

On 11/22/2011 10:14 AM, Rainer Orth wrote: > As an aside, in Solaris 10 Update 10 and Solaris 11, there's direct > support in ld and ld.so.1 to select different implementations of the > same interface, depending on hardware capabilites present: > > http://docs.oracle.com/cd/E23824_01/html/819-0690

Re: [RFC] Use which_alternative in preparation-statements of define_insn_and_split

On 11/21/2011 05:38 PM, Jiangning Liu wrote: > But I still want to know why we don't want to support this? I don't see any > GCC documentation saying not allowing this usage. Before reload, which_alternative doesn't make much sense, yet you compute it anyway. After reload, but for raw define_spl

[PATCH] Implement stap probe on ARM's unwinder

Hello, This is the implementation of for the ARM unwinder. Since ARM has a different unwinder, I basically replicated the existing code (on unwind-dw2.c) into it, with a few modifications in order to gather the necessary information for th

Re: PATCH RFA: Build stages 2 and 3 with C++

Gary Funck writes: > On 07/15/11 23:52:46, Ian Lance Taylor wrote: > [...] >> @@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@ >> # the last argument when conflicting --enable arguments are passed. >> # * Likewise, we force-disable coverage flags, since the installed >> # compiler

Re: [C++ Patch] PR 51265

OK, just adjust the comment to add "or non-type template parameter". Jason

Go patch committed: New lock/note implementation

This patch updates the implementations of locks and notes used in libgo to use the current version from the master Go library. This now uses futexes when running on GNU/Linux, while still using semaphores on other systems. This implementation should be faster, and does not require explicit initia

Re: [patch] support LTO of transactional memory

On 11/22/2011 09:55 AM, Aldy Hernandez wrote: > * opts.c (finish_options): Do not fail for -fgnu-tm. > * gimple-streamer-out.c (output_gimple_stmt): Handle GIMPLE_TRANSACTION. > * gimple-streamer-in.c (input_gimple_stmt): Same. > * lto-cgraph.c (input_overwrite_node): Read t

Re: Re-merge crtstuff.c from the trans-mem branch

On 11/22/2011 04:15 AM, Rainer Orth wrote: > This patch broke bootstrap on Solaris 8 and 9/x86 with Sun as which > doesn't support .hidden: linking the stage2 lto-plugin fails like this: > > ld: fatal: relocation error: R_386_GOTOFF: file > /var/gcc/regression/trunk/8-gcc/build/./prev-gcc/crtbegi

Re: [v3] updated atomic configury

On Tue, 22 Nov 2011, Andrew MacLeod wrote: > On 11/22/2011 10:32 AM, Joseph S. Myers wrote: > > On Tue, 22 Nov 2011, Andrew MacLeod wrote: > > > > > C currently doesn't have a char16_t and char32_t, so they aren't defined > > It certainly does have those types, as typedefs defined in for > > the

Ping: Java, disable -fdelete-null-pointer-checks

* lang.c (java_init_options_struct): Disable optimizations which assume a NULL pointer dereference will cause a fault. Index: lang.c === *** lang.c (revision 181321) --- lang.c (working copy) **

Re: PATCH RFA: Build stages 2 and 3 with C++

On 11/22/11 11:32:03, Ian Lance Taylor wrote: > > If CXXFLAGS, is this a potentially surprising departure from > > previous configure behavior? > > Perhaps. I don't see how we could reasonably make any other choice,though. Agreed. Just wondering if there might be potential documentation impact,

Re: [patch] support LTO of transactional memory

On Tue, Nov 22, 2011 at 10:30:44AM -0800, Richard Henderson wrote: > On 11/22/2011 09:55 AM, Aldy Hernandez wrote: > > * opts.c (finish_options): Do not fail for -fgnu-tm. > > * gimple-streamer-out.c (output_gimple_stmt): Handle GIMPLE_TRANSACTION. > > * gimple-streamer-in.c (input_gimp

--enable-checking=all results in long running compiles, where the compiler spends long periods of time in the garbage collector (GC)

On 11/22/11 12:57:38, Diego Novillo wrote: > --enable-checking=all enables GC checking, so I am not really > surprised at the behaviour you observe. Good to know. Thanks. > > I will try rebuilding with --disable-build-poststage1-with-cxx and > > --enable-checking=all to try to determine if this

Re: [patch] support LTO of transactional memory

On 22 Nov 2011, at 20:57, Jack Howarth wrote: On Tue, Nov 22, 2011 at 10:30:44AM -0800, Richard Henderson wrote: On 11/22/2011 09:55 AM, Aldy Hernandez wrote: * opts.c (finish_options): Do not fail for -fgnu-tm. * gimple-streamer-out.c (output_gimple_stmt): Handle GIMPLE_TRANSACTIO

[google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

This patch is for google-main only. Tested with bootstrap and regression tests. Under LIPO, estimate the code size footprint from the partial call graph, and if it is large limit unrolling and peeling to avoid increasing icache pressure. Teresa 2011-11-21 Teresa Johnson * loop-unroll.

Re: [patch] support LTO of transactional memory

-fgnu-tm -m32 -o gcc-dg-lto-trans-mem-1-01.exe (timeout = 300) Undefined symbols for architecture i386:^M "__ITM_registerTMCloneTable", referenced from:^M ___doTMRegistrations in crttms.o^M ___doTMRegistrations in crttms.o^M "__ITM_deregisterTMCloneTable", referenced from:^M ___doTMdeRegistratio

Re: [google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

On 11-11-22 16:06 , Teresa Johnson wrote: This patch is for google-main only. Tested with bootstrap and regression tests. Under LIPO, estimate the code size footprint from the partial call graph, and if it is large limit unrolling and peeling to avoid increasing icache pressure. So, currently,

Re: [patch] support LTO of transactional memory

On 22 Nov 2011, at 21:09, Aldy Hernandez wrote: -fgnu-tm -m32 -o gcc-dg-lto-trans-mem-1-01.exe (timeout = 300) Undefined symbols for architecture i386:^M "__ITM_registerTMCloneTable", referenced from:^M ___doTMRegistrations in crttms.o^M ___doTMRegistrations in crttms.o^M "__ITM_deregisterTMC

Re: [google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

The failures are independent which will be looked into at some point. Teresa's patch is/will be tested cleanly on google-46. David On Tue, Nov 22, 2011 at 1:12 PM, Diego Novillo wrote: > On 11-11-22 16:06 , Teresa Johnson wrote: >> >> This patch is for google-main only. >> Tested with bootstrap

Re: [PATCH] __atomic error reporting

On Tue, 22 Nov 2011, Andrew MacLeod wrote: > int n = get_atomic_generic_size (loc, function, params); > > + /* Size of 0 is an error condition. */ > + if (n == 0) > + { > + *new_return = error_mark_node; > + return true; > + } As far as I can see, get_atomic_generi

Re: [patch] support LTO of transactional memory

It's a consequence of a combination of the way that "weak" works on Darwin, and the fact that I tried to make a "one size fits all" crt. Can you try this? we will need a dummy for _ITM_deregisterTMCloneTable as well. Then try this; similarly for any other symbols Darwin may be generating

Re: [patch] support LTO of transactional memory

On Tue, Nov 22, 2011 at 03:30:22PM -0600, Aldy Hernandez wrote: > >> It's a consequence of a combination of the way that "weak" works on >> Darwin, and the fact that I tried to make a "one size fits all" crt. >> >>> >>> Can you try this? >>> >> >> we will need a dummy for _ITM_deregisterTMCloneTab

Re: [patch] support LTO of transactional memory

On 11/22/2011 01:37 PM, Jack Howarth wrote: > On x86_64-apple-darwin11, this converts the link failures into run-time > failures > as are seen on i386 linux. These aren't supposed to be runtime tests. Did a { dg-do link } marker get missed? r~

Re: [google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

Ok for google branches. David On Tue, Nov 22, 2011 at 1:06 PM, Teresa Johnson wrote: > This patch is for google-main only. > Tested with bootstrap and regression tests. > Under LIPO, estimate the code size footprint from the partial call > graph, and if it is large limit unrolling and peeling to

Re: [PATCH 0/7] Sparc atomic optabs errata

On 11/21/2011 09:21 PM, David Miller wrote: > Hey Richard, after the ICE fix you made today the only test that > fails is gcc.dg/atomic-flag.c at -O0. Below is the assembler > generated. Yeah, that test is in error. Andrew and I are discussing how to re-arrange the atomic_bool support. r~

Re: [PATCH] PR c++/51145 - Alias template in elaborated-type-specifier

Jason Merrill writes: > On 11/21/2011 11:41 AM, Dodji Seketeli wrote: >> -template class Ptr;//{ dg-error "explicit instantiation|non-class >> templ|does not decl|anything" } >> +template class Ptr;//{ dg-error "alias >> templ|specialization|Ptr|after|class" } > > You seem to be using | to mean

Re: [PATCH 0/7] Sparc atomic optabs errata

From: Richard Henderson Date: Tue, 22 Nov 2011 14:36:53 -0800 > On 11/21/2011 09:21 PM, David Miller wrote: >> Hey Richard, after the ICE fix you made today the only test that >> fails is gcc.dg/atomic-flag.c at -O0. Below is the assembler >> generated. > > Yeah, that test is in error. > > And

Re: [patch] support LTO of transactional memory

On 22 Nov 2011, at 21:43, Richard Henderson wrote: On 11/22/2011 01:37 PM, Jack Howarth wrote: On x86_64-apple-darwin11, this converts the link failures into run- time failures as are seen on i386 linux. These aren't supposed to be runtime tests. Did a { dg-do link } marker get missed?

Re: [patch] support LTO of transactional memory

On 11/22/11 16:40, Iain Sandoe wrote: On 22 Nov 2011, at 21:43, Richard Henderson wrote: On 11/22/2011 01:37 PM, Jack Howarth wrote: On x86_64-apple-darwin11, this converts the link failures into run-time failures as are seen on i386 linux. These aren't supposed to be runtime tests. Did a

RE: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL

At 2011-11-22 18:37:16,"Ramana Radhakrishnan" wrote: > >> > >> Though I don't fully understand this patch, I think it is unnecessary to > consider turn on Thumb2 for iwmmxt, > >> because there is no chip that supports WMMX instructions with thumb2 > mode. > > Xinyu: I seem to have mis-remembere

[arm-embedded] Fix restrict volatile bitfield

Committed to ARM/embedded-4_6-branch Partly apply restrict volatile bitfield fix from bernd. 2010-12-02 Bernd Schmidt * expr.c (store_field): Avoid a direct store if the mode is larger than the size of the bit field. * stor-layout.c (layout_decl): If fla