Re: RFA (layout): PATCH for c++/48029 (ICE-on-valid with templates and arrays)

On Wed, Mar 9, 2011 at 6:59 PM, Jason Merrill wrote: > In this testcase, when we first declare the myvectypes and mytype3, > vector has not been instantiated, so we mark the array, and the > pointer to the array, for structural equality comparison.  When we actually > go to instantiate mytype3, we

Re: [PATCH 14/18] move TS_STATEMENT_LIST to be a substructure of TS_TYPED

On 03/10/2011 11:23 PM, Nathan Froyd wrote: The new checks in add_stmt are required to make sure that cur_stmt_list can always point at something when calling append_to_statement_list_force. Why haven't we already pushed before we get to add_stmt? Jason

Re: [C++0x patch] constexpr in attribute argument

How about just calling maybe_constant_value call after the fold_non_dependent_expr call in cp_parser_parenthesized_expression_list? Jason

[PATCH 12/18] make CASE_LABEL_EXPR not abuse TREE_CHAIN

Move CASE_CHAIN into a local operand for CASE_LABEL_EXPR. Nothing to see here. -Nathan gcc/ * tree.def (CASE_LABEL_EXPR): Add an operand. * tree.h (CASE_CHAIN): Use TREE_OPERAND instead of TREE_CHAIN. diff --git a/gcc/tree.def b/gcc/tree.def index eb94ad2..9c6606d 100644 --- a/g

[PATCH 18/18] make TS_BLOCK a substructure of TS_BASE

Now that we've encapsulated all uses of BLOCK_CHAINON properly, we can make BLOCKs inherit from tree_base and redirect BLOCK_CHAINON to use a tree_block-private field instead of tree_common's chain. Doing so saves the never-used TREE_TYPE field. -Nathan gcc/ * tree.c (initialize_tree_co

[PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more

BLOCKs have a TREE_CHAIN and a TREE_TYPE; TREE_TYPE is useless for blocks, but we can't remove TREE_TYPE without also removing TREE_CHAIN. This patch lays the groundwork to do just that. It changes places that use chainon on BLOCKs to use block_chainon, which works identically to chainon except it

[PATCH 11/18] mark EXPR_PACK_EXPANSION as typed only

EXPR_PACK_EXPANSION nodes store things in TREE_CHAIN, for symmetry with TYPE_PACK_EXPANSIONs. In the interest of expendiency towards slimming tree_exp, this patch moves EXPR_PACK_EXPANSION's use of TREE_CHAIN into a local TREE_OPERAND. I suppose the conditional would be needed in any event later

[PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses

Now that we have a structure where not every node might include TREE_CHAIN or TREE_TYPE, we need to make sure that when we call said accessors that the argument is properly typed. This requires a number of changes: - It's not enough for FEs to assume that FE-specific DECLs are the only tree tha

[PATCH 09/18] convert cp IF_STMTs to use private scope fields

Just like the previous *FOR_STMT conversions, except with IF_STMTs. -Nathan gcc/cp/ * cp-tree.def (IF_STMT): Add an extra operand. * cp-objcp-common.c (cp_common_init_ts): Mark it as TS_TYPED. * cp-tree.h (IF_SCOPE): Define. * semantics.c (begin_if_stmt): Pass scop

[PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

IDENTIFIER_NODE is next up for a shrinking. To do that, though, we have to do some surgery on the C++ FE, as it uses TREE_TYPE (!) of such nodes to store local data. Fortunately, we can move that information into lang_identifier; unfortunately, that means we need to introduce a number of conditio

[PATCH 14/18] move TS_STATEMENT_LIST to be a substructure of TS_TYPED

STATEMENT_LISTs use TREE_CHAIN for approximately nothing, so let's try to shrink them. This patch involves quite a bit of refactoring in the C and C++ FEs, as they used TREE_CHAIN to hold a stack of STATEMENT_LISTs being built. Most of the noise comes from unifying the checking macro name between

[PATCH 16/18] make TS_IDENTIFIER be a substructure of TS_BASE

Now that we've done the requisite surgery on the C++ FE, we can eliminate TREE_CHAIN and TREE_TYPE from IDENTIFIER_NODEs. Doing so turns up a couple different places that need to be tweaked. The bit I'm not quite sure about is free_lang_data_in_decl and find_decls_types_r. Previously, due to C++

[PATCH 13/18] move TS_EXP to be a substructure of TS_TYPED

After all that, we can finally make tree_exp inherit from typed_tree. Quite anticlimatic. -Nathan gcc/ * tree.h (struct tree_exp): Inherit from struct typed_tree. * tree.c (initialize_tree_contains_struct): Mark TS_EXP as TS_TYPED instead of TS_COMMON. diff --git a/gcc/tr

[PATCH 07/18] generalize build_case_label to the rest of the compiler

If we're going to add another TREE_OPERAND to CASE_LABEL_EXPR, then we'd have to update a number of calls to buildN or similar to know about the new operand. But that's not a good idea; the new operand is a strictly private thing and FEs in particular shouldn't have to know anything about it. Ins

[PATCH 10/18] convert cp SWITCH_STMTs to use private scope fields

Just like the previous patches, except with SWITCH_STMT. -Nathan gcc/cp/ * cp-tree.def (SWITCH_STMT): Add an extra operand. * cp-objcp-common.c (cp_common_init_ts): Mark it as TS_TYPED. * cp-tree.h (SWITCH_STMT_SCOPE): Define. * semantics.c (begin_switch__stmt): Pa

[PATCH 08/18] convert cp *FOR_STMTs to use private scope fields

C++'s FOR_STMT and RANGE_FOR_STMT store the scope in which they occur in the TREE_CHAIN field of tree_exp. If we're going to remove TREE_CHAIN, that won't work very well. This patch introduces an extra tree operand to both tree kinds, accessor macros for those operands, and tweaks the code to use

[PATCH 06/18] define CASE_CHAIN accessor for CASE_LABEL_EXPR

This patch begins a subseries of patches aimed at removing TREE_CHAIN from expression trees. tree-cfg.c uses TREE_CHAIN for some analysis steps on CASE_LABEL_EXPRs. I looked at this for a while, thinking it'd be easy to use VECs instead, but AFAICS, it wasn't. I went for the next best thing, hid

[PATCH 04/18] remove TREE_CHAIN from SSA_NAME nodes

This conversion is straightforward. The tricky part is converting FREE_SSANAMES into a VEC to eliminate the only use of TREE_CHAIN on SSA_NAMEs. -Nathan gcc/ * tree-flow.h (struct gimple_df): Make free_ssanames a VEC. * tree-ssanames.c (fini_ssanames): VEC_free it. (make_

[PATCH 05/18] remove TREE_CHAIN from CONSTRUCTOR nodes

A straightforward conversion. -Nathan gcc/ * tree.h (struct tree_constructor): Include typed_tree instead of tree_common. * tree.c (initialize_tree_contains_struct): Mark TS_CONSTRUCTOR as TS_TYPED instead of TS_COMMON. diff --git a/gcc/tree.c b/gcc/tree.c index 0

[PATCH 03/18] remove TREE_CHAIN from *_CST nodes

*_CST nodes don't need TREE_CHAIN. Make them include typed_tree instead, mark them as such in initialize_tree_contains_struct, and don't print out their TREE_CHAIN. -Nathan gcc/ * tree.h (struct tree_int_cst, struct real_value): Include typed_tree instead of tree_common.

[PATCH 01/18] add typed_tree structure

The first step in removing TREE_CHAIN (and even TREE_TYPE) from a select few nodes is to create separate substructures for trees-with-type and trees-with-chain. Since trees-with-type but no chain are expected to be more common that vice versa, make the hierarchy reflect that. Modify a few macros

[4.7 PATCH 00/18] slim down a number of tree nodes

This patch series does something similar to what: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02491.html did, only it does it in a cleaner way and it addresses the problem more generally. It introduces a separate substructure (base class) for tree nodes that include TREE_TYPE so that a tree nod

[4.7] Avoid global state in s390_handle_option

This patch, for 4.7 and relative to a tree with applied, stops the S390 handle_option hook from using global state. S390 already had a processor enumeration, but not one suitable for direct use with Enum in the .opt file for handling -march

[trans-mem] Final piece of pr 47952

I believe this finally fixes all of the problems in 47952. The problem was that we needed to clone basic_string::~basic_string() which is inline, and also marked extern template, like so extern template class basic_string; which I believe maps things to the gnu extern inline form. In any

[committed] HP-UX 10.X reentrant functions

In HP-UX 10, the _r suffix routines are only declared when _REENTRANT is defined. Previously, we only defined _REENTRANT when -threads was specified (DCE thread model). However, we also need the reentrant functions in the single thread model for libgfortran. As far as I can tell, the reentrant f

Re: [PATCH] PR c++/PR48035

On 03/10/2011 11:14 AM, Dodji Seketeli wrote: + /* If we are initializing a sub-object of +CURRENT_OBJECT_TYPE [for which a primary base class +sub-object has already been initialized] then we must NOT +initialize any sub-object from a virtual base that

Re: [PATCH] PR c++/PR48035

On 03/10/2011 03:45 PM, Jakub Jelinek wrote: E.g. http://gcc.gnu.org/wiki/HowToPrepareATestcase recommends abort instead and it is existing practice too. In the C++ testcase most testcases return non-zero to indicate failure. The main reason for this is to avoid having to deal with declaring

[PATCH] With -fno-early-inlining -finline-functions-called-once don't inline functions if there is argument type mismatch (PR tree-optimization/48063)

Hi! ipa-inline.c apparently in all spots but one where it checks call_stmt_cannot_inline_p also checks tree_can_inline_p. With -fno-early-inlining tree_can_inline_p won't be called earlier and thus code to attempt to inline functions called once doesn't ever call it to notice there is an argument

Re: [cxx-mem-model] testing infrastructure

On Mar 10, 2011, at 11:58 AM, Aldy Hernandez wrote: > The following is a test harness for testing atomicity problems and data races > in multi-threaded environments. The idea of developing a methodology for testing corner cases I think is interesting and neat. volatile would be another area tha

Re: 4.5 backport request...

> This doesn't look like a regression fix. The changelog doesn't tell > if it is mere replacing macros by hooks, so please also attach the > patch. The original patch is here: http://gcc.gnu.org/ml/gcc/2010-10/msg00076.html It would need editing for 4.5, which I'll do if there's a good chance

Re: [PATCH] PR c++/PR48035

Jakub Jelinek writes: > http://gcc.gnu.org/wiki/HowToPrepareATestcase > recommends abort instead and it is existing practice too. Sure. I am going to update my local copy of the patch and re-post. I used return as I noticed it was working. I didn't realize the abort/exit was the recommended c

Re: [PATCH] PR c++/PR48035

On Thu, Mar 10, 2011 at 12:31:57PM -0800, Mike Stump wrote: > On Mar 10, 2011, at 10:22 AM, Jakub Jelinek wrote: > > The standard way of signalizing a test failure is calling abort (), > > not returning 1, see http://gcc.gnu.org/codingconventions.html > > Actually, returning 0 or 1 is a perfectly

Re: [PATCH] PR c++/PR48035

On Mar 10, 2011, at 10:22 AM, Jakub Jelinek wrote: > The standard way of signalizing a test failure is calling abort (), > not returning 1, see http://gcc.gnu.org/codingconventions.html Actually, returning 0 or 1 is a perfectly fine way to signal pass/fail in the testsuites, as it exit.

Re: [cxx-mem-model] testing infrastructure

Oh BTW, I have committed the aforementioned patch. This is one of the benefits of having your own branch (and Andrew being on vacation). You commit at will, and only later hide your head in shame after multiple flames-- correcting patches after the fact.

[cxx-mem-model] testing infrastructure

Hi folks. The following is a test harness for testing atomicity problems and data races in multi-threaded environments. Please see the README file in the patch below, which describes the use of GDB to test in-between states in a possibly threaded execution. I would like to use this branch a

Re: Problem with procedure pointers

>> While I am inclined to not-bump the version number, I won't mind if you >> decide to bump it. > > I agree. Ok, since you guys seem to agree on that, here is the patch without module version bumping, but this time complete with test case and ChangeLog. Ok for trunk? Cheers, Janus 2011-03-10

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

Richard Guenther writes: >> > Can we to fix 46944 change the dejagnu require-linker-plugin >> > to check if a linker plugin is used by default and not add >> > -fuse-linker-plugin? >> >> That might be involved since it requires parsing gcc -Wl,-debug output. >> I suppose the solution outlined ab

[C++0x patch] constexpr in attribute argument

Hi! Checking the new constexpr support in the C++0x frontend, I've notices that there is one place where a plain constant is accepted but a constexpr is not. Probably you have guessed (from the subject line above), it is in an attribute argument, e.g: constexpr int foo() { return 4; } int __a

Re: [PATCH] PR c++/PR48035

On Thu, Mar 10, 2011 at 05:14:12PM +0100, Dodji Seketeli wrote: > --- /dev/null > +++ b/gcc/testsuite/g++.dg/inherit/virtual8.C ... > + > +int > +main () > +{ > +char *v = new char[sizeof (E) + 16]; > +memset (v, 0x55, sizeof (E) + 16); > +E *e = new (v) E (); > +e->~E (); > + > +

Re: [PATCH] Fix s390_delegitimize_address (PR debug/48043)

On 03/10/2011 04:11 PM, Jakub Jelinek wrote: > Ok for trunk? > > 2011-03-09 Jakub Jelinek > > PR debug/48043 > * config/s390/s390.c (s390_delegitimize_address): Make sure the > > result mode matches

Re: [PATCH][C] Fix PR47939

On Wed, 2 Mar 2011, Richard Guenther wrote: > 2011-03-02 Richard Guenther > > PR c/47939 > * c-decl.c (grokdeclarator): Drop to the main variant only > for array types. Drop flag_gen_aux_info check. I can't convince myself that this is safe - that is, that it will maintain

[gomp3.1] In OpenMP 3.1 draft const-qualified decls having no mutable member are no longer predetermined shared

Hi! As %subj. said, const vars are no longer predetermined shared, they are just not allowed in private/lastprivate/reduction clauses. Tested on x86_64-linux, committed to gomp-3_1-branch. 2011-03-10 Jakub Jelinek * c-omp.c (c_omp_predetermined_sharing): Don't return OMP_CLAU

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

On Thu, 10 Mar 2011, Rainer Orth wrote: > Richard Guenther writes: > > > If I read this patch correctly then > > > > 1) it doesn't change the condition under which lto-plugin/ is built > > (good) > > Right. > > > 2) it makes -fuse-linker-plugin the default for and only for > > known

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

Richard Guenther writes: > If I read this patch correctly then > > 1) it doesn't change the condition under which lto-plugin/ is built > (good) Right. > 2) it makes -fuse-linker-plugin the default for and only for > known good linkers (GNU binutils >= 2.21) (good) Indeed. > 3) it m

Re: [PATCH][libstdc++-v3 parallel mode] Avoid taking address of dereferenced random access iterator

On 10 March 2011 15:02, Johannes Singler wrote: > > Well, isn't it a bit ugly to define such a guard newly every time? It's one of my favourite techniques, the type is local and has no linkage, it should be nothing but a destructor call which is guaranteed to happen when exiting that scope. > In

[PATCH] PR c++/PR48035

Hello, In the example of the patch below, the zero-initialization of the instance of E runs past the size of the object. That's because build_zero_init recursively tries to initialize all the sub-objects of 'e' without handling cases where 'e' could have sub-objects for virtual direct or indirect

Re: [PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

On Thu, Mar 10, 2011 at 4:57 PM, Jakub Jelinek wrote: > On Thu, Mar 10, 2011 at 04:48:48PM +0100, Uros Bizjak wrote: >> > Are you sure?  Making the vars static enables folding the zero >> > initialization. >> >> I was looking at other similar testcases (snprintf-chk.c, >> vsprintf-chk.c), where u

[DOC PATCH] Add -Wunused-but-set-* note to gcc-4.6/changes.html and mention removal of in STL headers

Hi! This mentions -Wunused-but-set-* warnings (which are C/C++/ObjC/ObjC++, so not sure how to mention them in the language specific areas instead) and briefly mentions removal of includes. More should go probably into gcc-4.6/porting_to.html. --- htdocs/gcc-4.6/changes.html.jj 2011-03-10

Re: [PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

On Thu, Mar 10, 2011 at 04:48:48PM +0100, Uros Bizjak wrote: > > Are you sure?  Making the vars static enables folding the zero > > initialization. > > I was looking at other similar testcases (snprintf-chk.c, > vsprintf-chk.c), where uninitialized buffer is declared as static (and > it didn't fa

Re: [PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

On Thu, Mar 10, 2011 at 3:59 PM, Richard Guenther wrote: >> wrote: >> Using binutils-2.21, a couple of gcc.c-torture/execute/builtins/__-chk.c testcases fail on alphaev68-pc-linux-gnu (-lto) with: /usr/lib/gcc/alpha-unknown-linux-gnu/4.4.5/../../../../alpha-unknown-linux

C++ PATCH for c++/47198 (ice-after-error with invalid type-name)

The call to cp_parser_skip_to_end_of_block_or_statement from cp_parser_parse_and_diagnose_invalid_type_name means that we're done looking at the current declaration; in the testcase, we were continuing to try to parse a declaration after skipping past the ;, so we ended up treating the construc

[PATCH] Fix s390_delegitimize_address (PR debug/48043)

Hi! The pr47201.c testcase ICEs on s390x-linux during var-tracking. The problem is that s390_delegitimize_address delegitimizes: (mem/u/c:SF (plus:SI (reg:SI 12 %r12) (const:SI (unspec:SI [(symbol_ref:SI ("u") )] 111))) [0 S4 A8]) into: (symbol_ref:SI ("u") ) Note the different mode. This mean

Re: RFA (layout): PATCH for c++/48029 (ICE-on-valid with templates and arrays)

On Thu, Mar 10, 2011 at 3:56 PM, Jason Merrill wrote: > On 03/10/2011 04:56 AM, Richard Guenther wrote: >> >> Ugh.  Why do we call layout_type on arrays with incomplete element type >> at all? > > layout_type has been called from the language-independent build_array_type > since the dawn of revisi

Re: [PATCH][libstdc++-v3 parallel mode] Avoid taking address of dereferenced random access iterator

On 03/10/2011 11:37 AM, Jonathan Wakely wrote: On 10 March 2011 09:47, Johannes Singler wrote: The attached patch patch solves a conformance problem of the parallel mode helper routine multiseq_partition. I have added a test case for that. multiseq_selection has similar problems, but is unuse

Re: [pph] Buffer overrun in preprocessor symbol replay

On 11-03-09 09:01 PM, Lawrence Crowl wrote: Index: gcc/cp/ChangeLog.pph 2011-03-09 Lawrence Crowl * pph.c (pth_dump_identifiers): Split cpp_idents_used::max_length into max_ident_length and max_value_length. (pth_save_identifiers): Likewise. (pth_load_identif

Re: [PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

On Thu, Mar 10, 2011 at 3:44 PM, Uros Bizjak wrote: > On Thu, Mar 10, 2011 at 1:30 PM, Richard Guenther > wrote: > >>> Using binutils-2.21, a couple of >>> gcc.c-torture/execute/builtins/__-chk.c testcases fail on >>> alphaev68-pc-linux-gnu (-lto) with: >>> >>> /usr/lib/gcc/alpha-unknown-linux-gn

Re: RFA (layout): PATCH for c++/48029 (ICE-on-valid with templates and arrays)

On 03/10/2011 04:56 AM, Richard Guenther wrote: Ugh. Why do we call layout_type on arrays with incomplete element type at all? layout_type has been called from the language-independent build_array_type since the dawn of revision control. I suppose the array type is still considered un-layo

Re: [PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

On Thu, Mar 10, 2011 at 1:30 PM, Richard Guenther wrote: >> Using binutils-2.21, a couple of >> gcc.c-torture/execute/builtins/__-chk.c testcases fail on >> alphaev68-pc-linux-gnu (-lto) with: >> >> /usr/lib/gcc/alpha-unknown-linux-gnu/4.4.5/../../../../alpha-unknown-linux-gnu/bin/ld: >> Warning:

Re: [PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

On Thu, Mar 10, 2011 at 1:19 PM, Uros Bizjak wrote: > Hello! > > Using binutils-2.21, a couple of > gcc.c-torture/execute/builtins/__-chk.c testcases fail on > alphaev68-pc-linux-gnu (-lto) with: > > /usr/lib/gcc/alpha-unknown-linux-gnu/4.4.5/../../../../alpha-unknown-linux-gnu/bin/ld: > Warning:

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

On Thu, 10 Mar 2011, Rainer Orth wrote: > After considerable discussion in this thread > > Unreviewed build, lto patch > http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00868.html > > Richard's recommendation was to only use the lto-plugin with known-good > linkers supporting -plugin,

[PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

Hello! Using binutils-2.21, a couple of gcc.c-torture/execute/builtins/__-chk.c testcases fail on alphaev68-pc-linux-gnu (-lto) with: /usr/lib/gcc/alpha-unknown-linux-gnu/4.4.5/../../../../alpha-unknown-linux-gnu/bin/ld: Warning: alignment 8 of symbol `buf5' in /tmp/ccgnDykf.ltrans1.ltrans.o is s

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

On 03/10/2011 12:26 PM, Rainer Orth wrote: + # GNU gold (GNU Binutils 2.21.51.20110225) 1.11 + # + # We extract the binutils version which is more familiar and specific + # than the gold version. + ld_vers=`echo $ld_ver | sed -n \ + -e 's,^.*[ ]\([0-9][0-9]*\.

RX: Fixing latency timings for BSET and BLCR insns

Hi Guys, I am applying the attached patch to fix a typo in the timings of the BSET and BCLR instructions for the RX port. Cheers Nick gcc/ChangeLog 2011-03-10 Nick Clifton * config/rx/rx.md (bitset_in_memory, bitclr_in_memory: Fix timings. Index: gcc/config/rx/rx.md ==

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

After considerable discussion in this thread Unreviewed build, lto patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00868.html Richard's recommendation was to only use the lto-plugin with known-good linkers supporting -plugin, i.e. GNU ld or gold >= 2.21. I'm extracting the bin

Re: [PATCH][libstdc++-v3 parallel mode] Avoid taking address of dereferenced random access iterator

On 10 March 2011 09:47, Johannes Singler wrote: > The attached patch patch solves a conformance problem of the parallel mode > helper routine multiseq_partition.  I have added a test case for that. >  multiseq_selection has similar problems, but is unused, so I plan to remove > that completely (whi

Re: RFA (layout): PATCH for c++/48029 (ICE-on-valid with templates and arrays)

On Thu, Mar 10, 2011 at 3:59 AM, Jason Merrill wrote: > In this testcase, when we first declare the myvectypes and mytype3, > vector has not been instantiated, so we mark the array, and the > pointer to the array, for structural equality comparison.  When we actually > go to instantiate mytype3, w

Re: 4.5 backport request...

On Wed, Mar 9, 2011 at 11:05 PM, DJ Delorie wrote: > > May I backport this change to 4.5 ?  rx-elf can use this for a > performance boost (a separate 4.5 target patch would be needed for > that) This doesn't look like a regression fix. The changelog doesn't tell if it is mere replacing macros by

[PATCH][libstdc++-v3 parallel mode] Avoid taking address of dereferenced random access iterator

The attached patch patch solves a conformance problem of the parallel mode helper routine multiseq_partition. I have added a test case for that. multiseq_selection has similar problems, but is unused, so I plan to remove that completely (which might ask for renaming of the file and the test).