[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 --- Comment #18 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #9) > So in uninit1 we have: > if (_6691 != 0) > goto ; [5.50%] > else > goto ; [94.50%] > >[local count: 17344687]: > goto ; [100.00%] > >[local count: 298013267]: > >[local count: 315357954]: > # const_upper_3854 = PHI <_6687(87), 18446744073709551615(287)> > # _870 = PHI <1(87), 0(287)> [snip] > But _870 is _6691 == 0 but that relationship is totally missed and there is > full on jump threading miss in the above IR. This matches what I mentioned in the mailing list. If we could notice this relationship, we could thread over the uninitialized use.
[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #19 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.
>
> FAIL: path through PHI in bb8 (incoming bb:6) crosses loop
>
> But but, it does not exactly cross the loop as 5 (6) is not part of the loop
> but rather just 8.
Interesting. The restriction that tickles this is old legacy code in place
from way before I touched any of this:
// This is like path_crosses_loops in profitable_path_p but more
// restrictive, since profitable_path_p allows threading the
// first block because it would be redirected anyhow.
//
// If we loosened the restriction and used profitable_path_p()
// here instead, we would peel off the first iterations of loops
// in places like tree-ssa/pr14341.c.
bool profitable_p = m_path[0]->loop_father == e->src->loop_father;
if (!profitable_p && 0)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
" FAIL: path through PHI in bb%d (incoming bb:%d) crosses
loop\n",
e->dest->index, e->src->index);
continue;
}
I even annotated it because it seemed strange that it was more restrictive than
the generic restrictions in the backward threader.
It is very possible that we can remove this, as we have much more thorough loop
restrictions in place in the shared registry.
If you remove the above chunk, does it work? If so, I may have to test and
benchmark the change.
[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 --- Comment #20 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #16) > (In reply to Andrew Pinski from comment #15) > > We totally missed the jump threading of 3->5->7 path and the 4->5->8 path. > > FAIL: path through PHI in bb8 (incoming bb:6) crosses loop > > But but, it does not exactly cross the loop as 5 (6) is not part of the loop > but rather just 8. I looked at the IL, and this still counts as crossing loop boundaries. Your going from no loop to loop 1. No cigar :-(. Actually, even if you remove the hunk I mentioned the shared registry restrictions will disallow it. That being said, I should clean that up.
[Bug c/102889] New: -funroll-loops generates incorrect codes from inline assembly on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102889
Bug ID: 102889
Summary: -funroll-loops generates incorrect codes from inline
assembly on aarch64
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ariel at amazon dot com
Target Milestone: ---
Created attachment 51651
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51651&action=edit
Source code that reproduces bug.
The attached code works correctly with both -O2 and -O3 on GCC7 and 11.2, all
clang versions on AARCH64.
But generates incorrect code with:
/usr/local/gcc11/bin/gcc -O2 -funroll-loops -Wall -Werror -Wextra aa1.c
-fsanitize=undefined -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -o aa11y
(and in -O3 as well, just adding -funroll-loops breaks).
on all versions of gcc (triggers printf("Mismatch %i != %i\n", res1, res2);)
Attaching code to reproduce.
---
Using built-in specs.
COLLECT_GCC=/usr/local/gcc11/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc11/libexec/gcc/aarch64-unknown-linux-gnu/11.2.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gcc11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-funroll-loops' '-Wall' '-Werror'
'-Wextra' '-march=armv8.2-a+fp16+rcpc+dotprod+crypto' '-mtune=neoverse-n1'
'-fsanitize=undefined' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-o' 'aa11y' '-mlittle-endian'
'-mabi=lp64' '-dumpdir' 'aa11y-'
/usr/local/gcc11/libexec/gcc/aarch64-unknown-linux-gnu/11.2.0/cc1 -E -quiet -v
aa1.c -march=armv8.2-a+fp16+rcpc+dotprod+crypto -mtune=neoverse-n1
-mlittle-endian -mabi=lp64 -Wall -Werror -Wextra -funroll-loops
-fsanitize=undefined -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -O3 -fpch-preprocess -o aa11y-aa1.i
ignoring nonexistent directory
"/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/../../../../aarch64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/include
/usr/local/include
/usr/local/gcc11/include
/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-funroll-loops' '-Wall' '-Werror'
'-Wextra' '-march=armv8.2-a+fp16+rcpc+dotprod+crypto' '-mtune=neoverse-n1'
'-fsanitize=undefined' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-o' 'aa11y' '-mlittle-endian'
'-mabi=lp64' '-dumpdir' 'aa11y-'
/usr/local/gcc11/libexec/gcc/aarch64-unknown-linux-gnu/11.2.0/cc1
-fpreprocessed aa11y-aa1.i -quiet -dumpdir aa11y- -dumpbase aa1.c -dumpbase-ext
.c -march=armv8.2-a+fp16+rcpc+dotprod+crypto -mtune=neoverse-n1 -mlittle-endian
-mabi=lp64 -O3 -Wall -Werror -Wextra -version -funroll-loops
-fsanitize=undefined -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -o aa11y-aa1.s
GNU C17 (GCC) version 11.2.0 (aarch64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 11.2.0 (aarch64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3921e1b032be4ab2b700d43daf3de441
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-funroll-loops' '-Wall' '-Werror'
'-Wextra' '-march=armv8.2-a+fp16+rcpc+dotprod+crypto' '-mtune=neoverse-n1'
'-fsanitize=undefined' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-o' 'aa11y' '-mlittle-endian'
'-mabi=lp64' '-dumpdir' 'aa11y-'
as -v -EL -march=armv8.2-a+fp16+rcpc+dotprod+crypto -mabi=lp64 -o aa11y-aa1.o
aa11y-aa1.s
GNU assembler version 2.29.1 (aarch64-redhat-linux) using BFD version version
2.29.1-30.amzn2
COMPILER_PATH=/usr/local/gcc11/libexec/gcc/aarch64-unknown-linux-gnu/11.2.0/:/usr/local/gcc11/libexec/gcc/aarch64-unknown-linux-gnu/11.2.0/:/usr/local/gcc11/libexec/gcc/aarch64-unknown-linux-gnu/:/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/:/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/:/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/gcc11/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-funroll-loops' '-Wall' '-Werror'
'-Wextra' '-march=armv8.2-a+fp16+rcpc+dotprod+crypto' '-mtune=neoverse-n1'
'-fsanitize=undefined' '-fno-stric
[Bug c/102889] -funroll-loops generates incorrect codes from inline assembly on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102889
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
This inline asm is totally wrong:
asm volatile("rbit %0,%0\n"
"clz %0,%0\n" : "=r" (val) : "r" (val) );
Try this:
asm volatile("rbit %0,%1\n"
"clz %0,%0\n" : "=&r" (val) : "r" (val) );
[Bug c/102889] -funroll-loops generates incorrect codes from inline assembly on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102889
--- Comment #2 from Andrew Pinski ---
Or this:
asm volatile("rbit %0,%0\n"
"clz %0,%0\n" : "=r" (val) : "0" (val) );
[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #21 from Richard Biener ---
(In reply to Andrew Pinski from comment #14)
> Created attachment 51650 [details]
> Little more reduced
>
> So FRE is able to figure out for the following:
> # _20 = PHI <0(2), 1(3)>
> # const_upper_26 = PHI
>
> # _30 = PHI <0(12), 1(13)>
> # const_upper_33 = PHI
>
> That _30 is the same as _20 but not _26 is the same as _33 even though it
> does figure out that _19 and _29 are the same as _10. If it is able to
> figure that out, then things would just work.
>
> Richi,
> I assume FRE does not Value number default SSA names (non-parm) the same
> which is why this is happening is that correct?
The issue with CSE here is that with RPO VN I made unvisited vars
VARYING due to on-demand handling. While vn_visit_phis has special
handling for undefs the hashtable insert/lookup do not.
I am testing the following to rectify this (which then CSEs this PHI).
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index ae0172a143e..893b1d0ddaa 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -4499,7 +4499,12 @@ vn_phi_lookup (gimple *phi, bool backedges_varying_p)
tree def = PHI_ARG_DEF_FROM_EDGE (phi, e);
if (TREE_CODE (def) == SSA_NAME
&& (!backedges_varying_p || !(e->flags & EDGE_DFS_BACK)))
- def = SSA_VAL (def);
+ {
+ if (ssa_undefined_value_p (def, false))
+ def = VN_TOP;
+ else
+ def = SSA_VAL (def);
+ }
vp1->phiargs[e->dest_idx] = def;
}
vp1->type = TREE_TYPE (gimple_phi_result (phi));
@@ -4543,7 +4548,12 @@ vn_phi_insert (gimple *phi, tree result, bool
backedges_varying_p)
tree def = PHI_ARG_DEF_FROM_EDGE (phi, e);
if (TREE_CODE (def) == SSA_NAME
&& (!backedges_varying_p || !(e->flags & EDGE_DFS_BACK)))
- def = SSA_VAL (def);
+ {
+ if (ssa_undefined_value_p (def, false))
+ def = VN_TOP;
+ else
+ def = SSA_VAL (def);
+ }
vp1->phiargs[e->dest_idx] = def;
}
vp1->value_id = VN_INFO (result)->value_id;
[Bug tree-optimization/102890] New: [12 Regression] ICE in duplicate_and_interleave, at tree-vect-slp.c:6173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102890
Bug ID: 102890
Summary: [12 Regression] ICE in duplicate_and_interleave, at
tree-vect-slp.c:6173
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc-12.0.0-alpha20211017 snapshot (g:5d4d64faa71a6389bfb76bfb3334b63360cf62c0)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/vect/fast-math-vect-call-1.c, w/ -march=armv8-a+sve -O2
-fassociative-math -fno-math-errno -fno-signed-zeros -fno-trapping-math:
float a[8], b[8], c[8];
void
f4 (float d_0, int f4_i)
{
while (f4_i < 1)
{
a[3 * f4_i] = 1.0f
+ __builtin_copysignf(b[3 * f4_i], c[3 * f4_i])
+ __builtin_sqrtf (d_0);
a[3 * f4_i + 1] = 2.0f
+ __builtin_copysignf(b[3 * f4_i + 1], c[3 * f4_i + 1])
+ __builtin_sqrtf (d_0);
a[3 * f4_i + 2] = 3.0f
+ __builtin_copysignf(b[3 * f4_i + 2], c[3 * f4_i + 2])
+ __builtin_sqrtf (d_0);
++f4_i;
}
}
% aarch64-linux-gnu-gcc-12.0.0 -march=armv8-a+sve -O2 -fassociative-math
-fno-math-errno -fno-signed-zeros -fno-trapping-math -c bd4s9dy9.c
during GIMPLE pass: vect
bd4s9dy9.c: In function 'f4':
bd4s9dy9.c:4:1: internal compiler error: in duplicate_and_interleave, at
tree-vect-slp.c:6173
4 | f4 (float d_0, int f4_i)
| ^~
0x7e6dcf duplicate_and_interleave(vec_info*, gimple**, tree_node*,
vec const&, unsigned int, vec&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:6173
0x120360e vect_create_constant_vectors
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:6394
0x120360e vect_schedule_slp_node
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:7099
0x121525f vect_schedule_scc
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:7417
0x1215e51 vect_schedule_scc
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:7434
0x1215e51 vect_schedule_scc
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:7434
0x1215e51 vect_schedule_scc
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:7434
0x121673f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-slp.c:7570
0x11ef0a9 vect_transform_loop(_loop_vec_info*, gimple*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vect-loop.c:9685
0x122251f try_vectorize_loop_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vectorizer.c:1110
0x1223141 vectorize_loops()
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-vectorizer.c:1249
[Bug fortran/102885] [12 Regression] ICE when compiling gfortran.dg/bind_c_char_10.f90 with -flto since r12-4467-g64f9623765da3306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102885 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[12 Regression] ICE when|[12 Regression] ICE when |compiling |compiling |gfortran.dg/bind_c_char_10. |gfortran.dg/bind_c_char_10. |f90 with -flto |f90 with -flto since ||r12-4467-g64f9623765da3306 --- Comment #2 from Martin Liška --- Started with r12-4467-g64f9623765da3306.
[Bug tree-optimization/102880] [12 Regression] Dead Code Elimination Regression at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102880 --- Comment #4 from Richard Biener --- Created attachment 51652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51652&action=edit not working patch OK, that's definitely a too simplistic idea, the basic assessment still holds though. CD-DCE benefits from forwarders for equal PHI arguments. Not working patch attached (using the common dominator idea). Regresses for example gcc.c-torture/execute/20050218-1.c.
[Bug fortran/102891] New: Passing real part of complex type component using w%z%re to a subroutine gives erroneous value of dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891 Bug ID: 102891 Summary: Passing real part of complex type component using w%z%re to a subroutine gives erroneous value of dummy argument Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: oeyvindyr at hotmail dot com Target Milestone: --- Created attachment 51653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51653&action=edit minimal fortran program The attached minimal program prints the real part of a complex allocatable type component in two ways: 1) "print*,w%z%re" in the caller 2) By passing w%z%re to a subroutine that prints the array. The printed numbers are different in the two cases, and it seems that the dummy argument in the called subroutine gets an incorrect stride of 1, whereas it should be 2 for the real part of a complex array. Compiling with ifort gives the expected result and no warnings.
[Bug rtl-optimization/79405] [9/10/11/12 Regression] Infinite loop in fwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #18 from rsandifo at gcc dot gnu.org --- (In reply to Steven Bosscher from comment #17) > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558946.html: "Also, > the old version didn't naturally guarantee termination (PR79405), > whereas the new one does." > > So, I'm guessing the RTL SSA fwprop fixed this? Ah, yeah.
[Bug c++/102881] gcc totally broken when trailing return type combine with decltype lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102881 Ivan Sorokin changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #2 from Ivan Sorokin --- PR92707 also features lambda inside decltype. Perhaps they are related.
[Bug c/102889] -funroll-loops generates incorrect codes from inline assembly on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102889 --- Comment #3 from ariel at amazon dot com --- Thanks for pointing out my mistake
[Bug tree-optimization/102892] New: [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
Bug ID: 102892
Summary: [12 Regression] Dead Code Elimination Regression at
-O3 (trunk vs 11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat test.c
static long b[2][1] = {0};
void bar(void);
void foo(void);
int main() {
long c = 0;
for (long a; a < 1; ++a)
for (; c <= 1; c++) {
bar();
if (1 == b[c][0])
foo();
}
}
11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:
gcc-11 -O3 -S test.c -o /dev/stdout
...
main:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callbar
callbar
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
gcc-trunk-O3 -S test.c -o /dev/stdout
main:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
xorl%ebx, %ebx
callbar
cmpq$1, b(,%rbx,8)
je .L11
.p2align 4,,10
.p2align 3
.L3:
cmpq$1, %rbx
je .L12
.L5:
callbar
movl$1, %ebx
cmpq$1, b(,%rbx,8)
jne .L3
.L11:
callfoo
cmpq$1, %rbx
jne .L5
.L12:
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
gcc-trunk -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211022 (experimental) (GCC)
Introduced with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=01b5038718056b024b370b74a874fbd92c5bbab3
[Bug tree-optimization/102893] New: [8/9/10/11/12 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893
Bug ID: 102893
Summary: [8/9/10/11/12 Regression] CDDCE does not detect empty
infinite nested loops
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The following example
int main() {
while(1) {
for(int i=0; i<900; i++){}
}
}
In GCC 7 compiled to
main:
.L2:
b .L2
but since GCC 8 compiles to
main:
.L3:
mov w0, 21568
movkw0, 0x89, lsl 16
.L2:
subsw0, w0, #1
bne .L2
b .L3
The difference seems to be in cddce which previously was able to detect the
code as dead:
;; 3 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6
;;
;; Loop 1
;; header 3, latch 6
;; depth 1, outer 0
;; nodes: 3 6 5 4
;;
;; Loop 2
;; header 5, latch 4
;; depth 2, outer 1
;; nodes: 5 4
;; 2 succs { 3 }
;; 3 succs { 5 }
;; 4 succs { 5 }
;; 5 succs { 4 6 }
;; 6 succs { 3 }
can not prove finiteness of loop 1
Removing basic block 4
Merging blocks 3 and 5
Removing basic block 6
but since GCC 8 does
;; 3 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6
;;
;; Loop 1
;; header 3, latch 6
;; depth 1, outer 0
;; nodes: 3 6 5 4
;;
;; Loop 2
;; header 5, latch 4
;; depth 2, outer 1
;; nodes: 5 4
;; 2 succs { 3 }
;; 3 succs { 5 }
;; 4 succs { 5 }
;; 5 succs { 4 6 }
;; 6 succs { 3 }
cannot prove finiteness of loop 1
[Bug libstdc++/102894] New: make_any is not SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894
Bug ID: 102894
Summary: make_any is not SFINAE-friendly
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
std::make_any is specified in [any.nonmembers] p2-3 via "Effects: Equivalent
to: ...". According to [structure.specifications] p4, it propagates the
"Constraints:" of the constructor (in [any.cons] p11 and p17), and thus
SFINAE-friendly.
The following program should fail to compile. But currently it compiles with
libstdc++ due to lack of constraints. Note that std::make_optional is correctly
constrained in libstdc++.
Wandbox link:https://wandbox.org/permlink/noMWBjdCp0hg1pEZ
#include
#include
#include
namespace test {
template
auto test_make_any(int)
-> decltype((void)std::make_any(std::declval()...),
std::true_type{});
template
auto test_make_any(...) -> std::false_type;
template
inline constexpr bool can_make_any = decltype(test_make_any(0))::value;
}
int main()
{
static_assert(test::can_make_any); // should not pass
}
[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 --- Comment #22 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:fe8475c500939011b90504304aec61bf6f48ac7d commit r12-4625-gfe8475c500939011b90504304aec61bf6f48ac7d Author: Richard Biener Date: Fri Oct 22 10:32:36 2021 +0200 bootstrap/102681 - properly CSE PHIs with default def args The PR shows that we fail to CSE PHIs containing (different) default definitions due to the fact on how we now handle on-demand build of VN_INFO. The following fixes this in the same way the PHI visitation code does. On gcc.dg/ubsan/pr81981.c this causes one expected warning to be elided since the uninit pass sees the change [local count: 1073741824]: # u$0_2 = PHI - # cstore_11 = PHI v = u$0_2; - return cstore_11; + return u$0_2; and thus only one of the conditionally uninitialized uses (the other became dead). I have XFAILed the missing diagnostic, I don't see a way to preserve that. 2021-10-22 Richard Biener PR bootstrap/102681 * tree-ssa-sccvn.c (vn_phi_insert): For undefined SSA args record VN_TOP. (vn_phi_lookup): Likewise. * gcc.dg/tree-ssa/ssa-fre-97.c: New testcase. * gcc.dg/ubsan/pr81981.c: XFAIL one case.
[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 --- Comment #23 from Richard Biener --- This should fix the missed CSE Andrew noticed, not sure if it is enough to aovid the bogus diagnostic.
[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892 --- Comment #1 from Aldy Hernandez --- Maybe a duplicate of PR102879?
[Bug tree-optimization/102895] New: [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895
Bug ID: 102895
Summary: [12 Regression] Dead Code Elimination Regression at
-O3 (trunk vs 11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat test.c
master
static int a, b, c;
void foo(void);
int main() {
for (a = 0; a <= 1; ++a)
if (c <= a) {
for (b = 0; b <= 1; ++b)
;
} else
foo();
}
11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:
gcc-11 -O3 -S test.c -o /dev/stdout
...
main:
.LFB0:
.cfi_startproc
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
movl$2, b(%rip)
addl$1, %eax
movl%eax, a(%rip)
cmpl$1, %eax
je .L2
xorl%eax, %eax
ret
.cfi_endproc
gcc-trunk -O3 -S test.c -o /dev/stdout
...
main:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
xorl%eax, %eax
movl$0, a(%rip)
.p2align 4,,10
.p2align 3
.L5:
testl %eax, %eax
jns .L9
callfoo
.p2align 4,,10
.p2align 3
.L7:
movla(%rip), %eax
addl$1, %eax
movl%eax, a(%rip)
cmpl$1, %eax
jle .L5
xorl%eax, %eax
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L9:
.cfi_restore_state
movl$2, b(%rip)
jmp .L7
.cfi_endproc
gcc-trunk -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211022 (experimental) (GCC)
Introduced with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8e1f1d24179690fd9c0f63c27b12e030010d9ea
[Bug tree-optimization/102890] [12 Regression] ICE in duplicate_and_interleave, at tree-vect-slp.c:6173 since r12-1329-gce670e4faafb296d1f1a7828d20f8c8ba4686797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102890 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression] ICE in |duplicate_and_interleave, |duplicate_and_interleave, |at tree-vect-slp.c:6173 |at tree-vect-slp.c:6173 ||since ||r12-1329-gce670e4faafb296d1 ||f1a7828d20f8c8ba4686797 Last reconfirmed||2021-10-22 --- Comment #1 from Martin Liška --- With -Ofast it started with r12-1329-gce670e4faafb296d1f1a7828d20f8c8ba4686797.
[Bug target/102171] vget_low_*/vget_high_* intrinsics should become BIT_FIELD_REF during gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102171 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 --- Comment #1 from Tamar Christina --- confirmed
[Bug tree-optimization/102895] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||missed-optimization Ever confirmed|0 |1 CC||aldyh at gcc dot gnu.org Last reconfirmed||2021-10-22 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- There's identical IL before the vrp2 pass (the one after strlen) but on the GCC 11 branch vrp2 eliminates the call to foo while on trunk it does not. On the branch VRP registers Registering jump thread: (2, 3) incoming edge; (3, 4) normal; which elides the call but vrp-thread2 does not do this: Registering value_relation (_5 > a.4_4) (bb5) at _5 = a.4_4 + 1; Registering value_relation (_19 > a.4_13) (bb4) at _19 = a.4_13 + 1; [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; on the branch this threading destroys the loop structure
[Bug tree-optimization/102893] [9/10/11/12 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |9.5
Last reconfirmed||2021-10-22
Summary|[8/9/10/11/12 Regression] |[9/10/11/12 Regression]
|CDDCE does not detect empty |CDDCE does not detect empty
|infinite nested loops |infinite nested loops
--- Comment #1 from Richard Biener ---
Hm, there's
/* For loops without an exit do not mark any condition. */
if (loop->exits->next && !finite_loop_p (loop))
but here
(gdb) p loop->exits
$2 = (loop_exit *) 0x76690440
(gdb) p loop->exits->next
$3 = (loop_exit *) 0x76690440
(gdb) p *loop->exits
$5 = {e = , prev = 0x76690440, next = 0x76690440,
next_e = 0x0}
so I suppose I misunderstood how loop->exits works, looks like ->e has to be
non-NULL as well. But that means the testcase I added this check for
somehow did not have loop->exits->next?!
Mine.
[Bug libffi/102896] New: src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896
Bug ID: 102896
Summary: src/moxie/ffi.c:239:arrayIndexOutOfBounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck says:
trunk.git/libffi/src/moxie/ffi.c:239:46: error: Array 'register_args[6]'
accessed at index 7, which is out of bounds. [arrayIndexOutOfBounds]
Source code is
unsigned register_args[6] =
{ arg1, arg2, arg3, arg4, arg5, arg6 };
...
else if (ptr == (char *) ®ister_args[7])
[Bug tree-optimization/102895] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895 --- Comment #2 from Aldy Hernandez --- (In reply to Richard Biener from comment #1) > There's identical IL before the vrp2 pass (the one after strlen) but on the > GCC 11 branch vrp2 eliminates the call to foo while on trunk it does not. > > On the branch VRP registers > > Registering jump thread: (2, 3) incoming edge; (3, 4) normal; > > which elides the call but vrp-thread2 does not do this: > > Registering value_relation (_5 > a.4_4) (bb5) at _5 = a.4_4 + 1; > Registering value_relation (_19 > a.4_13) (bb4) at _19 = a.4_13 + 1; > [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; > Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) > incoming edge; (3, 4) normal; > > on the branch this threading destroys the loop structure It seems there were other threads in play before the loop restriction changes went in. In the branch we have: $ gcc a.c -O2 -fdump-tree-all-details -c abulafia:~/bld/t/gcc$ grep thread a.c.* a.c.124t.dom2: Registering jump thread: (10, 5) incoming edge; (5, 12) normal; a.c.124t.dom2: Registering jump thread: (9, 3) incoming edge; (3, 4) normal; a.c.189t.dom3: Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.192t.vrp2: Registering jump thread: (2, 3) incoming edge; (3, 4) normal; DOM2 was getting 2 threads, but in mainline we have: ./cc1 a.c -O2 -fdump-tree-all-details -quiet abulafia:~/bld/t/gcc$ grep thread a.c.* a.c.128t.dom2:Threading through latch before loop opts would create non-empty latch: Cancelling jump thread: (10, 5) incoming edge; (5, 12) normal; a.c.128t.dom2:Path rotates loop: Cancelling jump thread: (9, 3) incoming edge; (3, 4) normal; a.c.193t.dom3: [3] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.193t.dom3:Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.197t.vrp-thread2: [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.197t.vrp-thread2:Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; Those DOM2 threads were cancelled because of the loop restrictions we put in. Since jump threads in one pass open the possibilities of further jump threads by other passes, it could be that the missing DOM2 threads are causing VRP2 to miss out. However, vrp-thread2 *does* find and register the path. It's the block copier that is complaining: a.c.197t.vrp-thread2: [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.197t.vrp-thread2:Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; Note that these "Failure in thread_through_loop_header" messages are new debugging aids in this release, but the cancel_thread was present nevertheless. It was just silent. I would guess it's either the missing DOM threads that has cascading effects, or something in the block copier (fwd_jt_path_registry::). FWIW, there have been no changes in the block copier in this release.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 David Binderman changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #1 from David Binderman --- git blame says: 92456a4e5658 (H.J. Lu 2021-08-31 07:14:47 -0700 239) else if (ptr == (char *) ®ister_args[7]) Adding HJ for their opinion.
[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from rsandifo at gcc dot gnu.org --- Yeah, bootstrap works again too. Thanks for the fix!
[Bug tree-optimization/102897] New: [12 Regression] simplify_permutation ICEs on assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897
Bug ID: 102897
Summary: [12 Regression] simplify_permutation ICEs on assert
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The following testcase
typedef __attribute__((vector_size(8))) signed char int8x8_t;
typedef __attribute__((vector_size(8))) unsigned char uint8x8_t;
int8x8_t fn1(int8x8_t val20, char tmp) {
uint8x8_t __trans_tmp_3;
__trans_tmp_3 = (uint8x8_t){tmp};
int8x8_t __a = (int8x8_t)__trans_tmp_3;
return __builtin_shuffle(__a, val20, (uint8x8_t){});
}
ICEs at -O1 and higher with
during GIMPLE pass: forwprop
: In function 'fn1':
:12:1: internal compiler error: in simplify_permutation, at
tree-ssa-forwprop.c:2271
12 | }
| ^
0x1000e00 simplify_permutation
src/gcc/gcc/tree-ssa-forwprop.c:2271
0x1007ae8 execute
src/gcc/gcc/tree-ssa-forwprop.c:3397
That line contains an assert with the comment
tree op2_type = TREE_TYPE (op2);
/* Should have folded this before. */
gcc_assert (op2_type != tgt_type);
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2021-10-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/102897] [12 Regression] simplify_permutation ICEs on assert since r12-1103-g4a9f2306cb39a3cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897 Martin Liška changed: What|Removed |Added CC||linkw at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 Summary|[12 Regression] |[12 Regression] |simplify_permutation ICEs |simplify_permutation ICEs |on assert |on assert since ||r12-1103-g4a9f2306cb39a3cf Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r12-1103-g4a9f2306cb39a3cf.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #22 from Tobias Burnus --- (In reply to sandra from comment #21) > Tobias, did your big patch fully fix this issue so that we can close it? I checked the examples – and did run into the following ICE. I think we should at some point compile all gfortran testcases with -fcheck= and/or -fsanitize=undefined(,address) and with and without optimization to see whether it triggers some ICE. Additionally, I think we might want to do something likewise for the dg-do run tests. * * * The testcase attachment 47882 of comment 3 still/now fails with: 9 | val = 2 | 1 internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:11732 It works when using 'val(:) = 2' - and only fails when compiled with both: -fcheck=all -fsanitize=undefined The fail is for: 11731 /* We should only get array references here. */ 11732 gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR 11733 || TREE_CODE (tmp) == ARRAY_REF); (gdb) p debug(tmp) (integer(kind=4) *) ((void *) D.4249 + (sizetype) ((S.5 + D.4250) * val->span)) (gdb) p debug_tree(tmp)
[Bug tree-optimization/102893] [9/10/11/12 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c2a9a98a369528c8689ecb68db576f8e7dc2fa45 commit r12-4627-gc2a9a98a369528c8689ecb68db576f8e7dc2fa45 Author: Richard Biener Date: Fri Oct 22 12:45:32 2021 +0200 tree-optimization/102893 - properly DCE empty loops inside infinite loops The following fixes the test for an exit edge I put in place for the fix for PR45178 where I somehow misunderstood how the cyclic list works. 2021-10-22 Richard Biener PR tree-optimization/102893 * tree-ssa-dce.c (find_obviously_necessary_stmts): Fix the test for an exit edge. * gcc.dg/tree-ssa/ssa-dce-9.c: New testcase.
[Bug tree-optimization/102893] [9/10/11 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||12.0 Summary|[9/10/11/12 Regression] |[9/10/11 Regression] CDDCE |CDDCE does not detect empty |does not detect empty |infinite nested loops |infinite nested loops --- Comment #3 from Richard Biener --- Not sure if worth backporting.
[Bug tree-optimization/102890] [12 Regression] ICE in duplicate_and_interleave, at tree-vect-slp.c:6173 since r12-1329-gce670e4faafb296d1f1a7828d20f8c8ba4686797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102890 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |12.0 Priority|P3 |P2 --- Comment #2 from Richard Biener --- Hum, the function is Richards area, possibly we trigger a latent issue here.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 H.J. Lu changed: What|Removed |Added CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com Status|NEW |WAITING --- Comment #2 from H.J. Lu --- Does it happen in libffi upstream? https://github.com/libffi/libffi
[Bug tree-optimization/102890] [12 Regression] ICE in duplicate_and_interleave, at tree-vect-slp.c:6173 since r12-1329-gce670e4faafb296d1f1a7828d20f8c8ba4686797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102890 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- I'll take a look in stage 3 (if not earlier).
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #3 from David Binderman --- (In reply to H.J. Lu from comment #2) > Does it happen in libffi upstream? > > https://github.com/libffi/libffi Yes.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #4 from Martin Liška --- Then, please file it here: https://github.com/libffi/libffi/issues.
[Bug fortran/96870] Class name on error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- Was fixed by r12-4464-g017665f63047ce47b087b0b283548a60e5abf3d2 for PR102745 Close as FIXED. Thanks for the report – and sorry for not reviewing your patch :-/
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #5 from David Binderman --- (In reply to Martin Liška from comment #4) > Then, please file it here: https://github.com/libffi/libffi/issues. Done. https://github.com/libffi/libffi/issues/666
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 Martin Liška changed: What|Removed |Added Resolution|--- |MOVED URL||https://github.com/libffi/l ||ibffi/issues/666 Status|WAITING |RESOLVED --- Comment #6 from Martin Liška --- Moved.
[Bug tree-optimization/102893] [9/10/11 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893 --- Comment #4 from Tamar Christina --- Thanks for the fix! This was reported to us by a user of the arm embedded toolchains that was upgrading from gcc 7. We won't be releasing any new releases for GCC 8 and 9, but may be for 10 and 11 is certain. So a backport to 11 and if possible 10 would be great as it avoids us having to possibly carry the patch in a vendor branch.
[Bug fortran/102503] ICE in gfc_conv_array_bound, at fortran/trans-types.c:1224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102503 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-22 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus --- (In reply to sandra from comment #9) > Jose's test case for this issue is still failing. Which is not surpising: sz = (size_t)auxp->elem_len / sizeof (char); for kind=4 character of len=1 and len=7 gives sz=4 and sz=28. The testcase should have used: sz = (size_t)auxp->elem_len / sizeof (CFI_type_ucs4_char); Or expect 4 and 28 instead of 1 and 7 as result ...
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 --- Comment #11 from Dominique d'Humieres --- In both case I get FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 67 != 65282 FAIL! chrcmp: 68 != 65283 FAIL! chrcmp: 69 != 65284 FAIL! chrcmp: 70 != 65285 FAIL! chrcmp: 71 != 65286 FAIL! chrcmp: 72 != 65287 FAIL! chrcmp: 73 != 65288 FAIL! chrcmp: 74 != 65289 FAIL! chrcmp: 75 != 65290 FAIL! chrcmp: 0 != 65291 FAIL! char: 75 != 11 Assertion failed: (c_vrfy_character (auxp)), function check_tk, file pr100907_db.c, line 215. Program received signal SIGABRT: Process abort signal.
[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #6 from Tobias Burnus ---
(In reply to sandra from comment #5)
> Jose's test case for this issue is still failing.
I find the testcase very confusing. For
type(c_other), intent(in) :: a(:)
call check_tk_as(a, t, k, e, 1_c_size_t)
it fails with:
FAIL! type (A): 6 != 255
which is printed by:
printf ("FAIL! type (A): %d != %d\n", auxp->type, type);
gfortran uses the following, which seems to be fine:
#define CFI_type_struct 6
I do not quite understand why the testcase expects 255 as type now how it tries
to generate that number.
Other fails:
FAIL! type (B): 6 != -1
FAIL! type (C): -1 != 6
FAIL! type: -1 != 6
Here the issue is that GCC uses CFI_type_struct (= 6)
while the testcase expects CFI_type_other (= -1).
I think one can argue for either.
[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 Ever confirmed|0 |1
[Bug testsuite/102886] [12 regression] gcc.dg/tree-ssa/sra-18.c fails starting with r12-4607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886 Martin Jambor changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-22 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #1 from Martin Jambor --- Oh, stupid me... mine.
[Bug fortran/102862] CLASS(*) – various issues, esp. with assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102862 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 --- Comment #1 from Dominique d'Humieres --- Confirmed from gfortan 10 up to master.
[Bug sanitizer/81981] [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981 Martin Sebor changed: What|Removed |Added Known to fail||12.0 Known to work||10.3.0, 11.2.0, 8.5.0, ||9.4.0 Keywords||xfail Last reconfirmed|2017-08-25 00:00:00 |2021-10-22 CC||msebor at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|FIXED |--- Blocks||24639 --- Comment #7 from Martin Sebor --- This has come back with r12-4625 (the fix for pr102681). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 81981, which changed state. Bug 81981 Summary: [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c++/102898] New: declaration of 'using Foo = enum class Foo' changes meaning of 'Foo'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102898
Bug ID: 102898
Summary: declaration of 'using Foo = enum class Foo' changes
meaning of 'Foo'
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roehling at debian dot org
Target Milestone: ---
The following C++ code fails to compile:
enum class Foo { foo };
class Bar
{
using Foo = Foo;
};
The generated error is
:5:11: error: declaration of 'using Foo = enum class Foo' changes
meaning of 'Foo' [-fpermissive]
5 | using Foo = Foo;
| ^~~
:1:12: note: 'Foo' declared here as 'enum class Foo'
1 | enum class Foo { foo };
|^~~
The code does compile with
using Baz = Foo;
or
using Foo = enum Foo;
[Bug fortran/102843] [12 regression] gfortran.dg/deferred_type_param_6.f90 fails after r12-4457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102843 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- Can you confirm that it is now fixed after the commit: r12-4511-gff0eec94e87dfb7dc387f120ca5ade2707aecf50 ?
[Bug fortran/100906] Bind(c): failure handling character with len/=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906 --- Comment #6 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:b7cb6d66bd52e884ff33c61e46a9ee9facc2ac60 commit r12-4628-gb7cb6d66bd52e884ff33c61e46a9ee9facc2ac60 Author: Sandra Loosemore Date: Thu Oct 21 19:17:50 2021 -0700 Add testcase for PR fortran/100906 2021-10-21 José Rui Faustino de Sousa Sandra Loosemore gcc/testsuite/ PR fortran/100906 * gfortran.dg/PR100906.f90: New. * gfortran.dg/PR100906.c: New.
[Bug fortran/100906] Bind(c): failure handling character with len/=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from sandra at gcc dot gnu.org --- This was fixed as part of Tobias's big GFC <-> CFI descriptor re-work, and I've separately committed the testcase for this issue. I think we can close this issue now.
[Bug c++/102899] New: Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899
Bug ID: 102899
Summary: Performing `delete this` within destructor in constant
evaluation results in infinitely recursive error
message
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: friedkeenan at protonmail dot com
Target Milestone: ---
See the following code:
struct Test {
constexpr Test() = default;
constexpr ~Test() {
delete this;
}
};
consteval bool test() {
const auto obj = Test{};
return true;
}
static_assert(test());
Godbolt link: https://godbolt.org/z/fv3dGWsY1
This bug still occurs when `obj` is heap-allocated and destroyed with
`std::destroy_at`.
This issue does not occur if the `delete this` statement is relegated to
another method, including the constructor; it only occurs when `delete this` is
placed within the destructor.
[Bug fortran/102503] ICE in gfc_conv_array_bound, at fortran/trans-types.c:1224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102503
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
F2018:C837 An assumed-rank entity shall be a dummy data object that does not
have the CODIMENSION or VALUE attribute.
In principle, something like the following should do - but reading the file
shows that there are many more issues of the same kind :-(
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -15623,7 +15623,7 @@ resolve_symbol (gfc_symbol *sym)
return;
}
if (as->type == AS_ASSUMED_RANK
- && (sym->attr.codimension || sym->attr.value))
+ && (class_attr->attr.codimension || sym->attr.value))
{
gfc_error ("Assumed-rank array at %L may not have the VALUE or "
"CODIMENSION attribute", &sym->declared_at);
[Bug fortran/102900] New: ICE via gfc_class_data_get in alloc_comp_class_4.f03 with -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900 Bug ID: 102900 Summary: ICE via gfc_class_data_get in alloc_comp_class_4.f03 with -fcheck=all Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Compiling the existing alloc_comp_class_4.f03 with -fcheck=all fails with: alloc_comp_class_4.f03:91:29: 91 | call add_class_c(c_init2()) | 1 internal compiler error: Segmentation fault 0xfaae63 crash_signal ../../repos/gcc/gcc/toplev.c:322 0xa050a1 gfc_class_data_get(tree_node*) ../../repos/gcc/gcc/fortran/trans-expr.c:230 0xa0f97f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../repos/gcc/gcc/fortran/trans-expr.c:7211
[Bug fortran/100917] Bind(c): errors handling long double real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from sandra at gcc dot gnu.org --- This is fully fixed now. I think the testcases in the c-interop testsuite are adequate, so nothing more to do here.
[Bug fortran/102901] New: ICE (segfault) when compiling pdt_13.f03 with -fcheck=all in gfc_check_pdt_dummy -> structure_alloc_comps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102901
Bug ID: 102901
Summary: ICE (segfault) when compiling pdt_13.f03 with
-fcheck=all in gfc_check_pdt_dummy ->
structure_alloc_comps
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Existing pdt_13.f03, pdt_14.f03 and pdt_15.f03 fail when compiled with
-fcheck=all
structure_alloc_comps:
9998case CHECK_PDT_DUMMY:
1 comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
10001 decl, cdecl, NULL_TREE);
->
#1 0x00be7ba7 in fold_build3_loc (loc=287456,
code=code@entry=COMPONENT_REF, type=type@entry=0x76fc15e8,
op0=op0@entry=0x766cdd00, op1=op1@entry=0x7719c2f8, op2=op2@entry=0x0)
at ../../repos/gcc-trunk-commit/gcc/fold-const.c:13813
13813 tem = fold_ternary_loc (loc, code, type, op0, op1, op2);
(gdb) p code
$16 = COMPONENT_REF
(gdb) p debug_tree(type)
Cannot access memory at address 0x7bffecef
(gdb) p debug_tree(op0)
Cannot access memory at address 0x7bffecef
(gdb) p debug_tree(op1)
Cannot access memory at address 0x7bffecef
(gdb) p debug_tree(op2)
Cannot access memory at address 0x7bffecef
Going up in the calltree:
10009 tmp = gfc_check_pdt_dummy (c->ts.u.derived, comp,
10010c->as ? c->as->rank : 0,
10011pdt_param_list);
(gdb) p *c->ts.u.derived
$19 = {name = 0x7716ee10 "Pdtlink_8", module = 0x7716ede0 "link_module"
(gdb) p c->as
$20 = (gfc_array_spec *) 0x0
(gdb) p pdt_param_list
$21 = (gfc_actual_arglist *) 0x2a4b070
(gdb) p *pdt_param_list
$22 = {name = 0x7716edf0 "real_kind", label = 0x0, missing_arg_type =
BT_UNKNOWN, spec_type = SPEC_EXPLICIT, expr = 0x2acfce0, next = 0x0}
[Bug tree-optimization/102902] New: wrong code at -O3 on x86_64-linux-gnu (generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902
Bug ID: 102902
Summary: wrong code at -O3 on x86_64-linux-gnu (generated code
hangs)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression.
[575] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211022 (experimental) [master r12-4624-gae5c540662e] (GCC)
[576] %
[576] % gcctk -O2 small.c; ./a.out
[577] %
[577] % gcctk -O3 small.c
[578] % timeout -s 9 10 ./a.out
Killed
[579] %
[579] % cat small.c
int printf (const char *, ...);
int a, b, c, d, e, f;
int main() {
int g;
short h = 1;
for (; e < 2; e++) {
L1:
f = 1;
while (b > 0 || a > 0) {
g++;
h++;
printf("%d", g);
}
L2:
if (!h && (!c || a))
goto L1;
if (c)
goto L2;
}
return 0;
}
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why do you think this is a compiler bug? If you delete this, you invoke the destructor and then the operator delete, so when you do this in the destructor, it means you do infinite recursion.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #2 from friedkeenan at protonmail dot com --- (In reply to Jakub Jelinek from comment #1) > Why do you think this is a compiler bug? > If you delete this, you invoke the destructor and then the operator delete, > so when you do this in the destructor, it means you do infinite recursion. Because this message is really unhelpful, and Clang handles it as I would expect, where it errors on the second deallocation of `this`, and that's it.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #3 from Jakub Jelinek --- Just compile your testcase with additional -Dconstexpr= -Dconsteval= -D'static_assert(x)=' to see how it is compiled, there is that infinite recursion with all compilers I've tried.
[Bug fortran/102900] ICE via gfc_class_data_get with alloc_comp_class_4.f03 or proc_ptr_52.f90 using -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900 Tobias Burnus changed: What|Removed |Added Summary|ICE via gfc_class_data_get |ICE via gfc_class_data_get |in alloc_comp_class_4.f03 |with alloc_comp_class_4.f03 |with -fcheck=all|or proc_ptr_52.f90 using ||-fcheck=all --- Comment #1 from Tobias Burnus --- Similar but slightly different ICE for proc_ptr_52.f90 with -fcheck=all: 65 | y = apply (f, x) ! Fixed by first chunk in patch | 1 internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.c:232 0x7c1370 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../repos/gcc/gcc/tree.c:8689 0x662539 tree_check3(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code) ../../repos/gcc/gcc/tree.h:3473 0x662539 gfc_class_data_get(tree_node*) ../../repos/gcc/gcc/fortran/trans-expr.c:232 0xa0f97f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../repos/gcc/gcc/fortran/trans-expr.c:7211
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #4 from friedkeenan at protonmail dot com --- (In reply to Jakub Jelinek from comment #3) > Just compile your testcase with additional > -Dconstexpr= -Dconsteval= -D'static_assert(x)=' > to see how it is compiled, there is that infinite recursion with all > compilers I've tried. The difference being that that's runtime which does not have the same heap safety guarantees as constant evaluation. The recursive error, while technically compliant with the standard afaik, is not that great from a figuring out what the issue is perspective.
[Bug fortran/102843] [12 regression] gfortran.dg/deferred_type_param_6.f90 fails after r12-4457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102843 seurer at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from seurer at gcc dot gnu.org --- Yes, it works now for me. Thanks!
[Bug tree-optimization/102886] [12 regression] gcc.dg/tree-ssa/sra-18.c fails starting with r12-4607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886 --- Comment #2 from Martin Jambor --- I posted a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582380.html
[Bug fortran/102903] New: Invalid gfortran.dg testcases or wrong-code with -fcheck=all -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102903 Bug ID: 102903 Summary: Invalid gfortran.dg testcases or wrong-code with -fcheck=all -fsanitize=undefined Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- With -fcheck=all -fsanitize=undefined the following shows up * Possibly okay (invalid on purpose) * Possibly a testcase bug * Possibly a code gen bug == PR95214.f90 == At line 69 of file PR95214.f90 Fortran runtime error: Actual string length does not match the declared one for dummy argument 'x' (1/77) == PR95331.f90 == PR95331.f90:137:7: runtime error: load of misaligned address 0x7ffcb894801c for type '', which requires 8 byte alignment 0x7ffcb894801c: note: pointer points here 2b 00 00 00 2c 00 00 00 2d 00 00 00 2e 00 00 00 2f 00 00 00 30 00 00 00 31 00 00 00 32 00 00 00 ^ == alloc_comp_class_5.f03 == alloc_comp_class_5.f03:26:57: runtime error: load of misaligned address 0x7ffea4a0384f for type '', which requires 8 byte alignment 0x7ffea4a0384f: note: pointer points here 00 00 00 00 66 6f 6f 62 61 72 62 61 7a 00 00 00 00 00 00 00 00 d0 27 cc 01 00 00 00 00 ff ff ff ^ == alloc_comp_constructor_6.f90 == alloc_comp_constructor_6.f90:26:25: runtime error: signed integer overflow: 5095827452369516032 * 2 cannot be represented in type 'integer(kind=8)' == allocate_with_source_8.f08 == allocate_with_source_8.f08:87:28: runtime error: load of misaligned address 0x7ffc8ce71bc2 for type '', which requires 8 byte alignment 0x7ffc8ce71bc2: note: pointer points here 00 00 00 00 66 6f 6f 62 61 72 04 00 00 00 cd cc 8c 3f cd cc 0c 40 04 00 00 00 cd cc 8c 3f cd cc ^ == alloc_comp_class_5.f03 == alloc_comp_class_5.f03:26:57: runtime error: load of misaligned address 0x7ffea4a0384f for type '', which requires 8 byte alignment 0x7ffea4a0384f: note: pointer points here 00 00 00 00 66 6f 6f 62 61 72 62 61 7a 00 00 00 00 00 00 00 00 d0 27 cc 01 00 00 00 00 ff ff ff ^ == assumed_type_13.f90 == assumed_type_13.f90:63:6: runtime error: load of misaligned address 0x0040b4c2 for type '', which requires 8 byte alignment 0x0040b4c2: note: pointer points here 02 00 03 00 01 00 02 00 03 00 01 00 02 00 03 00 00 00 44 08 00 00 ff 0f 00 00 00 00 00 00 01 00 ^ == auto_char_dummy_array_1.f90 == At line 34 of file auto_char_dummy_array_1.f90 Fortran runtime error: Actual string length does not match the declared one for dummy argument 'p' (12/0) == class_array_20.f03 == class_array_20.f03:44:8: runtime error: load of null pointer of type 'struct foo' class_array_20.f03:45:8: runtime error: load of null pointer of type 'struct foo' == missing_optional_dummy_6.f90 == missing_optional_dummy_6.f90:21:29: runtime error: load of null pointer of type 'integer(kind=4)' == mvbits_1.f90 == mvbits_1.f90:15:29: runtime error: negation of -128 cannot be represented in type 'integer(kind=1)'; cast to an unsigned type to negate this value to itself mvbits_1.f90:15:29: runtime error: signed integer overflow: -128 - 1 cannot be represented in type 'integer(kind=1)' mvbits_1.f90:22:29: runtime error: negation of -32768 cannot be represented in type 'integer(kind=2)'; cast to an unsigned type to negate this value to itself == optional_absent_5.f90 == optional_absent_5.f90:11:39: runtime error: load of null pointer of type 'logical(kind=4)' optional_absent_5.f90:11:39: runtime error: member access within null pointer of type 'struct array02_logical(kind=4)' optional_absent_5.f90:25:42: runtime error: load of null pointer of type 'logical(kind=4)' == power_8.f90 == power_8.f90:36:9: runtime error: signed integer overflow: -128 * -1 cannot be represented in type 'integer(kind=1)' power_8.f90:61:9: runtime error: signed integer overflow: -9223372036854775808 * -1 cannot be represented in type 'integer(kind=8)' == pr17143.f90 == pr17143.f90:10:19: runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'integer(kind=8)' == pr86328.f90 == pr86328.f90:41:37: runtime error: member access within null pointer of type 'struct __vtype__STAR' == pr17143.f90 == pr17143.f90:10:19: runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'integer(kind=8)' == random_7.f90 == random_7.f90:22:36: runtime error: load of null pointer of type 'integer(kind=4)' random_7.f90:22:36: runtime error: load of null pointer of type 'integer(kind=4)' == select_type_49.f90 == select_type_49.f90:13:26: runtime error: load of misaligned address 0
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 --- Comment #5 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:c31d2d14f798dc7ca9cc078200d37113749ec3bd commit r12-4629-gc31d2d14f798dc7ca9cc078200d37113749ec3bd Author: Sandra Loosemore Date: Fri Oct 22 11:08:19 2021 -0700 Add testcase for PR fortran/94289 2021-10-22 José Rui Faustino de Sousa Sandra Loosemore gcc/testsuite/ PR fortran/94289 * gfortran.dg/PR94289.f90: New.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899
--- Comment #5 from Jakub Jelinek ---
What I see is clang performing checks at a place it shouldn't.
It can be better seen on
struct Test {
constexpr Test() = default;
constexpr ~Test() {
delete this;
}
};
consteval bool test() {
auto obj = new Test();
delete obj;
return true;
}
static_assert(test());
where it reports
destruction of object that is already being destroyed
which definitely isn't something that happens in the testcase.
The object is only destroyed after the destructor finishes, which is never in
this case.
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from sandra at gcc dot gnu.org --- This is working now. I've committed a slightly cleaned-up version of the testcase (basically just exchanging the print "FAIL!"s with STOPs). I also convinced myself that the testcase is correct. ;-)
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #6 from friedkeenan at protonmail dot com --- Well it says "being destroyed" not "already destroyed", because the object is currently being destroyed
[Bug testsuite/102904] New: go testsuite does not always cause a timeout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102904 Bug ID: 102904 Summary: go testsuite does not always cause a timeout Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- I just ran into this on aarch64-linux-gnu. It seems like the gotest timeout mechanism is not working fully. go.test/test/fixedbugs/issue16095.go was running for 298:53.85 (minues:seconds). If I can reproduce it again, I will try to have more data.
[Bug libffi/101208] libffi.call/nested_struct12.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101208 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed when the libffi was synced with the upstream.
[Bug c++/102898] declaration of 'using Foo = enum class Foo' changes meaning of 'Foo'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102898 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- GCC is correct in this error message. The (current) C++ standard requires no diagnostic on this though.
[Bug tree-optimization/102902] [12 Regression] wrong code at -O3 on x86_64-linux-gnu (generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 Andrew Pinski changed: What|Removed |Added Depends on||100810 Last reconfirmed||2021-10-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. -fno-ivopts fixes the issue. I suspect (have not fully looked yet), this is the same issue as PR 100810. Initializing g also fixes the issue which is another sign it is the same issue as PR 100810. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 [Bug 100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
[Bug tree-optimization/102897] [12 Regression] simplify_permutation ICEs on assert since r12-1103-g4a9f2306cb39a3cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |12.0
[Bug testsuite/102905] New: [12 regression] several vector test cases fail on power 7 after r12-4490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905 Bug ID: 102905 Summary: [12 regression] several vector test cases fail on power 7 after r12-4490 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:caab0139761b04226fab14d87c4a4f981d942bbf, r12-4490: 201 failures > FAIL: gcc.dg/vect/vect-multitypes-4.c -flto -ffat-lto-objects > scan-tree-dump-times vect "Alignment of access forced using peeling" 2 > FAIL: gcc.dg/vect/vect-multitypes-4.c -flto -ffat-lto-objects > scan-tree-dump-times vect "Vectorizing an unaligned access" 8 > FAIL: gcc.dg/vect/vect-multitypes-4.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 1 loops" 2 > FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Alignment of > access forced using peeling" 2 > FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Vectorizing > an unaligned access" 8 > FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "vectorized 1 > loops" 2 > FAIL: gcc.dg/vect/vect-peel-1.c -flto -ffat-lto-objects scan-tree-dump-times > vect "Alignment of access forced using peeling" 1 > FAIL: gcc.dg/vect/vect-peel-1.c -flto -ffat-lto-objects scan-tree-dump-times > vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/vect-peel-1.c scan-tree-dump-times vect "Alignment of > access forced using peeling" 1 > FAIL: gcc.dg/vect/vect-peel-1.c scan-tree-dump-times vect "vectorized 1 > loops" 1 These are probably failing due to limitations in vector stuff on power 7. Perhaps just skip these on power 7? commit caab0139761b04226fab14d87c4a4f981d942bbf (HEAD, refs/bisect/bad) Author: Richard Biener Date: Mon Oct 18 15:55:22 2021 +0200 Remove check_aligned parameter from vect_supportable_dr_alignment
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- Just ran into this issue. :-((In reply to H.J. Lu from comment #4) > Another possibility is to add a configure test to locate the system > and include it instead of . Another possibility is to revert your patch so that others can bootstrap.
[Bug testsuite/102742] ERROR: descriptor 3 still open after tests complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102742 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:690180eb4b35df3f4b5def690878ecaeb5492e41 commit r12-4630-g690180eb4b35df3f4b5def690878ecaeb5492e41 Author: Martin Liska Date: Fri Oct 22 10:12:56 2021 +0200 Handle jobserver file descriptors in btest. PR testsuite/102742 libbacktrace/ChangeLog: * btest.c (MIN_DESCRIPTOR): New. (MAX_DESCRIPTOR): Likewise. (check_available_files): Likewise. (check_open_files): Check only file descriptors that were not available at the entry. (main): Call check_available_files.
[Bug testsuite/102742] ERROR: descriptor 3 still open after tests complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102742 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed.
[Bug fortran/102816] [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 since r12-4452-g1e819bd95ebeefc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102816 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Mine. Patch: https://gcc.gnu.org/pipermail/fortran/2021-October/056772.html
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #7 from H.J. Lu --- (In reply to kargl from comment #6) > > Another possibility is to revert your patch so that others can bootstrap. The problem won't go away as long as we keep syncing with upstream.
[Bug c++/102508] ICE on coroutine when awaiting inside a statement expression (in transform_local_var_uses, at cp/coroutines.cc:2102)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102508 --- Comment #2 from Iain Sandoe --- thanks for the simplified test case. As noted in pr98935, statement expressions are not handled (I deferred handling them in the initial implementation since they are an extension)... however, it is intended to support them when possible.
[Bug rtl-optimization/102627] [11 Regression] wrong code with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed for GCC 12 and 11.3.
[Bug fortran/99922] Bind(C) with assumed length character should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from sandra at gcc dot gnu.org --- This is a duplicate of now-fixed PR 92482. *** This bug has been marked as a duplicate of bug 92482 ***
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482 sandra at gcc dot gnu.org changed: What|Removed |Added CC||everythingfunctional@proton ||mail.com --- Comment #11 from sandra at gcc dot gnu.org --- *** Bug 99922 has been marked as a duplicate of this bug. ***
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- Has this bug been fully fixed now, so that we can close it?
[Bug fortran/102891] Passing real part of complex type component using w%z%re to a subroutine gives erroneous value of dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-10-22 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Interestingly, replacing the line call print_arr(w%z%re) by call print_arr([w%z%re]) works around the issue.
[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |12.0
[Bug tree-optimization/102902] [12 Regression] wrong code at -O3 on x86_64-linux-gnu (generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug testsuite/102905] [12 regression] several vector test cases fail on power 7 after r12-4490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #7 from Dominique d'Humieres --- > Has this bug been fully fixed now, so that we can close it? It seems so.
[Bug middle-end/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 Andrew Pinski changed: What|Removed |Added Summary|[12 regression] r12-4526|[12 regression] r12-4526 |caused regressions on |caused regressions on |vect/bb-slp-16.c and|ssa-dom-thread-7.c |ssa-dom-thread-7.c | --- Comment #3 from Andrew Pinski --- I can confirm ssa-dom-thread-7.c FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps threaded: 12"
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 --- Comment #3 from anlauf at gcc dot gnu.org --- Strange. We happen to call gfc_free_shape with inconsistent data: (gdb) p rank $84 = 2 (gdb) p shape[1] $85 = (mpz_t *) 0x0 Not good. Interestingly the following works: integer :: z(1,2) = (x(1)%a)
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |testsuite
CC||aldyh at gcc dot gnu.org,
||pinskia at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Keywords|wrong-code |
Last reconfirmed||2021-10-22
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski ---
/* { dg-final { scan-tree-dump "Jumps threaded: 12" "thread3" } } */
/* { dg-final { scan-tree-dump-not "Jumps threaded" "dom2" } } */
/* aarch64 has the highest CASE_VALUES_THRESHOLD in GCC. It's high enough
to change decisions in switch expansion which in turn can expose new
jump threading opportunities. Skip the later tests on aarch64. */
/* { dg-final { scan-tree-dump-not "Jumps threaded" "dom3" { target { !
aarch64*-*-* } } } } */
/* { dg-final { scan-tree-dump-not "Jumps threaded" "vrp-thread2" { target { !
aarch64*-*-* } } } } */
Someone didn't update this for aarch64 which is why you get:
gcc.dg/tree-ssa/ssa-dom-thread-7.c: dump file does not exist
UNRESOLVED: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp-thread2
"Jumps threaded"
On x86_64 also.
Christophe,
Can you file gcc.target/arm/ivopts-4.c seperately? Since it seems unrelated
to others. And this one can be for the ssa-dom-thread-7.c failure only.
[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
