[Bug target/92295] Inefficient vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92295
--- Comment #1 from Hongtao.liu ---
Created attachment 47143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47143&action=edit
This patch can fix this issue
In ix86_expand_vector_init_concat, vector are initialized per 2 elements,
that's why it failed to generate vpbroadcast, any purpose of this code???
--
13784 /* FIXME: We process inputs backward to help RA. PR 36222. */
13785 i = n - 1;
13786 j = (n >> 1) - 1;
13787 for (; i > 0; i -= 2, j--)
13788{
13789 first[j] = gen_reg_rtx (cmode);
13790 v = gen_rtvec (2, ops[i - 1], ops[i]);
13791 ix86_expand_vector_init (false, first[j],
13792 gen_rtx_PARALLEL (cmode, v));
13793}
13794
13795 n >>= 1;
13796 if (n > 4)
it can be implemented like
---
13776 /* FIXME: We process inputs backward to help RA. PR 36222. */
13777 i = n - 1;
13778 for (j = 1; j != -1; j--)
13779{
13780 half[j] = gen_reg_rtx (half_mode);
13781 switch (n >> 1)
13782{
13783case 2:
13784 v = gen_rtvec (2, ops[i-1], ops[i]);
13785 i -= 2;
13786 break;
13787case 4:
13788 v = gen_rtvec (4, ops[i-3], ops[i-2], ops[i-1], ops[i]);
13789 i -= 4;
13790 break;
13791case 8:
13792 v = gen_rtvec (8, ops[i-7], ops[i-6], ops[i-5], ops[i-4],
13793 ops[i-3], ops[i-2], ops[i-1], ops[i]);
13794 i -= 8;
13795 break;
13796default:
13797 gcc_unreachable ();
13798}
13799 ix86_expand_vector_init (false, half[j],
13800 gen_rtx_PARALLEL (half_mode, v));
13801}
13802
13803 ix86_expand_vector_init_concat (mode, target, half, 2);
13804 break;
---
Bootstrap and regression test is ok.
[Bug ipa/88702] [7/8/9/10 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-31 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|7.5 |8.5 Ever confirmed|0 |1
[Bug tree-optimization/14799] [tree-ssa] convert a sequence of "if"s to a "switch" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14799 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- I'm working on the optimization.
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595 Antonio Di Monaco changed: What|Removed |Added CC||antonio.di.monaco at sap dot com --- Comment #18 from Antonio Di Monaco --- This change introduced a regression in the allocator calls. I've created a new bug for it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300
[Bug bootstrap/92301] New: bootstrap internal compiler error: Aborted free(): invalid next size (fast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92301 Bug ID: 92301 Summary: bootstrap internal compiler error: Aborted free(): invalid next size (fast) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jan at jki dot io Target Milestone: --- gcc bootstrapped with -O3 seems to be broken at the moment. flags are: "-march=skylake -g1 -O2" latest trunk If I compile with -O2 it works COLLECT_GCC_OPTIONS='-B' '/var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/build/./gcc/' '-B' '/usr/x86_64-pc-linux-gnu/bin/' '-B' '/usr/x86_64-pc-linux-gnu/lib/' '-isystem' '/usr/ /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/build/./gcc/cc1 -fpreprocessed conftest.i -quiet -dumpbase conftest.c -march=skylake -auxbase conftest -g -g1 -O2 -O3 -version -fn GNU C17 (Gentoo 10.0.0_pre) version 10.0.0-pre 20191031 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 10.0.0-pre 20191031 (experimental), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (Gentoo 10.0.0_pre) version 10.0.0-pre 20191031 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 10.0.0-pre 20191031 (experimental), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: fa416f315144141f16c1f6d6e3d5dca9 free(): invalid next size (fast) during RTL pass: ree conftest.c: In function 'main': conftest.c:16:1: internal compiler error: Aborted 16 | } | ^ 0x7fa14496770f ??? /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7fa14496766a __GI_raise ../sysdeps/unix/sysv/linux/raise.c:51 0x7fa14491855b __GI_abort /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/stdlib/abort.c:79 0x7fa1449a682c __libc_message ../sysdeps/posix/libc_fatal.c:181 0x7fa1449ae519 malloc_printerr /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/malloc/malloc.c:5341 0x7fa144939c20 _int_free /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/malloc/malloc.c:4252 0x7fa144939c20 __GI___libc_free /var/tmp/portage/sys-libs/glibc-2.30/work/glibc-2.30/malloc/malloc.c:3127 0x7fa1449495eb __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug libstdc++/92300] New: Useless allocator call in std::map, when insert does not perform any insertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300 Bug ID: 92300 Summary: Useless allocator call in std::map, when insert does not perform any insertion. Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: antonio.di.monaco at sap dot com Target Milestone: --- Created attachment 47142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47142&action=edit code example The fix related to the bug 78595 introduced a regression in the std::map insert call. When a key already exists, an allocation is performed anyway. std::map< int, int, std::less< int >, MyAlloc< std::pair< const int, int > > > a; assert(a.insert(std::make_pair(1, 1)).second); assert(a.insert(std::make_pair(2, 2)).second); assert(!a.insert(std::make_pair(1, 3)).second); GCC 6: map: allocate 1 element(s) of size 40 allocated at: 0x13d8c20 allocate 1 element(s) of size 40 allocated at: 0x13d8c50 GCC >= 7.4.0: map: allocate 1 element(s) of size 40 allocated at: 0x14f1c20 allocate 1 element(s) of size 40 allocated at: 0x14f1c50 allocate 1 element(s) of size 40 allocated at: 0x14f1c80 Other associative containers have not been affected by the change.
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from gnzlbg --- > Note that the situation for zero-sized structs isn't very clear in most ABIs, these included. This is incorrect: zero-sized types are well-defined and efficient on most ABIs (most ABIs have a rule for small sizes, and these rules cover zero-sized types). AFAICT, these two (MSP430 and PPC32) are some of the very few ABIs in which zero-sized types waste one register and one instruction for no reason. > You must have an unusual program if this ever matters ;-) This bug / question was spawned due to a PR that attempted to fix a bug in Rust for these ABIs when zero-sized types are involved. Rust has first-class support for ZSTs and they are widely used, so the unusual situation where this happens is essentially "all Rust programs". While ZSTs are "free" on most ABIs, on these particular two, the ABI spec does not cover them, making "what GCC does" essentially the only documented behavior for these. Hence the question, is wasting one register and one instruction for ZSTs on these platforms a GCC bug, or part of the intended ABI for these? It appears that the answer is that this is intended: these ABIs always pass structs and unions indirectly, even if they are zero-sized, and that just means that a register and an instruction must be used when ZSTs are passed, even if those registers will never be read by anything. These ABIs know about this and find it an acceptable trade-off, so that's what Rust will do.
[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Thu Oct 31 07:10:57 2019 New Revision: 277656 URL: https://gcc.gnu.org/viewcvs?rev=277656&root=gcc&view=rev Log: PR c++/90947 * tree.h (type_initializer_zero_p): Remove. * tree.c (type_initializer_zero_p): Remove. cp/ * cp-tree.h (type_initializer_zero_p): Declare. * decl.c (reshape_init_array_1): Formatting fix. * tree.c (type_initializer_zero_p): New function. Moved from ../tree.c, use next_initializable_field, formatting fix. Return false for TYPE_NON_AGGREGATE_CLASS types. Added: trunk/gcc/testsuite/g++.dg/init/array54.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/tree.c trunk/gcc/tree.c trunk/gcc/tree.h
