[Bug target/62231] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #2 from manfred.rudigier at omicron dot at --- I've built 4.9.2 today and can also confirm that it is working with this version, so it seems the bug has already been fixed in newer GCC versions.
[Bug ipa/63470] [5 Regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Jan, as mentioned in PR63967, could you have a look ?
[Bug target/57353] unrecognizable insn in decLibrary.c, ICE in extract_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57353 --- Comment #2 from Roland Stigge stigge at antcom dot de --- Yes, me neither. Consider it gone. Thanks!
[Bug middle-end/63994] Ada bootstrap fails with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 26 Nov 2014, enkovich.gnu at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994 --- Comment #5 from Ilya Enkovich enkovich.gnu at gmail dot com --- (In reply to rguent...@suse.de from comment #4) Any reason why non-C-family languages cannot use MPX? Richard. There is no fundamental restriction. If someone wants to implement Pointer Bounds Checker for some language, then he needs to define how it instruments the program on that language and implement it in the compiler. Currently it is defined and implemented for C-languages only. I see. I mainly wonder because of LTO which can combine TUs from C and Ada and because for example both Fortran and Ada define interoperability with C. All languages also share the common C runtime builtins. Richard.
[Bug tree-optimization/61634] [4.8/4.9/5 Regression] ICE in in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61634 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Nov 27 09:33:32 2014 New Revision: 218113 URL: https://gcc.gnu.org/viewcvs?rev=218113root=gccview=rev Log: 2014-11-27 Richard Biener rguent...@suse.de PR tree-optimization/61634 * tree-vect-slp.c: Include gimple-walk.h. (vect_detect_hybrid_slp_stmts): Rewrite to propagate hybrid down the SLP tree for one scalar statement. (vect_detect_hybrid_slp_1): New walker function. (vect_detect_hybrid_slp_2): Likewise. (vect_detect_hybrid_slp): Properly handle pattern statements in a pre-scan over all loop stmts. * gcc.dg/vect/pr61634.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr61634.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug target/62173] [5.0 regression] [AArch64] Can't ivopt array base address while ARM can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Depends on||52563 --- Comment #12 from Jiong Wang jiwang at gcc dot gnu.org --- the root cause why it's not ivopted on AArch64 is because must_check_src_overflow = TYPE_PRECISION (ct) TYPE_PRECISION (type); code above in convert_affine_scev, the input type is sizetype, so DI for 64bit arch, SI for 32bit arch, ct is SI, thus, must_check_src_overflow set to true for 64bit arch, then failed later scev_probably_wraps_p check. And I found similar issue reported back in 2012, at bug 52563. I verified this bug exist on other 64 archs, like mips64, ppc64, x86-64 Richard, on 52563, I see you was working on this, do you have any thoughts on this?
[Bug tree-optimization/61634] [4.8/4.9 Regression] ICE in in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61634 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 Regression] ICE |[4.8/4.9 Regression] ICE in |in in |in |vect_get_vec_def_for_operan |vect_get_vec_def_for_operan |d, at |d, at |tree-vect-stmts.c:1423 |tree-vect-stmts.c:1423 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar. I'll give it some time before backporting - the patch is quite non-trivial.
[Bug middle-end/63994] Ada bootstrap fails with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994 --- Comment #7 from Ilya Enkovich enkovich.gnu at gmail dot com --- (In reply to rguent...@suse.de from comment #6) I see. I mainly wonder because of LTO which can combine TUs from C and Ada and because for example both Fortran and Ada define interoperability with C. All languages also share the common C runtime builtins. Richard. It should be OK to mix instrumented and not instrumented codes. Instrumentation happens in early passes before LTO streams out. Therefore we can compile C file with '-fcheck-pointer-bounds -mmpx -flto -c', then compile fortran (or any other) file with '-c -flto' and finally pass generated objects to LTO. It may be inconvenient to avoid '-fcheck-pointer-bounds' for nonc-C files when you work with mixed codes. To handle it I may use langhooks and ignore '-fcheck-pointer-bounds' when it's not supported for used language.
[Bug tree-optimization/64091] [5 Regression] ICE in update_debug_stmt, at tree-ssa-tail-merge.c:1620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64091 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- We have this debug bind statement: # DEBUG b = NULL then we iterate on its SSA_OP_USEs, but USE_FROM_PTR is a debug_expr_decl (D#1), not a ssa_name.
[Bug lto/63704] -flto internal compiler error: in mems_in_disjoint_alias_sets_p, at alias.c:398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63704 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug lto/63704] -flto internal compiler error: in mems_in_disjoint_alias_sets_p, at alias.c:398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63704 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Nov 27 09:51:32 2014 New Revision: 218114 URL: https://gcc.gnu.org/viewcvs?rev=218114root=gccview=rev Log: 2014-11-27 Richard Biener rguent...@suse.de PR middle-end/63704 * alias.c (mems_in_disjoint_alias_sets_p): Remove assert and instead return false when !fstrict-aliasing. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c
[Bug middle-end/64083] [5 Regression] ICE: in fix_loop_structure, at loop-init.c:252 compiling Linux Kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64083 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Nov 27 09:57:13 2014 New Revision: 218115 URL: https://gcc.gnu.org/viewcvs?rev=218115root=gccview=rev Log: 2014-11-27 Richard Biener rguent...@suse.de PR tree-optimization/64083 * tree-ssa-threadupdate.c (thread_through_all_blocks): Do not forcibly mark loop for removal the wrong way. * gcc.dg/torture/pr64083.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr64083.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug middle-end/64083] [5 Regression] ICE: in fix_loop_structure, at loop-init.c:252 compiling Linux Kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64083 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 ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org --- You also get to measure memory / cache behavior. The default grid size was (in the past ...) set to make sure we hit main memory, nowadays it's more like on the order of the size of L2 (or L3) caches. Once you make the problem smaller via cmdline parameters you can see the optimization effects more (ideally tramp3d ran on a cluster with MPI parallelization and on the node OpenMP enabled with each thread running fully inside the L3 cache - back in times Itanic was really great here with its gigantic L3/L4 caches). On an old iCore5 I see trunk outperforming 4.9 with just using -Ofast now (with generic tuning). The most important thing to make sure when optimizing is that no calls should survive in all the hot triple-nested loops and the innermost loop should look fast ;) The loops are in functions with symbols with the pattern *EvaluateLocLoop*runEv, for example _ZN14MultiArgKernelI9MultiArg2I5FieldI22UniformRectilinearMeshI10MeshTraitsILi3Ed21UniformRectilinearTag12CartesianTagLi3EEEd10BrickViewUES9_E15EvaluateLocLoopIN4Adv51Z7DensupdILi3EEELi3EEE3runEv (unfortunately the pattern matches on very many unrelated functions as well...) Note that we seem to vectorize the innermost loops now (yay!) but peel them for alignment (ugh - the prologue won't make things better - the innermost loops run only 64 iterations and thus 32 vector iterations by default). And then we of course have the epilogue for the remaining iteration. Luckily we peel both epilogue and prologue (both have at most 1 iteration with V2DF vectors). Code generated for trunk and 4.9 is almost the same for a few cases I looked at. And I think the performance to compare to is that with compiling with -Dleafify=flatten (which makes sure to do all the desired inlining very early). On my machine with flatten enabled its even a little slower. The graphs on gcc.opensuse.org show the regression is fixed as well (though compile-time had quite a surge). Thus I think we can close this as fixed.
[Bug tree-optimization/64091] [5 Regression] ICE in update_debug_stmt, at tree-ssa-tail-merge.c:1620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64091 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Ah, if we previously had multiple uses on the stmt we break the iterator by doing gimple_debug_bind_reset_value (stmt); update_stmt (stmt); but not terminating the walk. Testing a fix.
[Bug target/59593] [arm big-endian] using ldrh access a immediate which stored in a memory by word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59593 --- Comment #5 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Thu Nov 27 11:00:15 2014 New Revision: 218118 URL: https://gcc.gnu.org/viewcvs?rev=218118root=gccview=rev Log: 2014-11-27 Thomas Preud'homme thomas.preudho...@arm.com gcc/ PR target/59593 * config/arm/arm.c (dump_minipool): dispatch to consttable pattern based on mode size. * config/arm/arm.md (consttable_1): Move from config/arm/thumb1.md and make it TARGET_EITHER. (consttable_2): Move from config/arm/thumb1.md, make it TARGET_EITHER and move HFmode handling from consttable_4 to it. (consttable_4): Move HFmode handling to consttable_2 pattern. * config/arm/thumb1.md (consttable_1): Move to config/arm/arm.md. (consttable_2): Ditto. gcc/testsuite/ PR target/59593 * gcc.target/arm/constant-pool.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/constant-pool.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/thumb1.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64091] [5 Regression] ICE in update_debug_stmt, at tree-ssa-tail-merge.c:1620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64091 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Same issue on the 4.9 and 4.8 branches.
[Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Nov 27 11:02:02 2014 New Revision: 218119 URL: https://gcc.gnu.org/viewcvs?rev=218119root=gccview=rev Log: PR lto/64025 * alias.c (find_base_term): Use std::swap. Prefer tmp2 if it is CONSTANT_P other than CONST_INT. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c
[Bug tree-optimization/64024] [5 Regression] gcc.dg/vect/vect-simd-clone-6.c ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64024
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Thu Nov 27 11:03:12 2014
New Revision: 218120
URL: https://gcc.gnu.org/viewcvs?rev=218120root=gccview=rev
Log:
PR tree-optimization/64024
* tree-vectorizer.h (struct _stmt_vec_info): Remove simd_clone_fndecl
field. Add simd_clone_info field.
(STMT_VINFO_SIMD_CLONE_FNDECL): Remove.
(STMT_VINFO_SIMD_CLONE_INFO): Define.
* tree-vect-stmts.c (vectorizable_simd_clone_call): Adjust for
STMT_VINFO_SIMD_CLONE_FNDECL becoming first element of
STMT_VINFO_SIMD_CLONE_INFO vector. For linear arguments, remember
base and linear_step from analysis phase and use it during transform
phase, biased by the difference between LOOP_VINFO_NITERS{_UNCHANGED,}
multiplied by linear_step.
(free_stmt_vec_info): Release STMT_VINFO_SIMD_CLONE_INFO.
* gcc.dg/vect/vect-simd-clone-13.c: New test.
* gcc.dg/vect/vect-simd-clone-14.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-13.c
trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-14.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h
[Bug middle-end/64067] [4.8/4.9/5 Regression] ICE in expand_expr_real_1, at expr.c:10540, involving compound literal shenanigans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64067 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Nov 27 11:04:16 2014 New Revision: 218121 URL: https://gcc.gnu.org/viewcvs?rev=218121root=gccview=rev Log: PR middle-end/64067 * expr.c (expand_expr_addr_expr_1) case COMPOUND_LITERAL_EXPR: Handle it by returning address of COMPOUND_LITERAL_EXPR_DECL not only if modifier is EXPAND_INITIALIZER, but whenever COMPOUND_LITERAL_EXPR_DECL is non-NULL and TREE_STATIC. * gcc.c-torture/compile/pr64067.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr64067.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/64093] New: [5 Regression] ICE error: unrecognizable insn with -mcpu=cell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64093
Bug ID: 64093
Summary: [5 Regression] ICE error: unrecognizable insn with
-mcpu=cell
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Trying to build an allyesconfig Linux kernel with -O2:
trippels@gcc2-power8 linux-3.17.2 % cat prom.i
int a;
void
fn1 ()
{
for (;;)
if (a 1 || a 8)
continue;
}
trippels@gcc2-power8 linux-3.17.2 % gcc -c -O2 -mcpu=cell prom.i
prom.i: In function ‘fn1’:
prom.i:8:1: error: unrecognizable insn:
}
^
(insn 7 6 8 2 (parallel [
(set (reg:SI 159)
(and:SI (reg:SI 160)
(const_int 9 [0x9])))
(clobber (scratch:CC))
]) -1
(nil))
prom.i:8:1: internal compiler error: in extract_insn, at recog.c:2327
0x1073f7ab _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x1073f817 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0x10705f87 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2327
0x1048312b instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1582
0x1048312b instantiate_virtual_regs
../../gcc/gcc/function.c:1950
0x1048312b execute
../../gcc/gcc/function.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/64093] [5 Regression] ICE error: unrecognizable insn with -mcpu=cell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64093
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Try this patch:
Index: rs6000.md
===
--- rs6000.md(revision 218072)
+++ rs6000.md(working copy)
@@ -2644,7 +2644,8 @@ (define_expand andmode3
}
if (logical_const_operand (operands[2], MODEmode)
- !any_mask_operand (operands[2], MODEmode))
+ !any_mask_operand (operands[2], MODEmode)
+ rs6000_gen_cell_microcode)
{
emit_insn (gen_andmode3_imm (operands[0], operands[1], operands[2]));
DONE;
[Bug pending/64094] New: No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 Bug ID: 64094 Summary: No such file or directory - No such file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Hello I saw when main.cpp is not accessible, the standard ENOENT message No such file or directory is used. However, this is not really accurate, as it was open() that was used to open a file. A file was expected, therefore if GCC could output No such file the message would be clearer. I objdump has this behaviour already: $ objdump -a main2.exe objdump: 'main2.exe': No such file $ gcc --version gcc (GCC) 4.8.3 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -o main main.cpp gcc: error: main.cpp: No such file or directory gcc: fatal error: no input files compilation terminated.
[Bug target/64093] [5 Regression] ICE error: unrecognizable insn with -mcpu=cell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64093
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
Try this patch:
Index: rs6000.md
===
--- rs6000.md (revision 218072)
+++ rs6000.md (working copy)
@@ -2644,7 +2644,8 @@ (define_expand andmode3
}
if (logical_const_operand (operands[2], MODEmode)
- !any_mask_operand (operands[2], MODEmode))
+ !any_mask_operand (operands[2], MODEmode)
+ rs6000_gen_cell_microcode)
{
emit_insn (gen_andmode3_imm (operands[0], operands[1],
operands[2]));
DONE;
This fixes the problem. Thanks.
[Bug target/64093] [5 Regression] ICE error: unrecognizable insn with -mcpu=cell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64093 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Only to hit another issue: arch/powerpc/mm/pgtable.c:208:1: error: unrecognizable insn: } ^ (insn 53 52 54 6 (set (reg:DI 213 [ bits ]) (and:DI (reg/v:DI 180 [ entry ]) (const_int 900 [0x384]))) ./arch/powerpc/include/asm/pgtable-ppc64.h:311 -1 (nil)) arch/powerpc/mm/pgtable.c:208:1: internal compiler error: in extract_insn, at recog.c:2327
[Bug target/64093] [5 Regression] ICE error: unrecognizable insn with -mcpu=cell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64093 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-27 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #3) Only to hit another issue: There are many missing checks for rs6000_gen_cell_microcode now. :(. I had audit this code at one point and fixed all the issues but this was when I submitted the patch for rs6000_gen_cell_microcode and nobody kept this working. I don't enough about cell any more to do the work and really I don't have time to do it either.
[Bug middle-end/64088] [5 Regression] ICE: in fold_abs_const, at fold-const.c:15550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64088 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug rtl-optimization/64087] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in in lra_create_live_ranges, at lra-lives.c:1330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64087 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug bootstrap/64086] [5 Regression] building patched libstdc++ on powerpc64-linux-gnu gets ICE in expand_expr_addr_expr_1, at expr.c:7716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64086 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug target/64074] PowerPC E500: Passing of double parameters not EABI compliant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64074 Florian Miedniak florian.miedniak at web dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Florian Miedniak florian.miedniak at web dot de --- Closing this as won't fix because I assume that there is no intention to change existing behaviour of GCC 4.7.3 (choosing of proper options has been fixed in newer versions of GCC)
[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 27 Nov 2014, jiwang at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Depends on||52563 --- Comment #12 from Jiong Wang jiwang at gcc dot gnu.org --- the root cause why it's not ivopted on AArch64 is because must_check_src_overflow = TYPE_PRECISION (ct) TYPE_PRECISION (type); code above in convert_affine_scev, the input type is sizetype, so DI for 64bit arch, SI for 32bit arch, ct is SI, thus, must_check_src_overflow set to true for 64bit arch, then failed later scev_probably_wraps_p check. And I found similar issue reported back in 2012, at bug 52563. I verified this bug exist on other 64 archs, like mips64, ppc64, x86-64 Richard, on 52563, I see you was working on this, do you have any thoughts on this? See comment #5 of that bug. For 4.8(?) I started on work to relax the type requirements of the offset parameter of POINTER_PLUS_EXPR by abstracting stuff but I didn't get to continue on that work. Basically that we force the offset to 'sizetype' has both correctness issues (for targets where sizetype precision doesn't match Pmode precision) and optimization issues as we lose for example sign information and overflow knowledge in the computation of the offset. The last thing is also because we have transforms in fold which push typecasts of expressions down to operands - thus from (sizetype) (4 * i) we get 4 * (sizetype)i which may now be an unsigned multiplication with wrapping overflow. Note that it is the frontends who start the conversion thing and apply some tricks for code-gen (see pointer_int_sum in c-common.c). It's also not clear whether if you write p[i] with i of type int the multiplication by sizeof (*p) invokes undefined behavior if it wraps (that is, the C standard does not define the type the multiplication is performed in but just defines things in terms of array elements). Ideally we'd use a widening multiplication here but optimizers have little knowledge of that so it probably would cause quite some regressions. We could also keep the multiplication signed (but using ssizetype), but then fold will come along and undo that trick IIRC. That said, both the POINTER_PLUS_EXPR constraints on the offset type _and_ the C language issue with int * sizeof (element) overflowing for 64bit pointer sizes prevent us from optimizing this. It's a very tricky area ;)
[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 27 Nov 2014, rguenther at suse dot de wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 27 Nov 2014, jiwang at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Depends on||52563 --- Comment #12 from Jiong Wang jiwang at gcc dot gnu.org --- the root cause why it's not ivopted on AArch64 is because must_check_src_overflow = TYPE_PRECISION (ct) TYPE_PRECISION (type); code above in convert_affine_scev, the input type is sizetype, so DI for 64bit arch, SI for 32bit arch, ct is SI, thus, must_check_src_overflow set to true for 64bit arch, then failed later scev_probably_wraps_p check. And I found similar issue reported back in 2012, at bug 52563. I verified this bug exist on other 64 archs, like mips64, ppc64, x86-64 Richard, on 52563, I see you was working on this, do you have any thoughts on this? See comment #5 of that bug. For 4.8(?) I started on work to relax the type requirements of the offset parameter of POINTER_PLUS_EXPR by abstracting stuff but I didn't get to continue on that work. Basically that we force the offset to 'sizetype' has both correctness issues (for targets where sizetype precision doesn't match Pmode precision) and optimization issues as we lose for example sign information and overflow knowledge in the computation of the offset. The last thing is also because we have transforms in fold which push typecasts of expressions down to operands - thus from (sizetype) (4 * i) we get 4 * (sizetype)i which may now be an unsigned multiplication with wrapping overflow. Note that it is the frontends who start the conversion thing and apply some tricks for code-gen (see pointer_int_sum in c-common.c). It's also not clear whether if you write p[i] with i of type int the multiplication by sizeof (*p) invokes undefined behavior if it wraps (that is, the C standard does not define the type the multiplication is performed in but just defines things in terms of array elements). Ideally we'd use a widening multiplication here but optimizers have little knowledge of that so it probably would cause quite some regressions. We could also keep the multiplication signed (but using ssizetype), but then fold will come along and undo that trick IIRC. That said, both the POINTER_PLUS_EXPR constraints on the offset type _and_ the C language issue with int * sizeof (element) overflowing for 64bit pointer sizes prevent us from optimizing this. It's a very tricky area ;) A related part of code to pointer_int_sum is get_inner_reference. If you do Index: gcc/expr.c === --- gcc/expr.c (revision 218121) +++ gcc/expr.c (working copy) @@ -6852,9 +6852,10 @@ get_inner_reference (tree exp, HOST_WIDE index, low_bound); offset = size_binop (PLUS_EXPR, offset, +fold_convert (sizetype, size_binop (MULT_EXPR, -fold_convert (sizetype, index), -unit_size)); +fold_convert (ssizetype, index), +fold_convert (ssizetype, unit_size; } break; thus compute index * size multiplication in a signed type and then only convert the result back to unsigned then it for example improves the testcase in PR52563 comment #4 in the following way: .L5: - movq%rdx, %rcx - movq%rax, %r8 - movl$100, (%rax) - addq%rdi, %rdx - addq%rsi, %rax - cmpq$999, %rcx + movl$100, a(,%rax,4) + addq%rdi, %rax + movq%rdx, %rsi + addq%rcx, %rdx + cmpq$999, %rax jle .L5 not sure if that's really faster in the end though, but IVOPTs does its job in that case. Now you need to argue that doing that is safe - the change does two things. 1) we interpret 'index' as signed 2) we say the multiplication does not overflow that would break for example unsigned long i = 0x8000UL; int a[1]; a[i] = 0; as i * 4 overflows to 0 and thus the access is valid. Of course accessing the element 0x8000UL of an array of size 1 invokes undefined behavior. Now you get to prove that there is no case that breaks where it
[Bug driver/64094] No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-27 CC||manu at gcc dot gnu.org Component|pending |driver Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Can you figure out using GDB where the error comes from? I guess somewhere in gcc.c.
[Bug c++/63904] ICE when accessing array member of constexpr struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63904 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Thu Nov 27 12:56:58 2014 New Revision: 218122 URL: https://gcc.gnu.org/viewcvs?rev=218122root=gccview=rev Log: PR c++/63904 * g++.dg/cpp0x/pr63904.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr63904.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/63904] ICE when accessing array member of constexpr struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63904 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Thu Nov 27 13:02:45 2014 New Revision: 218123 URL: https://gcc.gnu.org/viewcvs?rev=218123root=gccview=rev Log: 2014-11-27 Kai Tietz kti...@redhat.com PR c++/63904 * constexpr.c (cxx_eval_vec_init_1): Avoid type-overflow issue. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 63904, which changed state. Bug 63904 Summary: ICE when accessing array member of constexpr struct https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63904 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/63904] ICE when accessing array member of constexpr struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63904 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- So fixed.
[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #15 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #14) I'd be happy to approve such a change - maybe you can check if it helps you and whether it passes testing and enough benchmarks? (there is still the related code in pointer_int_sum which should be adjusted accordingly) thanks for these explanation and information. Need some time to digest :) Sure, I will test it and check benchmarks.
[Bug driver/64094] No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 Harald van Dijk harald at gigawatt dot nl changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #2 from Harald van Dijk harald at gigawatt dot nl --- GCC uses strerror (indirectly) for printing error messages, through the use of %m with vfprintf. This is done in many separate locations. binutils has special cases in the form of (if ENOENT then print custom message else print system error). The GNU Coding Standards (http://www.gnu.org/prep/standards/html_node/Semantics.html) say: Include the system error text (from perror, strerror, or equivalent) in every error message resulting from a failing system call, as well as the name of the file if any and the name of the utility. I do not personally care either way, but GCC's error message is in line with those coding standards, and binutils's error message is not (even if it may be in line with the intent of those coding standards, I make no comment on that). Perhaps either GCC should be left as it is now, or if those coding standards do not correctly reflect the intent, they should be changed first?
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #16 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Thu Nov 27 13:58:35 2014 New Revision: 218126 URL: https://gcc.gnu.org/viewcvs?rev=218126root=gccview=rev Log: 2014-11-13 Thomas Preud'homme thomas.preudho...@arm.com Backport from mainline 2014-09-10 Tony Wang tony.w...@arm.com PR target/56846 * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Return with CONTINUE_UNWINDING when the state pattern contains: _US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/libsupc++/eh_personality.cc
[Bug driver/64094] No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- No such file or directory is a familiar, recognizable error message, and is automatically translated through libc. Is the required complexity for this special case really worth it?
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #17 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Thu Nov 27 14:10:10 2014 New Revision: 218127 URL: https://gcc.gnu.org/viewcvs?rev=218127root=gccview=rev Log: 2014-11-27 Thomas Preud'homme thomas.preudho...@arm.com Backport from mainline 2014-09-10 Tony Wang tony.w...@arm.com PR target/56846 * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Return with CONTINUE_UNWINDING when the state pattern contains: _US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_personality.cc
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Martin Liška from comment #2) There's a pair of functions 'g' and 'h' that are proved by IPA ICF to be equal Side remark: In terms of the Fortran standard, g() and h() are different in two regards: g()'s x can alias with other variables (pointers or nonpointers with target attribute) - and g()'s x itself can be a NULL pointer while for f(), it can't. [Would it help to mark the argument of h() with a nonnull attribute?] Side remark 2: I think the test case is not fully right. g()'s call check (x) is invalid if x is NULL as check's x is neither OPTIONAL nor a POINTER. In terms of the generated code, I think this shouldn't matter in this case.
[Bug driver/64094] No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- My preference would be a gnulib/glibc/libiberty function that all GNU utilities could use to give more precise error messages (open_strerror(int errnum, int flags)?). Then, perhaps update the Coding Standards to recommend the use of the function. Then, use it in GCC and binutils for consistency (and to avoid translating the same string for each project). The benefit may seem minor to many people (and I guess all existing GCC devs have things to work on that they consider much more crucial). However, somebody went through all the trouble to report a bug, so I would not want to discourage anyone from going ahead and do whatever is needed. Maybe then they will decide to tackle other problems with GCC/binutils (there are plenty to choose from, and help is always welcome). I would like to encourage people to work on GCC, even if, to me, the benefit does not compensate the effort, they may have other priorities. A good example of this is: https://gcc.gnu.org/ml/gcc/2014-10/msg00104.html where someone proposed a controversial change, but a path forward to a solution was offered. That person followed up and a patch is almost ready to be merged: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00845.html
[Bug middle-end/64088] [5 Regression] ICE: in fold_abs_const, at fold-const.c:15550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64088 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Nov 27 14:22:29 2014 New Revision: 218128 URL: https://gcc.gnu.org/viewcvs?rev=218128root=gccview=rev Log: 2014-11-27 Richard Biener rguent...@suse.de PR middle-end/64088 * fold-const.c (const_unop): Re-instantiate missing condition before calling fold_abs_const. * gcc.dg/torture/pr64088.c: New testcase. PR tree-optimization/64088 * tree-ssa-tail-merge.c (update_debug_stmt): After resetting the stmt break from the loop over use operands. * gcc.dg/torture/pr64091.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr64088.c trunk/gcc/testsuite/gcc.dg/torture/pr64091.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug middle-end/64088] [5 Regression] ICE: in fold_abs_const, at fold-const.c:15550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64088 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 tree-optimization/64091] [5 Regression] ICE in update_debug_stmt, at tree-ssa-tail-merge.c:1620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64091 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/63424] [4.9 regression] Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-27 CC||ramana at gcc dot gnu.org Known to work||4.8.3 Version|5.0 |4.9.0 Assignee|unassigned at gcc dot gnu.org |renlin.li at arm dot com Target Milestone|--- |4.9.3 Summary|Octave -O3 build: internal |[4.9 regression] Octave -O3 |compiler error: in |build: internal compiler |prepare_cmp_insn, at|error: in prepare_cmp_insn, |optabs.c:4237 |at optabs.c:4237 Ever confirmed|0 |1 Known to fail||4.9.0, 4.9.1, 4.9.2 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Renlin - can you ask for a 4.9 backport as well. This is a regression from 4.8 in 4.9 now. Fixed on trunk currently.
[Bug target/63634] Compiler generated R_AARCH64_TLSLE_ADD_TPREL_HI12/LO12 pair overflowed by large TP offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63634 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-27 CC||ramana at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |renlin.li at arm dot com Ever confirmed|0 |1
[Bug middle-end/62178] [5.0 regression] [AArch64] Performance regression on matrix matrix multiply due to r211211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/64009] ICE when compiling pr48335-2.c with armeb-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64009 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-27 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.0
[Bug target/64011] Fail to compile pr48335-2.c on big-endian aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64011 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-27 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.0
[Bug c++/64095] New: [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095
Bug ID: 64095
Summary: [C++14] Ellipsis at end of generic lambda
parameter-declaration-clause should be parsed as a
parameter pack
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot co.uk
void f() { [](auto...){}(); }
prog.cc: In function 'void f()':
prog.cc:1:26: error: no match for call to '(f()::lambda(auto:1, ...)) ()'
void f() { [](auto...){}(); }
^
prog.cc:1:13: note: candidate is:
void f() { [](auto...){}(); }
^
prog.cc:1:22: note: templateclass auto:1 f()::lambda(auto:1, ...)
void f() { [](auto...){}(); }
^
prog.cc:1:22: note: template argument deduction/substitution failed:
prog.cc:1:26: note: candidate expects 1 argument, 0 provided
void f() { [](auto...){}(); }
^
According to [dcl.fct]/14 the ellipsis should be parsed as part of the
abstract-declarator; however gcc parses it as part of the
parameter-declaration-clause.
Clang is similarly incorrect; according to
http://www.reddit.com/r/cpp/comments/2nkcvi/generic_lambda_inconsistency/ MSVC
(latest CTP) is correct.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #25 from Martin Liška marxin at gcc dot gnu.org ---
There's updated version of Honza's patch that fixes testcase instroduced in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573#c23:
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index d4864ae..0036f15 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1617,8 +1617,12 @@ remap_gimple_stmt (gimple stmt, copy_body_data *id)
/* Clear flags that need revisiting. */
if (gcall *call_stmt = dyn_cast gcall * (copy))
-if (gimple_call_tail_p (call_stmt))
- gimple_call_set_tail (call_stmt, false);
+{
+ if (gimple_call_tail_p (call_stmt))
+gimple_call_set_tail (call_stmt, false);
+ if (gimple_call_from_thunk_p (call_stmt))
+gimple_call_set_from_thunk (call_stmt, false);
+}
/* Remap the region numbers for __builtin_eh_{pointer,filter},
RESX and EH_DISPATCH. */
Honza, can we commit this hunk?
Thanks,
Martin
[Bug bootstrap/64086] [5 Regression] building patched libstdc++ on powerpc64-linux-gnu gets ICE in expand_expr_addr_expr_1, at expr.c:7716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64086 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška marxin at gcc dot gnu.org --- Duplicate. *** This bug has been marked as a duplicate of bug 63573 ***
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #26 from Martin Liška marxin at gcc dot gnu.org --- *** Bug 64086 has been marked as a duplicate of this bug. ***
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #27 from Martin Liška marxin at gcc dot gnu.org --- Reopened.
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #26 from Dominique d'Humieres dominiq at lps dot ens.fr --- I proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02832.html I have this patch in my working tree as well as the patch at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02838.html and the regression is gone (x86_64-apple-darwin14).
[Bug libstdc++/64096] New: std::list, set and map violate a rule about allocator::construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64096
Bug ID: 64096
Summary: std::list, set and map violate a rule about
allocator::construct
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: palpatin91 at mail dot ru
According to the 23.2.1p3 C++11 Standard:
===
For the components affected by this subclause that declare an allocator_type,
objects stored in these components shall be constructed using the
allocator_traitsallocator_type::construct function and destroyed using the
allocator_traitsallocator_type::destroy function (20.6.8.2). These functions
are called only for the container’s element type, not for internal types used
by the container. [ Note: This means, for example, that a node-based container
might need to construct nodes containing aligned buffers and call construct to
place the element into the buffer. —end note ]
===
Here allocator_type is a direct template's type argument, and allocator_traits
just call allocator's construct method, if it exists. However, std::list, set
and map (and also multiset and multimap) violate this rule and call construct
method from an allocator of rebinded type, not of an original one. I know, that
we need rebinding for memory allocation, but for construct call we should use
original one. 23.2.1p13 also proves this:
===
Given a container type X having an allocator_type identical to A and a
value_type identical to T and given an lvalue m of type A, a pointer p of type
T*, an expression v of type T, and an rvalue rv of type T, the following terms
are defined. (If X is not allocator-aware, the terms below are defined as if A
were std::allocatorT.)
— T is CopyInsertable into X means that the following expression is
well-formed: allocator_traitsA::construct(m, p, v);
— T is MoveInsertable into X means that the following expression is
well-formed: allocator_traitsA::construct(m, p, rv);
— T is EmplaceConstructible into X from args, for zero or more arguments args,
means that the following expression is well-formed:
allocator_traitsA::construct(m, p, args);
===
Now some code that confirms a bug:
===
#include vector
#include list
#include set
#include map
#include unordered_set
#include unordered_map
#include type_traits
templatetypename T
struct my_allocator : public std::allocatorT {
my_allocator() noexcept {}
templatetypename U
my_allocator(const my_allocatorU source) noexcept
: std::allocatorT(source) {}
templatetypename U
struct rebind {
using other = my_allocatorU;
};
templatetypename U, typename... Args
void construct(U*, Args...) {
static_assert(!std::is_sameU, U::value, Wrong construct);
}
};
template typename T, typename U
bool operator==(const my_allocatorT, const my_allocatorU)
{ return true; }
template typename T, typename U
bool operator!=(const my_allocatorT, const my_allocatorU)
{ return false; }
template
struct my_allocatorint : public std::allocatorint {
my_allocator() noexcept {}
templatetypename U
my_allocator(const my_allocatorU source) noexcept
: std::allocatorint(source) {}
templatetypename U
struct rebind {
using other = my_allocatorU;
};
};
using map_int_int_value_type = std::mapint, int::value_type;
template
struct my_allocatormap_int_int_value_type
: public std::allocatormap_int_int_value_type {
my_allocator() noexcept {}
templatetypename U
my_allocator(const my_allocatorU source) noexcept
: std::allocatormap_int_int_value_type(source) {}
templatetypename U
struct rebind {
using other = my_allocatorU;
};
};
int main()
{
{
using container = std::vectorint, my_allocatorint;
container c;
c.emplace_back(0);
}
{
using container = std::listint, my_allocatorint;
container c;
c.emplace_back(0);
}
{
using container = std::setint, std::lessint, my_allocatorint;
container c;
c.emplace(0);
}
{
using container = std::multisetint, std::lessint,
my_allocatorint;
container c;
c.emplace(0);
}
{
using container = std::unordered_setint, std::hashint,
std::equal_toint, my_allocatorint;
container c;
c.emplace(0);
}
{
using container = std::unordered_multisetint, std::hashint,
std::equal_toint, my_allocatorint;
container c;
c.emplace(0);
}
{
using container = std::mapint, int, std::lessint,
my_allocatormap_int_int_value_type;
[Bug middle-end/64032] [5 Regression] FAIL: gcc.dg/undefined-loop-2.c (test for warnings, line 18)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032 --- Comment #2 from Andrew Stubbs ams at gcc dot gnu.org --- When I configure for powerpc-linux-gnu, undefined-loop-2.c.003t.original contains this: if (((p != 0 ? (unsigned char) array1[i] != 0 : (unsigned char) array2[i] != 0) i = 4) i = 99) goto D.2332; else goto D.2334; When I configure for x86_64-linux-gnu, the same command and dump file contains this: if ((p != 0 ? (signed char) array1[i] != 0 : (signed char) array2[i] != 0) i = 4) goto D.1837; else goto D.1839; It looks like something has started optimizing the code really very early. This surprises me!
[Bug target/64093] [5 Regression] ICE error: unrecognizable insn with -mcpu=cell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64093 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #5 from Segher Boessenkool segher at gcc dot gnu.org --- (In reply to #c3) That is because the patch in #c1 is incorrect. Mine.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #28 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Martin Liška from comment #25)
There's updated version of Honza's patch that fixes testcase instroduced in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573#c23:
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index d4864ae..0036f15 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1617,8 +1617,12 @@ remap_gimple_stmt (gimple stmt, copy_body_data *id)
/* Clear flags that need revisiting. */
if (gcall *call_stmt = dyn_cast gcall * (copy))
- if (gimple_call_tail_p (call_stmt))
- gimple_call_set_tail (call_stmt, false);
+{
+ if (gimple_call_tail_p (call_stmt))
+ gimple_call_set_tail (call_stmt, false);
+ if (gimple_call_from_thunk_p (call_stmt))
+ gimple_call_set_from_thunk (call_stmt, false);
+ }
/* Remap the region numbers for __builtin_eh_{pointer,filter},
RESX and EH_DISPATCH. */
This fixes the ICE I'm seeing
[Bug c++/64077] dynamic_cast incorrectly rejected for private base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64077 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Andrew Dixie from comment #2) In p5, is inaccessible meant to include friendship relationships granted by the current scope or instead use the explicit public base rules spelt out in p8? p5 discusses the static scenario, while p8 discusses the runtime check. The second part of the patch was implementing the latter, but I now also think this is invalid. I'm not sure whether I understand your argument. Could you construct a code example that makes your point clearer?
[Bug lto/64075] [5 Regression] ICE: in bp_pack_value, at data-streamer.h:106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64075 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Well, then resolving the bug as fixed.
[Bug c++/64077] dynamic_cast incorrectly rejected for private base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64077
Andrew Dixie gcc at dixie dot net.nz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Andrew Dixie gcc at dixie dot net.nz ---
(In reply to Daniel Krügler from comment #3)
Given the reference to core issue 665, I now think the wording and intent of
the standard is clear.
For completeness I've given an example below, but I'm happy this can be closed.
Thanks.
class base { virtual ~base() {} };
class derived : private base {
friend bool t1(derived *);
};
bool t1(derived *x) {
return dynamic_castbase *(x) != 0;
}
If the 'accessible' in p5 includes friendships relationships, then the
dynamic_cast should succeed.
If the 'accessible' in p5 requires a public base (like is required by p8), then
the dynamic cast should fail (or be ill-formed).
I think the wording of the standard clearly specifies succeed.
[Bug target/63833] REAL_PIC_OFFSET_TABLE_REGNUM is wrong for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63833 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-27 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- The psABI http://www.x86-64.org/svn/trunk/x86-64-ABI/ has been fixed.
[Bug target/63833] REAL_PIC_OFFSET_TABLE_REGNUM is wrong for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63833 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Thu Nov 27 21:03:32 2014 New Revision: 218132 URL: https://gcc.gnu.org/viewcvs?rev=218132root=gccview=rev Log: Use R15_REG for REAL_PIC_OFFSET_TABLE_REGNUM PR target/63833 * config/i386/i386.h (REAL_PIC_OFFSET_TABLE_REGNUM): Use R15_REG for 64-bit. * config/i386/rdos64.h (REAL_PIC_OFFSET_TABLE_REGNUM): Removed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/rdos64.h
[Bug c++/64077] dynamic_cast incorrectly rejected for private base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64077 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Andrew Dixie from comment #4) If the 'accessible' in p5 includes friendships relationships, then the dynamic_cast should succeed. Yes, friendship relations need to be considered when accessibility is tested. If the 'accessible' in p5 requires a public base (like is required by p8), then the dynamic cast should fail (or be ill-formed). I think the wording of the standard clearly specifies succeed. Yes.
[Bug target/63833] REAL_PIC_OFFSET_TABLE_REGNUM is wrong for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63833 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-27 Ever confirmed|0 |1
[Bug c++/12277] Warn on dynamic casts with known NULL results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277
Andrew Dixie gcc at dixie dot net.nz changed:
What|Removed |Added
CC||gcc at dixie dot net.nz
--- Comment #7 from Andrew Dixie gcc at dixie dot net.nz ---
With final, I believe the following dynamic_cast must always return NULL:
struct a1 { virtual ~a1() {} };
struct a2 final { virtual ~a2() {} };
bool test(a1 *x)
{
return dynamic_casta2 *(x) != 0;
}
[Bug c++/12277] Warn on dynamic casts with known NULL results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277 --- Comment #8 from Andrew Dixie gcc at dixie dot net.nz --- Created attachment 34130 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34130action=edit dynamic_cast warning
[Bug target/63842] x86-64 large PIC model may load the GOT base into the wrong register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63842 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-27 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- r218132 generates: main: .LFB11: .cfi_startproc .L2: leaq.L2(%rip), %rax movabsq$_GLOBAL_OFFSET_TABLE_-.L2, %r11 movabsq$.LC0@GOTOFF, %rdx pushq%r15 .cfi_def_cfa_offset 16 .cfi_offset 15, -16 addq%r11, %rax leaq(%rax,%rdx), %rdi movabsq$puts@PLTOFF, %rdx movq%rax, %r15 addq%rax, %rdx call*%rdx xorl%eax, %eax popq%r15 .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE11: It looks OK. But it is hard to test without a linker supporting large model PLT. I will leave it open until I finish large model PLT support in binutils so that I can verify it.
[Bug tree-optimization/57249] Unrolling too late for inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57249 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- We probably should simply move cunrolli to early passes and let it to cunroll only when size is going to decrease (i.e. when we know late cunrolli will unroll no matter on the profile).
[Bug fortran/64097] New: Bug with nested WHERE constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64097 Bug ID: 64097 Summary: Bug with nested WHERE constructs Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gmx dot de I encountered a problem with nested WHERE constructs, which I discussed at https://groups.google.com/forum/#!topic/comp.lang.fortran/EG2k49ujggA It appears that the evaluated of inner masks may not be treated (i.e. masked) properly. Example code: % cat nested-where.f90 program nested_where implicit none integer, parameter :: n = 100 real :: x(n), y(n) real :: z = log (0.5) call random_number (x) y = 1 ! Good initialization y = 0 ! Bad initialization print *, count (x == 1) ! Prints 0 where (x 0.5) y = x where (log (y) z) ! The dangerous mask x = 1 end where end where print *, count (x == 1) ! Not reached for y=0 end program nested_where The code works with NAG, PGI and xlf. It throws an FP exception when evaluating the inner (dangerous) mask with GCC, Intel and Crayftn, provided FP exceptions for invalid are enabled. Ian Harvey cited sentence 10 in section 7.2.3.2 of the standard document, which appears to deal with this case.
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
--- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Martin Liška from comment #2)
There's a pair of functions 'g' and 'h' that are proved by IPA ICF to be
equal and thunk is created (darwin does not have alias support).
If you look at the tree dump, h's argument has restrict but not g:
h (struct array7_integer(kind=4) restrict x)
{
check ((struct array7_integer(kind=4) *) x);
}
g (struct array7_integer(kind=4) x)
{
check ((struct array7_integer(kind=4) *) x);
}
Shouldn't that disable semantic equality/equivalence?
[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 --- Comment #3 from Iain Sandoe iains at gcc dot gnu.org --- I'm not disputing that the code is wrong… … and the change that you've put forward looks reasonable. However, I'm not finding it easy to reproduce any failure - I've got a cross from darwin12 = x86-64-linux-gnu with gold-enabled binutils. There's no failure at either build-time or runtime for the liblto plugin. This is not entirely surprising (at least on the host I've tried), since the plugin is linked with -Wl,-undefined,dynamic_lookup. This means that _environ will be resolved from the executable. So I'm interested in how to reproduce the effect you show in c#1
[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED CC||cbaylis at gcc dot gnu.org Resolution|--- |INVALID --- Comment #7 from cbaylis at gcc dot gnu.org --- This is caused by an invalid implementation of memset in (old versions of) the Linux kernel. I investigated this, a longer description is on the Linaro bugzilla at https://bugs.linaro.org/show_bug.cgi?id=928#c7
[Bug libstdc++/64096] std::list, set and map violate a rule about allocator::construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64096 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to rylai from comment #0) As we can see, std::list implementation tries to call construct for whole list node (U = std::_List_nodeint), This is already fixed on the SVN trunk, which will be GCC 5. and std::set and map (and also multiset and multimap) call it for right type (int or std::pairconst int, int), but from rebinded allocator (T = std::_Rb_tree_nodeint). I've discussed this extensively with the main author of the C++11 allocator proposals and other members of the committee. The standard is supposed to allow that, the fact it doesn't is a defect, see http://cplusplus.github.io/LWG/lwg-active.html#2218
[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 Airbak airbak.li at huawei dot com changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|INVALID |FIXED --- Comment #8 from Airbak airbak.li at huawei dot com --- The problem is solved. Thanks.
[Bug c++/64092] when explicit uing synthesized move operation（constructorand assignment operator），synthesize move constructor by calling member‘s copy constructor。
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64092 xbguo guoxiangbin86 at 126 dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from xbguo guoxiangbin86 at 126 dot com --- Thank you very much for your patient explanation, thanks again.
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 java4ada at yahoo dot com changed: What|Removed |Added CC||java4ada at yahoo dot com --- Comment #16 from java4ada at yahoo dot com --- Question: There are ~98 calls to gomp_thread() which allocates struct gomp_thread when HAVE_TLS isn't defined, but only gomp_free_thread() frees this instance. Possible memory leak?
[Bug libstdc++/63497] std::regex can't handle [^class] correctly and cause runtime crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497 --- Comment #8 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Fri Nov 28 06:50:34 2014 New Revision: 218138 URL: https://gcc.gnu.org/viewcvs?rev=218138root=gccview=rev Log: PR libstdc++/63497 include/bits/regex_executor.tcc (_Executor::_M_dfs, _Executor::_M_word_boundary): Avoid dereferecing _M_current at _M_end or other invalid position. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_executor.tcc
