Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI

On 30/04/12 22:47, Michael Hope wrote: > On 1 May 2012 03:24, Richard Earnshaw wrote: >> On 27/04/12 00:27, Michael Hope wrote: >>> On 27 April 2012 08:20, Carlos O'Donell wrote: On Mon, Apr 23, 2012 at 5:36 PM, Michael Hope wrote: > 2012-04-24 Michael Hope >Ric

Re: Fix find_moveable_pseudos, PR52997

Bernd Schmidt writes: > * ira.c (allocated_reg_info_size): New static variable. > (expand_reg_info): Manage it. Call > setup_preferred_alternate_classes_for_new_pseudos. > (ira): Don't do it here. Remove local allocated_reg_info_size, > set the global before calling

Re: [rx] add initial rtx_costs() function

Hi DJ, Initial implementation of RTX_COSTS target function for rx-elf. Minor increase in coremark scores, and enables division by multiplication of reciprocals, tested on trunk and 4.7. Ok for trunk and/or 4.7 branch? * config/rx/rx.c (TARGET_RTX_COSTS): Define. (rx_rtx_costs)

Re: Patches to enable -ftrack-macro-expansion by default

Uros Bizjak writes: > Your patch introduced: > > FAIL: gcc.dg/gomp/macro-4.c (internal compiler error) > FAIL: gcc.dg/gomp/macro-4.c (test for excess errors) > > on alphaev68-pc-linux-gnu. The failure is silent on > x86_64-pc-linux-gnu, but can be uncovered by valgrind: > > $ valgrind ~/gcc-build

Re: Patches to enable -ftrack-macro-expansion by default

Dodji Seketeli writes: > Tested on x86_64-unknown-linux-gnu against trunk by running the > test gcc.dg/gomp/macro-4.c under Valgrind. Bootstrap is still > underway. For what it's worth, the patch passes bootstrap on x86_64-unknown-linux-gnu. > libcpp/ > > * directives.c (destringize_and_

Re: [RFH / Patch] PR 51222

On 05/01/2012 06:28 AM, Jason Merrill wrote: On 04/30/2012 07:37 PM, Paolo Carlini wrote: Thus, my question would be: is something like the below in the right direction? The alternate possibility I can see, would be basically redoing a slightly slimmed version of for_each_template_parm specializ

Add myself to write-after-approval section of MAINTAINERS file

I have just committed the patch below to add myself to the write-after-approval section of the MAINTAINERS file. Thanks, Greta ChangeLog: 2012-05-01 Greta Yorsh * MAINTAINERS (Write After Approval): Add myself. Index: MAINTAINERS ===

Ping: [Patch, Makefile.in, doc] Add new @include in doc/invoke.texi

The following patch has some parts that still need approval, i.e. * Makefile.in (TEXI_GCC_FILES): Add avr-mmcu.texi. * doc/avr-mmcu.texi: New auto-generated file. * doc/invoke.texi (AVR Options): Include avr-mmcu.texi in order to document all valid -mmcu= arguments. http://gcc.gnu.org/ml/gcc-p

Ping: [Patch, Makefile.in, doc] Add new @include in doc/invoke.texi

The following patch has some parts that still need approval, i.e. * Makefile.in (TEXI_GCC_FILES): Add avr-mmcu.texi. * doc/avr-mmcu.texi: New auto-generated file. * doc/invoke.texi (AVR Options): Include avr-mmcu.texi in order to document all valid -mmcu= arguments. http://gcc.gnu.org/ml/gcc-p

RE: [Patch, ARM] rename thumb_unexpanded_epilogue to thumb1_unexpanded_epilogue

Ping! http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01485.html Thanks, Greta > -Original Message- > From: Greta Yorsh [mailto:greta.yo...@arm.com] > Sent: 24 April 2012 17:41 > To: gcc-patches@gcc.gnu.org > Cc: p...@codesourcery.com; Ramana Radhakrishnan; Richard Earnshaw; > ni...@redhat.c

Re: Patches to enable -ftrack-macro-expansion by default

On 05/01/2012 05:36 AM, Dodji Seketeli wrote: pfile->context = XNEW (cpp_context); + memset (pfile->context, 0, sizeof (cpp_context)); You can use XCNEW instead of XNEW + memset. OK with that change. Jason

PR c/51712 -Wtype-limits should not trigger for types of implementation-defined signedness

This fixes half of PR51712. The other half is added as XFAIL. Bootstrapped and regression tested. OK? Fixing the other half requires either * Make build_binary_op take c_expr instead of trees. This will require adding c_expr to the C++ FE. For now, the C++ FE will just encapsulate the trees into

Re: PR c/51712 -Wtype-limits should not trigger for types of implementation-defined signedness

On Tue, 1 May 2012, Manuel L?pez-Ib??ez wrote: > +static tree expr_original_type (tree expr) That should be static tree expr_original_type (tree expr) with a comment explaining the semantics of the function. > +{ > + STRIP_NOPS (expr); Are you sure you want STRIP_NOPS rather than STRIP_SIGN_

Re: PR c/51712 -Wtype-limits should not trigger for types of implementation-defined signedness

On 1 May 2012 15:46, Joseph S. Myers wrote: > On Tue, 1 May 2012, Manuel López-Ibáñez wrote: > >> +static tree expr_original_type (tree expr) > > That should be > > static tree > expr_original_type (tree expr) > > with a comment explaining the semantics of the function. > >> +{ >> +  STRIP_NOPS (e

Re: [Patch, ARM] rename thumb_unexpanded_epilogue to thumb1_unexpanded_epilogue

On 24/04/12 17:41, Greta Yorsh wrote: > Rename thumb_unexpanded_epilogue to thumb1_unexpanded_epilogue. > > In preparation for epilogue generation in RTL and anyway it's the right name > for this function. > > Ok for trunk? > > Thanks, > Greta OK. R. > > gcc/ChangeLog > > 2012-04-24 Ian Bo

Re: PR c/51712 -Wtype-limits should not trigger for types of implementation-defined signedness

On Tue, 1 May 2012, Manuel López-Ibáñez wrote: > > Are you sure you want STRIP_NOPS rather than STRIP_SIGN_NOPS here?  If so, > > could you ensure there are comments explaining why removing sign changes > > is safe in this context? > > For getting the original enumeral type of a expr, why would s

Re: PR c/51712 -Wtype-limits should not trigger for types of implementation-defined signedness

On 1 May 2012 16:00, Joseph S. Myers wrote: > On Tue, 1 May 2012, Manuel López-Ibáñez wrote: > >> > Are you sure you want STRIP_NOPS rather than STRIP_SIGN_NOPS here?  If so, >> > could you ensure there are comments explaining why removing sign changes >> > is safe in this context? >> >> For getti

Re: [C Patch]: pr52543

Ian Lance Taylor writes: > Richard Sandiford writes: >> Does anyone else have any thoughts before I make that change? > > I think that one of you should try to write a test case where it makes a > difference, and add the test case to the testsuite. I originally took that to mean a case where fun

Re: PR c/51712 -Wtype-limits should not trigger for types of implementation-defined signedness

On Tue, 1 May 2012, Manuel López-Ibáñez wrote: > > What if the comparison is > > > >  (unsigned) (expr_of_signed_enum_type) >= 0 > > > > ?  (With GCC, the enum will have a signed type if one of its values is > > negative.)  That seems worth a warning - the point of the patch as I > > understand it

[committed] Run DImode atomic tests on ppc64

Committed as obvious. r~ * lib/target-supports.exp (check_effective_target_sync_long_long_runtime): True for check_effective_target_powerpc64. diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index 1a25324..b93dc5c 100644 --- a

Re: [PATCH] libatomic, v2

On 04/27/2012 12:26 PM, Richard Henderson wrote: I think the library is ready for merge back to mainline, but I will wait until at least Monday for feedback and proximity to my desk to deal with potential fallout. Now committed. r~

Re: Patches to enable -ftrack-macro-expansion by default

Jason Merrill writes: > On 05/01/2012 05:36 AM, Dodji Seketeli wrote: >> pfile->context = XNEW (cpp_context); >> + memset (pfile->context, 0, sizeof (cpp_context)); > > You can use XCNEW instead of XNEW + memset. > > OK with that change. Thank you. Here is the patch I will commit when Uros

[committed] Add -fno-sync-libcalls

A support option for implementing libatomic, committed as a separate patch. r~ * common.opt (fsync-libcalls): New. * doc/invoke.texi: Document it. * optabs.c (init_sync_libfuncs): Honor it. diff --git a/gcc/common.opt b/gcc/common.opt index af02992..cc57976 100644 --- a

Re: [PATCH] Improve COND_EXPR expansion

On 04/30/2012 08:22 PM, Andrew Pinski wrote: * expr.c (convert_tree_comp_to_rtx): New function. (expand_expr_real_2): Try using conditional moves for COND_EXPRs if they exist. * config/i386/i386.c (ix86_expand_int_movcc): Disallow comparison modes of DImode for 32bits and TImode. Looks ok, modu

Re: [C Patch]: pr52543

On Tue, May 1, 2012 at 7:46 AM, Richard Sandiford wrote: > Ian Lance Taylor writes: >> Richard Sandiford writes: >>> Does anyone else have any thoughts before I make that change? >> >> I think that one of you should try to write a test case where it makes a >> difference, and add the test case t

Re: [PATCH] teach phi-opt to produce -(a COND b)

On 04/27/2012 03:01 AM, Paolo Bonzini wrote: This patch teaches phiopt to look at phis whose arguments are -1 and 0, and produce negated setcc statements. Is this really a win over a COND_EXPR, i.e. (a < b ? -1 : 0)? There is quite a bit of logic inside the rtl and backend expansion of cmove t

Re: [RFH / Patch] PR 51222

On 05/01/2012 08:00 AM, Paolo Carlini wrote: I think either approach would be fine; I lean toward the first, but changing the name and adding a flag for clarity. Changing the walking behavior based on fn being null is too subtle. Agreed. The below is what I booted and tested on x86_64-linux.

Re: libgo patch committed: Fix build on MIPS GNU/Linux

cc/objdir/gcc/testsuite/go/../../gccgo version 4.8.0 20120501 (experimental) [trunk revision 187009] (GCC) === libgo tests === Running target unix FAIL: runtime FAIL: net/http FAIL: text/template === libgo Summary for unix === # of expected passes12

Re: libgo patch committed: Fix build on MIPS GNU/Linux

Andrew Pinski writes: > I tested the trunk after this patch on mips64-linux-gnu (with glibc > 2.15) and the testsuite looks good. Thanks for testing. > FAIL: go.test/test/nilptr.go execution, -O2 -g The nilptr.go test is known to fail on various targets. Search for nilptr in gcc/testsuite/go

Re: [PATCH] pr51020 Fix invalid options validation for ARM target

On Mon, Apr 30, 2012 at 02:15:03PM +0100, Richard Earnshaw wrote: > On 28/04/12 11:04, Alexey Kravets wrote: > > Hi guys, > > Please, take a look at this patch. It fixes the invalid star symbol > > processing in validate_switches function reported in GCC bugzilla: > > http://gcc.gnu.org/bugzilla/sh

RFA (i386): PATCH to ix86_code_end to set DECL_IGNORED_P on the PC thunk

While working on another DWARF patch I ran into a crash because we didn't set DECL_IGNORED_P on the PC thunk, but we also don't emit any debug info for it. Since there's no debug info, we should set DECL_IGNORED_P, and we shouldn't add ignored functions to .debug_aranges or .debug_ranges. OK

Re: RFA (i386): PATCH to ix86_code_end to set DECL_IGNORED_P on the PC thunk

On 05/01/2012 12:37 PM, Jason Merrill wrote: * config/i386/i386.c (ix86_code_end): Set DECL_IGNORED_P on the pc thunk. * dwarf2out.c (output_aranges): Skip DECL_IGNORED_P functions. (dwarf2out_finish): Likewise. Ok. r~

Put constant compound initializers in .rodata

This patch to the C frontend and the middle-end puts constant compound initializers in the readonly data section where possible. This is for PR 37303. Bootstrapped and ran full testsuite on x86_64-unknown-linux-gnu. OK for mainline? Ian gcc/: 2012-05-01 Ian Lance Taylor PR c/3730

Re: [RFH / Patch] PR 51222

Hi, On 05/01/2012 08:02 PM, Jason Merrill wrote: On 05/01/2012 08:00 AM, Paolo Carlini wrote: I think either approach would be fine; I lean toward the first, but changing the name and adding a flag for clarity. Changing the walking behavior based on fn being null is too subtle. Agreed. The bel

[PATCH] configure.ac: Also quote '$' in tbaseargs

Hi, While working on some GDB changes I have stumbled across this, which looks like a buglet in the top-level configure. Perhaps a three-way merge error from the past. Unfortunately there is nothing in ChangeLog that would indicate when these bits were introduced. We have these two variabl

Re: PR 53115

unordered_multilmap test added, attached patch applied to 4.7 branch and trunk. This bug was not so difficult to fix. It would even have been quite easy to detect with a good test coverage tool showing that not all possible path had been tested in this method. I hope to be able to make some p

Re: PR 53115

On 05/01/2012 10:23 PM, François Dumont wrote: unordered_multilmap test added, attached patch applied to 4.7 branch and trunk. This bug was not so difficult to fix. It would even have been quite easy to detect with a good test coverage tool showing that not all possible path had been tested i

Re: [RFH / Patch] PR 51222

On 05/01/2012 10:06 PM, Paolo Carlini wrote: I'm not 100% sure to understand the last two comments. I'm removing completely the latter cases and changing the former like the below. Note that the way I handle fn in walk_template_parms implies that when check_types is true then pfd->fn is always

Re: Backported r185231 from trunk. (issue 6139063)

On 2012/04/30 19:54:14, asharif wrote: I backported the following patch: 2012-03-12 Richard Guenther * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification. * gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define. (__gthread_mutex_

Re: Backported r185231 from trunk. (issue 6139063)

Ok for google branches (please also backport to google/gcc_47 branch. David On 2012/05/01 20:37:44, asharif wrote: On 2012/04/30 19:54:14, asharif wrote: > I backported the following patch: > > 2012-03-12 Richard Guenther > >* gthr.h (__GTHREAD_MUTEX_INIT_FUNCT

Re: Put constant compound initializers in .rodata

On 05/01/2012 01:05 PM, Ian Lance Taylor wrote: 2012-05-01 Ian Lance Taylor PR c/37303 * c-decl.c (build_compound_literal): Make the decl readonly if it an array of a readonly type. * gimplify.c (gimplify_compound_literal_expr): Add fallback parameter. C

Re: [Patch, fortran] PR41600 - [OOP] SELECT TYPE with associate-name => exp: Arrays not supported

Dear Tobias, dear all, Please accept my apologies for the long delay in responding to the review. A combination of overwhelming daytime works and a complete failure of my workstation at home have knocked me out for the last six weeks. Find attached a revised patch to fix PR 41600. On Sun, Mar 1

Re: [PATCH] Take branch misprediction effects into account when RTL loop unrolling (issue 6099055)

Fixed the stylist suggestions. Other responses below. On Tue, Apr 24, 2012 at 10:22 PM, wrote: > > http://codereview.appspot.com/6099055/diff/1/loop-unroll.c > File loop-unroll.c (right): > > http://codereview.appspot.com/6099055/diff/1/loop-unroll.c#newcode156 > loop-unroll.c:156: static bool >

Re: Backported r185231 from trunk. (issue 6139063)

On 2012/05/01 20:44:05, davidxl wrote: Ok for google branches (please also backport to google/gcc_47 branch. Commited as r187026. I'll backport to google/gcc-4_7 as well. David On 2012/05/01 20:37:44, asharif wrote: > On 2012/04/30 19:54:14, asharif wrote: > > I backported the following

[google-4_6] fix undefined typeinfo reference in LIPO (issue6149044)

Hi, This patch is for google-4_6 branch only. It fixes a undefined type-info reference in LIPO compilation. Tested with bootstrap, SPEC and internal benchmarks. Thanks, 2012-05-01 Rong Xu * gcc/cp/rtti.c (get_tinfo_decl): generate tinfo for aux modules in LIPO. Index: gcc

Re: [google-4_6] fix undefined typeinfo reference in LIPO (issue6149044)

ok. Needs to be in google47 and google/main too. David On Tue, May 1, 2012 at 3:26 PM, Rong Xu wrote: > Hi, > > This patch is for google-4_6 branch only. > > It fixes a undefined type-info reference in LIPO compilation. > > Tested with bootstrap, SPEC and internal benchmarks. > > Thanks, > > 20

Re: [RFH / Patch] PR 51222

On 05/01/2012 04:06 PM, Paolo Carlini wrote: Hmm, this preexisting code seems to assume that any type-dependent expression must include a direct use of a template parameter, but it might just have a declaration with dependent type. We should also test any_p/check_types, and this should apply to a

Re: [RFH / Patch] PR 51222

On 05/01/2012 04:32 PM, Paolo Carlini wrote: In fact, the reason why I'm still a bit confused about some of the cases of this switch, is that I'm not sure to understand what it could mean to call walk_template_parms with fn NULL and check_types false. It would mean to return non-null if there a

Backported r185231 from trunk to google/gcc-4_7. (issue 6151043)

Reviewers: xur, davidxl, Message: Please take a look at this. Description: This fixes an issue with profile collection when multiple threads call fork() around the same time. 2012-03-12 Richard Guenther * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification. * gthr-p

Re: Backported r185231 from trunk to google/gcc-4_7. (issue 6151043)

ok. David On Tue, May 1, 2012 at 3:47 PM, wrote: > Reviewers: xur, davidxl, > > Message: > Please take a look at this. > > Description: > This fixes an issue with profile collection when multiple threads call > fork() around the same time. > > 2012-03-12  Richard Guenther   > >        * gthr.h

[PATCH] Take branch misprediction effects into account when RTL loop unrolling (issue6099055)

Improved patch based on feedback. Main changes are: 1) Improve efficiency by caching loop analysis results in the loop auxiliary info structure hanging off the loop structure. Renamed this structure from niter_desc to loop_desc to reflect the broader type of information cached in the structure. Ad

[patch] Update DWARF codes for Fission

This patch to include/dwarf2.def updates the DW_FORM and DW_AT codes for the Fission extensions. We've eliminated DW_FORM_GNU_ref_index, and replaced DW_AT_GNU_ref_base with DW_AT_GNU_ranges_base. (The wiki page at http://gcc.gnu.org/wiki/DebugFission has been updated.) OK for binutils and gcc? -

Re: [RFH / Patch] PR 51222

On 05/02/2012 12:39 AM, Jason Merrill wrote: On 05/01/2012 04:06 PM, Paolo Carlini wrote: Hmm, this preexisting code seems to assume that any type-dependent expression must include a direct use of a template parameter, but it might just have a declaration with dependent type. We should also test

Re: [RFH / Patch] PR 51222

On 05/02/2012 01:27 AM, Paolo Carlini wrote: Note, there is the minor subtlety with checking !fn explicitly: in my current patch it's redundant because I make sure in the caller that when check_types is true, any fn accidentally passed by upper caller as non-null is zeroed. This way, walk_templ

Re: [RFH / Patch] PR 51222

On 05/01/2012 07:39 PM, Paolo Carlini wrote: I'm sorry, when a few days ago I noticed that we weren't tsubsting at all I thought the fix would be quite straightforward for me to handle because very local I didn't expect we would go ahead and resolve the FIXME about instantiation-dependent No

Re: User directed Function Multiversioning via Function Overloading (issue5752064)

On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam wrote: > Hi, > > New patch attached, updated test case and fixed bugs related to > __PRETTY_FUNCTION_. > > Patch also available for review here:  http://codereview.appspot.com/5752064 @@ -0,0 +1,39 @@ +/* Simple test case to check if Multiversioning

Re: [RFH / Patch] PR 51222

Hi, On 05/02/2012 01:46 AM, Jason Merrill wrote: On 05/01/2012 07:39 PM, Paolo Carlini wrote: I'm sorry, when a few days ago I noticed that we weren't tsubsting at all I thought the fix would be quite straightforward for me to handle because very local I didn't expect we would go ahead and res

[0/6] Fold prev/next into gimple

Hi, a long time ago, during development of [tuples] gimple_statement_base had prev/next links. Those were moved to gimple_seq_node, referred to from gimple_seq, and referring to gimple statements, on the grounds that this eases experimentation with different data structures. Well, those expe

Re: [RFH / Patch] PR 51222

On 05/02/2012 01:46 AM, Jason Merrill wrote: I think we need to handle FIELD_DECL, too. A data point I can give you, I put a gcc_assert (TREE_CODE (t) != FIELD_DECL) in the default case of the walk_template_parms_r switch, and it never triggers for the whole testsuite. Paolo.

[2/6] Fold prev/next into gimple: fewer gimple_seq_alloc calls

Hi, This patch gets rid of some easy gimple_seq_alloc calls that we don't even need currently because most gimple_seq modifier will lazily allocate one. Most of the time it's enough to simply initialize a seq to NULL and call the respective routines like gimple_seq_add_{stmt,seq}. (A notable

[3/6] Fold prev/next into gimple

Hi, this introduces a new helper (gsi_replace_with_seq) which can replace a single statement with a sequence, and makes use of it in gimplify_and_update_call_from_tree. This make sure that the statements aren't inserted into the target sequence while they still are in the original one. Could

Patches for building libstdc++ on vxWorks

These minor changes are needed to build libstdc++ on vxWorks. Note- these diffs are based off of gcc 4.7.0 diff -durp -x '*~' a/gcc/gcov-io.c b/gcc/gcov-io.c --- a/gcc/gcov-io.c2011-04-06 11:05:18.0 -0500 +++ b/gcc/gcov-io.c2012-01-15 21:27:41.407688488 -0500 @@ -92,7 +92,11 @@ g

[4/6] Fold prev/next into gimple

Hi, this trivial patch just moves several gimple.h functions down to after the gimple_statement_d definition (whose members will be used by them with patch 6). As per [0/6] regstrapped with the other five on x86_64-linux. I consider this obvious. Ciao, Michael. -- 2012-0

[5/6] Fold prev/next into gimple

Hi, this patch basically is the one that makes all interfaces that possibly change a gimple_seq take a pointer to one, this time _including_ the statement iterator. For that I opted to use the same idiom as our basic block edge iterators, namely via a wrapper macro that replaces the current gs

[6/6] Fold prev/next into gimple: do it

Hi, and this patch flips the switch. It removes the old seq_node and seq structures, adds the prev/next to gimple_statement_base, merges gimple, gimple_seq and gimple_seq_node and rewrites the helpers dealing with sequences or iterators to deal with the data structure of a cyclic list in the

Re: [RFH / Patch] PR 51222

On 05/01/2012 08:14 PM, Paolo Carlini wrote: I think we need to handle FIELD_DECL, too. Are there hopes that handling FIELD_DECL like FUNCTION_DECL and VAR_DECL (besides the DECL_LANG_SPECIFIC check) would work? I would think so. A data point I can give you, I put a gcc_assert (TREE_CODE (t)

Re: [RFH / Patch] PR 51222

Hi, On 05/02/2012 03:47 AM, Jason Merrill wrote: On 05/01/2012 08:14 PM, Paolo Carlini wrote: I think we need to handle FIELD_DECL, too. Are there hopes that handling FIELD_DECL like FUNCTION_DECL and VAR_DECL (besides the DECL_LANG_SPECIFIC check) would work? I would think so. Ok, if we wan

Re: [6/6] Fold prev/next into gimple: do it

On Wed, 2 May 2012 03:47:17 +0200 (CEST) Michael Matz wrote: > There's one thing I'd like an opinion about: I've added two new flags to > gimple_statement_base: start_of_seq and end_of_seq, and I had to > shorten the uid member by two bits for that. The two flags are used only > for asserts (

Re: [Patch, fortran] PR41600 - [OOP] SELECT TYPE with associate-name => exp: Arrays not supported

Dear Paul, Paul Richard Thomas wrote: Find attached a revised patch to fix PR 41600. Thanks for the patch. I think it is OK. Regarding: ! if (ref&& ref->type != REF_ARRAY&& seen_array) ! { ! gfc_error ("CLASS selector at %L is an array with CLASS " !

Re: [patch] Update DWARF codes for Fission

On Tue, May 01, 2012 at 04:17:02PM -0700, Cary Coutant wrote: > This patch to include/dwarf2.def updates the DW_FORM and DW_AT codes > for the Fission extensions. We've eliminated DW_FORM_GNU_ref_index, > and replaced DW_AT_GNU_ref_base with DW_AT_GNU_ranges_base. (The wiki > page at http://gcc.gnu

Patch to enable --with-multilib-list for arm-none-eabi target

Hello, This patch provides a bunch of predefined MULTILIB for various arm-none-eabi targets. The MULTILIB_EXCEPTIONS isn't needed because the patch takes advantage of the new term MULTILIB_REQUIRED which is introduced at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00975.html. The existing configu

Re: libgo patch committed: Fix build on MIPS GNU/Linux

On Tue, May 1, 2012 at 12:18 PM, Ian Lance Taylor wrote: > Andrew Pinski writes: > >> I tested the trunk after this patch on mips64-linux-gnu (with glibc >> 2.15) and the testsuite looks good. > > Thanks for testing. > >> FAIL: go.test/test/nilptr.go execution,  -O2 -g > > The nilptr.go test is k

Re: [patch, committed] invoke.texi: clean up texinfo markup

Hi Sandra, On Fri, 6 Apr 2012, Sandra Loosemore wrote: > This is another installment in my series of cleanups to invoke.texi. > In this patch I have taken a break from nit-picking grammar and have > nit-picked some Texinfo markup issues instead. kudos for the work you are doing on this front!

Re: [PATCH] libatomic, v2

Hi Richard, On Tue, 1 May 2012, Richard Henderson wrote: > Now committed. mind writing up something for the release notes? If you provide me text, I can take care of marking it up and committing it. Gerald