[Bug c++/90078] New: ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078 Bug ID: 90078 Summary: ICE with deep templates caused by overflow [PATCH] Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wlandry at caltech dot edu Target Milestone: --- Created attachment 46160 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46160=edit Failing test case Compiling the attached code with g++ -O2 ftensorShowcase.cpp -c -ftemplate-depth=100 fails with the internal compiler error below. Using godbolt, it seems that this bug started in gcc 7.1 and is still present in trunk. In gcc/tree-ssa-loop-ivopts.c, there is a cost struct that has a concept of infinity. For very deep, recursive templates, the cost can get larger than 'infinity' (1000). The diff below against trunk implements saturating arithmetic. It seems to work. Thanks. == diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c index a2b6b2b2312..a89782b13d0 100644 --- a/gcc/tree-ssa-loop-ivopts.c +++ b/gcc/tree-ssa-loop-ivopts.c @@ -276,7 +276,11 @@ comp_cost::operator+= (HOST_WIDE_INT c) if (infinite_cost_p ()) return *this; - this->cost += c; + /* Switch around comparison to avoid overflow */ + if (c > infinite_cost.cost - this->cost) +this->cost = infinite_cost.cost; + else +this->cost += c; return *this; } @@ -287,7 +291,11 @@ comp_cost::operator-= (HOST_WIDE_INT c) if (infinite_cost_p ()) return *this; - this->cost -= c; + /* Switch around comparison to avoid overflow */ + if (c < -infinite_cost.cost + this->cost ) +this->cost = infinite_cost.cost; + else +this->cost -= c; return *this; } @@ -298,7 +306,10 @@ comp_cost::operator/= (HOST_WIDE_INT c) if (infinite_cost_p ()) return *this; - this->cost /= c; + if (c == 0) +this->cost = infinite_cost.cost; + else +this->cost /= c; return *this; } @@ -309,7 +320,11 @@ comp_cost::operator*= (HOST_WIDE_INT c) if (infinite_cost_p ()) return *this; - this->cost *= c; + /* Switch around comparison to avoid overflow */ + if (c > infinite_cost.cost / this->cost ) +this->cost = infinite_cost.cost; + else +this->cost *= c; return *this; } == during GIMPLE pass: ivopts ftensorShowcase.cpp: In member function ‘auto& Tensor4_Expr, T, Dim0, Dim1, Dim2, Dim3, i, j, k, l>::operator=(const Tensor4_Expr&) [with B = Tensor3_times_Tensor3_21, const Tensor3, float, float, 100, 100, 1000, 100, 100, 'l', 'm', 'k', 'n', 'o'>; U = float; int Dim1_0 = 100; int Dim1_1 = 100; int Dim1_2 = 100; int Dim1_3 = 100; char i_1 = 'l'; char j_1 = 'm'; char k_1 = 'n'; char l_1 = 'o'; A = float; T = float; int Dim0 = 100; int Dim1 = 100; int Dim2 = 100; int Dim3 = 100; char i = 'l'; char j = 'm'; char k = 'n'; char l = 'o']’: ftensorShowcase.cpp:170:9: internal compiler error: in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6667 auto =(const Tensor4_Expr for instructions.
[Bug target/17108] Store with update not generated for a simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- We currently generate (for -O2 -m64, -O3 unrolls it completely, see comment 7) li 9,8 mtctr 9 .p2align 4,,15 .L2: stfs 1,0(3) addi 3,3,4 bdnz .L2 blr and for -m32 we get li 9,8 addi 3,3,-4 mtctr 9 .p2align 4,,15 .L2: stfsu 1,4(3) bdnz .L2 blr The difference is partly the selected -mcpu=, but that doesn't explain it completely. The gimple passes (probably ivopts) have decided to do a pre_inc here; all differences are at RTL level. Except for -mcpu=power9 they didn't. A case where it works as expected, -O2 -m32 -mcpu=power4, the auto_inc_dec pass does not help (this is caused by rtx_cost issues): starting bb 3 11: [r122:SI]=r127:SF 11: [r122:SI]=r127:SF found mem(11) *(r[122]+0) 10: r122:SI=r122:SI+0x4 10: r122:SI=r122:SI+0x4 found pre inc(10) r[122]+=4 11: [r122:SI]=r127:SF found mem(11) *(r[122]+0) trying SIMPLE_PRE_INC cost failure old=16 new=408 (I have a patch for that). but then combine comes along and does Trying 10 -> 11: 10: r122:SI=r122:SI+0x4 11: [r122:SI]=r127:SF Successfully matched this instruction: (parallel [ (set (mem:SF (plus:SI (reg:SI 122 [ ivtmp.10 ]) (const_int 4 [0x4])) [1 MEM[base: _17, offset: 0B]+0 S4 A32]) (reg/v:SF 127 [ d ])) (set (reg:SI 122 [ ivtmp.10 ]) (plus:SI (reg:SI 122 [ ivtmp.10 ]) (const_int 4 [0x4]))) ]) allowing combination of insns 10 and 11 original costs 4 + 4 = 8 replacement cost 4 -m64 however says Trying 10 -> 11: 10: r122:DI=r122:DI+0x4 11: [r122:DI]=r127:SF Failed to match this instruction: (parallel [ (set (mem:SF (plus:DI (reg:DI 122 [ ivtmp.11 ]) (const_int 4 [0x4])) [1 MEM[base: _17, offset: 0B]+0 S4 A32]) (reg/v:SF 127 [ d ])) (set (reg:DI 122 [ ivtmp.11 ]) (plus:DI (reg:DI 122 [ ivtmp.11 ]) (const_int 4 [0x4]))) ]) Oh dear, we do not have the float load/store-with-update instructions for -m64. On all modern 64-bit CPUs these are cracked, so they execute the same as the separate addi and store instructions, but it costs code space. And if we do not want them we should make them more expensive, not just pretend the insns do not exist :-)
[Bug c/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Jory A. Pratt changed: What|Removed |Added Attachment #46158|0 |1 is obsolete|| --- Comment #1 from Jory A. Pratt --- Created attachment 46159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46159=edit musl has no multlib support and should use lib only Update From: for original author. Do not want to take credit for his work.
[Bug c/90077] New: musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Bug ID: 90077 Summary: musl has no multlib support Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: anarchy at gentoo dot org Target Milestone: --- Created attachment 46158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46158=edit MULTILIB_OSDIRNAMES := for musl only There is no support for multlib on musl and upstream musl does not have any intentions to support anything other then lib gcc should respect that.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #24 from Peter Bergner --- So improve_allocation() initially looks at using r0, but disregards it because check_hard_reg_p() returns false for r0, and that is because we fail this test: /* Checking only profitable hard regs. */ if (! TEST_HARD_REG_BIT (profitable_regs, hard_regno)) return false; I don't know why r0 isn't in profitable_regs for pseudo 116.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #23 from Segher Boessenkool --- It says (I added some debug) Insn 50(l0): point = 27 ignoring for conflicts: (reg:SI 0 r0 [ a ]) but non_conflicting_reg_copy_p isn't called at all where it is improving the allocation
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-12 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Another way to do it is as an FMA in float mode, which should be faster everywhere (everywhere that has FMA). Current GCC doesn't do that either, not if you write 5* (it does a mulli), nor if you write 5.0* (it does the calculation in double precision, and rounds to single precision afterwards; it would give the exact same result if it did the calculation in single precision directly, afaics, bot when using FMA and when not). Confirmed.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #22 from Peter Bergner --- (In reply to Wilco from comment #21) > (In reply to Vladimir Makarov from comment #20) >> The question is why p116 conflicts with hr0. Before RA we have > > That's a bug since register copies should not create a conflict. It's one of > the most basic optimization of register allocator. > > And there is also the question why we do move r0 into a virtual register but > not assign the virtual register to an argument register. We don't since my patch adding that support in current trunk. That said, if non_conflicting_reg_copy_p() returns NULL_RTX for that r116=r0 copy insn, then they will conflict. So what does non_conflicting_reg_copy_p() return? ...and if it says they conflict, why? The insn has side effects or SImode is a register pair on arm or ???
[Bug c/89798] excessive vector_size silently accepted and truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798 --- Comment #7 from Martin Sebor --- Author: msebor Date: Fri Apr 12 22:37:12 2019 New Revision: 270331 URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev Log: Commit a change missed in r270326: gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . Modified: trunk/gcc/c-family/c-attribs.c
[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797 --- Comment #6 from Martin Sebor --- Author: msebor Date: Fri Apr 12 22:37:12 2019 New Revision: 270331 URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev Log: Commit a change missed in r270326: gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . Modified: trunk/gcc/c-family/c-attribs.c
[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 --- Comment #5 from Martin Sebor --- Author: msebor Date: Fri Apr 12 22:37:12 2019 New Revision: 270331 URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev Log: Commit a change missed in r270326: gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . Modified: trunk/gcc/c-family/c-attribs.c
[Bug c/88383] ICE calling _builtin_has_attribute with an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 --- Comment #5 from Martin Sebor --- Author: msebor Date: Fri Apr 12 22:37:12 2019 New Revision: 270331 URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev Log: Commit a change missed in r270326: gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . Modified: trunk/gcc/c-family/c-attribs.c
[Bug c/89933] [7/8 Regression] ICE in merge_decls, at c/c-decl.c:2517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89933 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |merge_decls, at |merge_decls, at |c/c-decl.c:2517 |c/c-decl.c:2517 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/89933] [7/8/9 Regression] ICE in merge_decls, at c/c-decl.c:2517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89933 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 21:45:54 2019 New Revision: 270329 URL: https://gcc.gnu.org/viewcvs?rev=270329=gcc=rev Log: PR c/89933 c/ * c-decl.c (merge_decls): When newdecl's type is its main variant, don't try to remove it from the variant list, but instead assert it has no variants. cp/ * decl.c (duplicate_decls): When newdecl's type is its main variant, don't try to remove it from the variant list, but instead assert it has no variants. testsuite/ * c-c++-common/pr89933.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr89933.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081 --- Comment #8 from Jason Merrill --- Created attachment 46157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46157=edit fix Here's a patch. I'm not sure if it will go into GCC 9 or 10.
[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #21 from Wilco --- (In reply to Vladimir Makarov from comment #20) > (In reply to Wilco from comment #19) > > (In reply to Peter Bergner from comment #18) > > > (In reply to Segher Boessenkool from comment #15) > > > > Popping a5(r116,l0) -- assign reg 3 > > > > Popping a3(r112,l0) -- assign reg 4 > > > > Popping a2(r114,l0) -- assign reg 3 > > > > Popping a0(r111,l0) -- assign reg 0 > > > > Popping a4(r117,l0) -- assign reg 0 > > > > Popping a1(r113,l0) -- assign reg 2 > > > > Assigning 4 to a5r116 > > > > Disposition: > > > > 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 > > > >3 > > > > 5:r116 l0 44:r117 l0 0 > > > > > > > > > > > > r116 does not conflict with *any* other pseudo. It is alive in the > > > > first > > > > two insns of the function, which are > > > > > > So we initially assign r3 to r116 presumably because it has the same cost > > > as > > > the other gprs and it occurs first in REG_ALLOC_ORDER. Then > > > improve_allocation() decides that r4 is a better hard reg and switches the > > > assignment to that. I'm not sure why it wouldn't choose r0 there instead. > > > > I would expect that r116 has a strong preference for r0 given the r116 = mov > > r0 and thus allocating r116 to r0 should have the lowest cost by a large > > margin. > > p116 conflicts with hr0. Therefore it can not get hr0. p112 is connected > with p116. p112 got hr4 and p116 got 3. Assigning 4 to 116 is profitable. > Therefore assignment of p116 is changed to 4. > > The question is why p116 conflicts with hr0. Before RA we have That's a bug since register copies should not create a conflict. It's one of the most basic optimization of register allocator. And there is also the question why we do move r0 into a virtual register but not assign the virtual register to an argument register.
[Bug fortran/90076] New: Polymorphic Allocate on Assignment Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90076 Bug ID: 90076 Summary: Polymorphic Allocate on Assignment Memory Leak Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brichardson at structint dot com Target Milestone: --- Allocate on assignment for polymorphic scalars causes a memory leak. The following program and execution demonstrates the problem. program assignment_memory_leak implicit none type, abstract :: base end type base type, extends(base) :: extended end type extended call run() contains subroutine run() class(base), allocatable :: var allocate(var, source = newVar()) var = newVar() ! This is a memory leak end subroutine run function newVar() class(base), allocatable :: newVar allocate(newVar, source = extended()) end function newVar end program assignment_memory_leak $ gfortran -g assignment_memory_leak.f90 -o assignment_memory_leak $ valgrind --leak-check=full ./assignment_memory_leak ==10130== Memcheck, a memory error detector ==10130== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==10130== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==10130== Command: ./assignment_memory_leak ==10130== ==10130== ==10130== HEAP SUMMARY: ==10130== in use at exit: 2 bytes in 2 blocks ==10130== total heap usage: 24 allocs, 22 frees, 13,523 bytes allocated ==10130== ==10130== 1 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==10130==at 0x483777F: malloc (vg_replace_malloc.c:299) ==10130==by 0x109241: newvar.3789 (assignment_memory_leak.f90:22) ==10130==by 0x1092D9: run.3791 (assignment_memory_leak.f90:15) ==10130==by 0x1091D6: MAIN__ (assignment_memory_leak.f90:10) ==10130==by 0x10947F: main (assignment_memory_leak.f90:10) ==10130== ==10130== 1 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==10130==at 0x483777F: malloc (vg_replace_malloc.c:299) ==10130==by 0x109241: newvar.3789 (assignment_memory_leak.f90:22) ==10130==by 0x10936B: run.3791 (assignment_memory_leak.f90:16) ==10130==by 0x1091D6: MAIN__ (assignment_memory_leak.f90:10) ==10130==by 0x10947F: main (assignment_memory_leak.f90:10) ==10130== ==10130== LEAK SUMMARY: ==10130==definitely lost: 2 bytes in 2 blocks ==10130==indirectly lost: 0 bytes in 0 blocks ==10130== possibly lost: 0 bytes in 0 blocks ==10130==still reachable: 0 bytes in 0 blocks ==10130== suppressed: 0 bytes in 0 blocks ==10130== ==10130== For counts of detected and suppressed errors, rerun with: -v ==10130== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Note that using a version of 9.0 from September that we use at work, the explicit allocate doesn't generate a memory leak, so I'm not worried about that for this bug report. Additionally, If I make the newVar function return the concrete type, I don't get any memory leaks. program assignment_memory_leak implicit none type, abstract :: base end type base type, extends(base) :: extended end type extended call run() contains subroutine run() class(base), allocatable :: var allocate(var, source = newVar()) var = newVar() ! This is fine now end subroutine run function newVar() type(extended) :: newVar end function newVar end program assignment_memory_leak $ gfortran -g assignment_memory_leak.f90 -o assignment_memory_leak $ valgrind --leak-check=full ./assignment_memory_leak ==10176== Memcheck, a memory error detector ==10176== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==10176== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==10176== Command: ./assignment_memory_leak ==10176== ==10176== ==10176== HEAP SUMMARY: ==10176== in use at exit: 0 bytes in 0 blocks ==10176== total heap usage: 22 allocs, 22 frees, 13,521 bytes allocated ==10176== ==10176== All heap blocks were freed -- no leaks are possible ==10176== ==10176== For counts of detected and suppressed errors, rerun with: -v ==10176== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) But if I remove the allocate statement, the compiler segfaults. program assignment_memory_leak implicit none type, abstract :: base end type base type, extends(base) :: extended end type extended call run() contains subroutine run() class(base), allocatable :: var var = newVar() ! This segfaults the compiler end subroutine run function newVar() type(extended) :: newVar end function newVar end program assignment_memory_leak $ gfortran -g assignment_memory_leak.f90 -o assignment_memory_leak assignment_memory_leak.f90:15:0:
[Bug c/90075] New: [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075
Bug ID: 90075
Summary: [AArch64] ICE during RTL pass when member of union
passed to copysignf
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jjhelmus at gmail dot com
Target Milestone: ---
Created attachment 46156
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46156=edit
preprocessed source of code mentioned in report
GCC 8.3.0 as well as other releases in the 8.x and 7.x line fail with an
internal compiler error when compiling the following example with -fPIC and
optimization enabled.
#include
typedef struct { float one, two; } twofloats;
float
bug(twofloats tf)
{
float f1, f2;
union {
twofloats tfloats;
float arr[2];
} utfloats;
utfloats.tfloats = tf;
f1 = utfloats.arr[1];
f2 = copysignf(0, f1);
return f2;
}
Using the gcc 8.3.0 docker image on a AArch64 system (RockChip rk3399) running
Ubunutu 18.04 produces the following results:
root@37bc4cc2fc49:/io# gcc --version
gcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
root@37bc4cc2fc49:/io# gcc -Wall -Wextra -O1 -fPIC -c mre.c
during RTL pass: expand
mre.c: In function 'bug':
mre.c:15:10: internal compiler error: Segmentation fault
f2 = copysignf(0, f1);
^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug debug/90074] New: wrong debug info at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90074
Bug ID: 90074
Summary: wrong debug info at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It's a latent issue which affects 4.8-6, and 8-trunk. Gcc-7 works fine.
It happens at -O3 only. Bisect between gcc-7 and gcc-8 points to r255267.
$ gcc-trunk -v
gcc version 9.0.1 20190412 (experimental) [trunk revision 270309] (GCC)
$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
## wrong result ##
$ gcc-trunk abc.c outer.c -g -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400394: file abc.c, line 12.
Breakpoint 1, main () at abc.c:12
12optimize_me_not();
$1 = 0
## correct result ##
$ gcc-trunk abc.c outer.c -g
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40049f: file abc.c, line 12.
Breakpoint 1, main () at abc.c:12
12optimize_me_not();
$1 = 7
$ cat abc.c
char a;
short b[7][1];
int main() {
int i, c;
a = 0;
i = 0;
for (; i < 7; i++) {
c = 0;
for (; c < 1; c++)
b[i][c] = 0;
}
optimize_me_not();
}
$ cat outer.c
void optimize_me_not() {}
$ cat cmds
b 12
r
p i
kill
q
[Bug c/90071] [7/8/9 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-12
CC||jakub at gcc dot gnu.org
Target Milestone|--- |7.5
Summary|internal compiler error:|[7/8/9 Regression] internal
|SSA corruption |compiler error: SSA
||corruption
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
With -O this started with r247495, with -O -fstrict-overflow already with
r229911.
Slightly cleaned up testcase:
int a;
static int b;
void
foo ()
{
int d;
int e = (int) (__INTPTR_TYPE__) &
void *g = &
h: ++e;
if (a)
i: goto *g;
for (;;)
{
e = 0;
if (b)
goto i;
}
f:
goto *({ d || e < 0 || e >= 2; });
}
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #20 from Vladimir Makarov ---
(In reply to Wilco from comment #19)
> (In reply to Peter Bergner from comment #18)
> > (In reply to Segher Boessenkool from comment #15)
> > > Popping a5(r116,l0) -- assign reg 3
> > > Popping a3(r112,l0) -- assign reg 4
> > > Popping a2(r114,l0) -- assign reg 3
> > > Popping a0(r111,l0) -- assign reg 0
> > > Popping a4(r117,l0) -- assign reg 0
> > > Popping a1(r113,l0) -- assign reg 2
> > > Assigning 4 to a5r116
> > > Disposition:
> > > 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0
> > > 3
> > > 5:r116 l0 44:r117 l0 0
> > >
> > >
> > > r116 does not conflict with *any* other pseudo. It is alive in the first
> > > two insns of the function, which are
> >
> > So we initially assign r3 to r116 presumably because it has the same cost as
> > the other gprs and it occurs first in REG_ALLOC_ORDER. Then
> > improve_allocation() decides that r4 is a better hard reg and switches the
> > assignment to that. I'm not sure why it wouldn't choose r0 there instead.
>
> I would expect that r116 has a strong preference for r0 given the r116 = mov
> r0 and thus allocating r116 to r0 should have the lowest cost by a large
> margin.
p116 conflicts with hr0. Therefore it can not get hr0. p112 is connected with
p116. p112 got hr4 and p116 got 3. Assigning 4 to 116 is profitable.
Therefore assignment of p116 is changed to 4.
The question is why p116 conflicts with hr0. Before RA we have
(insn 50 3 7 2 (set (reg:SI 116)
(reg:SI 0 r0 [ a ]))
"/home/cygnus/vmakarov/build1/trunk/gcc/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c":11:1
181 {*arm_mo\
vsi_insn}
(nil))
---> No reg-dead r0!
because later we have
call_insn 11 9 51 3 (parallel [
(set (reg:SI 0 r0)
(call (mem:SI (symbol_ref:SI ("foo") [flags 0x41]
) [0 foo S4 A32])
(const_int 0 [0])))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
"/home/cygnus/vmakarov/build1/trunk/gcc/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c":16:11
219 {*call_value_symbol}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("foo") [flags 0x41]
)
(nil))
(expr_list (clobber (reg:SI 12 ip))
(expr_list:SI (use (reg:SI 0 r0))
(nil
---> use r0!
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073 --- Comment #5 from Marc Glisse --- Looking at the attached asm, the main issue is PR 55266 (there should be no copying), and how exactly the copies are done (64/128/256 bits) is almost a detail...
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073 --- Comment #4 from Rodrigo --- (In reply to H.J. Lu from comment #3) > Fixed on > > https://gitlab.com/x86-gcc/wip/tree/usr/hjl/pr89226/master > > which will be submitted for GCC 10. > > *** This bug has been marked as a duplicate of bug 89226 *** Thank you very much.
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from H.J. Lu --- Fixed on https://gitlab.com/x86-gcc/wip/tree/usr/hjl/pr89226/master which will be submitted for GCC 10. *** This bug has been marked as a duplicate of bug 89226 ***
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 H.J. Lu changed: What|Removed |Added CC||rcc.dark at gmail dot com --- Comment #7 from H.J. Lu --- *** Bug 90073 has been marked as a duplicate of this bug. ***
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073
--- Comment #2 from Rodrigo ---
(In reply to H.J. Lu from comment #1)
> The problem is with the default -mtune=generic.
>
> [hjl@gnu-cfl-1 gcc]$ cat /tmp/foo.cc
> #include
>
> using data = long long __attribute__((vector_size(64)));
> void f(data& a, const data& x1, const data& x2) {
> a ^= x1 ^ x2;
> }
> [hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -O3 -mtune=skylake -mavx2 /tmp/foo.cc -S
>
> [hjl@gnu-cfl-1 gcc]$ cat foo.s
> .file "foo.cc"
> .text
> .p2align 4
> .globl _Z1fRDv8_xRKS_S2_
> .type _Z1fRDv8_xRKS_S2_, @function
> _Z1fRDv8_xRKS_S2_:
> .LFB5519:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq%rsp, %rbp
> .cfi_def_cfa_register 6
> andq$-64, %rsp
> subq$200, %rsp
> vmovdqa (%rsi), %ymm2
> vmovdqa 32(%rsi), %ymm0
> vpxor (%rdx), %ymm2, %ymm1
> vpxor 32(%rdx), %ymm0, %ymm0
> vpxor (%rdi), %ymm1, %ymm1
> vpxor 32(%rdi), %ymm0, %ymm0
> vmovaps %ymm1, (%rdi)
> vmovaps %ymm0, 32(%rdi)
> vzeroupper
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE5519:
> .size _Z1fRDv8_xRKS_S2_, .-_Z1fRDv8_xRKS_S2_
> .ident "GCC: (GNU) 9.0.1 20190412 (experimental)"
> .section.note.GNU-stack,"",@progbits
> [hjl@gnu-cfl-1 gcc]$
Hi! Using -mtune=skylake or -mtune=haswell doesn't fix the problem in my
installation (GCC 8.2, MingW64) or in GodBolt (8.2, 8.3 and trunk). Do you know
why could it be?
[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Martin Sebor --- Fixed in r270326.
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073
--- Comment #1 from H.J. Lu ---
The problem is with the default -mtune=generic.
[hjl@gnu-cfl-1 gcc]$ cat /tmp/foo.cc
#include
using data = long long __attribute__((vector_size(64)));
void f(data& a, const data& x1, const data& x2) {
a ^= x1 ^ x2;
}
[hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -O3 -mtune=skylake -mavx2 /tmp/foo.cc -S
[hjl@gnu-cfl-1 gcc]$ cat foo.s
.file "foo.cc"
.text
.p2align 4
.globl _Z1fRDv8_xRKS_S2_
.type _Z1fRDv8_xRKS_S2_, @function
_Z1fRDv8_xRKS_S2_:
.LFB5519:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-64, %rsp
subq$200, %rsp
vmovdqa (%rsi), %ymm2
vmovdqa 32(%rsi), %ymm0
vpxor (%rdx), %ymm2, %ymm1
vpxor 32(%rdx), %ymm0, %ymm0
vpxor (%rdi), %ymm1, %ymm1
vpxor 32(%rdi), %ymm0, %ymm0
vmovaps %ymm1, (%rdi)
vmovaps %ymm0, 32(%rdi)
vzeroupper
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE5519:
.size _Z1fRDv8_xRKS_S2_, .-_Z1fRDv8_xRKS_S2_
.ident "GCC: (GNU) 9.0.1 20190412 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 gcc]$
[Bug c/89798] excessive vector_size silently accepted and truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 Known to fail||8.3.0 --- Comment #6 from Martin Sebor --- Fixed in r270326.
[Bug c/88383] ICE calling _builtin_has_attribute with an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Martin Sebor --- Fixed in r270326.
[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 Bug 89288 depends on bug 88383, which changed state. Bug 88383 Summary: ICE calling _builtin_has_attribute with an expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/88383] ICE calling _builtin_has_attribute with an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797 --- Comment #4 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug c/89798] excessive vector_size silently accepted and truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798 --- Comment #5 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 --- Comment #4 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug target/90073] New: Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073
Bug ID: 90073
Summary: Very slow code for AVX2
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rcc.dark at gmail dot com
Target Milestone: ---
Created attachment 46155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46155=edit
Source code and assembly output
Hi all, the following code generates very poor assembly code for AVX2 targets
(GCC 8.2, 8.3 and trunk; compiler flags -O3 -mavx2).
---
#include
using data = long long __attribute__((vector_size(64)));
void f(data& a, const data& x1, const data& x2) {
a ^= x1 ^ x2;
}
---
GCC generates 128-loads and stores, which leads to STLF stalls. Possibly a
duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
ICC generates the expected code. I attach GCC and ICC outputs, but you can
check them here https://godbolt.org/z/bwtGUE
[Bug fortran/90072] New: Polymorphic Dispatch to Polymophic Return Type Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90072 Bug ID: 90072 Summary: Polymorphic Dispatch to Polymophic Return Type Memory Leak Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brichardson at structint dot com Target Milestone: --- It appears that trying to do polymorphic dispatch to a function that has a polymorphic return type leads to a memory leak. But, by using a select type construct, the memory leak doesn't occur. The following program and module demonstrate the problem. program dispatch_memory_leak implicit none call run() contains subroutine run() use types, only: base_returned, base_called, first_extended class(base_called), allocatable :: to_call class(base_returned), allocatable :: to_get allocate(to_call, source = first_extended()) allocate(to_get, source = to_call%get()) ! This is a memory leak deallocate(to_get) select type(to_call) type is (first_extended) allocate(to_get, source = to_call%get()) ! This got fixed end select end subroutine run end program dispatch_memory_leak module types implicit none type, abstract :: base_returned end type base_returned type, extends(base_returned) :: first_returned end type first_returned type, extends(base_returned) :: second_returned end type second_returned type, abstract :: base_called contains procedure(get_), deferred :: get end type base_called type, extends(base_called) :: first_extended contains procedure :: get => getFirst end type first_extended type, extends(base_called) :: second_extended contains procedure :: get => getSecond end type second_extended abstract interface function get_(self) result(returned) import base_called import base_returned class(base_called), intent(in) :: self class(base_returned), allocatable :: returned end function get_ end interface contains function getFirst(self) result(returned) class(first_extended), intent(in) :: self class(base_returned), allocatable :: returned allocate(returned, source = first_returned()) end function getFirst function getSecond(self) result(returned) class(second_extended), intent(in) :: self class(base_returned), allocatable :: returned allocate(returned, source = second_returned()) end function getSecond end module types $ gfortran -c -g types.f90 -o types.o $ gfortran -c -g dispatch_memory_leak.f90 -o dispatch_memory_leak.o $ gfortran -g types.o dispatch_memory_leak.o -o dispatch_memory_leak $ valgrind --leak-check=full ./dispatch_memory_leak ==8261== Memcheck, a memory error detector ==8261== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8261== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==8261== Command: ./dispatch_memory_leak ==8261== ==8261== ==8261== HEAP SUMMARY: ==8261== in use at exit: 2 bytes in 2 blocks ==8261== total heap usage: 26 allocs, 24 frees, 13,525 bytes allocated ==8261== ==8261== 1 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==8261==at 0x483777F: malloc (vg_replace_malloc.c:299) ==8261==by 0x1092EE: __types_MOD_getfirst (types.f90:41) ==8261==by 0x109446: run.3770 (dispatch_memory_leak.f90:13) ==8261==by 0x10973D: MAIN__ (dispatch_memory_leak.f90:4) ==8261==by 0x109789: main (dispatch_memory_leak.f90:4) ==8261== ==8261== 1 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==8261==at 0x483777F: malloc (vg_replace_malloc.c:299) ==8261==by 0x1092EE: __types_MOD_getfirst (types.f90:41) ==8261==by 0x10959A: run.3770 (dispatch_memory_leak.f90:18) ==8261==by 0x10973D: MAIN__ (dispatch_memory_leak.f90:4) ==8261==by 0x109789: main (dispatch_memory_leak.f90:4) ==8261== ==8261== LEAK SUMMARY: ==8261==definitely lost: 2 bytes in 2 blocks ==8261==indirectly lost: 0 bytes in 0 blocks ==8261== possibly lost: 0 bytes in 0 blocks ==8261==still reachable: 0 bytes in 0 blocks ==8261== suppressed: 0 bytes in 0 blocks ==8261== ==8261== For counts of detected and suppressed errors, rerun with: -v ==8261== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Note that the leak that occurs inside the select type construct here appears to have been fixed in the version of 9.0 that we are running at work. (That version is from some time in September). I'm running the official version from Arch Linux.
[Bug c/90071] New: internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071
Bug ID: 90071
Summary: internal compiler error: SSA corruption
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gsocshubham at gmail dot com
CC: mliska at suse dot cz
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 46154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46154=edit
Preprocessed code of program causing ICE "crash1.c"
---COMPILER CONFIGURATION-
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-lto
--disable-bootstrap : (reconfigured) ../gcc/configure --enable-languages=c,c++
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190412 (experimental) (GCC)
-COMMAND LINE USED FOR COMPILATION-
~/pull-gcc-9-trunk/build/gcc/xgcc -B ~/pull-gcc-9-trunk/build/gcc/
-I../../runtime/ crash1.c -w -O1
Unable to coalesce ssa_names 571 and 568 which are marked as MUST COALESCE.
p_61_571(ab) and p_61_568(ab)
during RTL pass: expand
crash1.c: In function ‘func_59’:
crash1.c:1696:20: internal compiler error: SSA corruption
1696 | static struct S0 * func_59(uint16_t p_60, uint32_t p_61, uint16_t
p_62)
|^~~
0xdc07c1 fail_abnormal_edge_coalesce
../../gcc/gcc/tree-ssa-coalesce.c:1002
0xdc07c1 coalesce_partitions
../../gcc/gcc/tree-ssa-coalesce.c:1424
0xdc07c1 coalesce_ssa_name(_var_map*)
../../gcc/gcc/tree-ssa-coalesce.c:1755
0xd585ab remove_ssa_form
../../gcc/gcc/tree-outof-ssa.c:1029
0xd585ab rewrite_out_of_ssa(ssaexpand*)
../../gcc/gcc/tree-outof-ssa.c:1287
0x7f8700 execute
../../gcc/gcc/cfgexpand.c:6314
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
REDUCED CODE
a;
static b;
c() {
int d, e = &
void *g = &
h:
++e;
if (a)
i:
goto *g;
for (;;) {
e = 0;
if (b)
goto i;
}
f:
goto *({ d || e < 0 || e >= 2; });
}
[Bug middle-end/90070] New: Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
Bug ID: 90070
Summary: Add optimization for optimizing small integer values
by fp integral constant
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I was looking at the Spec 2017 imagick benchmark, and in particular at the hot
function in enhance.c.
The code has many places where it has:
typedef struct _PixelPacket
{
unsigned short blue;
unsigned short green;
unsigned short red;
unsigned short opacity;
} PixelPacket;
typedef struct _MagickPixelPacket
{
float red;
float green;
float blue;
float opacity;
float index;
} MagickPixelPacket;
/* ... */
foo () {
MagickPixelPacket aggregate;
/* ... */
aggregate.red+=(5.0)*((r)->red);
/* ... */
}
In particular this becomes:
double temp1 = (double)r->red;
double temp2 = (double)aggregate.red;
double temp3 = temp2 + (temp1 * 5.0);
aggregate.red = (float) temp3;
This is due to 5.0 being considered a double precision constant.
It occurs to me that on many machines, multiplying an int by 5 is cheaper than
multiplying a double by 5.0. In particular, since you are multiply an unsigned
short by 5.0, you know the value will fit in a 32-bit or 64-bit integer. This
would mean the example might be executed as:
long temp1 = (long)r->red;
long temp2 = 5 * temp1;
float temp3 = (float) temp2;
aggregate.red += temp3;
Perhaps for non-fast-math it would need to be optimized as in case there are
rounding issues:
long temp1 = (long)r->red;
long temp2 = 5 * temp1;
double temp3 = aggregate.red;
double temp4 = (float) temp2;
double temp5 = temp3 * temp4;
aggregate.red = (float) temp5;
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070 Michael Meissner changed: What|Removed |Added Target||powerpc64le-gnu-linux, ||powerpc64-gnu-linux CC||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64le-gnu-linux, ||powerpc64-gnu-linux Build||powerpc64le-gnu-linux, ||powerpc64-gnu-linux --- Comment #1 from Michael Meissner --- Obviously this is can speed up various machines, but there might be machines where this is not optimal. Now, in the full benchmark, there are many other things going on, but in looking at the code, I figured this small optimization might help.
[Bug fortran/90069] New: Polymorphic Return Type Memory Leak Without Intermediate Variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90069 Bug ID: 90069 Summary: Polymorphic Return Type Memory Leak Without Intermediate Variable Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brichardson at structint dot com Target Milestone: --- It appears that, if a function returns a polymorphic (i.e. class(thing)) variable, if the result is not assigned to a variable, then a memory leak occurs. The following short program and command output demonstrates the problem. program returned_memory_leak implicit none type, abstract :: base end type base type, extends(base) :: extended end type extended type :: container class(*), allocatable :: thing end type call run() contains subroutine run() type(container) :: a_container a_container = theRightWay() a_container = theWrongWay() end subroutine function theRightWay() type(container) :: theRightWay class(base), allocatable :: thing allocate(thing, source = newAbstract()) theRightWay = newContainer(thing) end function theRightWay function theWrongWay() type(container) :: theWrongWay theWrongWay = newContainer(newAbstract()) end function theWrongWay function newAbstract() class(base), allocatable :: newAbstract allocate(newAbstract, source = newExtended()) end function newAbstract function newExtended() type(extended) :: newExtended end function newExtended function newContainer(thing) class(*), intent(in) :: thing type(container) :: newContainer allocate(newContainer%thing, source = thing) end function newContainer end program returned_memory_leak $ gfortran -g returned_memory_leak.f90 -o returned_memory_leak $ valgrind --leak-check=full ./returned_memory_leak ==7972== Memcheck, a memory error detector ==7972== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7972== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==7972== Command: ./returned_memory_leak ==7972== ==7972== ==7972== HEAP SUMMARY: ==7972== in use at exit: 3 bytes in 3 blocks ==7972== total heap usage: 27 allocs, 24 frees, 13,526 bytes allocated ==7972== ==7972== 1 bytes in 1 blocks are definitely lost in loss record 1 of 3 ==7972==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7972==by 0x1093BD: newabstract.3812 (returned_memory_leak.f90:41) ==7972==by 0x109601: therightway.3816 (returned_memory_leak.f90:28) ==7972==by 0x1098BE: run.3818 (returned_memory_leak.f90:19) ==7972==by 0x1091D6: MAIN__ (returned_memory_leak.f90:14) ==7972==by 0x109AD4: main (returned_memory_leak.f90:14) ==7972== ==7972== 1 bytes in 1 blocks are definitely lost in loss record 2 of 3 ==7972==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7972==by 0x1093BD: newabstract.3812 (returned_memory_leak.f90:41) ==7972==by 0x10945E: thewrongway.3814 (returned_memory_leak.f90:35) ==7972==by 0x109965: run.3818 (returned_memory_leak.f90:20) ==7972==by 0x1091D6: MAIN__ (returned_memory_leak.f90:14) ==7972==by 0x109AD4: main (returned_memory_leak.f90:14) ==7972== ==7972== 1 bytes in 1 blocks are definitely lost in loss record 3 of 3 ==7972==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7972==by 0x1093BD: newabstract.3812 (returned_memory_leak.f90:41) ==7972==by 0x10946D: thewrongway.3814 (returned_memory_leak.f90:35) ==7972==by 0x109965: run.3818 (returned_memory_leak.f90:20) ==7972==by 0x1091D6: MAIN__ (returned_memory_leak.f90:14) ==7972==by 0x109AD4: main (returned_memory_leak.f90:14) ==7972== ==7972== LEAK SUMMARY: ==7972==definitely lost: 3 bytes in 3 blocks ==7972==indirectly lost: 0 bytes in 0 blocks ==7972== possibly lost: 0 bytes in 0 blocks ==7972==still reachable: 0 bytes in 0 blocks ==7972== suppressed: 0 bytes in 0 blocks ==7972== ==7972== For counts of detected and suppressed errors, rerun with: -v ==7972== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) Note, whatever leak is happening in theRightWay function appears to have been fixed in the version of 9.0 from September that we are using at work, so don't worry about that one for this bug report. I'm using the official version on Arch Linux in the above.
[Bug fortran/90068] New: Array Constructor Containing Function Call Leaks Memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90068 Bug ID: 90068 Summary: Array Constructor Containing Function Call Leaks Memory Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brichardson at structint dot com Target Milestone: --- It appears that without an intermediate value to save the result of the function call, the value returned by the function ends up being leaked memory. The following example program and commands demonstrate the problem. program array_memory_leak implicit none type, abstract :: base end type base type, extends(base) :: extended end type extended type :: container class(base), allocatable :: thing end type type, extends(base) :: collection type(container), allocatable :: stuff(:) end type collection call run() contains subroutine run() type(collection) :: my_thing type(container) :: a_container a_container = newContainer(newExtended()) ! This is fine my_thing = newCollection([a_container]) my_thing = newCollection([newContainer(newExtended())]) ! This is a memory leak end subroutine run function newExtended() type(extended) :: newExtended end function newExtended function newContainer(thing) class(base), intent(in) :: thing type(container) :: newContainer allocate(newContainer%thing, source = thing) end function newContainer function newCollection(things) type(container), intent(in) :: things(:) type(collection) :: newCollection newCollection%stuff = things end function newCollection end program array_memory_leak $ gfortran -g array_memory_leak.f90 -o array_memory_leak $ valgrind --leak-check=full ./array_memory_leak ==7652== Memcheck, a memory error detector ==7652== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7652== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==7652== Command: ./array_memory_leak ==7652== ==7652== ==7652== HEAP SUMMARY: ==7652== in use at exit: 1 bytes in 1 blocks ==7652== total heap usage: 29 allocs, 28 frees, 13,554 bytes allocated ==7652== ==7652== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==7652==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7652==by 0x109A0B: newcontainer.3817 (array_memory_leak.f90:38) ==7652==by 0x10A17C: run.3822 (array_memory_leak.f90:27) ==7652==by 0x1091E6: MAIN__ (array_memory_leak.f90:18) ==7652==by 0x10A96B: main (array_memory_leak.f90:18) ==7652== ==7652== LEAK SUMMARY: ==7652==definitely lost: 1 bytes in 1 blocks ==7652==indirectly lost: 0 bytes in 0 blocks ==7652== possibly lost: 0 bytes in 0 blocks ==7652==still reachable: 0 bytes in 0 blocks ==7652== suppressed: 0 bytes in 0 blocks ==7652== ==7652== For counts of detected and suppressed errors, rerun with: -v ==7652== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) I'm running the official version of gcc on Arch Linux. I'm also running a version of 9.0 from September at work, which exhibits the same behavior.
[Bug translation/90041] Command line option without proper quoting in translation message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90041 --- Comment #5 from Jakub Jelinek --- %e/%n still not resolved and won't be until GCC 10.
[Bug rtl-optimization/89965] [8 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] wrong code |[8 Regression] wrong code |with -O -mtune=nano-x2 |with -O -mtune=nano-x2 |-fcaller-saves |-fcaller-saves |-fexpensive-optimizations |-fexpensive-optimizations |-fno-tree-dce -fno-tree-ter |-fno-tree-dce -fno-tree-ter Known to fail|9.0 | --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/89965] [8/9 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 16:20:21 2019 New Revision: 270323 URL: https://gcc.gnu.org/viewcvs?rev=270323=gcc=rev Log: PR rtl-optimization/89965 * dce.c: Include rtl-iter.h. (struct check_argument_load_data): New type. (check_argument_load): New function. (find_call_stack_args): Check for loads from stack slots still tracked in sp_bytes and punt if any is found. * gcc.target/i386/pr89965.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr89965.c Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/testsuite/ChangeLog
[Bug translation/90041] Command line option without proper quoting in translation message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90041 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 16:12:49 2019 New Revision: 270321 URL: https://gcc.gnu.org/viewcvs?rev=270321=gcc=rev Log: PR translation/90041 * exgettext: Print MissingArgError, UnknownError or Warn *.opt argument using error or warning instead of _ to mark it as gcc-internal-format. * c.opt (-fhandle-exceptions): Use %< and %> around option names in the Warn diagnostics. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/po/ChangeLog trunk/gcc/po/exgettext
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #19 from Wilco --- (In reply to Peter Bergner from comment #18) > (In reply to Segher Boessenkool from comment #15) > > Popping a5(r116,l0) -- assign reg 3 > > Popping a3(r112,l0) -- assign reg 4 > > Popping a2(r114,l0) -- assign reg 3 > > Popping a0(r111,l0) -- assign reg 0 > > Popping a4(r117,l0) -- assign reg 0 > > Popping a1(r113,l0) -- assign reg 2 > > Assigning 4 to a5r116 > > Disposition: > > 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3 > > 5:r116 l0 44:r117 l0 0 > > > > > > r116 does not conflict with *any* other pseudo. It is alive in the first > > two insns of the function, which are > > So we initially assign r3 to r116 presumably because it has the same cost as > the other gprs and it occurs first in REG_ALLOC_ORDER. Then > improve_allocation() decides that r4 is a better hard reg and switches the > assignment to that. I'm not sure why it wouldn't choose r0 there instead. I would expect that r116 has a strong preference for r0 given the r116 = mov r0 and thus allocating r116 to r0 should have the lowest cost by a large margin.
[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Polacek --- Fixed for GCC 9 (all dialects changed).
[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603 --- Comment #10 from Marek Polacek --- Author: mpolacek Date: Fri Apr 12 15:29:03 2019 New Revision: 270320 URL: https://gcc.gnu.org/viewcvs?rev=270320=gcc=rev Log: PR c++/87603 - constexpr functions are no longer noexcept. * constexpr.c (is_sub_constant_expr): Remove unused function. * cp-tree.h (is_sub_constant_expr): Remove declaration. * except.c (check_noexcept_r): Don't consider a call to a constexpr function noexcept. * g++.dg/cpp0x/constexpr-noexcept.C: Adjust the expected result. * g++.dg/cpp0x/constexpr-noexcept3.C: Likewise. * g++.dg/cpp0x/constexpr-noexcept4.C: Likewise. * g++.dg/cpp0x/constexpr-noexcept8.C: New test. * g++.dg/cpp0x/inh-ctor32.C: Remove dg-message. * g++.dg/cpp1y/constexpr-noexcept1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept8.C trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-noexcept1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept3.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept4.C trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor32.C
[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055 --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > Fixed on trunk with r250959 which is: > > 364bc5b93b76cf88(08 Aug 2017 14:09): [took: 2.844s] result: OK > sum: 0. > SVN revision: 250959 > Author: amker > * doc/invoke.texi: Document -ftree-loop-distribution for O3. > * opts.c (default_options_table): Add OPT_ftree_loop_distribution. > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250959 > 138bc75d-0d04-0410-961f-82ee72b054a4 > > Using: > gcc pr90055.c -O3 -ffast-math -march=haswell -mtune=haswell > -fno-tree-loop-distribution > > it disappeared in r253934: > > Author: hubicka > * x86-tune-costs.h (core_cost): Fix div, move and sqrt latencies. Those look like they are all would cause the issue to go latent. > > and it started with r238033. This one does it might be the real cause of the issue.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #18 from Peter Bergner --- (In reply to Segher Boessenkool from comment #15) > Popping a5(r116,l0) -- assign reg 3 > Popping a3(r112,l0) -- assign reg 4 > Popping a2(r114,l0) -- assign reg 3 > Popping a0(r111,l0) -- assign reg 0 > Popping a4(r117,l0) -- assign reg 0 > Popping a1(r113,l0) -- assign reg 2 > Assigning 4 to a5r116 > Disposition: > 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3 > 5:r116 l0 44:r117 l0 0 > > > r116 does not conflict with *any* other pseudo. It is alive in the first > two insns of the function, which are So we initially assign r3 to r116 presumably because it has the same cost as the other gprs and it occurs first in REG_ALLOC_ORDER. Then improve_allocation() decides that r4 is a better hard reg and switches the assignment to that. I'm not sure why it wouldn't choose r0 there instead.
[Bug target/89993] Inconsistent incoming stack boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89993 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from H.J. Lu --- -mstackrealign works as intended. It will align the stack for the function and won't align the stack for the outgoing stack.
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #4 from rene.r...@fu-berlin.de --- Hi gcc-team, is there any news about this issue? This ICE currently is always triggered when using the range-v3 library using the 1.0-beta branch with concepts. Let me know, if you need more information. Kind regards
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #45 from Ramana Radhakrishnan ---
(In reply to Jakub Jelinek from comment #42)
> Thanks for the explanation.
> In that case, I think it would be better to just add
> __attribute__((target("general-regs-only")))
> to the
> #ifdef __ARM_EABI_UNWINDER__
> _Unwind_Reason_Code
> PERSONALITY_FUNCTION (_Unwind_State, struct _Unwind_Exception *,
> struct _Unwind_Context *);
> decl in unwind-c.c and similarly for eh_personality.cc and to other
> personality routines that use CONTINUE_UNWINDING as well (plus to
> unwind-arm.c and pr-support.c using pragma for everything).
Thanks for all the analysis, this is what I had - I've been swamped this week
on a few other things, let me get this wrapped up soonish. (read it as during
next week).(In reply to Bernd Edlinger from comment #44)
> Comment on attachment 46013 [details]
> updated patch.
>
> @@ -122,12 +122,21 @@ extern tree arm_fp16_type_node;
> #define TARGET_32BIT_P(flags) (TARGET_ARM_P (flags) || TARGET_THUMB2_P
> (flags))
>
> /* Run-time Target Specification. */
> -/* Use hardware floating point instructions. */
> +/* Use hardware floating point instructions. -mgeneral-regs-only prevents
> +the use of floating point instructions and registers but does not prevent
> +emission of floating point pcs attributes. */
> #define TARGET_HARD_FLOAT(arm_float_abi != ARM_FLOAT_ABI_SOFT\
> + && bitmap_bit_p (arm_active_target.isa, \
> + isa_bit_vfpv2) \
> + && TARGET_32BIT \
> + && !TARGET_GENERAL_REGS_ONLY)
> +
> +#define TARGET_HARD_FLOAT_SUB(arm_float_abi != ARM_FLOAT_ABI_SOFT
> \
>&& bitmap_bit_p (arm_active_target.isa, \
> isa_bit_vfpv2) \
>&& TARGET_32BIT)
>
>
> BTW, you could define TARGET_HARD_FLOAT in terms of TARGET_HARD_FLOAT_SUB and
> !TARGET_GENERAL_REGS_ONLY.
Yep I could - been traveling quite a lot and I haven't managed to find someone
else to catch this - I will pick this up next week .
My fault, apologies.
Ramana
[Bug fortran/90067] New: Loop variables in Fortran 'do' statements within a compute construct must be predetermined private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067 Bug ID: 90067 Summary: Loop variables in Fortran 'do' statements within a compute construct must be predetermined private Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- Found while working on PR90048. OpenACC 2.6 (same in 2.7), in section 2.6.1. "Variables with Predetermined Data Attributes" states that "The loop variable in a C 'for' statement or Fortran 'do' statement that is associated with a loop directive is predetermined to be private to each thread that will execute each iteration of the loop. Loop variables in Fortran 'do' statements within a compute construct are predetermined to be private to the thread that executes the loop". Regarding the latter, for Fortran 'do' statements that are not directly associated with a 'loop' directive, when these 'do' statements are (somewhere) nested inside a 'loop' construct, we implement this in the front end by adding a 'private' clause to the containing 'loop' construct, but when these 'do' statements are not (somewhere) nested inside a 'loop' construct, we do not add a 'private' clause to the containing compute construct. For example, for: integer :: i !$acc parallel do i = 1, 100 end do !$acc end parallel ..., we do not in the front end add a 'private(i)' clause to the 'parallel' construct. By the rules as presented in section 2.5. "Compute Constructs", the gimplifier will then fix this up by adding a 'firstprivate' clause, in the common case of the 'parallel' construct (same for the 'serial' construct, but a 'copy' clause for the 'kernels' construct!). While it might generally be beneficial to have a pass promoting 'firstprivate(x)' with a dominating write operation on 'x' to 'private(x)', here it would be better (and much simpler) to handle this in the front end.
[Bug translation/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
--- Comment #3 from Michael James ---
HiSimple tests do not seem to be failing here either regardless of
optimisation.They are all producing correct 32 bit load/stores that can be
non-aligned. I shall try and extract the code from my larger project on
Monday.MikePLEASE NOTE email address change to mike@hamble.online
Original message From: "amonakov at gcc dot gnu.org"
Date: 12/04/2019 15:07 (GMT+00:00) To:
mike@hamble.online Subject: [Bug translation/90061] ARM cortex-M hard fault on
64 bit sized
object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061Alexander Monakov changed: What |Removed
|Added
Status|UNCONFIRMED |WAITING Last reconfirmed|
|2019-04-12 CC|
|amonakov at gcc dot gnu.org Ever confirmed|0
|1--- Comment #2 from Alexander Monakov ---Please
provide an example, as a simple smoke-test is compiled correctly:long f(struct
hardwareExample *h){ return h->a + h->b;}producesf: ldr r2, [r0,
#1] @ unaligned ldr r0, [r0, #5] @ unaligned add
r0, r0, r2 bx lr-- You are receiving this mail because:You
reported the bug.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #17 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #15)
> Forming thread by copy 0:a0r111-a4r117 (freq=500):
> Result (freq=3500): a0r111(2500) a4r117(1000)
> Forming thread by copy 2:a3r112-a5r116 (freq=125):
> Result (freq=4500): a3r112(1500) a5r116(3000)
> Forming thread by copy 1:a2r114-a3r112 (freq=62):
> Result (freq=5500): a2r114(1000) a3r112(1500) a5r116(3000)
> Pushing a1(r113,l0)(cost 0)
> Pushing a4(r117,l0)(cost 0)
> Pushing a0(r111,l0)(cost 0)
> Pushing a2(r114,l0)(cost 0)
> Pushing a3(r112,l0)(cost 0)
> Pushing a5(r116,l0)(cost 0)
> Popping a5(r116,l0) -- assign reg 3
> Popping a3(r112,l0) -- assign reg 4
> Popping a2(r114,l0) -- assign reg 3
> Popping a0(r111,l0) -- assign reg 0
> Popping a4(r117,l0) -- assign reg 0
> Popping a1(r113,l0) -- assign reg 2
> Assigning 4 to a5r116
> Disposition:
> 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3
> 5:r116 l0 44:r117 l0 0
>
>
> r116 does not conflict with *any* other pseudo. It is alive in the first
> two insns of the function, which are
>
> (insn 50 3 7 2 (set (reg:SI 116)
> (reg:SI 0 r0 [ a ])) "ira-shrinkwrap-prep-1.c":14:1 181
> {*arm_movsi_insn}
> (nil))
> (insn 7 50 8 2 (parallel [
> (set (reg:CC 100 cc)
> (compare:CC (reg:SI 116)
> (const_int 0 [0])))
> (set (reg/v:SI 112 [ a ])
> (reg:SI 116))
> ]) "ira-shrinkwrap-prep-1.c":17:6 188 {*movsi_compare0}
> (expr_list:REG_DEAD (reg:SI 116)
> (nil)))
>
> r0 _is_ used by a successor (as the argument for the call to foo), but we
> could use r0 for r116 anyway, since what we assign to it is r0 :-)
CCing Vlad on this. I don't see that *movsi_compare0 would in any way prefer
the =r,0 alternative over =r,r and using the =r,r alternative would allow to
remove one instruction.
[Bug fortran/90048] Fortran OpenACC 'private' clause rejected for predetermined private loop iteration variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048 Thomas Schwinge changed: What|Removed |Added Summary|Fortran OpenACC 'private' |Fortran OpenACC 'private' |clause rejected for |clause rejected for |implicitly private loop |predetermined private loop |iteration variable |iteration variable --- Comment #1 from Thomas Schwinge --- (Summary corrected to say "predetermined private" instead of "implicitly private".) OpenACC 2.6 (same in 2.7), in section 2.6.1. "Variables with Predetermined Data Attributes" states that "The loop variable in a C 'for' statement or Fortran 'do' statement that is associated with a loop directive is predetermined to be private to each thread that will execute each iteration of the loop. Loop variables in Fortran 'do' statements within a compute construct are predetermined to be private to the thread that executes the loop". It also states in section 2.6. "Data Environment" that "Variables with predetermined data attributes may not appear in a data clause that conflicts with that data attribute", which can be understood to mean that such variables may (redundantly) appear in clauses that conform with that data attribute.
[Bug gcov-profile/90066] [GCOV] function with inline attribute leading to incorrect coverage for the "if" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90066 Martin Liška changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-12 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- This is again a test-case with a dead condition: _1 = check_int (, 64); i.0_2 = i; if (_1 != i.0_2) goto ; else goto ; : :
[Bug tree-optimization/87008] [8 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #11 from Marc Glisse ---
The original testcase also shows a small, unrelated regression: DSE3 used to be
able to remove the initialization of sum to 0 when there were 2 statements
(setting each element to 0). Now that we vectorize so that sum is initialized
with { 0.0, 0.0 } in a single statement, DSE doesn't manage anymore, it doesn't
see that the 2 writes together cover the whole thing. Probably if we improved
the vectorizer to vectorize this loop (I think the blocker is that we go from
{x,y} to {x+y,x+y}), it would manage again.
[Bug tree-optimization/81435] missing strlen optimization for strcat past the beginning of clear array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81435 --- Comment #3 from Martin Sebor --- I think it means that Andrew is a maintainer of the overall tree-ssa infrastructure. AFAIK, he has not done any work on the strlen optimizations in the file. Jakub is the author of the pass so he knows the most about it. But he's also aware of most bugs that come in so I don't think he needs to be CC'd. Most of the bugs I raised for the strlen pass are enhancements. I noticed them while testing various warnings (-Wstringop-overflow, -Wrestrict, etc.) where they imply false negatives. The optimizations themselves aren't necessarily critical to performance but the better the strlen pass is at optimizing stuff the better the warnings are at finding bugs. I expect to be doing some work on the strlen pass for GCC 10 so I might pick up some of these bugs in the process.
[Bug gcov-profile/90066] New: [GCOV] function with inline attribute leading to incorrect coverage for the "if" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90066
Bug ID: 90066
Summary: [GCOV] function with inline attribute leading to
incorrect coverage for the "if" statement
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
$ cat small.c
int check_int (int *i, int align)
{
*i = 20;
return *i;
}
typedef int aligned __attribute__((aligned(64)));
static void
inline __attribute__((always_inline))
foo (void)
{
aligned i;
if (check_int (, __alignof__(i)) != i)
; // abort ();
}
int main()
{
foo ();
return 0;
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int check_int (int *i, int align)
-:2:{
1:3: *i = 20;
1:4: return *i;
-:5:}
-:6:
-:7:typedef int aligned __attribute__((aligned(64)));
-:8:
-:9:static void
-: 10:inline __attribute__((always_inline))
-: 11:foo (void)
-: 12:{
-: 13: aligned i;
2: 14: if (check_int (, __alignof__(i)) != i)
-: 15:; // abort ();
-: 16:}
-: 17:
1: 18:int main()
-: 19:{
-: 20: foo ();
1: 21: return 0;
-: 22:}
Line #14 is wrongly marked as executed twice. This statement should be only
executed once.
1. While Line #10 @@inline __attribute__((always_inline))@@ is removed, the
result is correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 9
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int check_int (int *i, int align)
-:2:{
1:3: *i = 20;
1:4: return *i;
-:5:}
-:6:
-:7:typedef int aligned __attribute__((aligned(64)));
-:8:
-:9:static void
-: 10:// inline __attribute__((always_inline))
1: 11:foo (void)
-: 12:{
-: 13: aligned i;
1: 14: if (check_int (, __alignof__(i)) != i)
-: 15:; // abort ();
1: 16:}
-: 17:
1: 18:int main()
-: 19:{
1: 20: foo ();
1: 21: return 0;
-: 22:}
2. While Line #12 is not removed, the result is also correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:85.71% of 7
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int check_int (int *i, int align)
-:2:{
1:3: *i = 20;
1:4: return *i;
-:5:}
-:6:
-:7:typedef int aligned __attribute__((aligned(64)));
-:8:
-:9:static void
-: 10:inline __attribute__((always_inline))
-: 11:foo (void)
-: 12:{
-: 13: aligned i;
1: 14: if (check_int
[Bug translation/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-04-12
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Alexander Monakov ---
Please provide an example, as a simple smoke-test is compiled correctly:
long f(struct hardwareExample *h)
{
return h->a + h->b;
}
produces
f:
ldr r2, [r0, #1] @ unaligned
ldr r0, [r0, #5] @ unaligned
add r0, r0, r2
bx lr
[Bug d/90065] Unaligned accesses on strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90065] New: Unaligned accesses on strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065 Bug ID: 90065 Summary: Unaligned accesses on strict-alignment targets Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-* Created attachment 46153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46153=edit src/std/math.d alignment hack I see a couple of tests FAIL due to the same issue on Solaris/SPARC: they die with SIGBUS due to unaligned access, which is a no-no on strict-alignment targets. FAIL: libphobos.phobos_shared/std/math.d execution test Segmentation fault while running unittests: /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:492 extern (C) void core.runtime.runModuleUnitTests().unittestSegvHandler(int, core.sys.posix.signal.siginfo_t*, void*) [0x590cd287] ??:? __sighndlr [0x7eee41bf] /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178 pure nothrow @nogc @trusted real std.math.NaN(ulong) [0x10003744c] /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:1052 nothrow @nogc @safe void std.math.__unittestL1001_11() [0x100037273] /var/gcc/gcc-9.0.1-20190408/11.5-gcc-gas-libphobos/sparc-sun-solaris2.11/libphobos/testsuite/libphobos9/:1 void std.math.__modtest() [0x1000697c3] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558 __foreachbody2 [0x590cd3c7] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599 __lambda2 [0x590f4a2b] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777 __foreachbody2 [0x5910f63f] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69 int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x5911444f] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770 int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x5910f527] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1598 int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x590f26fb] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:548 runModuleUnitTests [0x590cd0b3] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:484 runAll [0x5910323b] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:460 tryExec [0x5910317b] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:493 _d_run_main [0x59103073] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/__entrypoint.di:44 main [0x100069b3f] ??:? _start [0x100032e8b] truss shows the SIGBUS Incurred fault #5, FLTACCESS %pc = 0x10003734C siginfo: SIGBUS BUS_ADRALN addr=0x7FFFD942 Received signal #10, SIGBUS [default] siginfo: SIGBUS BUS_ADRALN addr=0x7FFFD942 but gdb currently mis-reports it as SIGSEGV (as does the libdruntime signal handler). Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x00010003734c in std.math.NaN(ulong) (payload=291) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178 6178*cast(ulong*)(2+cast(ubyte*)()) = v; (gdb) where #0 0x00010003734c in std.math.NaN(ulong) (payload=291) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178 #1 0x000100037174 in std.math.__unittestL1001_11() () at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:1052 #2 0x0001000696c4 in std.math.__modtest() () at :1 #3 0x57bcd3c8 in __foreachbody2 (this=0x7fffdfe8, m=0x1001bfb38 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558 #4 0x57bf4a2c in object.ModuleInfo.__lambda2 ( this=0x7fffdf10, m=0x1001bfb38 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599 #5 0x57c0f640 in rt.minfo.__foreachbody2 (this=0x7fffde38, sg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777 #6 0x57c14450 in rt.sections_elf_shared.DSO.opApply(scope int(ref rt.sections_elf_shared.DSO) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69 #7 0x57c0f528 in rt.minfo.moduleinfos_apply(scope int(immutable(object.ModuleInfo*)) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770 #8 0x57bf26fc in object.ModuleInfo.opApply(scope int(object.ModuleInfo*) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1598 #9 0x57bcd0b4 in runModuleUnitTests () at
[Bug d/90064] InSituRegion lacks SPARC64 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90064] New: InSituRegion lacks SPARC64 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064 Bug ID: 90064 Summary: InSituRegion lacks SPARC64 support Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-* Created attachment 46152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46152=edit InSituRegion SPARC64 support This tests only FAILs on 64-bit SPARC: FAIL: libphobos.phobos_shared/std/experimental/allocator/building_blocks/bitmapped_block.d (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/solaris/libphobos/src/std/experimental/allocator/building_blocks/region.d:402: error: undefined identifier 'growDownwards' /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/experimental/allocator/building_blocks/bitmapped_block.d:698: error: template instance std.experimental.allocator.building_blocks.region.InSituRegion!(10240LU, 64LU) error instantiating /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/experimental/allocator/building_blocks/bitmapped_block.d:700: note: while evaluating: static assert(hasMember!(InSituRegion!(10240LU, 64LU), "allocateAll")) The fix is trivial: just handle SPARC64 like SPARC. The attached patch does that.
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 --- Comment #16 from Marc Glisse --- (In reply to Jakub Jelinek from comment #15) > I certainly do see that. Uh, indeed. I don't remember what I may have tested where we failed to set a range, or maybe I just got confused, better ignore my comment then.
[Bug d/90063] druntime DSO first assertion fails on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90063] New: druntime DSO first assertion fails on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063
Bug ID: 90063
Summary: druntime DSO first assertion fails on Solaris/SPARC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc*-sun-solaris2.11
The next issue with Solaris 11/SPARC execution tests is
FAIL: libphobos.druntime_shared/core/internal/hash.d execution test
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x5e858a5c in gc_malloc (sz=80, ba=0,
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gc/proxy.d:117
117 return instance.malloc(sz, ba, ti);
(gdb) where
#0 0x5e858a5c in gc_malloc (sz=80, ba=0,
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gc/proxy.d:117
#1 0x5e7cc74c in core.memory.GC.malloc(ulong, uint, const(TypeInfo)) (
sz=80, ba=0,
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/memory.d:380
#2 0x5e803b60 in _d_newclass (
ci=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/lifetime.d:96
#3 0x5e7c9df8 in onAssertError (file=..., line=398)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:441
#4 0x5e7ca444 in _d_assert (file=..., line=398)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:641
#5 0x5e815684 in _d_dso_registry (data=0x7fffcfa0)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:398
#6 0x000137cc in gdc.dso_ctor () at :1
#7 0x00012db8 in global constructors keyed to 4core8internal4hash ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/internal/hash.d:1
#8 0x7f3253f0 in call_array () from /usr/lib/sparcv9/ld.so.1
#9 0x7f325590 in call_init () from /usr/lib/sparcv9/ld.so.1
#10 0x7f335524 in elf_bndr () from /usr/lib/sparcv9/ld.so.1
#11 0x7f316488 in elf_rtbndr () from /usr/lib/sparcv9/ld.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
#5 0x5e815684 in _d_dso_registry (data=0x7fffcfa0)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:398
398 assert(handleForAddr(data._slot) ==
handleForAddr(_get_bss_start));
(gdb) p data
$2 = (rt.sections_elf_shared.CompilerDSOData *) 0x7fffcfa0
(gdb) p *data
$3 = {_version = 1, _slot = 0x1001043d8 ,
_minfo_beg = 0x1001043b0 <__start_minfo>, _minfo_end = 0x1001043c8}
I haven't dug further yet why this fails on Solaris/SPARC, but not on
Solaris/x86.
For the moment, I've just disabled the assert.
[Bug tree-optimization/87008] [8 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008 Martin Jambor changed: What|Removed |Added Version|9.0 |8.3.1 Summary|[8/9 Regression] gimple |[8 Regression] gimple |mem-to-mem assignment badly |mem-to-mem assignment badly |optimized |optimized --- Comment #10 from Martin Jambor --- (In reply to Jakub Jelinek from comment #9) > Is this now fixed on the trunk with r269556? Yes. (And I guess it is about time I should start preparing a backport to GCC 8 too.)
[Bug d/90062] SPARC stack alignment is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90062] New: SPARC stack alignment is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062 Bug ID: 90062 Summary: SPARC stack alignment is wrong Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-* Created attachment 46151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46151=edit Correct SPARC stack alignment Even after the ucontext_t and makecontext patches, Solaris/SPARC execution tests were still FAILing (seem to have lost the notes about the details ;-(). However, I found that stack alignment was less than the SPARC ABI requires, i.e. doubleword alignment (also cf. sparc/sparc.h (SPARC_STACK_ALIGN)). The attached patch fixes that. However, I've been lazy and always use the existing 16-byte alignment code, although strictly speaking 32-bit SPARC only needs 8 bytes.
[Bug translation/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061 Michael James changed: What|Removed |Added Target||ARM Cortex M4 --- Comment #1 from Michael James --- I have seen the same bug in I believe versions of GCC from 4.x onwards
[Bug translation/90061] New: ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
Bug ID: 90061
Summary: ARM cortex-M hard fault on 64 bit sized object store
to unaligned address
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: mike at hamble dot online
Target Milestone: ---
When generating code for ARM Cortex M4 CPU, and a 64 bit object is stored in
memory to a possibly unaligned address, the code generated will cause an
exception in the case the address is not single word (32 bit aligned).
This fault is dependent on optimisation level in some cases.
This is because the 64 bit store operation generates either a STD or a STMIA
style instruction which requires 32 bit address alignment.
Single 32 bit word stores can be unaligned.
#pragma pack(push, 1)
struct hardwareExample
{
char x;
long a;
long b;
} s;
#pragma pack(pop)
If you are accessing hardware or message buffers where the structs map 1:1 to
external message content, you may well try to set the value of s.a and s.b
close together. The optimiser may try to combine these as a store multiple
operation on an ARM has always been more efficient than independent writes.
In -Og mode this code generates two independent 32 bit store unaligned
operations and it works.
In -Os mode this code will combine s.a and s.b store into a single STD or STMIA
instruction and produce a hard fault.
If the 64 bit value is an atomic type ; long long or double float for instance
then you cannot escape the hard fault.
In normal code , this problem does not occur as the structure would be created
with the correct alignment for the types, and would be allocated at the correct
alignment for the types concerned.
It is only where I am handling e.g. a binary GPS protocol.
There are always workarounds, it is just annoying that -Og code will work and
-Os code will fail (sometimes dependent on arbitrary structure alignment)
[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89291 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Dominique d'Humieres --- > If someone wants to try to download and build this. Too many prerequisites for me!-( Closing as INVALID.
[Bug d/90060] libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90060] New: libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060 Bug ID: 90060 Summary: libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-sun-solaris2.11 Created attachment 46150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46150=edit Use __makecontext_v2 on Solaris/SPARC With PR d/90059 fixed, (at least) the core.thread unittest FAILs: FAIL: libphobos.druntime_shared/core/thread.d execution test Segmentation fault while running unittests: Program terminated with signal SIGSEGV, Segmentation fault. #0 sparc64_is_sighandler (nframes=, cfa=0x7fffd470, pc=0x7f5c3fc8) at ./md-unwind-support.h:39 39 ./md-unwind-support.h: No such file or directory. [Current thread is 2 (Thread 1 (LWP 1))] (gdb) where #0 sparc64_is_sighandler (nframes=, cfa=0x7fffd470, pc=0x7f5c3fc8) at ./md-unwind-support.h:39 #1 sparc64_fallback_frame_state (fs=0x7fffbf40, context=0x7fffbb50) at ./md-unwind-support.h:271 #2 uw_frame_state_for (context=context@entry=0x7fffbb50, fs=fs@entry=0x7fffbf40) at /builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind-dw2.c:1257 #3 0x73b0ed50 in _Unwind_Backtrace ( trace=0x5d362438 , trace_argument=0x7fffc6d0) at /builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind.inc:290 #4 0x5d3624dc in backtrace_simple (state=0x7f5e8000, skip=, callback=0x5d2e40c4 , error_callback=0x5d2e4c28 , data=0x7fffc860) at /vol/gcc/src/hg/trunk/solaris/libbacktrace/simple.c:106 #5 0x5d2e521c in gcc.backtrace.LibBacktrace.this(int) ( this=0x7fffc860, firstFrame=1) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/backtrace.d:227 #6 0x5d2cd248 in core.runtime.runModuleUnitTests().unittestSegvHandler(int, core.sys.posix.signal.siginfo_t*, void*) (signum=11, info=0x7fffd370, ptr=0x7fffd060) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:492 #7 #8 0x7ef261b0 in memset%sun4v-hwcap4 () from /lib/64/libc.so.1 #9 0x7ede9108 in makecontext () from /lib/64/libc.so.1 #10 0x000100015bbc in core.thread.Fiber.initStack() ( this=0x7f1f6000) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5051 #11 0x000100015930 in core.thread.Fiber.reset() (this=0x7f1f6000) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4294 #12 0x00010001536c in core.thread.Fiber.reset(void() delegate) ( this=0x7f1f6000, dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4309 #13 0x0001000152a4 in core.thread.Fiber.this(void() delegate, ulong, ulong) (this=0x7f1f6000, dg=..., sz=32768, guardPageSize=8192) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4157 #14 0x00010001620c in core.thread.TestFiber.this() ( this=0x7f1f6000) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5175 #15 0x000100016300 in core.thread.runTen() () at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5195 #16 0x000100016578 in core.thread.__unittestL5218_20() () at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5220 #17 0x000100018cf8 in core.thread.__modtest() () at :1 #18 0x5d2cd388 in __foreachbody2 (this=0x7fffe308, m=0x1001208b8 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558 #19 0x5d2f49ec in object.ModuleInfo.__lambda2 ( this=0x7fffe230, m=0x1001208b8 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599 #20 0x5d30f600 in rt.minfo.__foreachbody2 (this=0x7fffe158, sg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777 #21 0x5d314410 in rt.sections_elf_shared.DSO.opApply(scope int(ref rt.sections_elf_shared.DSO) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69 #22 0x5d30f4e8 in rt.minfo.moduleinfos_apply(scope int(immutable(object.ModuleInfo*)) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770 #23 0x5d2f26bc in object.ModuleInfo.opApply(scope int(object.ModuleInfo*) delegate) (dg=...) at
[Bug c++/90058] False Positive in undefined-sanitizer only with GCC8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90058 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- As has been said many times, the -fsanitize= instrumentation affects (sometimes a lot) the optimizations and so introduces various late warning false positives. Use -fsanitize= to build the instrumented code, but pay more attention to warnings from non-instrumented builds.
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 --- Comment #1 from Rainer Orth --- Created attachment 46149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46149=edit Correct Solaris mcontext_t, ucontext_t declarations
[Bug d/90059] New: Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 Bug ID: 90059 Summary: Solaris mcontext_t, ucontext_t declarations are wrong Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.* Initially, all Solaris 11/SPARC execution tests (both 32 and 64-bit) FAILed like this: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfec37d08 in rw_wrlock_impl () from /lib/libc.so.1 (gdb) where #0 0xfec37d08 in rw_wrlock_impl () from /lib/libc.so.1 #1 0xfec3e62c in sigaction () from /lib/libc.so.1 #2 0x000a8be4 in runModuleUnitTests () at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:506 #3 0x0007bfac in runAll (this=this@entry=0xffbfe78c) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:484 #4 0x0007ba9c in tryExec (this=0xffbfe78c, dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:460 #5 0x0007bcb4 in _d_run_main (argc=1, argv=, mainFunc=) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:493 #6 0x000686d4 in main (argc=1, argv=0xffbfe864) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/__entrypoint.di:44 #7 0x000684c4 in _start () Backtrace stopped: previous frame identical to this frame (corrupt stack?) with libphobos built with -g3 -O0: 0xfec37cec : save %sp, -96, %sp 0xfec37cf0 : ld [ %g7 + 0x54 ], %i5 0xfec37cf4 : sethi %hi(0x2800), %i3 0xfec37cf8 : mov %g7, %l6 0xfec37cfc : add %i3, 0x146, %i2 0xfec37d00 : rd %pc, %i4 0xfec37d04 : sethi %hi(0x6a000), %g1 => 0xfec37d08 : ldsb [ %i5 + %i2 ], %l7 (gdb) p/x $i5 $14 = 0x0 (gdb) p/x $i2 $15 = 0x2946 The first arg (an rwlock_t *) should never be NULL. After some debugging, this turned out to be memory corruption happening after the call to swapcontext in fiber_switchContext. The root cause was that the declarations of mcontext_t and ucontext_t in core.sys.posix.ucontext are badly wrong for Solaris/SPARC. After correcting them as in the attached patch, those SEGVs are gone. Solaris/x86 is mostly right, the only correction being the introduction of the uc_xrs member of struct ucontext_t. This doesn't change either size or alignment, so it's primarily a cosmetic issue. This again seems strongly to argue for an approach like libgo's (generating Go structure declarations from the system headers at build time) or at least libsanitizer's (verifying struct sizes and member offsets at runtime) to avoid such isses.
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/90058] New: False Positive in undefined-sanitizer only with GCC8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90058 Bug ID: 90058 Summary: False Positive in undefined-sanitizer only with GCC8 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: svenja.mehringer at gmail dot com Target Milestone: --- Created attachment 46148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46148=edit intermediate cpp file Hi, When compiling with the undefined-sanitizer I get an uninitialized warning with GCC8 but not with GCC7 on the same intermediate file. I created the intermediate file with GCC-7.4.0 (flags: -fsanitize=undefined -fdiagnostics-color=always -O3 -DNDEBUG -pedantic -Wall -Wextra -Werror -std=c++17 -fconcepts -save-temps) Then when compiling the following (GCC-8.2.0) g++-8 -O3 -Wall -fsanitize=undefined -std=c++17 -fconcepts -pthread -o format_sam_test-gcc8 format_sam_test.ii gtest_project/src/gtest_project-build/googletest/libgtest.a gtest_project/src/gtest_project-build/googletest/libgtest_main.a this fails with ``` In file included from /srv/public/smehringer/seqan3/test/unit/io/alignment_file/format_sam_test.cpp:17: /srv/public/smehringer/seqan3/include/seqan3/io/alignment_file/format_sam.hpp: In lambda function: /srv/public/smehringer/seqan3/include/seqan3/io/alignment_file/format_sam.hpp:635:58: warning: ‘*((void*)& +12)’ may be used uninitialized in this function [-Wmaybe-uninitialized] write_range(stream_it, (header.ref_ids())[get<0>(mate).value()]); ``` but the exact same command compiles fine with GCC-7.4.0 I'm working on Linux: Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #15 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #12)
> > Canonical example would be if (int_arg + 32U <= 64U) __builtin_unreachable
> > (),
>
> We don't quite seem to put a range on int_arg with this. We have one
> temporarily, and deduce ranges for things computed based on int_arg, but I
> don't see one on int_arg itself after the pass.
I certainly do see that.
Try -O2 -fdump-tree-all-alias:
int
foo (int int_arg)
{
if (int_arg + 32U <= 64U) __builtin_unreachable ();
return int_arg;
}
Already in the evrp pass there is:
# RANGE ~[-32, 32]
int int_arg_3(D) = int_arg;
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Is this now fixed on the trunk with r269556?
[Bug middle-end/89970] [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Known to fail||8.3.0 --- Comment #5 from Martin Liška --- Fixed on trunk, not planning to backport.
[Bug middle-end/89970] [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970 --- Comment #4 from Martin Liška --- Author: marxin Date: Fri Apr 12 12:54:00 2019 New Revision: 270314 URL: https://gcc.gnu.org/viewcvs?rev=270314=gcc=rev Log: Handle multiple 'default' in target attribute (PR middle-end/89970). 2019-04-12 Martin Liska PR middle-end/89970 * multiple_target.c (create_dispatcher_calls): Wrap ifunc in error message. (separate_attrs): Handle multiple 'default's. (expand_target_clones): Rework error handling code. 2019-04-12 Martin Liska PR middle-end/89970 * gcc.target/i386/mvc15.c: New test. * gcc.target/i386/mvc3.c: Quote target in error pattern. * gcc.target/i386/mvc4.c: Remove duplicit 'default'. Added: trunk/gcc/testsuite/gcc.target/i386/mvc15.c Modified: trunk/gcc/ChangeLog trunk/gcc/multiple_target.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/mvc3.c trunk/gcc/testsuite/gcc.target/i386/mvc4.c
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #17 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Fri Apr 12 12:51:58 2019 New Revision: 270313 URL: https://gcc.gnu.org/viewcvs?rev=270313=gcc=rev Log: gcc/ChangeLog: 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000.c (rs6000_split_vec_extract_var): Use inner mode of vector rather than mode of destination for move instruction. * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-12 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/fold-vec-extract-char.p8.c: Adjust expected instruction counts. * gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise. * gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p8.c trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p8.c trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p8.c
[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075 --- Comment #1 from Hannes Hauswedell --- I see that this has changed for snapshots of GCC9 now, thanks a lot! Is this something you can backport to to GCC7 and GCC8 that would really help downstream projects to reduce needless use of MACROs! Thanks!
[Bug gcov-profile/90057] [GCOV] Wrong coverage for "if()" statement while it is embedded with an empty "for(;0;)" loop statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90057 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk in r263111.
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #67 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #66)
> (In reply to Iain Sandoe from comment #62)
> > (In reply to Iain Sandoe from comment #61)
> > > (In reply to Jonathan Wakely from comment #60)
> > > > PR 81797 was the relevant bug, which apparently is still present for
> > > > darwin
> > > > when using the buggy new APFS filesystem
> > >
> > > so, from discussion on IRC, and notes above, this seems to be a known
> > > issue
> > > (with AFPS only) and the current remedy is to continue the bootstrap.
> > >
> > > Let's consider that we have a viable work-around and then please can we
> > > wait
> > > for a response from Apple and the clang devs before making a final fix?
> > >
> > > (i.e. this is enough of a work-around to prevent folks from being blocked
> > > right now)
> >
> > BTW if you look at
> > https://godbolt.org/z/7nwoLN
> > and flip between C and C++, you will see that clang++ is not generating the
> > same code for _Atomic int x, as clang (C).
>
> Trying clang vs. clang++ (7.0.1) on
> _Atomic int a = 4;
> void foo () { a++; }
> (admittedly on x86_64-linux), I get the same generated code with C and C++,
> except for the mangling of the function, so it seems _Atomic is not ignored.
Indeed, not sure what caused the compiler explorer instance to report
differently, I can't repeat now (for trunk or 7.x clang).
> On the other side, if we fixinclude it, the fixincluded headers will be only
> used for gcc and not clang, right,
right,
I don't see any mechanism at the moment for clang to use GCC's fixed includes
(it could be forced with -isystem, I suppose - but that's the User's decision).
> so the condition I wrote should be
> sufficient. If the fixincluded headers would be also used by clang, then we
> might want to add && !defined(__clang__) to that.
The folks I'm hoping for comments from are travelling this week (or, I think,
in one case on vacation) so perhaps we can wait a few more days for some
conclusion before applying this (it needs to go on the branches too, I
suppose).
[Bug regression/89733] [7/8/9 Regression] -Wuninitialized false positive with unclear message pointing to a class name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733 --- Comment #8 from Jakub Jelinek --- On the reduced testcase the warning is completely correct. end_ is indeed uninitialized and then copied over in the Y constructor. As the ~F destructor is not defined, GCC can't optimize away those stores
[Bug gcov-profile/90053] [GCOV] A statement in while loop is wrongly marked as not executed when they are within the if(setjmp()) statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90053 --- Comment #2 from Yibiao Yang --- (In reply to Richard Biener from comment #1) > I think you need to use setjmp/longjmp, not the __builtin variants which have > special semantics. Thanks for the suggestion. This is a reduced version of the test program in the gcc testsuite: gcc-7.4.0/gcc/testsuite/gcc.dg/setjmp-2.c
[Bug gcov-profile/90054] [GCOV] A call statement to the __builtin_snprintf function is wrongly marked as not executed when it is in a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90054 --- Comment #2 from Yibiao Yang --- (In reply to Martin Liška from comment #1) > Fixed on trunk with r263111. Not planning to backport. Got it. Thanks a lot.
[Bug gcov-profile/90057] New: [GCOV] Wrong coverage for "if()" statement while it is embedded with an empty "for(;0;)" loop statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90057
Bug ID: 90057
Summary: [GCOV] Wrong coverage for "if()" statement while it is
embedded with an empty "for(;0;)" loop statement
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
$ cat small.c
int main()
{
int b = 0, d = 0, f = 0, p = -1;
if (f > p && p)
for (; 0;)
;
else if (d)
b = 0 >= b;
return 0;
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:71.43% of 7
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:
1:2:int main()
-:3:{
1:4: int b = 0, d = 0, f = 0, p = -1;
-:5:
2:6: if (f > p && p)
1:7:for (; 0;)
-:8: ;
#:9: else if (d)
#: 10:b = 0 >= b;
-: 11:
1: 12: return 0;
-: 13:}
Line #6 is wrongly marked as executed twice.
While Line 7 is removed. The result is correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:66.67% of 6
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:
1:2:int main()
-:3:{
1:4: int b = 0, d = 0, f = 0, p = -1;
-:5:
1:6: if (f > p && p)
-:7:// for (; 0;)
-:8: ;
#:9: else if (d)
#: 10:b = 0 >= b;
-: 11:
1: 12: return 0;
-: 13:}
While Line #9 and Line #10 are both removed, the result is also correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 5
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:
1:2:int main()
-:3:{
1:4: int b = 0, d = 0, f = 0, p = -1;
-:5:
1:6: if (f > p && p)
1:7:for (; 0;)
-:8: ;
-:9: // else if (d)
-: 10: // b = 0 >= b;
-: 11:
1: 12: return 0;
-: 13:}
[Bug middle-end/90056] New: 548.exchange2_r regressions on AMD Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90056 Bug ID: 90056 Summary: 548.exchange2_r regressions on AMD Zen Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux As of revision 270053, the 548.exchange2_r benchmark from SPEC 2017 INTrate suite suffered a number of smaller regressions on AMD Zen CPUs: - At -O2, it is 4.5% slower than when compiled with GCC 7 - At -Ofast, it is 4.7% slower than when compiled with GCC 8 - At -Ofast -march=native -mutine=native, this difference is 6.9% - At -Ofast and native tuning, it is 6% slower with PGO than without it. According to https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/options the last regression on a different Ryzen CPU is 6.8 and PGO+LTO is 8.2% slower than just native -Ofast. Bisecting does not help much because the performance of the benchmark has varied a lot. For example in September there was no PGO regression but only because the non-PGO executable was equally slow. I only have data from February from an Intel machine, but there I only saw the native -Ofast regression, but it might have gone away meanwhile. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #66 from Jakub Jelinek ---
(In reply to Iain Sandoe from comment #62)
> (In reply to Iain Sandoe from comment #61)
> > (In reply to Jonathan Wakely from comment #60)
> > > PR 81797 was the relevant bug, which apparently is still present for
> > > darwin
> > > when using the buggy new APFS filesystem
> >
> > so, from discussion on IRC, and notes above, this seems to be a known issue
> > (with AFPS only) and the current remedy is to continue the bootstrap.
> >
> > Let's consider that we have a viable work-around and then please can we wait
> > for a response from Apple and the clang devs before making a final fix?
> >
> > (i.e. this is enough of a work-around to prevent folks from being blocked
> > right now)
>
> BTW if you look at
> https://godbolt.org/z/7nwoLN
> and flip between C and C++, you will see that clang++ is not generating the
> same code for _Atomic int x, as clang (C).
Trying clang vs. clang++ (7.0.1) on
_Atomic int a = 4;
void foo () { a++; }
(admittedly on x86_64-linux), I get the same generated code with C and C++,
except for the mangling of the function, so it seems _Atomic is not ignored.
On the other side, if we fixinclude it, the fixincluded headers will be only
used for gcc and not clang, right, so the condition I wrote should be
sufficient. If the fixincluded headers would be also used by clang, then we
might want to add && !defined(__clang__) to that.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #13 from Martin Liška --- Situation is more complicated, deferring to GCC 10: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00495.html
[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055 Martin Liška changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Martin Liška --- Fixed on trunk with r250959 which is: 364bc5b93b76cf88(08 Aug 2017 14:09): [took: 2.844s] result: OK sum: 0. SVN revision: 250959 Author: amker * doc/invoke.texi: Document -ftree-loop-distribution for O3. * opts.c (default_options_table): Add OPT_ftree_loop_distribution. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250959 138bc75d-0d04-0410-961f-82ee72b054a4 Using: gcc pr90055.c -O3 -ffast-math -march=haswell -mtune=haswell -fno-tree-loop-distribution it disappeared in r253934: Author: hubicka * x86-tune-costs.h (core_cost): Fix div, move and sqrt latencies. and it started with r238033.
