Go patch committed: Copy channel implementation from master library

This patch copies the channel implementation from the master Go library to the gccgo library. This is a followon patch to the earlier change to multiplex goroutines onto threads. With this patch channels now use the goroutine scheduler directly, rather than taking up a thread by using a condition

Re: [PATCH] Avoid messages about non-existent gnatls command (PR bootstrap/51201)

> := assigned variable gets evaluated right away, including the case when > host doesn't have any Ada compiler installed. In that case we remove ada > from enabled languages, but still RTS_DIR is sometimes computed. Can you elaborate here? When is RTS_DIR computed if Ada is not enabled? That seem

Re: [PATCH] Remove dead labels to increase superblock scope

On 27/11/11 23:59, Eric Botcazou wrote: >> No, DELETED_LABEL notes still work just fine. It depends on how you >> remove the label and replace it with a note, and Tom isn't showing >> what he did, so... > > I agree that there is no obvious reason why just calling delete_insn would > not > work,

Re: [PATCH] Avoid messages about non-existent gnatls command (PR bootstrap/51201)

On Thu, Dec 01, 2011 at 09:08:27AM +0100, Arnaud Charlet wrote: > > := assigned variable gets evaluated right away, including the case when > > host doesn't have any Ada compiler installed. In that case we remove ada > > from enabled languages, but still RTS_DIR is sometimes computed. > > Can you

Re: [PATCH] Avoid messages about non-existent gnatls command (PR bootstrap/51201)

> As written in the PR, even if you on say x86_64-linux > ../configure --enable-languages=c --target=i686-pc-linux-gnu > you end up with: > CONFIG_LANGUAGES = c++ lto > LANGUAGES = c gcov$(exeext) gcov-dump$(exeext) $(CONFIG_LANGUAGES) > ... > LANG_MAKEFRAGS = $(srcdir)/ada/gcc-interface/Make-lan

Re: [PATCH] Avoid messages about non-existent gnatls command (PR bootstrap/51201)

On Thu, Dec 01, 2011 at 09:50:15AM +0100, Arnaud Charlet wrote: > > As written in the PR, even if you on say x86_64-linux > > ../configure --enable-languages=c --target=i686-pc-linux-gnu > > you end up with: > > CONFIG_LANGUAGES = c++ lto > > LANGUAGES = c gcov$(exeext) gcov-dump$(exeext) $(CONFIG

[Patch, fortran] Don't call stat before fopen

Hi, there's no need to stat() the filename before we fopen() it in gfc_open_file(). If the file doesn't exist, fopen() will return NULL anyway, and if the user really wants to read source or module data from a special file, so be it. Committed to trunk as obvious. 2011-12-01 Janne Blomqvist

Re: [PATCH] Avoid messages about non-existent gnatls command (PR bootstrap/51201)

On Thu, Dec 01, 2011 at 09:55:04AM +0100, Jakub Jelinek wrote: > I believe because we want > cd obj/gcc > make f951 > work even when --enable-languages=c,c++ , it is quite handy > not having to reconfigure gcc because you forgot one language, especially > when you have lots of cross-compilers aroun

Re: [PATCH] Avoid messages about non-existent gnatls command (PR bootstrap/51201)

> > when you have lots of cross-compilers around. > > If LANG_MAKEFRAGS would be limited only to the chosen languages, > > this would suddenly not work at all. > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg02100.html > is the change that went into 4.2. OK well, maybe the above patch is partly

Re: [C++ Patch] PR 51327

On 12/01/2011 07:13 AM, Jason Merrill wrote: Ah, I see. I guess what we want here is the GCC 4.5 version of locate_ctor instead of the new one; once we've checked that we have a default ctor and no user-provided default ctor, there must be a unique defaulted ctor so just walking CLASSTYPE_CONS

Re: [RFC] Port libitm to powerpc

On Wed, 2011-11-30 at 21:41 -0500, David Edelsohn wrote: > On Wed, Nov 30, 2011 at 8:05 PM, Richard Henderson wrote: > > This is a tad rough, but not too bad. > > Cool. > > Maybe I don't understand what they are suppose to represent, but why > the choice of values for cacheline size? Is that su

Re: [RFC] Port libitm to powerpc

On Wed, 2011-11-30 at 17:05 -0800, Richard Henderson wrote: > Oh, for the record, I think we should probably be saving and restoring the fp > state on all targets. If we restart a transaction, we're really saying that > absolutely nothing happened. Something like > > double a, b, c; > __tr

Use atomics in remaining libgomp/config/linux sources

This converts the remaining files in libgomp/config/linux/ to use atomics. gomp_init_thread_affinity fairly obviously needs no barriers; I wasn't so sure about ptrlock, so tried without the acquire/release barriers and found a number of the loop tests failed. So it seems the usual lock barriers a

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

On Tue, 22 Nov 2011, Jakub Jelinek wrote: > Hi! > > VEC_INTERLEAVE_*_EXPR trees are unfortunately dependent on BYTES_BIG_ENDIAN, > what is HIGH vs. LOW is different based on endianity. Huh, that looks bogus. Both tree codes operate on registers and no other codes care about "endianess" of vecto

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Wed, 23 Nov 2011, Diego Novillo wrote: > On Sat, Nov 5, 2011 at 07:02, Iain Sandoe > wrote: > > > > On 28 Oct 2011, at 13:57, Richard Guenther wrote: > > > >> > >> We fail to keep the cannot-inline flag up-to-date when turning > >> indirect to direct calls.  The following patch arranges to do

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

On Thu, Dec 01, 2011 at 10:53:57AM +0100, Richard Guenther wrote: > On Tue, 22 Nov 2011, Jakub Jelinek wrote: > > VEC_INTERLEAVE_*_EXPR trees are unfortunately dependent on BYTES_BIG_ENDIAN, > > what is HIGH vs. LOW is different based on endianity. > > Huh, that looks bogus. Both tree codes opera

[C++ Patch] PR 51326

Hi, in this ICE on invalid, 4.7 Regression, we ICE at the beginning of build_user_type_conversion_1 because expr is NULL_TREE. The function is called as such from reference_binding which, in 4.6, used to call instead convert_class_to_reference which does check for a NULL_TREE expr. Thus I thi

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Tue, 29 Nov 2011, Diego Novillo wrote: > Iain, could you let me know if the attached patch fixes your problem? > The patch changes gimple_call_set_cannot_inline to update the > corresponding callgraph edge, if needed. I did not touch any of the > other calls, because sometimes we are calling t

Re: [PATCH 2/5] arm: Emit swp for pre-armv6.

Sorry, no. It's essential we don't emit SWP instructions directly into code on any platform where that code may possibly be run on a later core that has LDREX/STREX. If we do that we'll end up with a mess that can't be resolved. In the absence of known OS helper functions the only solution to t

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Tue, 29 Nov 2011, Diego Novillo wrote: > On Tue, Nov 29, 2011 at 12:49, H.J. Lu wrote: > > > This caused: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51346 > > Thanks. I'm on it. The patch was wrong, please revert it. At the gimple stmt modification level we shouldn't modify the c

Re: Tidy up MD_INCLUDES in config/arm/t-arm

Richard Earnshaw wrote: > On 29/11/11 09:42, Matthew Gretton-Dann wrote: >> All, >> >> Whilst developing the Cortex-A15 integer pipeline patch it was noted >> that the MD_INCLUDES variable in config/arm/t-arm has not been kept >> up-to-date. >> >> The attached patch fixes this, and rearranges the

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

On Thu, 1 Dec 2011, Jakub Jelinek wrote: > On Thu, Dec 01, 2011 at 10:53:57AM +0100, Richard Guenther wrote: > > On Tue, 22 Nov 2011, Jakub Jelinek wrote: > > > VEC_INTERLEAVE_*_EXPR trees are unfortunately dependent on > > > BYTES_BIG_ENDIAN, > > > what is HIGH vs. LOW is different based on endi

Re: [PATCH 4/5] arm: Set predicable on more instructions.

Hi Richard, > --- >  gcc/config/arm/arm.md |   40 ++-- >  1 files changed, 30 insertions(+), 10 deletions(-) > > diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md > index b01343c..3b24627 100644 > --- a/gcc/config/arm/arm.md > +++ b/gcc/config/arm/arm

Re: [Patch,AVR] Light-weight DImode implementation.

Denis Chertykov wrote: The only question that remains is what the -m64 option should be like? [ ] Omit it altogether [ ] Leave it as is (off per default) [ ] Set it on per default As soon as the direction is clear, I'll post a follow-up patch to add the mis

PR libgomp/51376 fix

The simple one-line fix in GOMP_taskwait took many hours to find. Shared memory problems are a pain to debug, especially when adding code to dump some state turns a testcase that fails every hundred or so runs into one that takes thousands of times longer to fail. What happens here is that GOMP_ta

Re: [Patch.AVR,4.6] Fix PR51002

Joerg Wunsch wrote: > As Georg-Johann Lay wrote: > >> Then avr-mcus.def adopted this bug from the manual for ATtiny4313 at least: >> >> AVR_MCU ("attiny4313", ARCH_AVR25, "__AVR_ATtiny4313__", 1 /* short_sp, >> should >> be 0 ? */, 0, 0x0060, "tn4313") > > Not unlikely. > > I just ordered one.

Re: PR libgomp/51376 fix

On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote: > The GOMP_task change fixes a similar potential problem. Bootstrapped > and regression tested powerpc-linux. OK to apply? > > PR libgomp/51376 > * task.c (GOMP_taskwait): Don't access task->children outside of > task_

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

On Tue, 2011-11-22 at 10:37 +, Ramana Radhakrishnan wrote: > Xinyu: I seem to have mis-remembered that one of your patches was > turning on Thumb2 for wMMX. > > > > Ramana, in that case, should I add the change you suggested in ARM RTL > > epilogue patch only? > > The comment in Thumb2 epilog

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Thu, Dec 1, 2011 at 05:59, Richard Guenther wrote: > On Tue, 29 Nov 2011, Diego Novillo wrote: > >> On Tue, Nov 29, 2011 at 12:49, H.J. Lu wrote: >> >> > This caused: >> > >> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51346 >> >> Thanks.  I'm on it. > > The patch was wrong, please revert it

Re: [PATCH] Implement stap probe on ARM's unwinder

Sergio: Other than a few minor tweaks to the Changelog it largely looks obvious to me. Bernd, could you take another look at this since this is now shared with the c6x backend ? > Thanks, > > Sergio. > > diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog > index 305e8ad..f6e9dec 100644 > --- a/libg

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Thu, 1 Dec 2011, Diego Novillo wrote: > On Thu, Dec 1, 2011 at 05:59, Richard Guenther wrote: > > On Tue, 29 Nov 2011, Diego Novillo wrote: > > > >> On Tue, Nov 29, 2011 at 12:49, H.J. Lu wrote: > >> > >> > This caused: > >> > > >> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51346 > >> > >>

Re: [PATCH, PR 50744] Prevent overflows in IPA-CP

On Fri, Nov 18, 2011 at 6:47 PM, Martin Jambor wrote: > Hi, > > PR 50744 is an issue with an integer overflow when we propagate the > estimated size and time effects from callees to callers.  Because such > paths in the parameter value graph can be arbitrarily long, we simply > need to introduce a

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Thu, Dec 1, 2011 at 07:08, Richard Guenther wrote: > Sure, but then you can still have the issue of an inconsistency. Not if we make the edge attribute secondary to the statement attribute. Given that can_inline_edge_p() is the *only* tester for this attribute, what I was thinking was to chan

Re: [RFC] Use REG_EXPR in back-end (introduced by optimization to conditional and/or in ARM back-end)

On Tue, Nov 22, 2011 at 2:55 AM, Richard Henderson wrote: > On 11/21/2011 05:31 PM, Jiangning Liu wrote: >> My question is essentially is "May I really use REG_EXPR in back-end code?" >> like the patch I gave below? > > I suppose. I'm not so sure ;) At least checking for BOOLEAN_TYPE is incomple

Re: [PATCH] Fix predcom ICE introduced by var clobber changes (PR tree-optimization/51246)

On Thu, Nov 24, 2011 at 5:28 PM, Michael Matz wrote: > Hi, > > On Thu, 24 Nov 2011, Jakub Jelinek wrote: > >> When stmt is mem = {v} {CLOBBER};, then lhs is neither >> SSA_NAME, but it doesn't satisfy gimple_assign_copy_p either. >> With this patch it will set the new_tree also to the clobber, >>

Re: [PATCH] Fix predcom ICE introduced by var clobber changes (PR tree-optimization/51246, take 2)

On Thu, Nov 24, 2011 at 5:51 PM, Michael Matz wrote: > Hi, > > On Thu, 24 Nov 2011, Jakub Jelinek wrote: > >> On Thu, Nov 24, 2011 at 05:28:00PM +0100, Michael Matz wrote: >> > As the default defs are already automatically handled by all our ssa >> > infrastructure (including warning and propagati

Re: [PATCH] Fix predcom ICE introduced by var clobber changes (PR tree-optimization/51246, take 2)

Hi, On Thu, 1 Dec 2011, Richard Guenther wrote: > >> > As the default defs are already automatically handled by all our > >> > ssa infrastructure (including warning and propagation machinery) I > >> > think it would be best to generate such one instead of a clobber > >> > for the RHS. > >> > >

Re: RFA: Fix PR tree-optimization/50802

On Sat, Nov 26, 2011 at 10:17 AM, Joern Rennecke wrote: > With this rewrite of simplify_conversion_using_ranges we go back to the > original problem of considering if a single conversion is sufficient > considering the known input range. > > Bootstrapped and regtested on i686-pc-linux-gnu. Ok. T

Re: [Patch, fortran] PR 25708 Reduce seeks when loading module files

On Wednesday 30 November 2011 23:49:58 Janne Blomqvist wrote: > > With the updated patch, the number of lseek's when compiling > > aermod.f90 drop to 38, which is a factor of 15 reduction compared > > to the current trunk. And a factor of 55 compared to trunk a few days > > ago before Thomas' p

Re: [RFC] Port libitm to powerpc

On Thu, Dec 1, 2011 at 4:36 AM, Torvald Riegel wrote: > On Wed, 2011-11-30 at 21:41 -0500, David Edelsohn wrote: >> On Wed, Nov 30, 2011 at 8:05 PM, Richard Henderson wrote: >> > This is a tad rough, but not too bad. >> >> Cool. >> >> Maybe I don't understand what they are suppose to represent, b

Re: [RFC] Port libitm to powerpc

On 1 Dec 2011, at 01:05, Richard Henderson wrote: No support for non-ELF, aka AIX and Darwin. I'm not 100% sure how to handle the assembly markup for those, and I couldn't test it anyway. Again, I'd prefer someone else figure that stuff out. I've started to take a look at Darwin [sjl

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Thu, 1 Dec 2011, Diego Novillo wrote: > On Thu, Dec 1, 2011 at 07:08, Richard Guenther wrote: > > Sure, but then you can still have the issue of an inconsistency. > > Not if we make the edge attribute secondary to the statement > attribute. Given that can_inline_edge_p() is the *only* tester

Re: [PATCH] Don't ICE on label DEBUG_INSN in rtl loop unrolling (PR rtl-optimization/51014)

On Tue, Nov 29, 2011 at 12:16 AM, Jakub Jelinek wrote: > Hi! > > DEBUG_INSN with LABEL_DECL var isn't duplicated in bb copies (we want > just one definition of the label), which breaks apply_opt_in_copies > attempt to match insn in bb copy with orig_insn from the orig_bb. > > Fixed thusly, bootstr

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Thu, Dec 1, 2011 at 09:04, Richard Guenther wrote: > The above looks ok to me, but I don't want the > gimple_call_set_cannot_inline change (if it is in the tree - I have > not yet recovered from three weeks of vacation).  The edge attribute > is "recomputed" when necessary. The original patch

Re: [RFC] Port libitm to powerpc

On 1 Dec 2011, at 14:04, Iain Sandoe wrote: I presume that w should treat this as a normal prologue - and it looks very much like "save the world" - BTW, if this is true ( i.e. we should be preserving all call-saved regs around the call to GTM_begin_transaction), then I guess we should be

Re: [PATCH] Fix early inliner inlining uninlinable functions

On Thu, 1 Dec 2011, Diego Novillo wrote: > On Thu, Dec 1, 2011 at 09:04, Richard Guenther wrote: > > > The above looks ok to me, but I don't want the > > gimple_call_set_cannot_inline change (if it is in the tree - I have > > not yet recovered from three weeks of vacation).  The edge attribute >

[Patch, fortran] Make a few helper functions static

Hi, committed the patch below as obvious. 2011-12-01 Janne Blomqvist * module.c (dt_lower_string): Make static. (dt_upper_string): Likewise. Index: module.c === --- module.c(revision 181880) +++ module.c

Re: [Patch PPC/Darwin] add fp/gp save routines to ppc64 case.

On Nov 29, 2011, at 9:06 AM, Iain Sandoe > wrote: As Rainer recently pointed out, libgcc/config/rs6000/t-darwin64 overrides the t-darwin version. This would make it miss the out-of-line saves. corrected as attached, OK for trunk? Ok.

Re: [RFC] Port libitm to powerpc

On 12/01/2011 06:00 AM, David Edelsohn wrote: > On Thu, Dec 1, 2011 at 4:36 AM, Torvald Riegel wrote: >> On Wed, 2011-11-30 at 21:41 -0500, David Edelsohn wrote: >>> On Wed, Nov 30, 2011 at 8:05 PM, Richard Henderson wrote: This is a tad rough, but not too bad. >>> >>> Cool. >>> >>> Maybe I

Re: [PATCH, lto]: Handle *tm regparm attribute

On Wed, Nov 30, 2011 at 6:03 PM, Jan Hubicka wrote: >> Hello! >> >> Attached patch handles "*tm regparm" attribute, to avoid "*tm regparm" >> attribute ignored warnings in lto compile on non-x86 targets. >> >> 2011-11-30  Uros Bizjak   >> >>       * lto-lang.c (lto_attribute_table): Handle *tm reg

Re: [RFC] Port libitm to powerpc

On 12/01/2011 01:42 AM, Torvald Riegel wrote: > The ABI defines the pr_hasNoFloatUpdate and pr_hasNoVectorUpdate flags > for _ITM_beginTransaction but we don't handle these currently. I guess > we should do the save/restore unless those flags are set? > > How difficult would it be to set these fl

Re: [PATCH] Fix PR 51198, DECL_INITIAL still contains stuff for FIELD_DECLs

On Wed, Nov 30, 2011 at 8:05 PM, Andrew Pinski wrote: > Hi, >  With C++11's decl initialization for non static members, the > DECL_INITIAL for FIELD_DECLs contains stuff which we don't need to > keep around after the front-end is done.  This patch clears them in > the free_lang_data pass. > > OK?

Re: [testsuite] xfail target-specific asms, & gcov

On Nov 27, 2011, at 3:41 PM, Nathan Sidwell wrote: this patch extends scan-assembler (and scan-assembler-not) to allow something like: /* { dg-final { scan-assembler "\\.hidden \t__gcov___ZN1X4FinkEv" { target { ! *-*-darwin* } } { xfail *-*- * } } } */ ok? Almost... Every test that ca

Re: [RFC] Port libitm to powerpc

On 12/01/2011 06:42 AM, Iain Sandoe wrote: >> I presume that w should treat this as a normal prologue - and it >> looks very much like "save the world" - > > BTW, if this is true ( i.e. we should be preserving all call-saved > regs around the call to GTM_begin_transaction), then I guess we > shoul

Re: [PATCH, lto]: Handle *tm regparm attribute

> On Wed, Nov 30, 2011 at 6:03 PM, Jan Hubicka wrote: > >> Hello! > >> > >> Attached patch handles "*tm regparm" attribute, to avoid "*tm regparm" > >> attribute ignored warnings in lto compile on non-x86 targets. > >> > >> 2011-11-30  Uros Bizjak   > >> > >>       * lto-lang.c (lto_attribute_tabl

Re: [PATCH 2/5] arm: Emit swp for pre-armv6.

On 12/01/2011 02:59 AM, Richard Earnshaw wrote: > It's essential we don't emit SWP instructions directly into code on any > platform where that code may possibly be run on a later core that has > LDREX/STREX. If we do that we'll end up with a mess that can't be resolved. Ok. It's easy enough to

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

On 12/01/2011 03:21 AM, Richard Guenther wrote: > Yes, sorry - I'm recovering from a 3 week e-mail lag ;) I agree > using VEC_PERM_EXPR would be best - but that would also affect > backend patterns. Can we have a middle-ground that leaves those > untouched? We're still in stage 3, so fixing the

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

On Thu, Dec 01, 2011 at 07:57:48AM -0800, Richard Henderson wrote: > On 12/01/2011 03:21 AM, Richard Guenther wrote: > > Yes, sorry - I'm recovering from a 3 week e-mail lag ;) I agree > > using VEC_PERM_EXPR would be best - but that would also affect > > backend patterns. Can we have a middle-gr

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

On Thu, 1 Dec 2011, Jakub Jelinek wrote: > On Thu, Dec 01, 2011 at 07:57:48AM -0800, Richard Henderson wrote: > > On 12/01/2011 03:21 AM, Richard Guenther wrote: > > > Yes, sorry - I'm recovering from a 3 week e-mail lag ;) I agree > > > using VEC_PERM_EXPR would be best - but that would also aff

[PATCH, PR 50622] Force a gimple operand in load_assign_lhs_subreplacements when necessary

Hi, PR 50622 is an omission in load_assign_lhs_subreplacements, which should force a gimple operand on a RHS of a gimple assignment if both sides are new replacements of scalar types which are not gimple registers, because they are partially modified (which can happen to complex numbers and bit-fi

Re: [PATCH, PR 50744] Prevent overflows in IPA-CP

> On Fri, Nov 18, 2011 at 6:47 PM, Martin Jambor wrote: > > Hi, > > > > PR 50744 is an issue with an integer overflow when we propagate the > > estimated size and time effects from callees to callers.  Because such > > paths in the parameter value graph can be arbitrarily long, we simply > > need

Re: [PATCH, lto]: Handle *tm regparm attribute

2011/12/1 Jan Hubicka : >> >> Attached patch handles "*tm regparm" attribute, to avoid "*tm regparm" >> >> attribute ignored warnings in lto compile on non-x86 targets. >> >> >> >> 2011-11-30  Uros Bizjak   >> >> >> >>       * lto-lang.c (lto_attribute_table): Handle *tm regparm. >> >>       (igno

Re: [PATCH 4/5] arm: Set predicable on more instructions.

On 12/01/2011 03:22 AM, Ramana Radhakrishnan wrote: >> "tst\\t%0, #255" >> - [(set_attr "conds" "set")] >> + [(set_attr "conds" "set") >> + (set_attr "predicable" "yes")] >> ) > > It should be tst%? . Otherwise in the predicable case we wouldn't have > the condition code printed out. Yes,

Re: [PATCH, PR 50744] Prevent overflows in IPA-CP

On Thu, Dec 01, 2011 at 05:16:21PM +0100, Jan Hubicka wrote: > > This introduces host-dependent code generation differences, right? > > You can simply use int64_t for code that is run on the host only. > > Well, if we rely on int64_t being around now (that is probably the case with > C++ switch),

Re: [PATCH, lto]: Handle *tm regparm attribute

On Thu, Dec 1, 2011 at 5:19 PM, Uros Bizjak wrote: > 2011/12/1 Jan Hubicka : > >>> >> Attached patch handles "*tm regparm" attribute, to avoid "*tm regparm" >>> >> attribute ignored warnings in lto compile on non-x86 targets. >>> >> >>> >> 2011-11-30  Uros Bizjak   >>> >> >>> >>       * lto-lang.c

Re: Go patch committed: Multiplex goroutines onto OS threads

Ian Lance Taylor writes: > This patch changes the Go library to multiplex goroutines onto operating > system threads. Previously, each new goroutine ran in a separate > thread. That is inefficient for programs with lots of goroutines. This > patch changes the library such that it runs a certai

[PATCH] Don't change DR_STMT if vect_pattern_recog_1 would fail (PR tree-optimization/51356)

Hi! As mentioned in the PR, vect_pattern_recog_1 attempts to find out if the computed type_in and type_out are already vector types or not, and uses VECTOR_MODE_P (TYPE_MODE (type_in)) as the test. Unfortunately, get_vectype_for_scalar_type on some targets (e.g. PowerPC) returns a VECTOR_TYPE wit

Re: Go patch committed: New lock/note implementation

Ian Lance Taylor writes: >> ... and also Solaris 8 and 9 bootstrap which lack sem_timedwait: >> >> /vol/gcc/src/hg/trunk/local/libgo/runtime/thread-sema.c: In function >> 'runtime_semasleep': >> /vol/gcc/src/hg/trunk/local/libgo/runtime/thread-sema.c:42:7: error: >> implicit declaration of func

[PATCH] Improve debug info if tree DCE removes stores (PR debug/50317)

Hi! As discussed in the PR, in 4.7 we regressed some GDB testcases, because previously unused addressable vars were first previously optimized into non-addressable and only afterwards removed (which results in correct debug stmts covering those assignments), but after some recent changes it is CDD

Re: Use atomics in remaining libgomp/config/linux sources

On 12/01/2011 01:44 AM, Alan Modra wrote: > * config/linux/affinity.c: Use atomic rather than sync builtin. > * config/linux/lock.c: Likewise. > * config/linux/ptrlock.h: Likewise. > * config/linux/ptrlock.c: Likewise. > * config/linux/ptrlock.h (gomp_ptrlock_set): Alw

Re: [RFC] Port libitm to powerpc

On Thu, 2011-12-01 at 07:42 -0800, Richard Henderson wrote: > I didn't notice CR registers being saved in the linux setjmp function, > but perhaps I just missed it? I believe the setjmp/getcontext functions save the entire CR rather than just the non-volatile CR fields. Looking at the glibc code,

Re: [PATCH 2/5] arm: Emit swp for pre-armv6.

On 12/01/2011 10:49 AM, Richard Henderson wrote: On 12/01/2011 02:59 AM, Richard Earnshaw wrote: It's essential we don't emit SWP instructions directly into code on any platform where that code may possibly be run on a later core that has LDREX/STREX. If we do that we'll end up with a mess that

Re: [RFC] Port libitm to powerpc

On 1 Dec 2011, at 16:50, Peter Bergner wrote: On Thu, 2011-12-01 at 07:42 -0800, Richard Henderson wrote: I didn't notice CR registers being saved in the linux setjmp function, but perhaps I just missed it? I believe the setjmp/getcontext functions save the entire CR rather than just th

Re: [PATCH, PR 50744] Prevent overflows in IPA-CP

> On Thu, Dec 01, 2011 at 05:16:21PM +0100, Jan Hubicka wrote: > > > This introduces host-dependent code generation differences, right? > > > You can simply use int64_t for code that is run on the host only. > > > > Well, if we rely on int64_t being around now (that is probably the case with > > C

Re: Go patch committed: Multiplex goroutines onto OS threads

Rainer Orth writes: > Unfortunately, this patch broke Solaris bootstrap (and would break IRIX > bootstrap if this ever started working again): > > /vol/gcc/src/hg/trunk/local/libgo/runtime/go-signal.c:221:1: error: > conflicting types for 'sigignore' > In file included from > /vol/gcc/src/hg/tr

Re: [RFC] Port libitm to powerpc

On Thu, 2011-12-01 at 17:01 +, Iain Sandoe wrote: > However, we (on Darwin) don't seem to save the FPSCR - and there's no > mention of it in "preserved regs" section of the ABI doc. I wonder if > that's an oversight. The ppc* linux ABIs state the FPSCR is volatile, maybe it's the same on

Re: PR middle-end/51273: call cgraph_call_node_duplication_hooks

On 11/27/2011 04:44 PM, Patrick Marlier wrote: > PR middle-end/51273 > * cgraph.h (cgraph_call_node_duplication_hooks): Declare. > * cgraph.c (cgraph_call_node_duplication_hooks): Make global. > * cgraphunit.c (cgraph_copy_node_for_versioning): Call duplication > hook

Re: [PATCH] Don't change DR_STMT if vect_pattern_recog_1 would fail (PR tree-optimization/51356)

On 1 December 2011 18:41, Jakub Jelinek wrote: > Hi! Hi, > > As mentioned in the PR, vect_pattern_recog_1 attempts to find out > if the computed type_in and type_out are already vector types or not, > and uses VECTOR_MODE_P (TYPE_MODE (type_in)) as the test.  Unfortunately, > get_vectype_for_sca

Re: [RFC] Port libitm to powerpc

On Thu, Dec 1, 2011 at 10:30 AM, Richard Henderson wrote: > I made it up.  As he said, it's only used for padding to *attempt to* avoid > false sharing.  Currently sources won't actually fail with the wrong > cacheline value, but they'll work more efficiently with the right value. The cache li

Re: [PATCH] Improve debug info if tree DCE removes stores (PR debug/50317)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/11 09:49, Jakub Jelinek wrote: > Hi! > > As discussed in the PR, in 4.7 we regressed some GDB testcases, > because previously unused addressable vars were first previously > optimized into non-addressable and only afterwards removed (which >

Re: [RFC] Port libitm to powerpc

On Thu, 1 Dec 2011, Iain Sandoe wrote: > However, we (on Darwin) don't seem to save the FPSCR - and there's no mention > of it in "preserved regs" section of the ABI doc. I wonder if that's an > oversight. As I previously noted in the ARM discussion, C specifically says that setjmp/longjmp sho

Go patch committed: Export and import of predeclared error type

This patch from Rémy Oudompheng fixes the export and import of the predeclared error type. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r 2769c29f2014 go/export.cc --- a/go/export.cc Thu Dec 01 09:07:49 2011 -0800 +++ b/go/export.cc Thu Dec 01

Re: [PATCH, PR 50622] Force a gimple operand in load_assign_lhs_subreplacements when necessary

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/11 09:15, Martin Jambor wrote: > Hi, > > PR 50622 is an omission in load_assign_lhs_subreplacements, which > should force a gimple operand on a RHS of a gimple assignment if > both sides are new replacements of scalar types which are not > g

[Gcov] Unbreak C++ coverage

I've committed this patch, which unbreaks the firefox build problem Markus found. The problem is that the list of functions to emit coverage data is determined before the final culling of functions that don't need emitting. There's a circular dependency here with the cgraph machinery, and I nee

Re: [testsuite] xfail target-specific asms, & gcov

On 12/01/11 15:39, Mike Stump wrote: Makes this trivially true. In your patch, you alter the spelling of a test, never do that. Once that is fixed, Ok. Oh dear, I didn't mean to do that. Anyway, I decided to remove the visibility tests here for the moment, so the scanasm change is moot and

Re: [RFC] Port libitm to powerpc

On 12/01/2011 10:47 AM, Joseph S. Myers wrote: > As I previously noted in the ARM discussion, C specifically says that > setjmp/longjmp should *not* save/restore floating-point exceptions and > rounding modes. Think of the floating-point state as being a global > variable (well, thread-local).

[PR bootstrap/51346] Fix lto profiledbootstrap (issue5437103)

These two patches fix the profiledbootstrap failure I caused earlier this week. The first patch reverts my original fix. The second one implements a different approach for this problem. Instead of trying to keep the edge attribute in sync with the statement, we do not use the edge attribute as l

Re: [patch] original function and TM clone has to be marked needed

On 11/30/2011 08:25 PM, Patrick Marlier wrote: > In the current version, the original function and its clone are marked as > taken with cgraph_mark_address_taken_node. But it seems not enough and it has > to be marked as needed. > It comes with a testcase (testsuite/g++.dg/tm/ctor-used.C). > > P

Re: [C++ Patch] PR 51326

OK. Jason

[PATCH] Fix PR middle-end/39976, 200.sixtrack degradation

Greetings, Bug 39976 reported a degradation to 200.sixtrack wherein a hot single-block loop is broken into two blocks. Investigation showed the cause to be a redundant PHI statement in the block, which the tree-outof-ssa logic doesn't handle well. Currently we don't have code following the intro

Re: [RFC] Port libitm to powerpc

On 1 Dec 2011, at 20:20, Richard Henderson wrote: On 12/01/2011 10:47 AM, Joseph S. Myers wrote: As I previously noted in the ARM discussion, C specifically says that setjmp/longjmp should *not* save/restore floating-point exceptions and rounding modes. Think of the floating-point state as

RTEMS Specific Ada Patch

Hi, The attached patch is necessary to let the gcc head compile Ada for *-*-rtems*. Other than terminals.c, the files impacted are RTEMS specific. OK to commit? I have posted ACATS results for sparc-rtems4.11 at http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg00108.html These are better res

[patch committed] Fix target/50814

Hi, The attached patch is to fix PR50814. The sh2a support wrongly assumed that shad/shld instructions on sh2a are 4-byte long. The patch is tested on sh-elf. Regards, kaz -- 2011-12-01 Kaz Kojima PR target/50814. * config/sh/sh.c (expand_ashiftrt): Handle TARGET_SH2A

Re: [RFC] Port libitm to powerpc

On 1 Dec 2011, at 22:42, Iain Sandoe wrote: now I'm slightly confused - do we need to preserve if across the call or not? erm. not well phrased. I am trying to get a grasp on what determines the set of registers that should be saved. Initially, I was thinking that it was the "call-sa

Re: Go patch committed: New lock/note implementation

Rainer Orth writes: > FAIL: go.go-torture/execute/go-1.go execution, -O0 There should be more information in gcc/testsuite/go/go.log. > * All 64-bit libgo tests fail on the same target: > > FAIL: asn1 > /vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[422]: gotest-timeout: > cannot create

Go patch committed: Remove temporary function

I added the function runtime_cond_wait to libgo temporarily during the conversion to multiplexing goroutines. It is no longer needed and this patch removes it. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r 2ce500c576dc libgo/runtime/runtime.h

Re: [PATCH] Fix early inliner inlining uninlinable functions

Sure, but then you can still have the issue of an inconsistency. Thus, would you then remove the remaining asserts? I believe in the end the proper fix is to _not_ throw away cgraph edges all the time, but keep them up-to-date and thus make the stmt flag not necessary. (we can define "up-to-dat

Ping Re: Fix doloop bug with maximum-length loops

Ping. This patch is pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: Ping Re: Fix doloop bug with maximum-length loops

On Thu, Dec 1, 2011 at 6:08 PM, Joseph S. Myers wrote: > Ping.  This patch > is pending > review. > From my point of view, reverting my patch is fine as the testcase which I was trying to optimized was not even optimized on the trunk after

Re: Ping Re: Fix doloop bug with maximum-length loops

On Thu, Dec 1, 2011 at 6:28 PM, Andrew Pinski wrote: > On Thu, Dec 1, 2011 at 6:08 PM, Joseph S. Myers > wrote: >> Ping.  This patch >> is pending >> review. >> > > From my point of view, reverting my patch is fine as the testcase > which

  1   2   >