[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279 --- Comment #5 from Sebastian Pop --- After fixing the graphite fail, I get these warnings from the testcase in comment4: FAIL: gfortran.dg/graphite/pr68279.f90 -O (test for excess errors) Excess errors:

Re: RFA: PATCH to match.pd for c++/68385

On 11/21/2015 01:30 AM, Richard Biener wrote: What happens if we remove the nops stripping from integer_zerop? Do other integer predicates strip nops? Many predicates do, but removing that doesn't break anything in the testsuite. So, how about this? commit

[PATCH 1/3] [graphite] call update_ssa once

--- gcc/graphite-isl-ast-to-gimple.c | 9 - gcc/sese.c | 4 2 files changed, 13 deletions(-) diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c index 557c44c..30c3a21 100644 --- a/gcc/graphite-isl-ast-to-gimple.c +++

[PATCH 2/3] [graphite] fix PR68279: bail out when scev gets instantiated to not_known

--- gcc/graphite-poly.c| 1 - gcc/graphite-poly.h| 6 +- gcc/graphite-sese-to-poly.c| 103 ++--- gcc/graphite-sese-to-poly.h| 26 --- gcc/graphite.c

[PATCH 3/3] [graphite] fix PR68493: bail out when codegen_error is set

--- gcc/graphite-isl-ast-to-gimple.c| 2 ++ gcc/testsuite/gcc.dg/graphite/pr68493.c | 34 + 2 files changed, 36 insertions(+) create mode 100644 gcc/testsuite/gcc.dg/graphite/pr68493.c diff --git a/gcc/graphite-isl-ast-to-gimple.c

[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573 --- Comment #10 from Segher Boessenkool --- GCC thinks bar2 will be executed more often that bar1; the code it generates is perfectly fine for that. If you think GCC's heuristics for branch prediction are no good, could use some improvement,

[PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

We blow up on the following testcase because we find ourselves passing [_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1; that's bad because this function immediately calls vrp_int_const_binop which just doesn't work for symbolic ranges, it only wants int_csts. This started

Re: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek wrote: >We blow up on the following testcase because we find ourselves passing >[_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1; >that's bad because this function immediately calls

Re: [PATCH] Fix GC ICE during simd clone creation (PR middle-end/68339)

> On Fri, Nov 20, 2015 at 9:03 PM, Jakub Jelinek wrote: > > Hi! > > > > node->get_body () can run various IPA passes and ggc_collect in them > > Aww. Looks like we never implemented that ggc_defer_collecting idea > (don't remember the context this popped up, maybe it was when

Re: Enable pointer TBAA for LTO

> > I think it also causes the following and one related ICE > > FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal compiler > error) > > /space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1: > internal compiler error: in get_alias_set, at alias.c:880^M >

Re: [PATCH/RFC] C++ FE: expression ranges (v2)

On Mon, 2015-11-23 at 10:59 +0100, Richard Biener wrote: > On Sat, Nov 21, 2015 at 9:21 AM, Jakub Jelinek wrote: > > On Sat, Nov 21, 2015 at 02:16:49AM -0500, Jason Merrill wrote: > >> On 11/19/2015 03:46 PM, Jason Merrill wrote: > >> >On 11/15/2015 12:01 AM, David Malcolm

[Bug middle-end/67714] [6 Regression] signed char is zero-extended instead of sign-extended

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67714 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #5 from

Re: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

On Mon, Nov 23, 2015 at 05:40:14PM +0100, Richard Biener wrote: > On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek > wrote: > >We blow up on the following testcase because we find ourselves passing > >[_13 + 1, INT_MAX] as a vr1 to

[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68483 --- Comment #6 from lvqcl.mail at gmail dot com --- (In reply to Richard Biener from comment #2) > With i?86 I can confirm your observation but I don't see it fixed on trunk. Sorry, the GCC 6.x compiler that I downloaded was built with

Re: [AArch64][dejagnu][PATCH 5/7] Dejagnu support for ARMv8.1 Adv.SIMD.

On 23/11/15 12:24, James Greenhalgh wrote: On Tue, Oct 27, 2015 at 03:32:04PM +, Matthew Wahab wrote: On 24/10/15 08:16, Bernhard Reutner-Fischer wrote: On October 23, 2015 2:24:26 PM GMT+02:00, Matthew Wahab wrote: The ARMv8.1 architecture extension adds two

[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484 --- Comment #8 from Vladimir Sedach --- Adding "static" to "volatile" "solves" the problem: static int * volatile x = _x; I'm using this trick to avoid aggressive optimization when measuring the time of execution. The compiler does not skip

Re: [PATCH/RFC] C++ FE: expression ranges (v2)

On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote: > Does the following look like the kind of thing you had in mind? (just > the tree.def part for now). Presumably usable for both lvalues and > rvalues, where the thing it wraps is what's important. It merely exists > to add an

Re: Enable pointer TBAA for LTO

On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka wrote: >> >> I think it also causes the following and one related ICE >> >> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal >compiler >> error) >> >>

[Bug tree-optimization/68455] [6 Regression] ICE: tree check: expected integer_cst, have plus_expr in decompose, at tree.h:5123

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68455 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Mon Nov 23 17:18:36 2015 New Revision: 230768 URL: https://gcc.gnu.org/viewcvs?rev=230768=gcc=rev Log: PR tree-optimization/68455 * tree-vrp.c

[Bug tree-optimization/68455] [6 Regression] ICE: tree check: expected integer_cst, have plus_expr in decompose, at tree.h:5123

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68455 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279 --- Comment #6 from Joost VandeVondele --- (In reply to Sebastian Pop from comment #5) > After fixing the graphite fail, I get these warnings from the testcase in thanks, these are due to reducing the testcase stripping variable definitions.

Re: [PATCH] Fix PR objc/68438 (uninitialized source ranges)

On 11/23/2015 04:13 AM, Joseph Myers wrote: On Sun, 22 Nov 2015, David Malcolm wrote: Is there (or could there be) a precanned dg- directive to ask if ObjC is available? I don't think so. Normal practice is that each language's tests are in appropriate directories for that language, with

[Bug tree-optimization/68493] [6 Regression] [graphite] ICE in copy_loop_phi_args

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68493 --- Comment #1 from Sebastian Pop --- Passes on ISL 0.14, fails with 0.15. This patch fixes it: we will bootstrap and commit. diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c index 30c3a21..2783ac4 100644 ---

[PATCH] PR c/68473: sanitize source range-printing within certain macro expansions

This patch fixes PR c/68473 by bulletproofing the new diagnostic_show_locus implementation against ranges that finish before they start (which can happen when using the C preprocessor), falling back to simply printing a caret. Successfully bootstrapped on x86_64-pc-linux-gnu; adds 7 new PASS

[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 --- Comment #5 from David Malcolm --- I've posted a candidate patch here: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02771.html

[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 --- Comment #15 from Steve Kargl --- On Sun, Nov 22, 2015 at 08:10:19PM +, jvdelisle at gcc dot gnu.org wrote: > > Attached is an expanded test case. Could someone review and confirm this is > valid. I need to work some code in interface.c

Re: update zlib to 1.2.8

On 11/22/2015 09:37 PM, Matthias Klose wrote: In GCC zlib is only used for libjava; for binutils and gdb it is used when building without --with-system-zlib. This just updates zlib from 1.2.7 to 1.2.8 (released in 2013). Applies cleanly, libjava still builds and doesn't show any regressions in

[Bug middle-end/68314] [6 Regression] Invalid read in build_pbb_minimal_scattering_polyhedrons (graphite-sese-to-poly.c:148)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68314 Sebastian Pop changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |spop at gcc dot gnu.org ---

Re: [PATCH] PR c/68473: sanitize source range-printing within certain macro expansions

On 11/23/2015 06:52 PM, David Malcolm wrote: This patch fixes PR c/68473 by bulletproofing the new diagnostic_show_locus implementation against ranges that finish before they start (which can happen when using the C preprocessor), falling back to simply printing a caret. Hmm, wouldn't it be

[Bug libfortran/51119] MATMUL slow for large matrices

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #23 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #21) > > Hidden behind a -fexternal-blas-n switch might be an option. Including GPUs > > seems even a tad more tricky. We have a paper on GPU (small) matrix > >

[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68492 --- Comment #5 from Ilya Enkovich --- (In reply to H.J. Lu from comment #4) > r230743 still fails for me. Can you show me your linking command line > for 465.tonto build? Here it is. Works OK for today's trunk (revision 230759). gfortran

[Bug other/68498] Replace LOOPS_MAY_HAVE_MULTIPLE_LATCHES with LOOPS_HAVE_SINGLE_LATCH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68498 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 --- Comment #2 from David Malcolm --- It's attempting to print this source range: (gdb) p *range $8 = {m_start = {m_line = 13, m_column = 12}, m_finish = {m_line = 6, m_column = 26}, m_show_caret_p = true, m_caret = {m_line =

Re: Fix lto-symtab ICE during Ada LTO bootstrap

> But can't you on the GENERIC side drop System.Address to void_ptr_node > again and just not make use of the "heavy lifting" you were talking about? No "heavy lifting" in this thread, just a heavy machinery in the language. :-) > That is, why is that speciality of System.Address not a Ada FE

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

Hi, On Fri, 20 Nov 2015, Jeff Law wrote: > > I'm undecided on whether cs-elim is safe wrt the store speculation vs > > locks concerns raised in the thread discussing Ian's > > noce_can_store_speculate_p, but that's not something we have to consider > > to solve the problem at hand. > I don't

Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def

On November 23, 2015 4:37:18 PM GMT+01:00, Tom de Vries wrote: >On 23/11/15 12:31, Richard Biener wrote: From the dump below I understand you want no memory references in > >the outer loop? > >So the issue seems to be that store motion fails > >to

Re: [PATCH 12/12] always define ENABLE_OFFLOADING

On Mon, Nov 09, 2015 at 19:41:21 +0100, Bernd Schmidt wrote: > On 11/09/2015 05:47 PM, tbsaunde+...@tbsaunde.org wrote: > >-#ifdef ENABLE_OFFLOADING > >/* If the user didn't specify any, default to all configured offload > > targets. */ > >if (offload_targets == NULL) > >

Re: [PATCH/RFC] C++ FE: expression ranges (v2)

On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote: > On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote: > > Does the following look like the kind of thing you had in mind? (just > > the tree.def part for now). Presumably usable for both lvalues and > > rvalues, where the

Re: Enable pointer TBAA for LTO

> > Please in future leave patches for review again if you do such > big changes before committing... Uhm, sorry, next time I will be more cureful. It seemed rather easy after debugging it but indeed it is somewhat surprising issue. > > I don't understand why we need this (testcase?) because

Re: Enable pointer TBAA for LTO

> > You are right, TYPE_NONALIASED_COMPONENT is the wrong way. I will fix it > > and try to come up with a testcase (TYPE_NONALIASED_COMPONENT is quite > > rarely used beast) > > It's only used in Ada as far as I know, but is quite sensitive and quickly > leads to wrong code if not handled

Re: [PATCH, ARM, v2] PR target/68059 libgcc should not use __write for printing fatal error

On 06/11/15 13:32, Szabolcs Nagy wrote: libgcc/config/arm/linux-atomic-64bit.c uses __write to print an error message if the 64bit cmpxchg method is not available in the kernel. __write is not part of the public libc abi, so use write instead. (user code may define write in iso c conforming

Re: [PATCH][AArch64][v2] Improve comparison with complex immediates followed by branch/cset

On 23/11/15 14:58, James Greenhalgh wrote: On Mon, Nov 23, 2015 at 10:33:01AM +, Kyrill Tkachov wrote: On 12/11/15 12:05, James Greenhalgh wrote: On Tue, Nov 03, 2015 at 03:43:24PM +, Kyrill Tkachov wrote: Hi all, Bootstrapped and tested on aarch64. Ok for trunk? Comments in-line.

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

Hi, On Fri, 20 Nov 2015, Bernd Schmidt wrote: > On 11/19/2015 12:49 AM, Jeff Law wrote: > > On 11/18/2015 12:16 PM, Bernd Schmidt wrote: > > > I don't think so, actually. One safe option would be to rip it out and > > > just stop transforming this case, but let's start by looking at the code > >

Re: [ptx] Fix sso tests

On 11/23/15 15:41, Jeff Law wrote: In the 'put' function, why not just make all targets go through putchar? It's not like this is performance critical code and I don't think it compromises any of the tests, does it? I contemplated that, but wondered if someone would complain. I'm happy

[Bug objc/68438] [6 Regression] Conditional jump or move depends on uninitialised value in location_adhoc_data_eq (line-map.c:89)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68438 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Mon Nov 23 21:00:13 2015 New Revision: 230775 URL: https://gcc.gnu.org/viewcvs?rev=230775=gcc=rev Log: Fix PR objc/68438 (uninitialized source ranges) gcc/c/ChangeLog: PR

Re: [PATCH, PING*3] DWARF: materialize subprogram renamings in Ada as imported declarations

On 08/31/2015 03:26 AM, Pierre-Marie de Rodat wrote: On 07/25/2015 09:44 PM, Pierre-Marie de Rodat wrote: This change makes GCC materialize subprogram renamings in Ada as imported declarations (DW_TAG_imported_declarations). For instance, procedure Foo renames Bar; will output:

Re: basic asm and memory clobbers

On 11/23/2015 2:04 AM, Andrew Haley wrote: On 21/11/15 12:56, David Wohlferd wrote: So, what now? While I'd like to take the big step and start kicking out warnings for non-top-level right now, that may be too bold for phase 3. A more modest step for v6 would just provide a way to find them

Re: [PATCH] Fix PR objc/68438 (uninitialized source ranges)

On Nov 23, 2015, at 3:13 AM, Joseph Myers wrote: > On Sun, 22 Nov 2015, David Malcolm wrote: > >> Is there (or could there be) a precanned dg- directive to ask if ObjC is >> available? > > I don't think so. Normal practice is that each language's tests are in >

Re: [ptx] Fix sso tests

On 11/23/2015 01:16 PM, Nathan Sidwell wrote: The gcc.dg/sso tests gratuitously fail on PTX because they use IO facilities that don't exist there. This patch changes the dumping to use the putchar function call (and not a macro), and not use fputs. With this they all pass. I'm not quite sure

Re: [PATCH] Fix PR objc/68438 (uninitialized source ranges)

On 11/23/2015 12:50 PM, David Malcolm wrote: On Mon, 2015-11-23 at 10:25 -0700, Jeff Law wrote: On 11/23/2015 04:13 AM, Joseph Myers wrote: On Sun, 22 Nov 2015, David Malcolm wrote: Is there (or could there be) a precanned dg- directive to ask if ObjC is available? I don't think so.

Re: [PATCH] Add LANG_HOOKS_EMPTY_RECORD_P for C++ empty class

On Mon, Nov 23, 2015 at 1:57 AM, Richard Biener wrote: > On Sat, Nov 21, 2015 at 12:46 AM, H.J. Lu wrote: >> On Fri, Nov 20, 2015 at 2:17 PM, Jason Merrill wrote: >>> On 11/20/2015 01:52 PM, H.J. Lu wrote: On Tue, Nov

[Bug objc/68438] [6 Regression] Conditional jump or move depends on uninitialised value in location_adhoc_data_eq (line-map.c:89)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68438 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

Re: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

On November 23, 2015 6:09:33 PM GMT+01:00, Marek Polacek wrote: >On Mon, Nov 23, 2015 at 05:40:14PM +0100, Richard Biener wrote: >> On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek > wrote: >> >We blow up on the following testcase because we find

Re: [PATCH] Don't lower VEC_PERM_EXPR if it can be expanded using vec_shr optab (PR target/68483)

On November 23, 2015 8:14:59 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The patches that removed VEC_RSHIFT_EXPR regressed the first of these >testcases on i?86/-msse2, because can_vec_perm_p returns false for >that, >and indeed as can_vec_perm_p is given only the mode and mask

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

On 11/23/2015 08:53 AM, Pierre-Marie de Rodat wrote: Do you think the other patches could make it before the branch? (if they could, I will rebase+retest them as quick as possible). Probably, yes. I can't find the DW_AT_static_link patch, though; it doesn't seem to have been attached to

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

On 08/31/2015 03:28 AM, Pierre-Marie de Rodat wrote: On 07/20/2015 02:45 PM, Pierre-Marie de Rodat wrote: On PowerPC targets with -mlongcall, most subprogram calls are turned into indirect calls: the call target is read from a register even though it is compile-time known. This makes it

libgo patch committed: Fix reflect.Call of function returning zero-sized type

PR 68496 points out a bug in the handling of reflect.Call calling a function that returns a zero-sized type. libffi doesn't understand zero-sized types, which don't exist in C, so they require special handling. This patch fixes the problem. Bootstrapped and ran Go testsuite on

[Bug go/68496] [libgo] reflect test fails on Linux x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Mon Nov 23 21:17:45 2015 New Revision: 230776 URL: https://gcc.gnu.org/viewcvs?rev=230776=gcc=rev Log: PR go/68496 reflect: Allocate space for FFI functions returning

[Bug go/68496] [libgo] reflect test fails on Linux x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496 --- Comment #4 from ian at gcc dot gnu.org --- Author: ian Date: Mon Nov 23 21:18:03 2015 New Revision: 230777 URL: https://gcc.gnu.org/viewcvs?rev=230777=gcc=rev Log: PR go/68496 reflect: Allocate space for FFI functions returning

[Bug go/68496] [libgo] reflect test fails on Linux x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/67677] [6 Regression] r226005 causes "Conditional jump or move depends on uninitialised value(s)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67677 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug lto/68322] -Wodr warning on templates should list the instantiation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68322 Segher Boessenkool changed: What|Removed |Added CC||trippels at gcc dot gnu.org ---

Re: basic asm and memory clobbers

On 11/23/2015 12:37 PM, Jeff Law wrote: On 11/23/2015 03:04 AM, Andrew Haley wrote: On 21/11/15 12:56, David Wohlferd wrote: So, what now? While I'd like to take the big step and start kicking out warnings for non-top-level right now, that may be too bold for phase 3. A more modest step for

[Bug target/67677] [6 Regression] r226005 causes "Conditional jump or move depends on uninitialised value(s)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67677 --- Comment #3 from Segher Boessenkool --- *** This bug has been marked as a duplicate of bug 68332 ***

[Bug target/68332] [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68332 Segher Boessenkool changed: What|Removed |Added CC||trippels at gcc dot gnu.org ---

[Bug lto/68322] -Wodr warning on templates should list the instantiation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68322 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org ---

Re: basic asm and memory clobbers

> On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote: > > ... >> The more I think about it, I'm just not keen on forcing all those old-style >> asms to change. > > If you mean you aren't keen to change them to "clobber all," I'm with you. > If you are worried about

[Bug libstdc++/68479] Dynamic loading multiple shared libraries with identical static libstdc++ breaks streams

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68479 --- Comment #2 from Stefan H. --- Interesting. So this breakage is expected behavior? I wasn't sure as there were so many ways to load it differently that didn't seem to exhibit the problems. I assume the ones I listed (except linking libstdc++

<    1   2   3   4