[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #24 from nightstrike --- (In reply to Marek Polacek from comment #20) > Sorry, the patch hasn't been applied to 4.9 nor 4.8 branch yet, and I don't > think it should be backported as-is, because just today I found out that the > patch contains a bug; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 Now that PR64709 is fixed, could you please backport both to 4.9 (and possibly 4.8)?
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #4 from David --- (In reply to Mikael Pettersson from comment #3) > Do you have a test case which fails without your patch? I do not. But this is a "by definition" thing. This instruction is intended to emulate the Windows InterlockedCompareExchange instruction (see the comments above the code). And all Windows Interlocked* instructions perform an implicit compiler barrier. After all, it does no good for the 'lock' prefix to prevent the processor from re-ordering instructions if the compiler does it while building the code. Moving loads or stores past this statement makes a mess of thread synchronization. That said, this instruction was only intended to be used on Win95 (neither NT nor Win98 need it). Not exactly a common platform these days. But it's possible someone is still using this, or will copy this asm block for their own use, so it should still be correct.
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 --- Comment #5 from Alan Modra --- Author: amodra Date: Mon Mar 16 03:29:36 2015 New Revision: 221445 URL: https://gcc.gnu.org/viewcvs?rev=221445&root=gcc&view=rev Log: PR target/63150 gcc/ * config/rs6000/rs6000.md (bswapdi2): Remove one scratch reg. Modify Z->r bswapdi splitter to use dest in place of scratch. In r->Z and Z->r bswapdi splitter rename word_high, word_low to word1, word2 and rearrange logic to suit. (bswapdi2_64bit): Remove early clobber on Z->r alternative. (bswapdi2_ldbrx): Likewise. Remove '??' on r->r. (bswapdi2_32bit): Remove early clobber on Z->r alternative. Add one '?' on r->r. Modify Z->r splitter to avoid need for early clobber. gcc/testsuite/ * gcc.target/powerpc/pr53199.c: Add extra functions. Revert 2014-12-05 change. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr53199.c
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #4 from Jan Hubicka --- Hmm, this one compiles just fine for me with today mainline. Does the problem still reproduce for you? Can you possibly dump out node->debug() and c?
[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #12 from Andrew Pinski --- (In reply to Andrew Pinski from comment #11) > I am almost 100% sure it was caused by > e2a16b9122d238b8877640b5f6ef1599e195fae0 (revision 221372). I am checking > if reverting this patch from the current upstream will not crash. yes reverting that patch fixes the bootstrap for me.
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #34 from Jan Hubicka --- The problem is (as described earlier) the fact htat we sum size of all call statmts in function after every inline decision. Most of time is spent in calling estimate_edge_size_and_time: 79.95% cc1 cc1[.] _ZL28estimate_calls_size_and_timeP11cgraph_nodePiS1_S1_S1_j3vecIP9tree_node7va_heap6vl_ptrES2_I28ipa_polymorphic_call_contextS5_S6_ES2_IP21ipa_agg 2.21% cc1 libc-2.13.so [.] _int_malloc 0.59% cc1 libc-2.13.so [.] _int_free Updating summaries incrementally will solve it but at the moment do not see any really simple change for GCC-5 (i looked at this code couple times already because of this PR) Honza
[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46115 --- Comment #6 from Andrew Pinski --- (In reply to Rob Staudinger from comment #3) > For the record, this is already possible using bracketed expressions, but > the syntactical sugar of not having to pick a function name would be great. Actually that is not valid as func is local to that scope and now it escapes.
[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 Andrew Pinski changed: What|Removed |Added Keywords||build, wrong-code CC||vries at gcc dot gnu.org Component|target |middle-end Severity|normal |blocker --- Comment #11 from Andrew Pinski --- I am almost 100% sure it was caused by e2a16b9122d238b8877640b5f6ef1599e195fae0 (revision 221372). I am checking if reverting this patch from the current upstream will not crash.
[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46115 --- Comment #5 from Shawn Landden --- http://mackyle.github.io/blocksruntime/#download
[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46115 Shawn Landden changed: What|Removed |Added CC||shawn at churchofgit dot com --- Comment #4 from Shawn Landden --- There is also the Apple blocks extension to C. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf http://clang.llvm.org/docs/Block-ABI-Apple.html#history
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #32 from Harald Anlauf --- Jerry, to give you some positive feedback: I'm now using your latest patch in https://gcc.gnu.org/ml/fortran/2015-03/msg00067.html It works for me. Thanks, Harald
[Bug libgcj/52579] [4.8/4.9/5 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52579 gee changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from gee --- (In reply to Kai Tietz from comment #7) > This issue seems to be fixed in 5.0 by Richard's work on libffi. > > Could you please check, if issue is fixed for you? libffi is now have frame information for raw-stub closure of stdcall calling convention.
[Bug libstdc++/58625] std::signbit always converts to double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
Tijl Coosemans changed:
What|Removed |Added
CC||tijl at coosemans dot org
--- Comment #15 from Tijl Coosemans ---
(In reply to Jakub Jelinek from comment #8)
> That said, I'd say that every conversion to double that would change the
> sign looks wrong to me, no matter of what the rounding mode is, except
> perhaps for NaN canonicalization and that sNaN could be signalled. So IMHO
> this is mostly an optimization thing, not correctness.
I do think this is a correctness problem for long double. Consider the
following C code:
int test( long double x ) {
return( __builtin_signbit( x ));
}
With "gcc49 -O2 -S test.c" on x86_64 this compiles to:
fldt 8(%rsp)
fstpl -16(%rsp)
movsd -16(%rsp), %xmm0
movmskpd %xmm0, %eax
andl $1, %eax
ret
The fstpl instruction converts long double to double and may generate all kinds
of floating point exceptions if the value can't be converted exactly and I
don't think signbit(x) is allowed to generate FP exceptions. So it would be
best to fix the c_std version too.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf --- 5.0.0 20150129 is too old. Please use latest trunk when reporting bugs against 5.0.
[Bug target/63234] arm used label is removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234 --- Comment #8 from Mikael Pettersson --- The failures on 4.7+ seem to be triggered by r177855, yet another ARM costing tweak. I'm not going to investigate this any further.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #4 from Avi Kivity --- I see the same crash on trunk, only now I get a stack trace: 0xca999f crash_signal ../../gcc/toplev.c:383 0x7f0b74 contains_struct_check ../../gcc/tree.h:2959 0x7f0b74 lambda_expr_this_capture(tree_node*, bool) ../../gcc/cp/lambda.c:752 0x7f12c7 maybe_resolve_dummy(tree_node*, bool) ../../gcc/cp/lambda.c:789 0x5f3cde build_new_method_call_1 ../../gcc/cp/call.c:8010 0x5f3cde build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../gcc/cp/call.c:8258 0x5f5379 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int) ../../gcc/cp/call.c:7802 0x5ebac9 build_temp ../../gcc/cp/call.c:6039 0x5ebac9 convert_like_real ../../gcc/cp/call.c:6428 0x5ecbf1 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int) ../../gcc/cp/call.c:9405 0x73b4d6 check_return_expr(tree_node*, bool*) ../../gcc/cp/typeck.c:8708 0x77a0ae finish_return_stmt(tree_node*) ../../gcc/cp/semantics.c:887 0x7f2879 maybe_add_lambda_conv_op(tree_node*) ../../gcc/cp/lambda.c:1085 0x68e6cf instantiate_class_template_1 ../../gcc/cp/pt.c:9619 0x68e6cf instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9672 0x72bf73 complete_type(tree_node*) ../../gcc/cp/typeck.c:146 0x65f3b3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:15673 0x660d6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:15050 0x64db96 tsubst_expr ../../gcc/cp/pt.c:14382 0x64f3dc tsubst_expr ../../gcc/cp/pt.c:13789 g++5 (GCC) 5.0.0 20150129 (experimental) Not bootstraped (built by gcc 4.9.2)
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #3 from Avi Kivity --- Ok, will check with trunk. On Sun, Mar 15, 2015 at 9:48 PM, maltsevm at gmail dot com < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 > > Mikhail Maltsev changed: > >What|Removed |Added > > > CC||maltsevm at gmail dot com > > --- Comment #2 from Mikhail Maltsev --- > Does not reproduce on trunk > > $ /opt/gcc-5.0.0/bin/g++ -v > Using built-in specs. > COLLECT_GCC=/opt/gcc-5.0.0/bin/g++ > > COLLECT_LTO_WRAPPER=/opt/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper > Target: x86_64-unknown-linux-gnu > Configured with: /home/miyuki/gcc/src/configure --prefix=/opt/gcc-5.0.0 > --enable-clocale=gnu --disable-nls --with-system-zlib > --with-demangler-in-ld > --enable-plugins --enable-shared --enable-bootstrap --with-fpmath=sse > --enable-languages=c,c++,lto > Thread model: posix > gcc version 5.0.0 20150315 (experimental) (GCC) > > $ /opt/gcc-5.0.0/bin/g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden > -pthread -O2 -c fail.i > > -- > You are receiving this mail because: > You reported the bug. >
[Bug tree-optimization/65337] [5 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 --- Comment #3 from Jan Hubicka --- Indeed, the cd-dce is one the worst documented of the tradition SSA optimizations. I commented on this to Jakum on IRC. The mechanizm that should prevent conditional from being removed is the control dependency. For every PHI argument, the control dependent conditional is marked live. So it is a question why the control dependent conditional is not live here - one of problems I remember was that control dependency is defined for basic blocks, while PHI handling needs it for edges. This mostly does not matter because critical edges are split, but with abnormal edges perhaps we manage to get things wrong. I am finishing paper today and fly to Vancouver at Tuesday, but will try to look into this as time allows.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev --- Does not reproduce on trunk $ /opt/gcc-5.0.0/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc-5.0.0/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/miyuki/gcc/src/configure --prefix=/opt/gcc-5.0.0 --enable-clocale=gnu --disable-nls --with-system-zlib --with-demangler-in-ld --enable-plugins --enable-shared --enable-bootstrap --with-fpmath=sse --enable-languages=c,c++,lto Thread model: posix gcc version 5.0.0 20150315 (experimental) (GCC) $ /opt/gcc-5.0.0/bin/g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 -c fail.i
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #1 from Avi Kivity --- Created attachment 35038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35038&action=edit Preprocessed source triggering ICE (bzip2'ed)
[Bug c++/65433] New: ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433
Bug ID: 65433
Summary: ICE processing lambdas
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Processing some complex code involving lambdas in gnu++1y mode, the compiler
segfaults:
$ g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 fail.i
In file included from ./core/seastar.hh:26:0,
from ./core/reactor.hh:25,
from ./net/net.hh:25,
from net/native-stack.hh:25,
from net/native-stack.cc:22:
./core/future.hh: In instantiation of 'struct future::then_wrapped(Func&&)
[with Func = smp_message_queue::async_work_item::process() [with Func =
net::arp_learn(net::ethernet_address,
net::ipv4_address)::]::; T = {};
futurize_t)> > = future<>]::&&)>':
./core/future.hh:510:58: required from
'futurize_t)> > future::then_wrapped(Func&&)
[with Func = smp_message_queue::async_work_item::process() [with Func =
net::arp_learn(net::ethernet_address,
net::ipv4_address)::]::; T = {};
futurize_t)> > = future<>]'
./core/reactor.hh:454:18: required from 'future<>
smp_message_queue::async_work_item::process() [with Func =
net::arp_learn(net::ethernet_address, net::ipv4_address)::]'
net/native-stack.cc:338:1: required from here
./core/future.hh:510:86: internal compiler error: Segmentation fault
return
then)>>(std::forward(func), []
(future_state&& state) { return future(std::move(state)); });
^
This is using gcc 5.0.0 from Fedora 22 (5.0.0-0.17).
Full source available from https://github.com/cloudius-systems/seastar.
Preprocessed source attached.
[Bug target/63234] arm used label is removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234 --- Comment #7 from Mikael Pettersson --- The wrong-code started in the 4.7 dev cycle with r183328, a fix for a similar bug (PR50313) in 4.6. That fix was backported to 4.6 but doesn't trigger this PR there (I just re-checked with 4.6.4). The bug is masked on trunk by r211885, a generic missed-optimization tweak, and even earlier for Cortex-A9 by a costing tweak in r203828, but I doubt either of those actually fixes the underlying problem.
[Bug go/65272] switch on type of interface failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272 --- Comment #5 from James Michael DuPont --- @iant thanks for the update. my bad, I got confused. here is the commit. https://github.com/gcc-mirror/gcc/commit/cc0446bae7c8c0ccead885787ad3fc4db0c127e0
[Bug preprocessor/60875] `_Pragma("message \"foo\")"` doesn't work in expression contexts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875 Ryan Lortie changed: What|Removed |Added CC||desrt at desrt dot ca --- Comment #3 from Ryan Lortie --- We want to do similar things in GLib in order to warn in the middle of arbitrary expressions or statements expanded from macros (essentially: support for deprecated macros).
[Bug go/65272] switch on type of interface failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- I was also closed on github because the bug was fixed in gccgo.
[Bug c++/65159] Linker forgets definition of type_info::__is_pointer_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159 --- Comment #9 from Jonathan Wakely --- (In reply to David Krauss from comment #8) > Jonathan, what does the "confirmed" mean, were you able to reproduce it at > all? Yes, but not after starting a fresh build in am empty directory, so it seems to be due to building in a dirty tree. Please try again with a clean build.
[Bug c++/65159] Linker forgets definition of type_info::__is_pointer_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159 --- Comment #8 from David Krauss --- It was an updated tree. I'm not sure what revision it was updated from, but it was probably late January. Sorry for the delay, my machine got completely hosed by a bad RAM chip. Took the filesystem with it. So, bit rot and disk corruption can't be ruled out either. Jonathan, what does the "confirmed" mean, were you able to reproduce it at all?
[Bug go/65272] switch on type of interface failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65272 --- Comment #3 from James Michael DuPont --- (In reply to James Michael DuPont from comment #2) > also on github https://github.com/golang/go/issues/10047 this was closed on github because it is valid go.
[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833 --- Comment #6 from John Paul Adrian Glaubitz --- Here's a tarball with the failed build: > http://userpage.physik.fu-berlin.de/~glaubitz/graphicsmagick-failed-build.tar.gz You can reproduce the problem with: $ cd graphicsmagick-1.3.20/ $ cd PerlMagick/ $ make Magick.o You probably need a working Perl installation to be able to build. Adrian
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #10 from Andrew Pinski --- 132858c819691c84077f130a5e7021961c0fb3ef (revision 221370) works.
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > It is working with 2ed7acc3505bbfed6a80787cf2537e212ff2bbe2 (revision > 221332). Fails with f4aade0acf5728ebadda80b38944f427a000e255 (revision 221402)
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #8 from Andrew Pinski --- It is working with 2ed7acc3505bbfed6a80787cf2537e212ff2bbe2 (revision 221332).
[Bug fortran/65024] [OOP] unlimited polymorphic pointer structure not built when it should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024 Paul Thomas changed: What|Removed |Added Keywords|ice-on-valid-code |FIXME Version|4.9.2 |5.0 Target Milestone|4.9.3 |6.0 Summary|[4.9/5 Regression] [OOP]|[OOP] unlimited polymorphic |ICE concerning unlimited|pointer structure not built |polymorphic pointer |when it should be --- Comment #14 from Paul Thomas --- Although the regression is fixed, it is desirable to find out why the unlimited polymorphic type is not being built at source. This foxed me completely; albeit with a limited amount of time spent on it. The patch has the virtue that it is failsafe but I will leave the PR open. Thanks for the report Paul
[Bug c/65423] No warning on always-true/false predicates containing bitwise operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65423 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev --- Probably this one: PR17534
[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024 --- Comment #13 from Paul Thomas --- Author: pault Date: Sun Mar 15 09:13:03 2015 New Revision: 221440 URL: https://gcc.gnu.org/viewcvs?rev=221440&root=gcc&view=rev Log: 2015-03-15 Paul Thomas PR fortran/65024 * trans-expr.c (gfc_conv_component_ref): If the component backend declaration is missing and the derived type symbol is available in the reference, call gfc_build_derived_type. 2015-03-15 Paul Thomas PR fortran/65024 * gfortran.dg/unlimited_polymorphic_23.f90: New test Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_23.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-expr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/65431] [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65431 --- Comment #1 from Markus Trippelsdorf --- To reproduce: trippels@gcc2-power8 testsuite % ~/gcc_valgrind/usr/local/bin/g++ -c -std=c++11 -fopenacc c-c++-common/goacc/nesting-1.c
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 --- Comment #1 from Markus Trippelsdorf --- To reproduce: trippels@gcc2-power8 testsuite % ~/gcc_valgrind/usr/local/bin/g++ -c -O2 -fdump-ipa-icf -fno-inline g++.dg/ipa/ipa-icf-4.C
