[Bug target/70406] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70406 --- Comment #4 from Kirill Yukhin --- Author: kyukhin Date: Mon Mar 28 07:59:44 2016 New Revision: 234500 URL: https://gcc.gnu.org/viewcvs?rev=234500&root=gcc&view=rev Log: PR target/70406 gcc/ * config/i386/i386.md (define_split, andn): Fix modes. gcc/testsuite/ * gcc.target/i386/pr70406.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr70406.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug target/70406] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70406 --- Comment #5 from Kirill Yukhin --- Author: kyukhin Date: Mon Mar 28 08:01:56 2016 New Revision: 234501 URL: https://gcc.gnu.org/viewcvs?rev=234501&root=gcc&view=rev Log: PR target/70406. gcc/ * config/i386/i386.md (define_split, andn): Fix modes. gcc/testsuite/ * gcc.target/i386/pr70406.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr70406.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/i386.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/70429] New: Wrong code with -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70429
Bug ID: 70429
Summary: Wrong code with -O1.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Created attachment 38111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38111&action=edit
Reproducer.
Test case produces incorrect result with -O1 and all x86 arch. Everything works
fine with -O0 option.
Output:
> g++ -O0 repr.cpp -mavx2; ./a.out
4119272
> g++ -O1 repr.cpp -mavx2; ./a.out
272554728
GCC version:
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/export/users/vlivinsk/gcc-trunk/bin/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/users/vlivinsk/gcc-trunk/gcc/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --enable-checking=release --enable-languages=c,c++,lto
--with-gmp=/export/users/vlivinsk/gcc-trunk/gmp-6.1.0/bin
--with-mpfr=/export/users/vlivinsk/gcc-trunk/mpfr-3.1.3/bin
--with-mpc=/export/users/vlivinsk/gcc-trunk/mpc-1.0.3/bin
--prefix=/export/users/vlivinsk/gcc-trunk/bin
Thread model: posix
gcc version 6.0.0 20160327 (experimental) (Revision=234496)
Test:
#include
#include
bool a = 1;
int b = 612010083;
void foo () {
b = (int)((~7710322944595239647L + 9223372036854775807L) >> a) >> 4;
}
int main () {
foo ();
if (b != 4119272)
abort();
return 0;
}
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1 from Tom Honermann ---
I'm also experiencing this; gcc r234493.
$ cat t.cpp
template
constexpr bool b = false;
template
constexpr bool b = true;
int main() {
b;
b;
}
$ g++ -std=c++14 t.cpp -o t
/tmp/ccYIejpd.s: Assembler messages:
/tmp/ccYIejpd.s:27: Error: symbol `_ZL1b' is already defined
$ gcc --version
gcc (GCC) 6.0.0 20160327 (experimental)
...
[Bug target/70429] Wrong code with -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70429
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-03-28
CC||ienkovich at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Ilya Enkovich ---
Confirm.
Looks like combine issue. Before combine:
6: r94:DI=0x14ff6e2207db5d1f
7: {r93:DI=r94:DI>>r92:SI#0;clobber flags:CC;}
REG_DEAD r94:DI
REG_DEAD r92:SI
REG_UNUSED flags:CC
REG_EQUAL 0x14ff6e2207db5d1f>>r92:SI#0
8: {r95:SI=r93:DI#0>>0x4;clobber flags:CC;}
Combine log:
allowing combination of insns 6, 7 and 8
original costs 3 + 4 + 4 = 11
replacement costs 3 + 4 = 7
deferring deletion of insn with uid = 6.
modifying insn i2 7: r93:DI=0x14ff6e2207db5d1
deferring rescan insn with uid = 7.
modifying insn i3 8: {r95:SI#0=r93:DI>>r92:SI#0;clobber flags:CC;}
This affects 4 high bits if the result.
[Bug target/70429] Wrong code with -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70429 Markus Trippelsdorf changed: What|Removed |Added CC||segher at gcc dot gnu.org, ||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf --- Adding CC.
[Bug target/70406] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70406 Kirill Yukhin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Kirill Yukhin --- Done.
[Bug target/70429] Wrong code with -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70429 Segher Boessenkool changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- This is a lot like PR70222, but that was fixed. Adding cc:.
[Bug rtl-optimization/70134] combine misses jump optimization on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70134 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- Right. But why is such awful code generated before combine? Either the tree passes missed something, or expand is doing a shitty job, I bet.
[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70416 --- Comment #15 from Oleg Endo --- (In reply to Oleg Endo from comment #14) > > Maybe at that stage in the reload code it will end up using the last *addsi3 > pattern and not try to look for a new pattern in the .md when it wants to > change it. In other words, maybe it'll help if the *addsi3 patterns are > merged into a single pattern somehow. I'll give it a try... The following seems to fix the problem: Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md (revision 234258) +++ gcc/config/sh/sh.md (working copy) @@ -2248,7 +2248,7 @@ (plus:SI (match_operand:SI 1 "arith_reg_operand" "r") (match_operand:SI 2 "arith_or_int_operand" "rn")))] "TARGET_SH1 && !sh_lra_p () - && reload_completed + && (reload_completed || reload_in_progress) && !reg_overlap_mentioned_p (operands[0], operands[1])" "#" "&& 1"
[Bug c++/70095] [C++14] Link error on partially specialized variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70095
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #2 from Tom Honermann ---
The change in comment 1 introduced a regression. The following test passes
with r234230, but fails with r234231:
$ cat t.cpp
template
constexpr bool b = false;
template
constexpr bool b = true;
int main() {
b;
b;
}
$ g++ -std=c++14 t.cpp -o t
/tmp/ccJTAQId.s: Assembler messages:
/tmp/ccJTAQId.s:27: Error: symbol `_ZL1b' is already defined
[Bug bootstrap/70422] [6 regression] Bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70422 --- Comment #5 from Jason Merrill --- (In reply to Jim Wilson from comment #4) > The broken targets all define flag_section_anchors at -O1 and up. Probably the -O1 matters because it implies -fmerge-constants.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #2 from Tom Honermann --- (In reply to Tom Honermann from comment #1) Actually, the test case in comment 1 seems to be a different issue; its failure is a regression introduced in r234231 via bug 70095. As of r234231 (and up through at least r234502), the test case in comment 0 triggers an ICE. $ g++ -std=c++14 t.cpp -o t t.cpp:9:31: error: Two symbols with same comdat_group are not linked by the same_comdat_group list. auto&& b = foo>; ^ foo/3 (A foo) @0x7f6c0f987000 Type: variable definition analyzed Visibility: public weak comdat comdat_group:foo one_only previous sharing asm name: 2 References: Referring: b/1 (addr)_Z41__static_initialization_and_destruction_0ii/5 (addr) Availability: not-ready Varpool flags: foo/2 (A foo) @0x7f6c0f97cf80 Type: variable definition analyzed Visibility: public weak comdat comdat_group:foo one_only next sharing asm name: 3 References: Referring: a/0 (addr)_Z41__static_initialization_and_destruction_0ii/5 (addr) Availability: not-ready Varpool flags: t.cpp:9:31: internal compiler error: symtab_node::verify failed 0x928ee1 symtab_node::verify_symtab_nodes() ../../gcc-trunk/gcc/symtab.c:1219 0x93ba14 symtab_node::checking_verify_symtab_nodes() ../../gcc-trunk/gcc/cgraph.h:602 0x93ba14 symbol_table::compile() ../../gcc-trunk/gcc/cgraphunit.c:2380 0x93df87 symbol_table::compile() ../../gcc-trunk/gcc/cgraphunit.c:2536 0x93df87 symbol_table::finalize_compilation_unit() ../../gcc-trunk/gcc/cgraphunit.c:2562
[Bug target/70429] Wrong code with -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70429
Kirill Yukhin changed:
What|Removed |Added
CC||kyukhin at gcc dot gnu.org
--- Comment #4 from Kirill Yukhin ---
Seems like combiner performs invalid reassociation. This trivial addition to
Jakub's PR70222 fix makes test work:
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -10526,7 +10526,7 @@ simplify_shift_const_1 (enum rtx_code code,
machine_mode result_mode,
{
/* For ((unsigned) (cstULL >> count)) >> cst2 we have to make
sure the result will be masked. See PR70222. */
- if (code == LSHIFTRT
+ if ((code == LSHIFTRT || code == ASHIFTRT)
&& mode != result_mode
&& !merge_outer_ops (&outer_op, &outer_const, AND,
GET_MODE_MASK (result_mode)
[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70416 --- Comment #16 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #15) > (In reply to Oleg Endo from comment #14) > > > > Maybe at that stage in the reload code it will end up using the last *addsi3 > > pattern and not try to look for a new pattern in the .md when it wants to > > change it. In other words, maybe it'll help if the *addsi3 patterns are > > merged into a single pattern somehow. I'll give it a try... > > The following seems to fix the problem: Wow, great to hear :).
[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70416 --- Comment #17 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #16) > > Wow, great to hear :). I'm now testing this patch on sh-elf...
[Bug c++/70430] New: Incorrect result for logical "and" operation with mixed vector and scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70430
Bug ID: 70430
Summary: Incorrect result for logical "and" operation with
mixed vector and scalar
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mjh at edg dot com
Target Milestone: ---
I'm seeing surprising results at run time when mixing a vector and a scalar in
a logical "and" operation:
$ cat foo.C
extern "C" int printf (const char *, ...);
typedef int v4si __attribute__ ((vector_size (16)));
int main() {
v4si a = {1,1,1,1}, b = {1,0,-1,2}, x = {-1,-1,-1,-1}, z = {0,0,0,0}, c;
c = a && b; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = x && b; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = (v4si){1,1,1,1} && b;printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = 1 && b; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = b && a; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = b && x; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = b && (v4si){1,1,1,1};printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
printf("bug:\n");
c = b && 1; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]); //?
c = z && b; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = (v4si){0,0,0,0} && b;printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = 0 && b; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = b && z; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
c = b && (v4si){0,0,0,0};printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]);
printf("bug:\n");
c = b && 0; printf("%d %d %d %d\n", c[0], c[1], c[2], c[3]); //?
return 0;
}
$ g++520 foo.C && a.out
-1 0 -1 -1
-1 0 -1 -1
-1 0 -1 -1
-1 0 -1 -1
-1 0 -1 -1
-1 0 -1 -1
-1 0 -1 -1
bug:
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
bug:
-1 0 -1 -1
$
These two cases (i.e., with an initial vector and a subsequent scalar) seem to
give the opposite result of what I would expect. I didn't check to see if
logical "or" has similar issues.
[Bug target/70107] ICE: in emit_move_insn, at expr.c:3546 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70107 --- Comment #2 from Bill Schmidt --- Could not confirm with trunk r234476 on powerpc64le dated 2016-03-24. Can you please retry with something at least that recent?
[Bug target/70107] ICE: in emit_move_insn, at expr.c:3546 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70107 --- Comment #3 from Bill Schmidt --- Also, on latest GCC 5 and GCC 4.9, the front end objects: wschmidt@genoa:~/src$ $GCC_INSTALL/bin/g++ -w -c -mcpu=power8 pr70107.ii pr70107.ii:3:46: error: expected type-specifier before 'decltype' auto operator()(T Base::*, Derived ref) -> decltype(ref); ^ pr70107.ii:3:46: error: expected initializer before 'decltype' pr70107.ii: In function 'void test_b12(Functor)': pr70107.ii:8:9: error: expected nested-name-specifier before 'ClassFunc' using ClassFunc = Signature TestClass::*; ^ pr70107.ii:9:3: error: 'ClassFunc' was not declared in this scope ClassFunc b; ^ pr70107.ii:10:5: error: 'b' was not declared in this scope a(b, f); ^ wschmidt@genoa:~/src$
[Bug target/70107] ICE: in emit_move_insn, at expr.c:3546 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70107 --- Comment #4 from Markus Trippelsdorf --- You need to add "-std=c++11 -fpermissive" to gcc < 6. Trunk seems to be fixed, but gcc-5 and gcc-4.9 still ICE.
[Bug fortran/70397] [5/6 Regression] ice while allocating ultimate polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70397 --- Comment #2 from vehre at gcc dot gnu.org --- Author: vehre Date: Mon Mar 28 16:29:14 2016 New Revision: 234507 URL: https://gcc.gnu.org/viewcvs?rev=234507&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-03-28 Andre Vehreschild PR fortran/70397 * trans-expr.c (gfc_class_len_or_zero_get): Add function to return a constant zero tree, when the class to get the _len component from is not unlimited polymorphic. (gfc_copy_class_to_class): Use the new function. * trans.h: Added interface of new function gfc_class_len_or_zero_get. gcc/testsuite/ChangeLog: 2016-03-28 Andre Vehreschild PR fortran/70397 * gfortran.dg/unlimited_polymorphic_25.f90: New test. * gfortran.dg/unlimited_polymorphic_26.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-expr.c branches/gcc-5-branch/gcc/fortran/trans.h branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug testsuite/64177] Various cilk+ testsuite failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64177
iverbin at gcc dot gnu.org changed:
What|Removed |Added
CC||iverbin at gcc dot gnu.org,
||tschwinge at gcc dot gnu.org
--- Comment #1 from iverbin at gcc dot gnu.org ---
This issue was discussed here:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01817.html
We need __cilkrts_set_param ("nworkers", "2"); in such tests.
[Bug c++/70430] Incorrect result for logical "and" operation with mixed vector and scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70430 Marc Glisse changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-28 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- cp/typeck.c:4367 op1 = build_conditional_expr (location, op1, z, m1, complain); Argh!!! I don't dare run svn blame, but I am pretty sure that's my fault :-(
[Bug target/70421] [5/6 Regression] wrong code with v16si vector and useless cast at -O -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70421
--- Comment #3 from Zdenek Sojka ---
(In reply to Jakub Jelinek from comment #2)
> Untested fix:
> --- gcc/config/i386/i386.c(revision 234449)
> +++ gcc/config/i386/i386.c(working copy)
> @@ -46930,7 +46930,7 @@ half:
> {
>tmp = gen_reg_rtx (mode);
>emit_insn (gen_rtx_SET (tmp, gen_rtx_VEC_DUPLICATE (mode, val)));
> - emit_insn (gen_blendm (target, tmp, target,
> + emit_insn (gen_blendm (target, target, tmp,
>force_reg (mmode,
> gen_int_mode (1 << elt, mmode;
> }
Thanks, that fixes the testcase and some other miscompiles. I haven't run the
testsuite though.
Is the fact that the useless cast in:
x ^= ((v16si)v)[u[0]];
changes the generated code (makes it significantly worse at all opt levels)
worth creating a PR?
[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235 --- Comment #23 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #22) > Created attachment 38107 [details] > New patch with test. > > With the patch we now get for y=6431.25 > > ru,-8pf18.2 y= 0.01 > > IMO this is the correct rounding. Does someone disagree with that? > > What tests should be removed/added from gfortran.dg/fmt_pf.f90? I think good. With round up, Any x, .01 >= x > 0.0 is .01 .1 >= x > 0.0 is .1
[Bug c++/70431] New: [C++11] Out of line defaulted copy constructor of a union does not compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70431
Bug ID: 70431
Summary: [C++11] Out of line defaulted copy constructor of a
union does not compile.
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vmpstr at chromium dot org
Target Milestone: ---
Given:
union Foo {
Foo() = default;
Foo(const Foo& other);
int a;
float b;
};
Foo::Foo(const Foo& other) = default;
I get the following compilation error:
$ g++ -std=c++11 -c foo.cpp
foo.cpp: In copy constructor ‘Foo::Foo(const Foo&)’:
foo.cpp:1:7: error: initializations for multiple members of ‘Foo’
union Foo {
^
foo.cpp: At global scope:
foo.cpp:9:30: note: synthesized method ‘Foo::Foo(const Foo&)’ first required
here
Foo::Foo(const Foo& other) = default;
^
$ g++ --version
g++ (GCC) 5.3.0
The expected behavior is that this would compile. Note that if the constructor
is inline, then it compiles as expected.
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266 --- Comment #6 from Jason Merrill --- Author: jason Date: Mon Mar 28 20:16:21 2016 New Revision: 234511 URL: https://gcc.gnu.org/viewcvs?rev=234511&root=gcc&view=rev Log: PR c++/70422 PR c++/64266 PR c++/70353 * decl.c, pt.c, constexpr.c: Revert last patch. Added: trunk/gcc/testsuite/g++.old-deja/g++.ext/pretty4.C Removed: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C trunk/gcc/testsuite/g++.dg/ext/fnname5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c
[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 --- Comment #14 from Jason Merrill --- Author: jason Date: Mon Mar 28 20:16:21 2016 New Revision: 234511 URL: https://gcc.gnu.org/viewcvs?rev=234511&root=gcc&view=rev Log: PR c++/70422 PR c++/64266 PR c++/70353 * decl.c, pt.c, constexpr.c: Revert last patch. Added: trunk/gcc/testsuite/g++.old-deja/g++.ext/pretty4.C Removed: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C trunk/gcc/testsuite/g++.dg/ext/fnname5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c
[Bug bootstrap/70422] [6 regression] Bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70422 --- Comment #6 from Jason Merrill --- Author: jason Date: Mon Mar 28 20:16:21 2016 New Revision: 234511 URL: https://gcc.gnu.org/viewcvs?rev=234511&root=gcc&view=rev Log: PR c++/70422 PR c++/64266 PR c++/70353 * decl.c, pt.c, constexpr.c: Revert last patch. Added: trunk/gcc/testsuite/g++.old-deja/g++.ext/pretty4.C Removed: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C trunk/gcc/testsuite/g++.dg/ext/fnname5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c
[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 Jason Merrill changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #15 from Jason Merrill --- Reverted the fix because it broke bootstrap on some targets.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 70353, which changed state. Bug 70353 Summary: [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |---
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266 Jason Merrill changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #7 from Jason Merrill --- Reverted the patch due to bootstrap problems on some targets. Martin, have you tried just building with -fmerge-all-constants? That should provide the effect you are looking for, until the C++ committee decides something about whether __func__ can be shared.
[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64971 --- Comment #8 from Richard Henderson --- Created attachment 38112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38112&action=edit proposed patch Andrew's approach to force the SYMBOL_REF to DImode is certainly one way to approach it; another is to accept the SImode SYMBOL_REF. Which can be done relatively easily with a define_special_predicate. Whichever solution is chosen, there appears to be a disconnect between the call and sibcall patterns: (1) sibcalls fail to check for aarch64_islong_call_p. (2) sibcalls use a combined pattern with aarch64_call_insn_operand and Usf constraint, whereas calls use two separate patterns. This disconnect should be fixed at the same time.
[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353
--- Comment #16 from Martin Sebor ---
I was just about commit the following patch for the failure (false positive) in
the test.
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 234510)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2016-03-28 Martin Sebor
+
+ * g++.dg/ext/fnname5.C: Adjust ERE pattern to anticipate any
+ whitespace character after the .string assembler directive.
+
2016-03-28 Dominique d'Humieres
g++.dg/ext/fnname5.C: Update the test for Darwin.
Index: gcc/testsuite/g++.dg/ext/fnname5.C
===
--- gcc/testsuite/g++.dg/ext/fnname5.C (revision 234510)
+++ gcc/testsuite/g++.dg/ext/fnname5.C (working copy)
@@ -29,5 +29,5 @@ main ()
/* { dg-final { scan-assembler-not "_ZZN1A3fooEvE12__FUNCTION__" } } */
/* { dg-final { scan-assembler-not "_ZZN1A3fooEiE12__FUNCTION__" } } */
/* { dg-final { scan-assembler-not "_ZZN1A3fooEiE19__PRETTY_FUNCTION__" } } */
-/* { dg-final { scan-assembler ".(string|ascii) \"void A::foo\\(int\\)(.0)?\""
} } */
-/* { dg-final { scan-assembler ".(string|ascii) \"foo(.0)?\"" } } */
+/* { dg-final { scan-assembler ".(string|ascii)\[\[:space:\]\]*\"void
A::foo\\(int\\)(.0)?\"" } } */
+/* { dg-final { scan-assembler ".(string|ascii)\[\[:space:\]\]*\"foo(.0)?\"" }
} */
[Bug bootstrap/70422] [6 regression] Bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70422 --- Comment #7 from Jim Wilson --- The function alloc_entries calls fancy_abort with __func__, causing the string to get into the output. This function is inlined into the hash_table expand function, which is then in turn inlined into other functions. Without debug info, there is a single reference to this string, in the hash_table expand function, so it gets emitted into the comdat rodata section for that function. With debug info, we have multiple references to this string. One is in the code for the expand function. The others are symbol table entries for the inlined instances of the alloc_entries and/of hash_table expand functions. dwarf2out calls output_constant_def to get the rtl for a string. output_constant_def calls build_constant_desc which generates the rtl for a string. Without flag_section_anchors, build_constant_desc generates a SYMBOL_REF, and the placement to a section happens later. With flag_section_anchors, build_constant_desc generates a label in a specific section. It calls get_constant_section to get the section, which calls select_section, which is default_elf_select_section, which calls mergeable_constant_section, which calls function_mergeable_rodata_prefix, which uses current_function_decl. So the section placement depends on which function we happen to be in when we see the first reference to the string, which in this case is curr_statistics_hash. So the string gets emitted into different sections with and without debug info when flag_sections_anchors is true. It seems like there are some conflicting goals here. We want to share the string across functions, but we also want to put it in function specific comdat sections. We want the same code with and without debug info, but we have more references to the string with debug info than without. It isn't clear what the solution is. It does appear that the fundamental problem is that the section anchors support in build_constant_desc should not be choosing a section when it is called from dwarf2out.c. The section should be chosen later somehow. Or perhaps just not for debug info references. Not clear how to handle this as the moment.
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266 --- Comment #8 from Jason Merrill --- (In reply to Jason Merrill from comment #7) > until the C++ committee decides something about whether __func__ can be > shared. Actually, C++11 already says "It is unspecified whether such a variable has an address distinct from that of any other object in the program." So it's definitely sharable.
[Bug libgcc/66382] POWER8 Vector optimized implementation of __float128 (IEEE754 128-bit Binary Floating Point)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66382 --- Comment #7 from Michael Meissner --- I do not think it is worthwhile to expand the IEEE 128-bit software emulation routines at the point of call in ISA 2.07 (power8). This is due to the fact that a lot of processing goes on in the emulation library. Now if people were motivated, we could replace the soft-fp functions with tuned versions written for the Power8 ISA. However, I don't think it is going to be an easy task. I'll list the things that come to mind first. They might be able to be done, but it is a time/effort calculation of whether the return on investment is worth it. The first issue is the next ISA (3.0) has support in it already for doing IEEE 128-bit floating point in hardware, including supporting the various rounding modes, etc. If you configure and build gcc with an assembler that supports the ISA 3.0 instruction set, it will add in IFUNC support so that when a program is run on ISA 3.0 hardware, it will automatically use a version of __addkf3 that uses the xsaddqp instruction instead of doing the emulation. So this effort would only be for the current generation of hardware. The next issue is right now you cannot do 64-bit scalar int arithmetic in the VSX unit. At present, the compiler does not allow DImode into the Altivec registers, but the only support for 64-bit integer arithmetic uses an Altivec encoding and only uses Altivec registers (vaddudm, etc.). I am working on patches to allow DImode variables in Altivec registers (and later SImode, HImode, QImode). My first run with the patch shows 1 benchmark 2% faster (perlbench) and one 2% slower (omnetpp), but I feel it needs a lot more tuning. At the moment, that work is lower priority, as I am trying to make __float128 _Complex work as my highest priority (obviously other people could take up this work). After allowing DImode into Altivec registers, and perhaps doing 64-bit arithmetic via the 64-bit integer vector instructions, another issue is that the cycle time of the vector unit is 1/2 that of the GPR unit, so it will need a lot of tuning. I don't think the ISA 2.07 instruction set is general enough to do inserts and extracts of 128-bit values that you would need for packing and unpacking the IEEE 128-bit floating point values. ISA 3.0 has all of this support, including specialized instructions to extract/set the exponent or mantissa, but then it also has the hardware support for IEEE 128-bit floating point. Load/stores are also problematical in ISA 2.07, given there is no d-form addressing for Altivec registers. So if you spill a DImode value in an Altivec register, you need to load up the offset in a GPR to do the memory operation.
[Bug rtl-optimization/70432] New: Move operation across function call to reduce save / restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70432
Bug ID: 70432
Summary: Move operation across function call to reduce save /
restore
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
I have no idea how one would do such a transformation, and there is likely a
dup of this somewhere... The compiler generates much smaller code for f2 than
f1.
void g(void);
int f1(int a,int b,int c){
g();
return a+b+c;
}
int f2(int a,int b,int c){
int r=a+b+c;
g();
return r;
}
f1:
.LFB0:
.cfi_startproc
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
movl%esi, %r12d
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
movl%edi, %ebx
movl%edx, %ebp
callg
leal(%rbx,%r12), %eax
popq%rbx
.cfi_def_cfa_offset 24
addl%ebp, %eax
popq%rbp
.cfi_def_cfa_offset 16
popq%r12
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size f1, .-f1
.p2align 4,,15
.globl f2
.type f2, @function
f2:
.LFB1:
.cfi_startproc
addl%esi, %edi
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
leal(%rdi,%rdx), %ebx
callg
movl%ebx, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
[Bug target/70355] [5/6 Regression] ICE: in simplify_subreg_concatn, at lower-subreg.c:617 with -funroll-loops -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70355 --- Comment #2 from Richard Henderson --- Created attachment 38113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38113&action=edit proposed patch Testing the following, which works on the reduced test case. As a missed-optimization, we really ought to be handling logic operations on these wide types via normal sse logic insns. Perhaps not for V1TI, but definitely for V2TI and V4TI. There's no point in breaking them down into 4 and 8 DImode operations, respectively.
