[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Attachment #35125|0 |1 is obsolete|| --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Created attachment 35189 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35189action=edit reduced C testcase To be compiled at -O2.
[Bug fortran/65429] ICE on implied-length character empty array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429 --- Comment #4 from drikosev at otenet dot gr --- So, the proper solution is described at: https://gcc.gnu.org/ml/fortran/2015-03/msg00163.html
[Bug ada/65490] terminals.c:1266:21: warning: argument to ‘sizeof’ in ‘bzero’ call is the same expression as the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65490 --- Comment #2 from vries at gcc dot gnu.org --- Author: vries Date: Tue Mar 31 08:30:15 2015 New Revision: 221789 URL: https://gcc.gnu.org/viewcvs?rev=221789root=gccview=rev Log: Fix bzero warning in child_setup_tty 2015-03-31 Tom de Vries t...@codesourcery.com PR ada/65490 * terminals.c (child_setup_tty): Fix warning 'argument to sizeof in bzero call is the same expression as the destination'. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/terminals.c
[Bug target/65531] ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531 --- Comment #5 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Tue Mar 31 08:29:28 2015 New Revision: 221788 URL: https://gcc.gnu.org/viewcvs?rev=221788root=gccview=rev Log: gcc/ PR target/65531 * ipa-chkp.c (chkp_maybe_create_clone): Don't set same_comdat_group for external symbols. * symtab.c (symtab_node::verify_symtab_nodes): Avoid infinite same_comdat_group traversal loop. gcc/testsuite/ PR target/65531 * gcc.target/i386/mpx/pr65531.cc: New. Added: trunk/gcc/testsuite/gcc.target/i386/mpx/pr65531.cc Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-chkp.c trunk/gcc/symtab.c trunk/gcc/testsuite/ChangeLog
[Bug target/65602] gcc.target/i386/mpx tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65602 Ilya Enkovich ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Fixed
[Bug c/65620] Incorrect warning for !! with -Wlogical-not-parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65620 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I don't see the warnings, I think it has been already fixed in r221284.
[Bug target/65602] gcc.target/i386/mpx tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65602 --- Comment #4 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Tue Mar 31 08:24:38 2015 New Revision: 221787 URL: https://gcc.gnu.org/viewcvs?rev=221787root=gccview=rev Log: PR target/65602 * gcc.target/i386/mpx/alloca-1-lbv.c (mpx_test): Use __builtin_alloca instead of alloca. * gcc.target/i386/mpx/alloca-1-nov.c (mpx_test): Likewise. * gcc.target/i386/mpx/alloca-1-ubv.c (mpx_test): Likewise. * lib/mpx-dg.exp (check_effective_target_mpx): Add wrapper check. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/mpx/alloca-1-lbv.c trunk/gcc/testsuite/gcc.target/i386/mpx/alloca-1-nov.c trunk/gcc/testsuite/gcc.target/i386/mpx/alloca-1-ubv.c trunk/gcc/testsuite/lib/mpx-dg.exp
[Bug target/58945] Improve atomic_compare_and_swap*_doubleword pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58945 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Attachment #33729|0 |1 is obsolete|| Attachment #33744|0 |1 is obsolete|| Assignee|steven at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 35190 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35190action=edit Patch to simplify atomic_compare_and_swapdwi_doubleword pattern At the end of the day ... the problem was in the patch itself, the infrastructure is OK. We have to use A constraint for doubleword eax/edx register pair. Where did I put my brown paperbag? The resulting code for the testcase from the Comment #0 is considerably better: movqi(%rip), %rax movq$-1, %rcx movqi+8(%rip), %rdx .L2: movq%rcx, %rbx lock; cmpxchg16bi(%rip) jne .L2
[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Something goes wrong during the creation of the thunk, probably because the type is both a scalar type and returned by reference in the 64-bit MS ABI.
[Bug target/65531] ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531 Ilya Enkovich ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Fixed
[Bug ada/65490] terminals.c:1266:21: warning: argument to ‘sizeof’ in ‘bzero’ call is the same expression as the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65490 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org --- Comment #3 from vries at gcc dot gnu.org --- Committed patch, marking resolved fixed.
[Bug testsuite/64983] Incomplete summary when regtesting with dejagnu 1.5.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- Fixed in dejagnu 1.5.3. So closing as MOVED (dejagnu bug).
[Bug tree-optimization/65511] transform_to_exit_first_loop looses edge probabilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65511 --- Comment #6 from vries at gcc dot gnu.org --- bootstrapped and reg-tested: - https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01536.html - https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01537.html
[Bug tree-optimization/65492] Bad optimization in -O3 due to if-conversion and/or unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492 --- Comment #12 from Allan Jensen linux at carewolf dot com --- I have a very crude fix for this. First though, according to comments in tree-if-conv.c and earlier bugs on the issues. If-conversion is suppposed to be conditional. It performed in a piece of conditionally code only to be used if vectorized. For some reason this version appears to be used. But secondly. If conditional move instructions are generally slower than branches, shouldn't they be avoided during instruction selections? The crude fix is simply placing a 'return false;' in the top of ix86_expand_int_movcc in i386.c. So this case somehow triggers a case where the if-conversion that is supposed to only be used by vectorization gets used anyway, but more generally, i386 shouldn't be generating cmov instructions for conditional moves in the first place for modern architectures (anything newer than core2 and bulldozer). At least not without input from a profile run.
[Bug tree-optimization/65637] New: expand_omp_for_static_chunk ssa-code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 Bug ID: 65637 Summary: expand_omp_for_static_chunk ssa-code is untested Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org This is the more generic version of https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01149.html . Currently, ssa-handling code in expand_omp_for_static_chunk is dead and not exercised by testing. Ssa-handling code in omp-low.c is only triggered by pass_parallelize_loops, and that pass doesn't specify a chunk size on the GIMPLE_OMP_FOR it constructs, so that will only call expand_omp_for_static_nochunk.
[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 --- Comment #2 from vries at gcc dot gnu.org --- (In reply to vries from comment #1) A patch like this will excercise the code: Indeed: ... $ grep -i 'internal compiler error' build/gcc/testsuite/gcc/gcc.log gcc/testsuite/gcc.dg/autopar/pr46099.c:17:3: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/pr46099.c:17:3: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/pr46099.c:17:3: internal compiler error: Segmentation fault FAIL: gcc.dg/autopar/pr46099.c (internal compiler error) gcc/testsuite/gcc.dg/autopar/pr46099.c:17:3: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/pr49580.c:24:9: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/pr49580.c:24:9: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/pr49580.c:24:9: internal compiler error: Segmentation fault FAIL: gcc.dg/autopar/pr49580.c (internal compiler error) gcc/testsuite/gcc.dg/autopar/pr49580.c:24:9: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/reduc-3.c:21:3: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/reduc-3.c:21:3: internal compiler error: Segmentation fault gcc/testsuite/gcc.dg/autopar/reduc-3.c:21:3: internal compiler error: Segmentation fault ... FAIL: gcc.dg/autopar/reduc-3.c (internal compiler error) gcc/testsuite/gcc.dg/autopar/reduc-3.c:21:3: internal compiler error: Segmentation fault
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #30 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #28) So I've been thinking about how to integrate life/conflict analysis into the uncprop code and it may not be that bad, both from an implementation and computation standpoint. Most importantly, we don't have to compute full life information. We really just need to compute the life of the equivalence. Given the life of the equivalence, if the equivalence is live in any block that contains the defining statement for an SSA_NAME appearing in the target PHI, then the equivalence conflicts and we don't want to unpropagate it. Computing the life of the equivalence is pretty easy and should be reasonably quick. This is a cost we'd have to pay regardless of whether or not we integrate uncprop with out-of-ssa since we won't have life information for the expression. Collecting the SSA_NAMEs appearing on the RHS of the PHI so that we don't test for conflicts multiple times if an SSA_NAME shows up in multiple PHI alternatives would help keep the cost down as well. Ultimately I don't think we need to integrate uncprop and out-of-ssa to avoid the unprofitable transformation during uncprop. Also see Boissinot et al., Fast Liveness Checking for SSA-Form Programs (CGO 08). They describe a way to do fast liveness queries without actually doing a (memory) expensive data-flow analysis but using SSA immediate-uses and dominance checks. Sth we could use in SSA coalescing as well to avoid both the liveness bitmaps and the conflict graph.
[Bug fortran/64613] incomplete type allocatable array after 4.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64613
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2015-03-31
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I get
(gdb) i lo
x = {{1, 4, 2}, {5, 3, 6}}
y = incomplete type
with 4.6.4, 4.7.3, and 4.8.2. With 5.0 I get
x = (( 1, 4) ( 2, 5) ( 3, 6) )
y = ()
Could this be related/duplicate of pr59438?
[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 --- Comment #1 from vries at gcc dot gnu.org --- A patch like this will excercise the code: ... diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c index 62a6444..b600b2c 100644 --- a/gcc/tree-parloops.c +++ b/gcc/tree-parloops.c @@ -1719,6 +1719,7 @@ create_parallel_loop (struct loop *loop, tree loop_fn, tree data, type = TREE_TYPE (cvar); t = build_omp_clause (loc, OMP_CLAUSE_SCHEDULE); OMP_CLAUSE_SCHEDULE_KIND (t) = OMP_CLAUSE_SCHEDULE_STATIC; + OMP_CLAUSE_SCHEDULE_CHUNK_EXPR(t) = integer_one_node; for_stmt = gimple_build_omp_for (NULL, GF_OMP_FOR_KIND_FOR, t, 1, NULL); gimple_set_location (for_stmt, loc); ...
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 --- Comment #20 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 30 Mar 2015, hubicka at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 --- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org --- Actually at second thought, would BIT_FIELD_REF arg1_3(D), ... allow us to avoid the actual memory store? I tought like COMPONENT_REF it takes address as parameter. What I am hoping is to fully optimize out union doub x; at early optimization time. Yes
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.3 |6.0 Summary|[4.9/5 Regression] one more |[4.9/5/6 Regression] one |stack slot used due to one |more stack slot used due to |less inlining level |one less inlining level Known to fail||5.0 --- Comment #31 from Richard Biener rguenth at gcc dot gnu.org --- I'd say we push this back to GCC 6.
[Bug fortran/64613] incomplete type allocatable array after 4.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64613 --- Comment #2 from Quang Linh LE ql.le at hotmail dot com --- Actually the problem was because I recompiled vanilla versions of GCC/GDB on Fedora (I was on Fedora 17 with GCC 4.7). Fedora has long history of patches for GBD include VLA. After trying serveral times with Archer and other VLA implement, I gave up. The best way I can suggest to a normal user is grabbing a new version of Fedora with recent version of GCC and GDB... Unfortunately, if one is on OS X, I can't find any solution atm.
[Bug fortran/65438] Unnecessary ptr check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65438 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-31 CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The function check_array_not_assumed (openmp.c) performs an unnecessary check on pointers. Does this refer to sym-attr.pointer in the lines if (sym-as sym-as-type == AS_DEFERRED sym-attr.pointer !sym-attr.contiguous) ?
[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 vehre at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #7 from vehre at gcc dot gnu.org --- Patch available at https://gcc.gnu.org/ml/fortran/2015-03/msg00168.html. Awaiting review, targeting for 5.x.
[Bug fortran/57307] ICE with sourced allocation with array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57307 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||vehre at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #2 from vehre at gcc dot gnu.org --- Taking this pr, because my patch at https://gcc.gnu.org/ml/fortran/2015-03/msg00168.html fixes the issue as reported by Dominique.
[Bug c++/56100] spurious -Wshadow warning with local variable in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-31 Ever confirmed|0 |1
[Bug fortran/64861] Possible wrong code with BIND(C) and PRIVATE + slightly bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-31 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- This looks as duplicate of PR49111, even the concern expressed in * Check whether the TREE_PUBLIC handling is correctly done for BIND(C)+PRIVATE (honoring additionally whether it has a binding name or not.)
[Bug c++/56387] Alias of class template wrongly seen as different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.3 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed in 4.8.3.
[Bug c++/56287] __do_global_ctors_aux() crashing when LTO enabled with flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56287 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||vehre at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #11 from vehre at gcc dot gnu.org --- Taking this pr, because my patch at https://gcc.gnu.org/ml/fortran/2015-03/msg00168.html fixes the issue as reported by Dominique.
[Bug c++/65619] friend declaration with template template parameter not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-31 Blocks||65608 Ever confirmed|0 |1
[Bug c++/60437] [C++11] Bogus error: no matching function for call to 'X::X(brace-enclosed initializer list)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60437 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||david.d.kretzmer at gmail dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 65622 has been marked as a duplicate of this bug. ***
[Bug c++/65622] No known conversion to initializer_list with default argument in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65622 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 60437 ***
[Bug c++/65626] [5 Regression] ICE in fixup_noreturn_call called by tree-ssa-forwprop.c:2492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65626 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Mar 31 09:34:08 2015 New Revision: 221790 URL: https://gcc.gnu.org/viewcvs?rev=221790root=gccview=rev Log: 2015-03-31 Richard Biener rguent...@suse.de PR middle-end/65626 * tree-cfgcleanup.c (fixup_noreturn_call): Only split the block of the noreturn call so it is last and cleanup_control_flow_bb can do the CFG part. * g++.dg/torture/pr65626.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr65626.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c
[Bug c++/65626] [5 Regression] ICE in fixup_noreturn_call called by tree-ssa-forwprop.c:2492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65626 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Well, it worked reasonably well (not ICEing) since GCC 4.8 (or 4.9) at least.
[Bug libstdc++/64132] [5 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64132 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Not a primary or secondary arch (and still unconfirmed).
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #31 from Richard Biener rguenth at gcc dot gnu.org --- No negative effects seen. Update on the regression? P3-P1 before willfully downgrading later...
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 65243 has been marked as a duplicate of this bug. ***
[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65243 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Same as PR65549 I'd say. Marking as dup. *** This bug has been marked as a duplicate of bug 65549 ***
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- i686-apple-darwin is a secondary arch and supposedly (but not verified?) affected. A workaround is to disable building of libcc1 (but it's enabled by default it seems).
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org --- Is the slowdown fixed?
[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug target/65489] [5 Regression] Testcase for PR 65427 ICEs at -Os on arm-none-eabi in hoist pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65489 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #32 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Biener from comment #31) No negative effects seen. Update on the regression? P3-P1 before willfully downgrading later... It depends on the target machine. On amdfam10 it is still 12%, on sandybridge it is less than 10%. But tramp3d-v4.cpp compiled with gcc-5 runs 3.5% faster thanks to -ipa-icf.
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) i686-apple-darwin is a secondary arch and supposedly (but not verified?) affected. A workaround is to disable building of libcc1 (but it's enabled by default it seems). i686-apple-darwin is affected, I will test the patch @comment #3 on linux and then re-post (it is addressing iant's review comments). The workaround is to disable -mdynamic-no-pic in BOOT_CFLAGS, but that's just pretending that the problem doesn't exist, of course.
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Reproduces also with -flto-partition=max and GCC 4.9 succeeds with that. Suggesting this may be a real regression and not just a latent issue popping up(?) Honza, can you please have a look?
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- And can somebody bisect this with -flto-partition=max (and or reduce further)?
[Bug pch/65550] [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|NEW |WAITING --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Bisect? Reduce to a set of files to produce the PCH and a file to use it?
[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Needs more analysis from folks that can reproduce - see Honzas comment.
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Attachment #35158|0 |1 is obsolete|| --- Comment #12 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 35191 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35191action=edit reduced testcase Further reduced with -flto-partition=max, but still 4.3k.
[Bug target/65582] [5 Regression] testsuite lto issue: xgcc.exe: warning: '-x lto' after last input file has no effect, fatal error: no input files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65582 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- x86_64-w64-mingw32 is not primary or secondary.
[Bug target/65564] [5 Regression] builtin-bnd-narrow-ptr-bounds-2-nov.c:15:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65564 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- No primary/secondary target in the list of affected targets.
[Bug ada/65618] [5 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- mips is only primary as cross.
[Bug c++/65625] [5 Regression] ICE in make_typename_type, at cp/decl.c:3499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65625 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Not error-recovery - P1.
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 --- Comment #2 from Kirill Yukhin kyukhin at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) IMHO a user error, if you use -nostdinc, you are responsible for letting the compiler know where to find all the needed includes. Yes, but for my case, these header is not needed. Moreover, as far as I understand stdlib.h inclusion was added for compatibility with ICC only. Maybe, somehow check if this header is available and include mm_malloc.h into x86intrin.h only if it is.
[Bug c++/65638] Crash on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-31 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- This doesn't crash for me with 4.8/4.9 nor 5; what options did you use?
[Bug driver/65639] New: -nostdlib/-nodefaultlibs should not affect ASan runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65639 Bug ID: 65639 Summary: -nostdlib/-nodefaultlibs should not affect ASan runtime Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: earthdok at google dot com CC: jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, samsonov at google dot com In GCC trunk, if -nostdlib/-nodefaultlibs is passed together with -fsanitize=address, the ASan runtime is not linked. Clang had the same behavior briefly but ended up reverting to the old behavior (i.e. those flags do not affect the ASan runtime): http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20141020/117217.html https://code.google.com/p/address-sanitizer/issues/detail?id=344 One use case where GCC's behavior is problematic is building an ASan-instrumented glibc. Some executables are linked with -nostdlib and explicitly linked against the just-built libc.so.6; -fsanitize=address causes those build steps to fail due to unresolved ASan symbols.
[Bug c++/65638] Crash on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64le-linux-gnu Status|WAITING |NEW CC||trippels at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- trippels@gcc2-power8 ~ % echo bool | /home/trippels/gcc_valgrind/usr/local/bin/g++ -x c++ - ==12604== Invalid read of size 1 ==12604==at 0x10D99290: _cpp_lex_direct (lex.c:2279) ==12604==by 0x10D9A6F7: _cpp_lex_token (lex.c:2163) ==12604==by 0x10DA1147: cpp_get_token_1(cpp_reader*, unsigned int*) (macro.c:2442) ==12604==by 0x102E2FB3: c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) (c-lex.c:408) ==12604==by 0x101B235B: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*) (parser.c:780) ==12604==by 0x101F36A7: cp_lexer_new_main (parser.c:660) ==12604==by 0x101F36A7: cp_parser_new (parser.c:3484) ==12604==by 0x101F36A7: c_parse_file() (parser.c:33187) ==12604==by 0x102E952B: c_common_parse_file() (c-opts.c:1057) ==12604==by 0x107688AB: compile_file() (toplev.c:594) ==12604==by 0x10111D33: do_compile (toplev.c:2076) ==12604==by 0x10111D33: toplev::main(int, char**) (toplev.c:2174) ==12604==by 0x10112747: main (main.c:39) ==12604== Address 0x68 is not stack'd, malloc'd or (recently) free'd ==12604== stdin:1:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/65638] New: Crash on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638 Bug ID: 65638 Summary: Crash on invalid input Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: JamesMikeDuPont at googlemail dot com using the invalid input file: ``` void crash (bool ``` found using permutation testing based on the https://h4ck3rm1k3.wordpress.com/2015/03/31/test-random-permutations-of-files-and-lines-for-gccgo-golang-go-compiler-bug-reporting/ Arch: Linux gcc2-power8.osuosl.org 3.17.4-301.fc21.ppc64le #1 SMP Mon Dec 1 07:51:01 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux crashes on : gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1) and gcc (GCC) 5.0.0 20150331 (experimental) but not on : Linux 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27) x86_64 GNU/Linux with g++-4.9 (Debian 4.9.2-10) 4.9.2 ``` test.cc:1:14: error: expected ‘,’ or ‘...’ at end of input void crash ( bool ^ test.cc:1:14: error: expected ‘)’ at end of input test.cc:1:14: error: expected initializer at end of input ```
[Bug c++/56100] spurious -Wshadow warning with local variable in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- I wonder if in such cases would it simply make sense to suppress the warning basing on the locations, eg the below certainly works for the testcase and passes testing: Index: name-lookup.c === --- name-lookup.c (revision 221789) +++ name-lookup.c (working copy) @@ -1271,7 +1271,9 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend) } } else if (oldglobal != NULL_TREE - (VAR_P (oldglobal) + ((VAR_P (oldglobal) +(input_location +DECL_SOURCE_LOCATION (oldglobal))) /* If the old decl is a type decl, only warn if the old decl is an explicit typedef or if both the old and new decls are type decls. */
[Bug c++/65638] Crash on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638 --- Comment #2 from James Michael DuPont JamesMikeDuPont at googlemail dot com --- No options at all. On the gcc compile farm : gcc112.fsffrance.org [h4ck3rm1k3@gcc2-power8 ~]$ which g++ /usr/bin/g++ [h4ck3rm1k3@gcc2-power8 ~]$ g++ test1.cc test1.cc:1:1: internal compiler error: Segmentation fault void crash ( bool ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions.
[Bug c++/65638] Crash on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638 --- Comment #3 from James Michael DuPont JamesMikeDuPont at googlemail dot com --- This test case can be reduced to just a file with the word bool in it. ``` bool ```
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org --- Agreed, though ideally it should be fixed early in stage1.
[Bug sanitizer/65643] New: FAIL: c-c++-common/asan/swapcontext-test-1.c on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65643 Bug ID: 65643 Summary: FAIL: c-c++-common/asan/swapcontext-test-1.c on powerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org In addition to those noted in pr65479 the following failures are seen in runs of the the Address Sanitizer test suite (both C and C++): Running /src/gcc-trunk-git/gcc/testsuite/gcc.dg/asan/asan.exp ... FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -g execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -Os execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test === gcc Summary === # of expected passes1072 # of unexpected failures10 # of unsupported tests136 /build/gcc-5.0/gcc/xgcc version 5.0.0 20150323 (experimental) (GCC) The output of the tests suggests that the failures are due to incomplete support for the support makecontext/swapcontext functions: Child stack: 0x3fffd4ef9870 ==41773==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ASAN:SIGSEGV = ==41773==ERROR: AddressSanitizer: SEGV on unknown address 0x0058 (pc 0x3fffb251349c bp 0x10012480 sp 0x3fffd4ef96f0 T0) #0 0x3fffb251349c (/lib64/libc.so.6+0x7349c) #1 0x3fffb27b79a8 in __interceptor_swapcontext /src/gcc-trunk-git/libsanitizer/asan/asan_interceptors.cc:260 #2 0x100010a0 in Run /src/gcc-trunk-git/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:39 #3 0x1ba8 in main /src/gcc-trunk-git/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:54 #4 0x3fffb24e5d68 (/lib64/libc.so.6+0x45d68) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ??:0 ?? ==41773==ABORTING
[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
--- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK, this patch extends the calls.c hack:
Index: calls.c
===
--- calls.c (revision 221805)
+++ calls.c (working copy)
@@ -1321,6 +1321,15 @@ initialize_argument_information (int num
TREE_CODE (base) != SSA_NAME
(!DECL_P (base) || MEM_P (DECL_RTL (base)
{
+ /* We may have turned the parameter value into an SSA name.
+Go back to the original parameter so we can take the
+address. */
+ if (TREE_CODE (args[i].tree_value) == SSA_NAME)
+ {
+ gcc_assert (SSA_NAME_IS_DEFAULT_DEF (args[i].tree_value));
+ args[i].tree_value = SSA_NAME_VAR (args[i].tree_value);
+ gcc_assert (TREE_CODE (args[i].tree_value) == PARM_DECL);
+ }
/* Argument setup code may have copied the value to register. We
revert that optimization now because the tail call code must
use the original location. */
We fail to produce tail call, because the logic checking return values
triggers. At least save the extra copy of parameter:
func1:
subq$56, %rsp
.seh_stackalloc 56
.seh_endprologue
movq%rcx, %r8
leaq32(%rsp), %rcx
callfunc2
fldt32(%rsp)
movq%r8, %rax
fstpt (%r8)
addq$56, %rsp
ret
.seh_endproc
.section.text.unlikely,x
I will regtestbootstrap this on ppc but it would be nice if someone could
verify the generated code works (it seems RDX is holding the parameter pointer
and RCX the temporary slot).
Making this tail call seem to need more work, because the link to the actual
return address is lost much earlier:
#0 initialize_argument_information (num_actuals=2, args=0x3fffdb80,
args_size=0x3fffdf68, n_named_args=3, exp=0x3fffaf9415e0,
struct_value_addr_value=0x3fffaf9518c0,
fndecl=0x3fffafa5e580, fntype=0x3fffaf8c5898, args_so_far=...,
reg_parm_stack_space=32, old_stack_level=0x3fffdfb0,
old_pending_adj=0x3fffdfb8,
must_preallocate=0x3fffdf9c, ecf_flags=0x3fffdfa0,
may_tailcall=0x3fffdf60, call_from_thunk_p=true) at ../../gcc/calls.c:1343
#1 0x1038abfc in expand_call (exp=0x3fffaf9415e0, target=0x0,
ignore=0) at ../../gcc/calls.c:2695
#2 0x104f0980 in expand_expr_real_1 (exp=exp@entry=0x3fffaf9415e0,
target=optimized out, tmode=optimized out, modifier=optimized out,
alt_rtl=0x3fffe308,
inner_reference_p=optimized out) at ../../gcc/expr.c:10492
#3 0x104f50b0 in expand_expr_real (exp=exp@entry=0x3fffaf9415e0,
target=optimized out, tmode=optimized out,
modifier=modifier@entry=EXPAND_NORMAL,
alt_rtl=alt_rtl@entry=0x3fffe308,
inner_reference_p=inner_reference_p@entry=false) at ../../gcc/expr.c:8018
#4 0x104ff7f0 in store_expr_with_bounds (exp=exp@entry=0x3fffaf9415e0,
target=target@entry=0x3fffaf88c5e8, call_param_p=call_param_p@entry=0,
nontemporal=nontemporal@entry=false, btarget=btarget@entry=0x3fffaf920ee8)
at ../../gcc/expr.c:5385
#5 0x10502188 in expand_assignment (to=0x3fffaf920ee8,
from=0x3fffaf9415e0, nontemporal=optimized out) at ../../gcc/expr.c:5154
already in expand assignment to is set as follows:
ssa_name 0x3fffaf920ee8
type real_type 0x3fffaf8c1500 long double XF
size integer_cst 0x3fffaf880cf0 constant 128
unit size integer_cst 0x3fffaf880d08 constant 16
align 128 symtab 0 alias set 1 canonical type 0x3fffaf8c1500 precision
80
pointer_to_this pointer_type 0x3fffaf8c16f8
visited var var_decl 0x3fffaf9514d0 retval.2def_stmt retval.2_2 = func2
(x_1(D)); [return slot optimization] [tail call]
version 2
and retval is temporary produced by expand_thunk. I suppose expand_thunk must
not do the temporary in this case.
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 --- Comment #2 from Martin Sebor msebor at gcc dot gnu.org --- Created attachment 35196 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35196action=edit Proof-of-concept patch. Two problems are contributing to the failures in these tests: 1) a missing -fasynchronous-unwind-tables option; the option is necessary on powerpc*-*-*-* to generate a full stack trace 2) a bug in the backtrace_qsort function introduced in r208403 that makes the algorithm unstable (see also http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00342.html) The attached proof-of-concept patch adds the missing option mentioned in (1) and backs out the commit referenced in (2) as a proof of concept of fixing the problem. I'll try to come up with an approach that doesn't undo the performance improvement in a subsequent patch.
[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK,
hand written wrapper is produced as follows:
f3 (long double x)
{
long double _3;
bb 2:
_3 = func2 (x_2(D)); [return slot optimization]
retval = _3;
return retval;
}
and create_wrapper produces:
func1 (long double x)
{
long double retval.3;
bb 2:
retval.3_2 = func2 (x_1(D)); [return slot optimization] [tail call]
return retval.3_2;
}
I suppose it is the tail call that fails here, but I think it is just missed
optimization we do not produce it in the first case because the parameter also
needs copying:
f3:
subq$72, %rsp
.seh_stackalloc 72
.seh_endprologue
fldt(%rdx)
movq%rcx, %r8
leaq32(%rsp), %rdx
leaq48(%rsp), %rcx
fstpt 32(%rsp)
callfunc2
movq%r8, %rax
fldt48(%rsp)
fstpt (%r8)
addq$72, %rsp
ret
compiling it as jmp func2 would definitly be an improvmeent!
We die expanding address of the first parameter:
#2 0x104f6d5c in expand_expr_addr_expr_1 (exp=0x3fffaf921050,
target=target@entry=0x0, tmode=tmode@entry=DImode,
modifier=modifier@entry=EXPAND_NORMAL, as=as@entry=0 '\000')
at ../../gcc/expr.c:7761
7761 gcc_assert (inner != exp);
(gdb) p debug_tree (exp)
ssa_name 0x3fffaf921050
type real_type 0x3fffaf8c1500 long double XF
size integer_cst 0x3fffaf880cf0 constant 128
unit size integer_cst 0x3fffaf880d08 constant 16
align 128 symtab 0 alias set 1 canonical type 0x3fffaf8c1500 precision
80
pointer_to_this pointer_type 0x3fffaf8c16f8
visited var parm_decl 0x3fffafa8 xdef_stmt GIMPLE_NOP
version 1
$1 = void
Where clearly we have problem of copying it to SSA name.
I suppose code in https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00423.html may
need to happen on non-aggregates, too
[Bug bootstrap/65645] New: --without-system-zlib has no impact in gcc directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65645 Bug ID: 65645 Summary: --without-system-zlib has no impact in gcc directory Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com When GCC is configured with --without-system-zlib, cc1 is still linked with system zlib due to # Use the system's zlib library. zlibdir=-L../zlib zlibinc=-I\$(srcdir)/../zlib AC_ARG_WITH(system-zlib, [AS_HELP_STRING([--with-system-zlib], [use installed libz])], zlibdir= zlibinc= ) AC_SUBST(zlibdir) AC_SUBST(zlibinc) in gcc/configure.ac. if test x$with_system_zlib = xyes ; then fi is missing.
[Bug bootstrap/7125] libz is built even if configured with --with-system-zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7125 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from H.J. Lu hjl.tools at gmail dot com --- Works for me with GCC 5.
[Bug target/65644] New: Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644
Bug ID: 65644
Summary: Assembler errors on Solaris 10 x86-64: `(%eXX)' is not
a valid 64 bit base/index expression
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: skunk at iskunk dot org
Host: x86_64-pc-solaris2.10
Target: x86_64-pc-solaris2.10
Build: x86_64-pc-solaris2.10
Created attachment 35197
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35197action=edit
test case
I built GCC 4.9.2 on a Solaris 10 system on x86-64, and then compiled a C
codebase that does some 64-bit-unsafe things (notably, assuming that pointers
are 32 bits, by casting unsigned ints to pointers). This resulted in cast to
pointer from integer of different size warnings as well as errors of the form
{standard input}: Assembler messages:
{standard input}:233: Error: `(%esi)' is not a valid 64 bit base/index
expression
{standard input}:250: Error: `(%edx)' is not a valid 64 bit base/index
expression
{standard input}:1150: Error: `(%edx)' is not a valid 64 bit base/index
expression
I have prepared a small test case that exhibits this same failure mode:
$ gcc -m64 -O -c gcc-asm-bug.c
gcc-asm-bug.c: In function 'foo1':
gcc-asm-bug.c:14:4: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
((struct foo_struct *)xptr)-one = val;
^
gcc-asm-bug.c: In function 'foo2':
gcc-asm-bug.c:19:4: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
((struct foo_struct *)xptr)-two = val;
^
/var/tmp//ccI3ovqk.s: Assembler messages:
/var/tmp//ccI3ovqk.s:6: Error: `(%edi)' is not a valid 64 bit base/index
expression
No such error occurs when I compile this source on a Linux system, so this may
have to do with the Solaris assembler.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #30 from Pierre Ossman ossman at cendio dot se --- (In reply to Dominique d'Humieres from comment #29) I can reopen the PR, but I don't see the point: (1) I can reproduce the problem only on x86_64-apple-darwin10 with gcc version 4.4.7 (I get 'CAUGHT' for all the other revisions I have tested on powerpc-apple-darwin9, x86_64-apple-darwin10, and x86_64-apple-darwin14. I'm not sure what we're doing differently in that case. Are you sure you are using libgcc_s from your gcc and not getting the routines from libSystem? What if you statically link libstdc++ and libgcc_eh like we do? (2) You should be able to build 4.9 and 5.0 without any patch for x86_64-apple-darwin* and a few for powerpc-apple-darwin9 and 5.0. Sorry, my bad. It was other issues preventing us from moving our development platform to 4.9. We should be able to do a test build. Do you think anything has changed since 4.8.4 though? (3) Why are you not using a more recent version of OS X? We need to produce binaries that most people can run, and 10.6 seemed like a good cut-off for now. We did however see the same crashes running the binary on 10.10. We have not tested using a newer target for the gcc build though.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #39 from Jan Hubicka hubicka at ucw dot cz --- Hi, yep, -Os or flatten is unchanged. It seems something regress with -O3 inline decisions but it is somewhat hard to pinpoint. I am on a way to Victoria, so I will do more only tonight. https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01615.html makes it possible to get comparable binary with old early inlining limits and unit growth (--param early-inlining-insns=11 --param inline-unit-growth=30). But the increased early inlining limits does not really seem to lead to more inlines for tramp3d. Honza
[Bug libstdc++/59406] functions labelled FNV-1a in tr1/functional_hash.h are not FNV-1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-31 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to g1 from comment #2) Don't know if those functions are used somewhere or are leftovers. The comments in the file suggest that Murmur hash is used in the std::hash template instead of FNV-1a. They're just leftovers retained for backwards compatibility in applications that need the old hashing algorithm, so changing them is probably not a good idea as it would not be backwards compatible. I'll add a comment to libsupsc++/hash_bytes.cc saying it's not really FNV-1a but I don't think we should change it now. Thanks for pointing it out though.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #29 from Dominique d'Humieres dominiq at lps dot ens.fr --- I'd like to reopen this issue as we are still seeing this with as new gcc as 4.8.4 (we've been unable to build anything newer). Unfortunately I do not seem to have the access rights to reopen the bug. Help? I can reopen the PR, but I don't see the point: (1) I can reproduce the problem only on x86_64-apple-darwin10 with gcc version 4.4.7 (I get 'CAUGHT' for all the other revisions I have tested on powerpc-apple-darwin9, x86_64-apple-darwin10, and x86_64-apple-darwin14. (2) You should be able to build 4.9 and 5.0 without any patch for x86_64-apple-darwin* and a few for powerpc-apple-darwin9 and 5.0. (3) Why are you not using a more recent version of OS X?
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #32 from boger at us dot ibm.com --- I have a prototype working for #2. I am assuming #1 would not be accepted. This fix consists of building a library called libnetgo.a which consists of the net files that would be built if the netgo tag was used. This new library was installed into the same directory as libgo.a. Once this library has been built and installed in the correct location, I was able to get this to work by explicitly linking in this lib: go build -gccgoflags '-static -lnetgo' lookup.go I will attach a patch after some more testing.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #35 from Markus Trippelsdorf trippels at gcc dot gnu.org --- POWER8 : 23.424 vs. 20.676 = 11.7316% Firefox LTO buildtime on ppc64le: 5:18.12 total vs. 4:48.85 total = 6.25%
[Bug tree-optimization/52340] autopar (at least) corrupts dominance info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52340 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #1 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-cvs/2012-03/msg00260.html : Author: rguenth Date: Mon Mar 5 14:36:18 2012 New Revision: 184933 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184933 Log: 2012-03-05 Richard Guenther rguent...@suse.de * cfgexpand.c (gimple_expand_cfg): Free dominator info. * tree-if-conv.c (combine_blocks): Free post-dominator info after breaking it. * tree-parloops.c (create_parallel_loop): Free and re-compute dominator info after breaking it. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/tree-if-conv.c trunk/gcc/tree-parloops.c
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #14 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #13) Started with r220011. But that doesn't make too much sense and indeed when I use an earlier version of the reduced testcase it still crashes with -flto-partition=max on r220010...
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Attachment #35191|0 |1 is obsolete|| --- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 35193 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35193action=edit reduced testcase Started with r220011.
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- I would hazard a guess that this started with r171740. And I think the fix is the following: --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -6366,7 +6366,8 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, field = next_initializable_field (TYPE_FIELDS (totype)); CONSTRUCTOR_APPEND_ELT (vec, field, array); field = next_initializable_field (DECL_CHAIN (field)); -CONSTRUCTOR_APPEND_ELT (vec, field, size_int (len)); +CONSTRUCTOR_APPEND_ELT (vec, field, +build_int_cst (TREE_TYPE (field), len)); new_ctor = build_constructor (totype, vec); return get_target_expr_sfinae (new_ctor, complain); }
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #37 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Richard Biener from comment #31) No negative effects seen. Update on the regression? P3-P1 before willfully downgrading later... Compiled with -Ofast -flto -funroll-loops -m32 and corresponding -march= spec2000 252.eon performance regressed on 5%, 197.parser on 2%.
[Bug libstdc++/65641] New: unordered_map - __detail::_Mod_range_hashing is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641 Bug ID: 65641 Summary: unordered_map - __detail::_Mod_range_hashing is slow Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: j.breitbart at tum dot de Created attachment 35192 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35192action=edit Small benchmark for our unordered_map change Hi, we have been using std::unordered_map with a pointer as the key in one of our applications and analysis showed that the find() function is one of two performance bottlenecks. Further analysis showed that about 40% of the total application runtime is spent in a single x86 divq instruction coming from std::__detail::_Mod_range_hashing. We think that using a modulo operation (translated to divq x86 instruction) all the time is suboptimal and have attached a simple example to show the benefits that can be achieved by replacing the modulo operation by masking. Example code (attachment) - We specialized the _Hashtable template to insert our own implementation of __detail::_Mod_range_hashing. In general the attached code should only be considered a demo for the performance increase possible, and not be considered a good solution. Benchmark - The example does 50,000,000 emplace and 50,000,000 find operations on an unordered_map. The test system is a Intel(R) Core(TM) i7-3740QM CPU @ 2.70GHz using gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6). Here are the performance results for the current implementation: $ g++ -Wall -Wextra -O3 -std=c++11 umap_test.cpp ./a.out runtime(s) emplace = 3.09947 runtime(s) find = 6.67535 Here is our optimization. $ g++ -Wall -Wextra -O3 -std=c++11 -DLESSDIV umap_test.cpp ./a.out runtime(s) emplace = 2.21004 runtime(s) find = 2.77398 Related work Facebooks folly uses a similar approach to what we do, but relies on a fixed bucket count. libcxx uses masking to compute the bucket number only if the number of buckets is a power of two. Getting the change upstream --- If there is any interest we would be happy to help out, but we are afraid that it requires an ABI change, as we must store a mask for every unordered_map (unless using libcxx's approach).
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marek Polacek from comment #6) --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -6366,7 +6366,8 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, field = next_initializable_field (TYPE_FIELDS (totype)); CONSTRUCTOR_APPEND_ELT (vec, field, array); field = next_initializable_field (DECL_CHAIN (field)); - CONSTRUCTOR_APPEND_ELT (vec, field, size_int (len)); + CONSTRUCTOR_APPEND_ELT (vec, field, + build_int_cst (TREE_TYPE (field), len)); new_ctor = build_constructor (totype, vec); return get_target_expr_sfinae (new_ctor, complain); } Not really, it doesn't fix the unreduced testcase.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #38 from Richard Biener rguenth at gcc dot gnu.org --- Looks that compile-time with -Dleafify=flatten is basically unchanged. So it is definitely different inlining decisions for tram3d-v4.cpp. Maybe we inline a lot more early now (due to early-insn param change?) and thus push more stmts through th eearly pipeline before we get rid of the bodies via IPA inlining? That -Os behaves sane hits at that (we ignore early-inlining-insns there). Though the base for inline-unit-growth is the size after early inlining and the former was dropped to 15%... Would be nice to have 'phase opt and generate' split into lowering, early opts, IPA, late opts and RTL phase.
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- I think the original testcase and the reduced testcase point out to different issues. The issue with the testcase in comment 1 is that we don't reject the user-provided definition of std::initializer_list (it has a pointer followed by an integer field), but convert_like_real assumes that the second integer field has a size_type, which might not be true, here my fix helps. I don't know yet the cause of the ICE with the unreduced testcase. It might make sense to fix these separately.
[Bug inline-asm/65640] New: multiple alternative constraints and earlyclobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65640
Bug ID: 65640
Summary: multiple alternative constraints and earlyclobbers
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: mjh at edg dot com
There seems to be an issue with earlyclobbers and multiple alternative
constraints. Take this example:
int f(int out, int in) {
asm(foo %1,%0; : =a (out) : b (in));// Okay
asm(foo %1,%0; : =b (out) : b (in));// Expected error
asm(foo %1,%0; : =a (out) : a (in));// Expected error
asm(foo %1,%0; : =a,b (out) : b,b (in)); // Okay
asm(foo %1,%0; : =a,b (out) : a,a (in)); // Unexpected error
asm(foo %1,%0; : =b,a (out) : b,b (in)); // Okay
asm(foo %1,%0; : =b,a (out) : a,a (in)); // Okay
return out;
}
With 4.9.2, I see three errors:
$ g++492 -S ex.c
ex.c: In function 'int f(int, int)':
ex.c:3:47: error: 'asm' operand has impossible constraints
asm(foo %1,%0; : =b (out) : b (in));// Expected error
^
ex.c:4:47: error: 'asm' operand has impossible constraints
asm(foo %1,%0; : =a (out) : a (in));// Expected error
^
ex.c:6:52: error: 'asm' operand has impossible constraints
asm(foo %1,%0; : =a,b (out) : a,a (in)); // Unexpected error
^
The first two are expected, but I'm at a loss to explain the third error. In
all four of the multi alternative constrain cases, there is exactly one good
constraint and one bad constraint in the pair, yet only one of the four cases
is diagnosed.
What is the expected behavior for this case?
[Bug c++/56100] spurious -Wshadow warning with local variable in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Doh, thanks Jason I thought I had already checked the behavior in that case.
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398 --- Comment #14 from Marek Polacek mpolacek at gcc dot gnu.org --- I see. Luckily these didn't regress with my fix for this PR, so I think these are separate issues. Could you please open a new PR? I'll see if I can fix these new ones.
[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540 --- Comment #6 from Martin Liška marxin at gcc dot gnu.org --- Without having a Windows machine, what is the easiest way to reproduced the problem? Can I reproduce the problem with cross compiler? Thanks, Martin
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Jack Howarth howarth.at.gcc at gmail dot com changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #31 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Pierre Ossman from comment #28) Or normal way of doing things is to statically link libstdc++ and libgcc_eh. This results in crashing programs. If we inject libSystem before libgcc_eh however, we get the system unwind routines and the program works fine. This is not quite the same as the previous cases mentioned on this bug, but the dumps show that a custom libgcc_s is being used so it should be equivalent. You might check out the original posting on this issue... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html IMHO, the static linkage of -lgcc_eh is evil as it potentially breaks the requirement that only a single unwinder (always the system one) be used.
[Bug target/61977] powerpc preprocessor breaks on lines that end with vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61977 --- Comment #3 from Martin Sebor msebor at gcc dot gnu.org --- See also pr65638 for a similar problem.
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
Does the following patch:
--- config/picflag.m42013-11-18 09:59:08.420212365 +0100
+++ config/picflag.m42015-03-31 18:36:21.989401000 +0200
@@ -9,7 +9,9 @@ case ${$2} in
*-*-darwin*)
# PIC is the default on this platform
# Common symbols not allowed in MH_DYLIB files
-$1=-fno-common
+# Cancel any earlier -mdynamic-no-pic, as that makes
+# the code not suitable for shared libraries.
+$1=-fno-common -mno-dynamic-no-pic
;;
alpha*-dec-osf5*)
# PIC is the default.
fix the libcc1 issue?
[Bug preprocessor/65638] Crash on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65638 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Martin Sebor from comment #5) Replacing bool with vector also leads to an ICE. Perhaps this is the same issue as pr61977. Yes. *** This bug has been marked as a duplicate of bug 61977 ***
[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Without having a Windows machine, what is the easiest way to reproduced the problem? Can I reproduce the problem with cross compiler? Yes, configure for the target indicated in the field above.
[Bug debug/65549] [5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #15 from Markus Trippelsdorf trippels at gcc dot gnu.org --- It really started with r219076 aka ipa-inline sreal conversion.
[Bug ipa/65557] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize -fipa-cp -fipa-icf-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65557 --- Comment #1 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #40 from Jan Hubicka hubicka at gcc dot gnu.org --- -O3 graph http://gcc.opensuse.org/c++bench/tramp3d/split-build.html seems to show 3 bigger increases recently. Can we get the revisions for those?
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 --- Comment #7 from Iain Sandoe iains at gcc dot gnu.org --- BOOT_CFLAGS has included -mdynamic-no-pic for a long time (before my time here), so I'm not aware of what criteria were discussed then, however -mdynamic-non-pic cannot be overridden by fPIC. I don't have spare cycles to investigate a more fine-grained approach in the short-term (although it seems like a reasonable way forward). Anyway, in the light of comment #6 I'm abandoning this patch.
