[Bug rtl-optimization/64041] [4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64041 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-24 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.9.3 Summary|wrong code at -O2 and -O3 |[4.9/5 Regression] wrong |on x86_64-linux-gnu |code at -O2 and -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r208831.
[Bug c++/63905] redundant fields left in gcc/cp/cp-tree.h:lang_decl_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63905 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Nov 24 08:36:32 2014 New Revision: 218001 URL: https://gcc.gnu.org/viewcvs?rev=218001root=gccview=rev Log: 2014-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/63905 * cp-tree.h (lang_decl_fn): Remove constructor_attr, destructor_attr. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h
[Bug c++/63905] redundant fields left in gcc/cp/cp-tree.h:lang_decl_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63905 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Done, thanks!
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #16 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 21 Nov 2014, jgreenhalgh at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #15 from jgreenhalgh at gcc dot gnu.org --- I wonder whether the call to can_move_by_pieces in gimplify.c is bogus. It seems to me that gimplify.c really wants to know whether it is a good idea to scalarize the constructor copy - nothing to do with whether we will copy it by pieces or as a block or otherwise. If that is what gimplify.c wants to ask, then we can use the SRA parameters I added last month to get a better answer. The patch would look something like the below, it won't fix this testcase - but it would allow you to revert to the 4.9 behaviour by tweaking the parameter value. It *feels* like the right thing to do, but I don't know the code and I might be wrong. An alternate approach would be to introduce a new target hook which returns true if scalarizing a copy is smarter than leaving it as an aggregate, but that sounds so close to what SRA is supposed to control as to end up indistinguishable from this patch. Any thoughts? Or should I just propose this patch on gcc-patches. (It passes an x86_64 bootstrap with no issues). Certainly removing the alignment is not going to fly - we'd generate very bad code for strict-align targets for initializing packed structs by pieces for example.
[Bug middle-end/28367] accessing via union on a vector does not cause vec_extract to be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28367 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Yeah, something along that line would be needed. The issue is that the partial value is not available (as in: it doesn't have a SSA name) and thus there is nothing to CSE the load to. I suppose that we should generalize this support for real-/imag-part of complex values as well. Not sure if it is worth using BIT_FIELD_REF for getting at pieces of scalar registers (maybe it would pay off for targets that can efficiently compute lowpart subregs).
[Bug sanitizer/64013] [5 Regression] libsanitizer fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed, thanks Dmitry.
[Bug c++/64029] [4.9/5 Regression] const int (in)[]{1,2,3,4,5}; results in internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64029 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.9.3 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r208002. The ICE is because the gimplifier sees a VAR_DECL with const int[unknown] type (incomplete ARRAY_TYPE with no TYPE_SIZE*).
[Bug go/64021] Empty struct vs libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Isn't that just because in C++ empty structs are forced by the FE into having
length of one byte? I mean, if you:
struct S {};
int a = sizeof (struct S);
struct S b;
then in C it is int a = 0; and b is a common with zero size, while in C++ it is
int a = 1; and b has size 1. So it is natural that those two (which are very
much different thing) are passed differently, I don't see anything to change on
that. So, for go, the question is if it follows GNU C or C++ for empty
structs.
[Bug tree-optimization/55334] [4.8/4.9/5 Regression] mgrid regression (ipa-cp disables vectorization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #44 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Nov 24 09:24:26 2014 New Revision: 218004 URL: https://gcc.gnu.org/viewcvs?rev=218004root=gccview=rev Log: 2014-11-24 Richard Biener rguent...@suse.de PR tree-optimization/55334 * function.h (struct function): Add last_clique member. * tree-inline.c (remap_dependence_clique): New function. (remap_gimple_op_r): Remap dependence cliques in MEM_REFs. (copy_tree_body_r): Likewise. (copy_cfg_body): Free dependence map. (copy_gimple_seq_and_replace_locals): Likewise. * tree-pretty-print.c (dump_generic_node): Dump dependence info. * tree-ssa-alias.c (refs_may_alias_p_1): Use dependence info to answer alias query. * tree-ssa-structalias.c: Include tree-phinodes.h, ssa-iterators.h, tree-pretty-print.h and gimple-walk.h. (struct variable_info): Add is_restrict_var flag and ruid member. (new_var_info): Initialize is_restrict_var. (make_constraint_from_restrict): Likewise. (create_variable_info_for): Exclude restricts from global vars from new handling. (intra_create_variable_infos): But not those from parameters. (visit_loadstore): New function. (maybe_set_dependence_info): Likewise. (compute_dependence_clique): Likewise. (compute_may_aliases): Call compute_dependence_clique. * tree-data-ref.c (dr_analyze_indices): Copy dependence info to fake MEM_REF. (dr_may_alias_p): Use recorded dependence info to answer alias query. * tree-core.h (struct tree_base): Add clique, base struct in union. * tree.h (MR_DEPENDENCE_CLIQUE): New macro. (MR_DEPENDENCE_BASE): Likewise. * tree-inline.h (dependence_hasher): New hash-map kind. (struct copy_body_data): Add dependence_map pointer. * gimple-fold.c (maybe_canonicalize_mem_ref_addr): Avoid throwing away dependence info. * tree-streamer-in.c (unpack_value_fields): Stream dependence info. * tree-streamer-out.c (streamer_pack_tree_bitfields): Likewise. * gcc.dg/tree-ssa/restrict-5.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.h trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-core.h trunk/gcc/tree-data-ref.c trunk/gcc/tree-inline.c trunk/gcc/tree-inline.h trunk/gcc/tree-pretty-print.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c trunk/gcc/tree.h
[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] mgrid |mgrid regression (ipa-cp|regression (ipa-cp disables |disables vectorization) |vectorization) --- Comment #46 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/55334] [4.8/4.9/5 Regression] mgrid regression (ipa-cp disables vectorization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #45 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Nov 24 09:24:50 2014 New Revision: 218005 URL: https://gcc.gnu.org/viewcvs?rev=218005root=gccview=rev Log: 2014-11-24 Richard Biener rguent...@suse.de PR tree-optimization/55334 * function.h (struct function): Add last_clique member. * tree-inline.c (remap_dependence_clique): New function. (remap_gimple_op_r): Remap dependence cliques in MEM_REFs. (copy_tree_body_r): Likewise. (copy_cfg_body): Free dependence map. (copy_gimple_seq_and_replace_locals): Likewise. * tree-pretty-print.c (dump_generic_node): Dump dependence info. * tree-ssa-alias.c (refs_may_alias_p_1): Use dependence info to answer alias query. * tree-ssa-structalias.c: Include tree-phinodes.h, ssa-iterators.h, tree-pretty-print.h and gimple-walk.h. (struct variable_info): Add is_restrict_var flag and ruid member. (new_var_info): Initialize is_restrict_var. (make_constraint_from_restrict): Likewise. (create_variable_info_for): Exclude restricts from global vars from new handling. (intra_create_variable_infos): But not those from parameters. (visit_loadstore): New function. (maybe_set_dependence_info): Likewise. (compute_dependence_clique): Likewise. (compute_may_aliases): Call compute_dependence_clique. * tree-data-ref.c (dr_analyze_indices): Copy dependence info to fake MEM_REF. (dr_may_alias_p): Use recorded dependence info to answer alias query. * tree-core.h (struct tree_base): Add clique, base struct in union. * tree.h (MR_DEPENDENCE_CLIQUE): New macro. (MR_DEPENDENCE_BASE): Likewise. * tree-inline.h (dependence_hasher): New hash-map kind. (struct copy_body_data): Add dependence_map pointer. * gimple-fold.c (maybe_canonicalize_mem_ref_addr): Avoid throwing away dependence info. * tree-streamer-in.c (unpack_value_fields): Stream dependence info. * tree-streamer-out.c (streamer_pack_tree_bitfields): Likewise. * gcc.dg/tree-ssa/restrict-5.c: New testcase. Modified: trunk/gcc/tree-ssa-structalias.c
[Bug boehm-gc/64042] New: FAIL: boehm-gc.c/gctest.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 Bug ID: 64042 Summary: FAIL: boehm-gc.c/gctest.c -O2 execution test Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org I run into this failure once. This time, it's when testing a nonbootstrap build from an AFAIU unrelated patch set on top of the gomp-4_0-branch. boehm-gc.log: ... PASS: boehm-gc.c/gctest.c -O2 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/vries/gcc_versions/data/test-devel-oacc-11/with/nobootstrap/build/gcc:/home/vries/gcc_versions/data/test-devel-oac\ c-11/with/nobootstrap/build/gcc/32:/home/vries/gcc_versions/data/test-devel-oacc-11/with/nobootstrap/build/x86_64-unknown-linux-gnu/./boehm-gc/.libs:\ .libs:.:/home/vries/gcc_versions/data/test-devel-oacc-11/with/nobootstrap/build/gcc:/home/vries/gcc_versions/data/test-devel-oacc-11/with/nobootstrap\ /build/gcc/32:/home/vries/gcc_versions/data/test-devel-oacc-11/with/nobootstrap/build/x86_64-unknown-linux-gnu/./boehm-gc/.libs:.libs:/home/vries/gcc\ _versions/infra/lib spawn [open ...]^M Switched to incremental mode Emulating dirty bits with mprotect/signals Segfault at 0x2b2d48936000 Unexpected bus error or segmentation fault FAIL: boehm-gc.c/gctest.c -O2 execution test ... core backtrace: ... Core was generated by `/home/vries/gcc_versions/data/test-devel-oacc-11/with/nobootstrap/build/x86_64-'. Program terminated with signal SIGABRT, Aborted. #0 0x2b2d47c31bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x2b2d47c31bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x2b2d47c34fc8 in __GI_abort () at abort.c:89 #2 0x2b2d47093c59 in GC_abort (msg=msg@entry=0x2b2d4709bb48 Unexpected bus error or segmentation fault) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/misc.c:1081 #3 0x2b2d4709554e in GC_write_fault_handler (sig=optimized out, si=0x2b2d481c06f0, scp=0x2b2d481c05c0) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/os_dep.c:2643 #4 signal handler called #5 GC_typed_mark_proc (addr=0x2b2d48936000, mark_stack_ptr=0x2b2d485e1a00, mark_stack_limit=0x2b2d487dd000, env=4) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/typd_mlc.c:415 #6 0x2b2d47091aeb in GC_mark_from (mark_stack_top=optimized out, mark_stack=0x2b2d485dd000, mark_stack_limit=0x2b2d487dd000) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/mark.c:699 #7 0x2b2d47092be5 in GC_mark_some (cold_gc_frame=cold_gc_frame@entry=0x2b2d481c0c2c ) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/mark.c:361 #8 0x2b2d4708a648 in GC_stopped_mark (stop_func=stop_func@entry=0x2b2d4708a3c0 GC_timeout_stop_func) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/alloc.c:531 #9 0x2b2d4708aeac in GC_maybe_gc () at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/alloc.c:307 #10 0x2b2d4708b81d in GC_allocobj (sz=sz@entry=39, kind=kind@entry=6) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/alloc.c:1073 #11 0x2b2d4708fced in GC_generic_malloc_inner (lb=lb@entry=271, k=k@entry=6) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/malloc.c:136 #12 0x2b2d4708fe24 in GC_generic_malloc (lb=271, k=6) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/malloc.c:192 #13 0x2b2d4709819e in GC_malloc_explicitly_typed (lb=optimized out, d=18446462525718396929) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/typd_mlc.c:653 #14 0x0040363e in typed_test () #15 0x in ?? () ... Investigating the segfault site: ... #4 signal handler called (gdb) up #5 GC_typed_mark_proc (addr=0x2b2d48936000, mark_stack_ptr=0x2b2d485e1a00, mark_stack_limit=0x2b2d487dd000, env=4) at /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/boehm-gc/typd_mlc.c:415 415current = *current_p; (gdb) p current_p $1 = (word *) 0x2b2d48936000 (gdb) p *current_p $2 = 0 (gdb) ...
[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 --- Comment #1 from vries at gcc dot gnu.org --- configure line: ... Target: x86_64-unknown-linux-gnu Configured with: /home/vries/gcc_versions/data/test-devel-oacc-11/with/src/configure --prefix=/home/vries/gcc_versions/data/test-devel-oacc-11/with/nobootstrap/install --with-cloog=/home/vries/gcc_versions/infra --with-ppl=/home/vries/gcc_versions/infra --with-gmp=/home/vries/gcc_versions/infra --with-mpfr=/home/vries/gcc_versions/infra --with-mpc=/home/vries/gcc_versions/infra --disable-bootstrap --enable-checking=yes,rtl --enable-languages=c,fortran,ada,java,objc,c++ Thread model: posix ...
[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 --- Comment #2 from vries at gcc dot gnu.org --- Googling the sigsegv site GC_typed_mark_proc finds these threads, which may be related: - http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2010-March/003796.html - http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2010-March/003799.html
[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-11-24 CC||ebotcazou at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I don't think fcaller-save made it into 4.9. You're confusing -fcaller-saves and -fuse-caller-saves here.
[Bug go/64021] Empty struct vs libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
--- Comment #6 from Richard Henderson rth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
Isn't that just because in C++ empty structs are forced by the FE into
having length of one byte?
Yes, of course.
I mean, if you:
struct S {};
int a = sizeof (struct S);
struct S b;
then in C it is int a = 0; and b is a common with zero size...
The zero-sized data thing is a rather useless GCC extension, IMO.
If you use -pedantic you will of course error out.
So, for go, the question is if it follows GNU C or C++ for
empty structs.
Since Go doesn't really have pointers in the usual sense, it's
difficult to ask the question a[1] != a[2]. Which *must* be
false for C++ and will be true for the GCC extension.
This does need a Go expert to figure out if there's another case
which can be determined from the language level.
[Bug lto/64043] New: [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 Bug ID: 64043 Summary: [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914 Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Created attachment 34087 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34087action=edit Test case (unpack, run make) Using GCC 5.0.0 20141121, the attached program fails with the following ICE. To reproduce: Unpack and hit make. It will compile one.ii and two.ii and gcc-ar them to libonetwo.ii; it compiles three.ii - and then LTOs them together. (Requires an LD with plugin capabilities; I've put the git version of binutils into the path.) The failure is: 0xa36e4f crash_signal ../../gcc/toplev.c:359 0xc97211 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:2758 0xc97211 get_binfo_at_offset(tree_node*, long, tree_node*) ../../gcc/tree.c:11914 0x884cf4 possible_polymorphic_call_targets(tree_node*, long, ipa_polymorphic_call_context, bool*, void**, bool) ../../gcc/ipa-devirt.c:2404 0x7ef9d7 possible_polymorphic_call_targets(tree_node*, gimple_statement_base*, bool*, void**) ../../gcc/ipa-utils.h:126 0x7edcd0 gimple_fold_call ../../gcc/gimple-fold.c:2667 0x7edcd0 fold_stmt_1 ../../gcc/gimple-fold.c:3246 0xb55323 execute ../../gcc/tree-ssa-forwprop.c:2228
[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 --- Comment #3 from vries at gcc dot gnu.org --- I run into this failure once. I meant: I run into this failure once in a while. It's sort of reproducible. In running the testcase a thousand times, it triggered 3 times: ... Segfault at 0x7f088a81f000 Unexpected bus error or segmentation fault Segfault at 0x7febfdf73000 Unexpected bus error or segmentation fault Segfault at 0x7f0af403c000 Unexpected bus error or segmentation fault ...
[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška marxin at gcc dot gnu.org --- Fixed.
[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968 --- Comment #7 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Mon Nov 24 10:25:06 2014 New Revision: 218006 URL: https://gcc.gnu.org/viewcvs?rev=218006root=gccview=rev Log: PR lto/63968 * bb-reorder.c (find_traces_1_round): decreate_key is replaced with replace_key method. * fibonacci_heap.h (fibonacci_heap::insert): New argument. (fibonacci_heap::replace_key_data): Likewise. (fibonacci_heap::replace_key): New method that can even increment key, this operation costs O(log N). (fibonacci_heap::extract_min): New argument. (fibonacci_heap::delete_node): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c trunk/gcc/fibonacci_heap.h
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-11-24
CC||trippels at gcc dot gnu.org
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
This is a case of -O0 vs -O2 (during final link):
Further reduced:
markus@x4 testcase % cat one.ii
class Validator
{
public:
virtual ~Validator ();
};
class FooWriter
{
Validator *validator;
~FooWriter ();
};
FooWriter::~FooWriter () { delete validator; }
markus@x4 testcase % g++ -flto -std=c++11 -c one.ii
markus@x4 testcase % g++ -r -nostdlib -O2 -flto one.o
one.ii: In member function ‘__base_dtor ’:
one.ii:11:1: internal compiler error: Segmentation fault
FooWriter::~FooWriter () { delete validator; }
^
0x9dc45f crash_signal
../../gcc/gcc/toplev.c:359
0xc3f211 tree_check
../../gcc/gcc/tree.h:2758
0xc3f211 get_binfo_at_offset(tree_node*, long, tree_node*)
../../gcc/gcc/tree.c:11914
0x82855b possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/gcc/ipa-devirt.c:2404
0x792a2f possible_polymorphic_call_targets(tree_node*, gimple_statement_base*,
bool*, void**)
../../gcc/gcc/ipa-utils.h:126
0x790c4a gimple_fold_call
../../gcc/gcc/gimple-fold.c:2667
0x790c4a fold_stmt_1
../../gcc/gcc/gimple-fold.c:3246
0xafb1a3 execute
../../gcc/gcc/tree-ssa-forwprop.c:2228
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.
lto-wrapper: fatal error: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit
status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug java/64044] New: Java emits bogus .class$ decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 Bug ID: 64044 Summary: Java emits bogus .class$ decls Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: aph at gcc dot gnu.org Currently the Java FE is lucky that not all -findirect-dispatch testcases are miscompiled as gimple-fold.c:get_symbol_constant_value has /* Variables declared 'const' without an initializer have zero as the initializer if they may not be overridden at link or run time. */ if (!val (INTEGRAL_TYPE_P (TREE_TYPE (sym)) || SCALAR_FLOAT_TYPE_P (TREE_TYPE (sym return build_zero_cst (TREE_TYPE (sym)); which for unkown reason avoids to fold the reads from .class$ at the beginning of all functions to NULL (because the above doesn't allow pointer types). I ran into this when doing the same during value-numbering but forgetting to paper over the Java FE bug. The Java FE emits (for example) var_decl 0x76c6e360 Array_2.class$ type pointer_type 0x76c69a80 type record_type 0x76c69930 java.lang.Class readonly type_4 BLK size integer_cst 0x76c43858 constant 2240 unit size integer_cst 0x76c43828 constant 280 align 64 symtab 0 alias set -1 canonical type 0x76c69930 fields field_decl 0x76c521c8 D.89 pointer_to_this pointer_type 0x76c699d8 readonly public unsigned DI size integer_cst 0x76c25bb8 constant 64 unit size integer_cst 0x76c25bd0 constant 8 align 64 symtab 0 alias set -1 canonical type 0x76c69a80 pointer_to_this pointer_type 0x76c7f888 readonly constant addressable public static unsigned ignored DI file Array_2.java line 4 col 0 size integer_cst 0x76c25bb8 64 unit size integer_cst 0x76c25bd0 8 align 64 context record_type 0x76c5e540 Array_2 (mem/u/f/c:DI (symbol_ref:DI (_ZN7Array_27class$$E) [flags 0x2] var_decl 0x76c6e360 Array_2.class$) [2 Array_2.class$+0 S8 A64]) which misses an initializer (it seems to be not initialized in .s either, thus the flags on it are wrong? Probably they get initialized by the runtime?).
[Bug java/64044] Java emits bogus .class$ decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Simple patch to reproduce the issue: Index: gcc/gimple-fold.c === --- gcc/gimple-fold.c (revision 218005) +++ gcc/gimple-fold.c (working copy) @@ -255,7 +255,8 @@ get_symbol_constant_value (tree sym) overridden at link or run time. */ if (!val (INTEGRAL_TYPE_P (TREE_TYPE (sym)) - || SCALAR_FLOAT_TYPE_P (TREE_TYPE (sym + || SCALAR_FLOAT_TYPE_P (TREE_TYPE (sym)) + || POINTER_TYPE_P (TREE_TYPE (sym return build_zero_cst (TREE_TYPE (sym)); } it should use is_gimple_reg_type (TREE_TYPE (sym)) in the end.
[Bug java/64044] Java emits bogus .class$ decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 Andrew Haley aph at redhat dot com changed: What|Removed |Added CC||aph at redhat dot com --- Comment #2 from Andrew Haley aph at redhat dot com --- So, is the solution to this trivially not to mark the .class$ decls as TREE_CONST ?
[Bug java/64044] Java emits bogus .class$ decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Suggested fix: Index: gcc/java/class.c === --- gcc/java/class.c(revision 218005) +++ gcc/java/class.c(working copy) @@ -1084,8 +1084,6 @@ build_classdollar_field (tree type) TYPE_QUAL_CONST)), TYPE_QUAL_CONST))); TREE_STATIC (decl) = 1; - TREE_CONSTANT (decl) = 1; - TREE_READONLY (decl) = 1; TREE_PUBLIC (decl) = 1; java_hide_decl (decl); DECL_IGNORED_P (decl) = 1; not sure why it doesn't end up in .rodata.
[Bug fortran/63938] OpenMP atomic update does not protect access to automatic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63938 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.4
[Bug fortran/63938] OpenMP atomic update does not protect access to automatic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63938 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34088 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34088action=edit gcc5-pr63938.patch Untested fix.
[Bug sanitizer/61021] [4.9/5 regression] libsanitizer fails to build with old glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Thus we should have this already in GCC trunk. Does it still fail to build there?
[Bug java/64044] Java emits bogus .class$ decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 24 Nov 2014, aph at redhat dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 Andrew Haley aph at redhat dot com changed: What|Removed |Added CC||aph at redhat dot com --- Comment #2 from Andrew Haley aph at redhat dot com --- So, is the solution to this trivially not to mark the .class$ decls as TREE_CONST ? Yes, see the patch I proposed (in testing right now, I'll post it and ask for approval later today unless you want to pre-approve here)
[Bug ipa/63856] [5 Regression] ICE: verify_gimple failed: invalid argument to gimple call with -O2 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška marxin at gcc dot gnu.org --- Fixed by r217909.
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/64041] [4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64041 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 CC||jamborm at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- It looks similar to the signed/unsigned IPA CP issue.
[Bug testsuite/64039] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized return 28;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64039 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-24 Component|tree-optimization |testsuite Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Summary|FAIL: |[5 Regression] FAIL: |gcc.dg/tree-ssa/ssa-dom-cse |gcc.dg/tree-ssa/ssa-dom-cse |-2.c scan-tree-dump |-2.c scan-tree-dump |optimized return 28; |optimized return 28; Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- a = *L$C; ok, so PA has a similar issue as aarch64 (PR63679), I suppose for those targets we need to XFAIL the test (it's a known missed-optimization tracked in that PR). I'll take care of this.
[Bug testsuite/64039] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized return 28;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64039 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug testsuite/64039] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized return 28;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64039 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Nov 24 11:07:23 2014 New Revision: 218011 URL: https://gcc.gnu.org/viewcvs?rev=218011root=gccview=rev Log: 2014-11-24 Richard Biener rguent...@suse.de PR testsuite/64039 * gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL for hppa*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
[Bug testsuite/64038] [5 Regression] FAIL: gcc.dg/ipa/ipa-icf-5.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64038
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-11-24
Target Milestone|--- |5.0
Summary|FAIL: |[5 Regression] FAIL:
|gcc.dg/ipa/ipa-icf-5.c |gcc.dg/ipa/ipa-icf-5.c
|(test for excess errors)|(test for excess errors)
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Other testcases have (gcc.dg/pr42427.c)
/* { dg-add-options c99_runtime } */
does adding that fix it? Patch pre-approved then.
[Bug target/64037] Miscompilation with LTO and enum class : char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ABI, wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-24 Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.2 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Same issue without -flto but just -Os -fwhole-program. Can also reproduced with just -Os when making 'foo' static. Confirmed.
[Bug rtl-optimization/64033] [5.0 Regression] ICE: in expand_expr_addr_expr_1, at expr.c:7741
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64033 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[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 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-24 Component|c |middle-end CC||ams at gcc dot gnu.org Ever confirmed|0 |1 Summary|FAIL: |[5 Regression] FAIL: |gcc.dg/undefined-loop-2.c |gcc.dg/undefined-loop-2.c |(test for warnings, line|(test for warnings, line |18) |18) Target Milestone|--- |5.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I also see this on x86_64 with -m32.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #17 from Tejas Belagod belagod at gcc dot gnu.org ---
-
/* Do a block move either if the size is so small as to make
each individual move a sub-unit move on average, or if it
-is so large as to make individual moves inefficient. */
+is so large as to make individual moves inefficient. Reuse
+the same costs logic as we use in the SRA passes. */
+unsigned max_scalarization_size
+ = optimize_function_for_size_p (cfun)
+ ? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
+ : PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED);
+
if (size 0
num_nonzero_elements 1
(size num_nonzero_elements
- || !can_move_by_pieces (size, align)))
+ || size max_scalarization_size))
{
if (notify_temp_creation)
return GS_ERROR;
I think both move_by_pieces and SRA can co-exist here:
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 8e3dd83..be51ce7 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -70,6 +70,7 @@ along with GCC; see the file COPYING3. If not see
#include omp-low.h
#include gimple-low.h
#include cilk.h
+#include params.h
#include langhooks-def.h/* FIXME: for lhd_set_decl_assembler_name */
#include tree-pass.h/* FIXME: only for PROP_gimple_any */
@@ -3895,7 +3896,6 @@ gimplify_init_constructor (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
DECL_ATTRIBUTES (current_function_decl
{
HOST_WIDE_INT size = int_size_in_bytes (type);
unsigned int align;
/* ??? We can still get unbounded array types, at least
from the C++ front end. This seems wrong, but attempt
@@ -3907,20 +3907,19 @@ gimplify_init_constructor (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
TREE_TYPE (ctor) = type = TREE_TYPE (object);
}
/* Find the maximum alignment we can assume for the object. */
/* ??? Make use of DECL_OFFSET_ALIGN. */
if (DECL_P (object))
align = DECL_ALIGN (object);
else
align = TYPE_ALIGN (type);
/* Do a block move either if the size is so small as to make
each individual move a sub-unit move on average, or if it
- is so large as to make individual moves inefficient. */
+ is so large as to make individual moves inefficient. Reuse
+ the same costs logic as we use in the SRA passes. */
+unsigned max_scalarization_size
+ = optimize_function_for_size_p (cfun)
+? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
+: PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED);
+
if (size 0
num_nonzero_elements 1
(size num_nonzero_elements
+|| size max_scalarization_size
|| !can_move_by_pieces (size, align))
{
if (notify_temp_creation)
return GS_ERROR;
If it isn't profitable to do an SRA, we can fall-back to the backend hook to
move it by pieces. This way, I think we'll have move opportunity for
optimization.
[Bug tree-optimization/64031] (un-)conditional execution state is not preserved by PRE/sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64031 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-24 Blocks||53947 Summary|Vectorization of max/min is |(un-)conditional execution |not robust enough |state is not preserved by ||PRE/sink Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- The issue is that PRE optimizes this to f2_11 = f2_10 * f2_10; if (f2_10 f2_11) goto bb 5; else goto bb 4; bb 4: pretmp_25 = f2_11 * f2_11; bb 5: # prephitmp_26 = PHI f2_11(3), pretmp_25(4) *_9 = prephitmp_26; and f2_11 * f2_11 may trap thus ifcvt refuses to execute it unconditionally (but only PRE made it executed conditionally). Thus confirmed that both PRE and code sinking can make stmts executed conditionally while they were not so before which can pessimize transforms done by later passes such as LIM and if-conversion.
[Bug middle-end/64028] [5 Regression] r211599 caused many vectorizer test failures with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64028 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 --- Comment #6 from ktkachov at gcc dot gnu.org --- By the way, this ICE manifests when building perlbmk in SPEC2006
[Bug tree-optimization/64026] [5 Regression] Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- So is this one now a dup of PR64028??
[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 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Several testsuite execution |[5 Regression] Several |failures with -O2 -flto |testsuite execution |-fuse-linker-plugin |failures with -O2 -flto |-fno-fat-lto-objects|-fuse-linker-plugin ||-fno-fat-lto-objects
[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 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug java/64044] Java emits bogus .class$ decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 --- Comment #5 from Andrew Haley aph at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #4) On Mon, 24 Nov 2014, aph at redhat dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 Andrew Haley aph at redhat dot com changed: What|Removed |Added CC||aph at redhat dot com --- Comment #2 from Andrew Haley aph at redhat dot com --- So, is the solution to this trivially not to mark the .class$ decls as TREE_CONST ? Yes, see the patch I proposed (in testing right now, I'll post it and ask for approval later today unless you want to pre-approve here) Fine by me. I did that because I wanted some way to tell GCC that it could treat the field as readonly, but TREE_CONST doesn't do that.
[Bug middle-end/64017] Support ISL 0.14.0 (to fix ICE with gfortran.dg/graphite/pr42393.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64017 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- That sounds like sth sensible. Note that I'd put that test into gcc/configure as there you can perform link tests even to an in-tree compiled ISL.
[Bug tree-optimization/64026] [5 Regression] Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Richard Biener from comment #5) So is this one now a dup of PR64028?? Looks so, let's move to PR64028 which points to offending commit. *** This bug has been marked as a duplicate of bug 64028 ***
[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #21 from Rohit rohitarulraj at gmail dot com --- (In reply to Francois-Xavier Coudert from comment #20) The commits from comments #16 and #17 broke the compiler (and bootstrap) on powerpc-apple-darwin9: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 Sorry. The REGISTER_NAMES macro that was updated in rs6000.h file gets redefined in darwin.h file. I can provide the required patch, but I don't have a darwin machine to test the changes.
[Bug middle-end/64028] [5 Regression] r211599 caused many vectorizer test failures with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64028 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- *** Bug 64026 has been marked as a duplicate of this bug. ***
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #18 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 24 Nov 2014, belagod at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #17 from Tejas Belagod belagod at gcc dot gnu.org ---
-
/* Do a block move either if the size is so small as to make
each individual move a sub-unit move on average, or if it
- is so large as to make individual moves inefficient. */
+ is so large as to make individual moves inefficient. Reuse
+ the same costs logic as we use in the SRA passes. */
+unsigned max_scalarization_size
+ = optimize_function_for_size_p (cfun)
+ ? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
+ : PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED);
+
if (size 0
num_nonzero_elements 1
(size num_nonzero_elements
- || !can_move_by_pieces (size, align)))
+ || size max_scalarization_size))
{
if (notify_temp_creation)
return GS_ERROR;
I think both move_by_pieces and SRA can co-exist here:
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 8e3dd83..be51ce7 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -70,6 +70,7 @@ along with GCC; see the file COPYING3. If not see
#include omp-low.h
#include gimple-low.h
#include cilk.h
+#include params.h
#include langhooks-def.h/* FIXME: for lhd_set_decl_assembler_name */
#include tree-pass.h/* FIXME: only for PROP_gimple_any */
@@ -3895,7 +3896,6 @@ gimplify_init_constructor (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
DECL_ATTRIBUTES (current_function_decl
{
HOST_WIDE_INT size = int_size_in_bytes (type);
unsigned int align;
/* ??? We can still get unbounded array types, at least
from the C++ front end. This seems wrong, but attempt
@@ -3907,20 +3907,19 @@ gimplify_init_constructor (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
TREE_TYPE (ctor) = type = TREE_TYPE (object);
}
/* Find the maximum alignment we can assume for the object. */
/* ??? Make use of DECL_OFFSET_ALIGN. */
if (DECL_P (object))
align = DECL_ALIGN (object);
else
align = TYPE_ALIGN (type);
/* Do a block move either if the size is so small as to make
each individual move a sub-unit move on average, or if it
- is so large as to make individual moves inefficient. */
+ is so large as to make individual moves inefficient. Reuse
+ the same costs logic as we use in the SRA passes. */
+unsigned max_scalarization_size
+ = optimize_function_for_size_p (cfun)
+? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
+: PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED);
+
if (size 0
num_nonzero_elements 1
(size num_nonzero_elements
+|| size max_scalarization_size
|| !can_move_by_pieces (size, align))
{
if (notify_temp_creation)
return GS_ERROR;
If it isn't profitable to do an SRA, we can fall-back to the backend hook to
move it by pieces. This way, I think we'll have move opportunity for
optimization.
But that wouldn't fix the AARCH64 case as the backend says no here
anyway?
[Bug target/64045] New: fortran.dg/pr45636.f90 fails for AArch64 - memcpy and memset are not combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64045 Bug ID: 64045 Summary: fortran.dg/pr45636.f90 fails for AArch64 - memcpy and memset are not combined Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kugan at gcc dot gnu.org In current trunk, fortran.dg/pr45636.f90 fails for AArch64 as memcpy and memset are not combined.
[Bug target/64045] fortran.dg/pr45636.f90 fails for AArch64 - memcpy and memset are not combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64045
--- Comment #1 from kugan at gcc dot gnu.org ---
Look at gcc/tree-ssa-fwprop.c:1650
/* If the new memcpy wouldn't be emitted by storing the literal
by pieces, this optimization might enlarge .rodata too much,
as commonly used string literals couldn't be shared any
longer. */
if (!can_store_by_pieces (src_len,
builtin_strncpy_read_str,
src_buf, ptr1_align, false))
break;
AArch64 back-end rejects use_by_pieces_infrastructure for STORE_BY_PIECES and
hence this optimisation will fail. It is probably an xfail case if back-end is
going to reject it.
static bool
aarch64_use_by_pieces_infrastructure_p (unsigned int size,
unsigned int align,
enum by_pieces_operation op,
bool speed_p)
{
/* STORE_BY_PIECES can be used when copying a constant string, but
in that case each 64-bit chunk takes 5 insns instead of 2 (LDR/STR).
For now we always fail this and let the move_by_pieces code copy
the string from read-only memory. */
if (op == STORE_BY_PIECES)
return false;
return default_use_by_pieces_infrastructure_p (size, align, op, speed_p);
}
[Bug jit/64020] jit misses sin/cos optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64020
--- Comment #2 from dmalcolm at gcc dot gnu.org ---
For reference, both at -O3, based on r217939:
./cc1 of
#include math.h
int
test_of_builtin_trig (double theta)
{
return 2 * sin (theta) * cos (theta);
}
generates:
test_of_builtin_trig:
.LFB3:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
leaq8(%rsp), %rdi
movq%rsp, %rsi
callsincos
movsd 8(%rsp), %xmm0
addsd %xmm0, %xmm0
mulsd (%rsp), %xmm0
addq$24, %rsp
.cfi_def_cfa_offset 8
cvttsd2si %xmm0, %eax
ret
.cfi_endproc
[would it be even better to optimize this to just a sin (2 * theta) ?]
whereas the jit test generates:
test_of_builtin_trig:
.LFB32:
.cfi_startproc
.LVL4:
.L37:
subq$24, %rsp
.cfi_def_cfa_offset 32
movsd%xmm0, 8(%rsp)
callsin@PLT
.LVL5:
movsd8(%rsp), %xmm1
movsd%xmm0, (%rsp)
movapd%xmm1, %xmm0
callcos@PLT
.LVL6:
mulsd(%rsp), %xmm0
addq$24, %rsp
.cfi_def_cfa_offset 8
addsd%xmm0, %xmm0
ret
.cfi_endproc
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #19 from jgreenhalgh at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #16) Certainly removing the alignment is not going to fly - we'd generate very bad code for strict-align targets for initializing packed structs by pieces for example. Surely this is already true? The alignment here is what we can assume for the entire aggregate - the previous check was can_move_by_pieces, which doesn't check the components of the aggregate. For a well-aligned aggreagate of the appropriate size, can_move_by_pieces will return true, and we'll initialize the packed struct by its components regardless of the component alignment. Or am I missing something?
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #23 from preshing filter-gcc at preshing dot com --- Hi, I went ahead and verified this bug using a cross-compiler built from GCC 4.9.2 sources. The bug indeed exists and happens when compiling for AArch64, but not PowerPC. Andrew's patch fixes it (changing the first ldr instruction to an ldar in this case). Full AArch64 assembly listings below. I've also written a blog post on this subject in the hope of clarifying the issue for anyone determined enough to make sense of it: http://preshing.com/20141124/fixing-gccs-implementation-of-memory_order_consume Andrew's patch, if it works the way I understand it, seems like the correct thing for GCC to do until somebody figures out how to safely implement the efficient compiler strategy for consume semantics. I guess the next step is to run the test suite on a few platforms to make sure there are no regressions, then submit? Cheers, Jeff -- AArch64 listing of threadB() without Andrew's patch: _Z7threadBv: .LFB2304: .cfi_startproc adrpx1, .LANCHOR0 stp x29, x30, [sp, -16]! .cfi_def_cfa_offset 16 .cfi_offset 29, -16 .cfi_offset 30, -8 add x1, x1, :lo12:.LANCHOR0 add x29, sp, 0 .cfi_def_cfa_register 29 .L10: add x0, x1, 8 ldr w0, [x0] cbz w0, .L10 ldr w0, [x1] cmp w0, 1 bne .L15 str wzr, [x1] add x0, x1, 8 stlrwzr, [x0] b .L10 .L15: adrpx3, .LANCHOR1 adrpx0, .LC2 adrpx1, .LC1 add x3, x3, :lo12:.LANCHOR1 add x0, x0, :lo12:.LC2 add x1, x1, :lo12:.LC1 mov w2, 47 add x3, x3, 16 bl __assert_fail .cfi_endproc -- AArch64 listing of threadB() with Andrew's patch: _Z7threadBv: .LFB2304: .cfi_startproc adrpx1, .LANCHOR0 stp x29, x30, [sp, -16]! .cfi_def_cfa_offset 16 .cfi_offset 29, -16 .cfi_offset 30, -8 add x1, x1, :lo12:.LANCHOR0 add x29, sp, 0 .cfi_def_cfa_register 29 .L10: add x0, x1, 8 ldarw0, [x0] cbz w0, .L10 ldr w0, [x1] cmp w0, 1 bne .L15 str wzr, [x1] add x0, x1, 8 stlrwzr, [x0] b .L10 .L15: adrpx3, .LANCHOR1 adrpx0, .LC2 adrpx1, .LC1 add x3, x3, :lo12:.LANCHOR1 add x0, x0, :lo12:.LC2 add x1, x1, :lo12:.LC1 mov w2, 47 add x3, x3, 16 bl __assert_fail .cfi_endproc
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 --- Comment #21 from Dominik Vogt vogt at linux dot vnet.ibm.com --- With today's HEAD, the ICE in libgo is gone (s390x). Thanks.
[Bug target/62173] [5.0 regression] [AArch64] Performance regression due to r213488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #7 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to bin.cheng from comment #6) Em, is offset valid for [reg+offset] addressing mode? if it is, why don't we transform reg+reg+offset into regX - reg + reg; [regX + offset];? that's because for local char array A, if we want to address it's element, like A[I], first we get the base address of array A, which is (plus virtual_stack_vars_rtx, offset), then we add the index offset I which is in register B: (plus (plus virtual_stack_vars_rtx, offset), B) while from my experiment, above will be canonicalized into : (plus (plus virtual_stack_vars_rtx, B), offset) and for any target define FRAME_GROWS_DOWNWARD be 1, virtual_stack_vars_rtx will be eliminated into (plus frame pointer, offset1), instead of (plus, frame_pointer, const_0) which only happen when FRAME_GROWS_DOWNWARD be 0. so, transform reg+reg+offset into regX - reg + reg; [regX + offset]; will cause some trouble for gcc rtl optimization, because it's finally splitted into: regA - frame - offset0 regA - regA + regB regA - regA + offset1 and somehow, later rtl optimization can't fold offset 0 and offset 1, because virtual_stack_var_rtx elimination happens at quite later stage in LRA. so, if we found virtual_stack_var_rtx + reg + offset, it's better to associate constant offset with it, which means transform it into regA - virtual_stack_var_rtx + offset regA - regA + regB thus the elimination offset will be merged into the array offset automatically in LRA. I verified if we add such transform in aarch64's LEGITIMIZE_ADDRESS hook, then we do generate optimized code for Pinski's sample code: bar: stp x29, x30, [sp, -48]! add x29, sp, 0 stp x19, x20, [sp, 16] add x19, x29, 32 mov w20, w0 mov x0, x19 bl g ldrbw0, [x19, w20, sxtw] bl f ldp x19, x20, [sp, 16] ldp x29, x30, [sp], 48 ret
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #20 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 24 Nov 2014, jgreenhalgh at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #19 from jgreenhalgh at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #16) Certainly removing the alignment is not going to fly - we'd generate very bad code for strict-align targets for initializing packed structs by pieces for example. Surely this is already true? The alignment here is what we can assume for the entire aggregate - the previous check was can_move_by_pieces, which doesn't check the components of the aggregate. For a well-aligned aggreagate of the appropriate size, can_move_by_pieces will return true, and we'll initialize the packed struct by its components regardless of the component alignment. Or am I missing something? I thought that AARCH64 fails to do the init by pieces exactly because can_move_by_pieces_p say so. Adding another condition that may also reject it won't help, no? Richard.
[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|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Martin Liška marxin at gcc dot gnu.org --- Resolved.
[Bug target/63661] [4.9/5 Regression] -O2 miscompiles with -mtune=nehalem or corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||renlin.li at arm dot com --- Comment #22 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to H.J. Lu from comment #21) It was fixed by r217783 on trunk and the fix also works on 4.9 branch. Is is the real fix? I am not familiar enough with IRA to be really sure but I would say that yes. This bug really looks as if IRA and LRA chose the same register (r12) for a different thing, which is described as the problem in the email accompanying the patch. The weird sequence clobbering the register certainly goes away with just this patch applied. So let's wait for a week or so if any of the RA people confirm this or have any comments and prepare a backport if they don't.
[Bug target/62173] [5.0 regression] [AArch64] Performance regression due to r213488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #8 from Jiong Wang jiwang at gcc dot gnu.org ---
while above associate virtual_stack_var_rtx with constant offset actually cause
another hidding issue.
I assume after the association, we are generating cleaner insn sequences.
given the following testcase
void bar(int i)
{
char A[10];
char B[10];
char C[10];
g(A);
g(B);
g(C);
f(A[i]);
f(B[i]);
f(C[i]);
return;
}
it will generate the following assembly
bar:
stpx29, x30, [sp, -96]!
addx29, sp, 0
stpx21, x22, [sp, 32]
addx22, x29, 48
addx21, x29, 64
stpx19, x20, [sp, 16]
sxtwx19, w0
movx0, x22
addx20, x29, 80
blg
movx0, x21
blg
movx0, x20
blg
ldrbw0, [x22, x19]
blf
ldrbw0, [x21, x19]
blf
ldrbw0, [x20, x19]
blf
ldpx19, x20, [sp, 16]
ldpx21, x22, [sp, 32]
ldpx29, x30, [sp], 96
ret
above assembly is bad, because extra callee saved registers are used which we
should rematerialize those frame address instead of keeping them in callee
saved to avoid extra load/store.
looks like current register allocation don't rematerialize above situation.
[Bug preprocessor/60436] [4.8/4.9/5 Regression] C preprocessor segfaults on assembly file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34089 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34089action=edit gcc5-pr60436.patch Untested fix. For add_map we have code to handle this. But if add_map is false too many times, we can still overflow. This patch forces add_map to true if highest is too high.
[Bug target/62173] [5.0 regression] [AArch64] Performance regression due to r213488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #9 from Jiong Wang jiwang at gcc dot gnu.org ---
To summary, given the following testcases:
case A.C
===
void bar(int i)
{
char A[10];
g(A);
f(A[i]);
}
case B.c
===
void bar(int i)
{
char A[10];
char B[10];
char C[10];
g(A);
g(B);
g(C);
f(A[i]);
f(B[i]);
f(C[i]);
return;
}
current code base:
* generate sub-optimal code for case A.
* generate optimal code for case B, because frame address are rematerialized.
I verified *arm/mips also generate the same sub-optimal code layout for case
A*, and I believe should be the same for Sebastian's testcase.
r213488 bring AArch64 to the correct road then we run into common issue existed
on other target also.
for any target with FRAME_GROWS_DOWNWARD be 1, the same sub-optimal code layout
will be generated, because the base address of the first stack variable will be
eliminated into frame + some_minus_value in later stage of LRA which cause it
can't be foled with other constant.
and after my experimental hack on LEGITIMIZE_ADDRESS to associate
stack_var_virtual_rtx with constant offset, then:
* generate optimal code for case A.
* generate sub-optimal code for case B, because frame address are *not
rematerialized*.
will do further investigation on this especially the frame address
rematerialization after my patch.
[Bug other/64046] New: Malformed .eh_frame generated with LTO, gold and LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64046
Bug ID: 64046
Summary: Malformed .eh_frame generated with LTO, gold and LTO
enabled
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at lekensteyn dot nl
While trying to track down a weird crash in libunwind, I found that the library
I was debugging (libgudev-1.0.so.0.2.0) has a weird .eh_frame. I could minimize
the problem to:
echo 'int main(void) { return 0; }' hello.c
gcc -shared -Wl,-fuse-ld=gold -fPIC -flto -ffat-lto-objects -O2 hello.c
-Wl,--gc-sections
readelf --hex-dump=.eh_frame a.out | head -n5
Omitting any of the gcc options would result in a .eh_frame section that does
not look odd. Output of readelf follows (note the leading 8 zeroes, and the
warning about the invalid FDE length).
Hex dump of section '.eh_frame':
0x06b0 1400
0x06c0 017a5200 01781001 1b0c0708 9001 .zR..x..
0x06d0 c0fe 1c00 0200
0x06e0 2400 3400 $...4...
0x06f0 70fe 3000 000e1046 0e184a0f p...0..F..J.
0x0700 0b770880 003f1a3b 2a332422 .w...?.;*3$
Contents of the .eh_frame section:
ZERO terminator
0004 ZERO terminator
0008 0014 CIE
Version: 1
Augmentation: zR
Code alignment factor: 1
Data alignment factor: -8
Return address column: 16
Augmentation data: 1b
DW_CFA_def_cfa: r7 (rsp) ofs 8
DW_CFA_offset: r16 (rip) at cfa-8
DW_CFA_nop
DW_CFA_nop
readelf: Warning: Invalid length 0xfec0 in FDE at 0x20
0020 fec0 001c FDE cie=0008
pc=06d8..06da
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_??? (User defined call frame op: 0x24)
This .eh_frame encoding looks strange to me as it does not conform to LSB
4.1[1] nor the AMD64 ABI document. It also trips up Wireshark's ELF dissector.
Linux x86_64
GCC versions 4.8.2-1ubuntu6 (Ubuntu 14.04) and 4.9.2-1 (Arch Linux).
binutils 2.24-8 (Arch Linux)
[1]:
https://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
[2]: http://www.x86-64.org/documentation/abi.pdf
[Bug target/63965] [5 Regression] ICE: in extract_constrain_insn, at recog.c:2230 on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63965 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Sorry for the delay. But the two ICEs still happen on gcc112 with r218013. ../gcc/configure --disable-bootstrap --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --enable-werror --disable-multilib --enable-languages=c,c++,fortran
[Bug c++/63942] [5.0 Regression] constexpr conflicts with previous declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63942 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Nov 24 12:49:08 2014 New Revision: 218016 URL: https://gcc.gnu.org/viewcvs?rev=218016root=gccview=rev Log: PR c++/63942 * mangle.c (mangle_decl): If we aren't going to create a symbol alias, don't build the alias DECL either. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c
[Bug target/64047] New: [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047 Bug ID: 64047 Summary: [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c 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 Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu trippels@gcc2-power8 testsuite % gcc -g -ftree-parallelize-loops=4 -O2 -flto -fno-use-linker-plugin -flto-partition=none gcc.dg/torture/pr52429.c gcc.dg/torture/pr52429.c: In function ‘foo’: gcc.dg/torture/pr52429.c:24:1: internal compiler error: Segmentation fault } ^ 0x107bdbeb crash_signal ../../gcc/gcc/toplev.c:359 0x105e4187 record_operand_costs ../../gcc/gcc/ira-costs.c:1303 0x105e482b scan_one_insn ../../gcc/gcc/ira-costs.c:1483 0x105e482b process_bb_for_costs ../../gcc/gcc/ira-costs.c:1604 0x105ddb3f ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) ../../gcc/gcc/ira-build.c:1838 0x105e6e67 find_costs_and_classes ../../gcc/gcc/ira-costs.c:1701 0x105e72ab ira_costs() ../../gcc/gcc/ira-costs.c:2216 0x105df9ab ira_build() ../../gcc/gcc/ira-build.c:3459 0x105d5803 ira ../../gcc/gcc/ira.c:5227 0x105d5803 execute ../../gcc/gcc/ira.c:5518 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/64047] [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/61925] [4.8/4.9/5 Regression] internal error when using vectorization on CPU without SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61925 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 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 --- I will have a look.
[Bug middle-end/61927] [4.9/5 Regression] Wrong results with loop vectorization of: var[i] = ABS_EXPRvar2[i] 9.9e-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61927 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look.
[Bug ipa/62016] [4.8/4.9/5 Regression] very slow compilation at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/62044] [4.8/4.9/5 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Known to fail|4.10.0 |5.0
[Bug target/62173] [5.0 regression] [AArch64] Performance regression due to r213488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[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 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/62238] [4.9/5 Regression] ICE with LTO on valid code on x86_64-linux-gnu in verify_ssa (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62238 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 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 --- I will have a look.
[Bug rtl-optimization/62265] [4.8/4.9/5 regression] FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree Elimination opportunities = 3 realized = 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62265 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed. I don't see this test on the branches.
[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|sparc*-sun-solaris2.*, |sparc*-sun-solaris2.*, |arm*, aarch64* |arm*, aarch64*, x86_64-*-*, ||i?86-*-* Priority|P3 |P1 Host|sparc*-sun-solaris2.* | Build|sparc*-sun-solaris2.* | --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Also x86_64. Should be at least investigated.
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2
[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #22 from fxcoudert at gmail dot com fxcoudert at gmail dot com --- Sorry. The REGISTER_NAMES macro that was updated in rs6000.h file gets redefined in darwin.h file. I can provide the required patch, but I don't have a darwin machine to test the changes. If you upload a patch on the bugzilla entry, I will test it. FX
[Bug middle-end/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog Priority|P3 |P2 Component|other |middle-end
[Bug tree-optimization/64048] New: UNRESOLVED: gcc.dg/tree-prof/peel-1.c scan-rtl-dump loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64048 Bug ID: 64048 Summary: UNRESOLVED: gcc.dg/tree-prof/peel-1.c scan-rtl-dump loop2_unroll Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Caused by Move loop peeling from RTL to gimple [1], r216238. The gcc.dg/tree-prof/peel-1.c testcase needs further updates in dump scan and cleanup dg-directives. [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01211.html
[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/63184] [4.8/4.9/5 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug testsuite/63256] [5 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63256 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-24 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/63940] C++ constexpr errors on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63940 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- (In reply to David Edelsohn from comment #7) The test was not failing on Linux x86-64 nor x86-32. I sent pre-processed testcase from AIX that Jason was able to reproduce on Linux. But the fix did not solve the failure on AIX. I just checked in an additional fix for bug 63942. Does that resolve it?
[Bug c++/64049] New: Wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049 Bug ID: 64049 Summary: Wrong code at -O3 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de the attached C++ program is mis-compiled with recent GCC trunk at -O3 g++ -O3 ValueHelper1.cpp ValueHelper2.cpp ./a.out Assertion failed at ValueHelper1.cpp(9): Unexpected null pointer Segmentation fault (core dumped) which is not supposed to happen. correct: g++ -O2 ValueHelper1.cpp ValueHelper2.cpp ./a.out text= Localized Text
[Bug c++/64049] Wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 34090 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34090action=edit ValueHelper1.cpp
[Bug c++/64049] Wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049 --- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 34091 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34091action=edit ValueHelper2.cpp
[Bug middle-end/63311] [4.9/5 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.8.3 Known to fail||4.9.2 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed that it is ifcombine. Not sure if I'd call it wrong-code though. Note that there are no default-defs involved thus ifcombine doesn't see must-uninits and disabling its transform when maybe-uninits are seen is IMHO bogus. Not sure what to do about this one. There is no way to preserve evaluation order (no andif / orif on gimple).
[Bug c++/64049] Wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049 --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 34092 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34092action=edit ValueHelper.h
[Bug ipa/63313] [5 Regression] ICE in ipa-comdats.c:371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63313 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-24 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed (I've see a dup of this?).
[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Assuming fixed.
[Bug rtl-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- I believe that the testcase is invalid - the atomic is an automatic variable which can never be involved in data races given the stack is not shared amongst threads and you do not take the address of the variable and let it escape to other threads.
