[Bug c++/102538] New: Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538
Bug ID: 102538
Summary: Wrong narrowing conversion checking for initializer
with union
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
How to reproduce:
g++ x.cpp
Testcase:
```
#include
struct X {
union {
uint8_t r8[8];
uint32_t r32[2];
};
};
struct ctx {
X v[1];
};
ctx x = {
{
{.r32 = {5,0x3}},
}
};
```
Message:
x.cpp:19:1: error: narrowing conversion of '209715' from 'int' to 'uint8_t'
{aka 'unsigned char'} [-Wnarrowing]
19 | };
| ^
Work with GCC 11.1 but not work with GCC 11.2 and trunk
[Bug target/102522] Multiplication by scalar on arm-v7 seems to generate scalar code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102522 --- Comment #2 from Denis Yaroshevskiy --- You are right, it works. Tried in a loop, I get: vmul.i32q8, q8, d9[0]
[Bug fortran/102532] [10/11/12 Regression] ICE in gfc_get_corank, at fortran/expr.c:5769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102532 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4 Priority|P3 |P4
[Bug c++/102538] Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538 --- Comment #1 from Jakub Jelinek --- Started with r12-954-g84fd1b5dff70cd74aee7e8b18f66959d8b8e1ce7 aka PR100489 fix.
[Bug c++/102538] [11/12 Regression] Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-09-30 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |11.3 Status|UNCONFIRMED |NEW Priority|P3 |P2 Summary|Wrong narrowing conversion |[11/12 Regression] Wrong |checking for initializer|narrowing conversion |with union |checking for initializer ||with union Ever confirmed|0 |1
[Bug c++/102538] [11/12 Regression] Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538 Jakub Jelinek changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Jakub Jelinek --- With -std=gnu++98 it is actually wrong-code (and after all, with newer modes too if you change 0x3 to say 6). With 5, 6 this used to result in .type x, @object .size x, 8 x: .long 5 .long 6 but now it is: .type x, @object .size x, 8 x: .byte 5 .byte 6 .zero 6
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 --- Comment #23 from Aldy Hernandez --- I have built a cross to ppcle on gcc135 (ppc64le) and then bisected the lowest amount of memory ./cc1 -O2 can compile rlwimi-1.c (via ulimit -v). Before the VRP threader replacement it could run with 271megs. Current trunk can run it with 289megs for a 6.6% increase. I also tried valgrind both on a cross from x86-64 and on ppc64le. Nothing comes up except some existing sparseset_bit_p stuff. I still cannot reproduce :-(.
[Bug target/89954] missed optimization for signed extension for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954 --- Comment #10 from Uroš Bizjak --- (In reply to Hongtao.liu from comment #9) > (In reply to Hongtao.liu from comment #8) > > (In reply to Uroš Bizjak from comment #7) > > > Created attachment 51496 [details] > > > Prototype patch > > > > +;; convert (sign_extend:WIDE (any_logic:NARROW (memory, immediate))) > > +;; to (any_logic:WIDE (sign_extend (memory)), (sign_extend (immediate))). > > +;; This eliminates sign extension after logic operation. > > + > > +(define_split > > + [(set (match_operand:SWI248 0 "register_operand") > > + (sign_extend:SWI248 > > + (any_logic:QI (match_operand:QI 1 "memory_operand") > > + (match_operand:QI 2 "const_int_operand"] > > + "" > > + [(set (match_dup 0) (any_logic:SWI248 (match_dup 0) (match_dup 2)))] > > + "convert_move (operands[0], operands[1], false);") > > > > Shouldn't we make sure (any_logic op1 const_int) would change sign bit of > > op1? > Typo, would not change sign bit of op1. It doesn't matter, since all constants are implicitly sign-extended by the insn. For example, convert sext:HI (xor:QI (op1, -1)) to xor:HI (sext:HI (op1), -1): (a = op1, b = -1) sext:HI (xor:QI (op1, -1)): a 0xxx b 1xxx r 1xxx a 1xxx b 1xxx r 0xxx xor:HI (sext:HI (op1), -1): a 0xxx b 1xxx r 1xxx a 1xxx b 1xxx r 0xxx
[Bug c/102539] New: [11/12 regression] -Wmaybe-uninitialized false positive, invalid location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102539
Bug ID: 102539
Summary: [11/12 regression] -Wmaybe-uninitialized false
positive, invalid location
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Minimal example is extracted from aerospike-server-4.2.0.4:
$ cat a.c.c
void msg_set_buf(const int *);
void clustering_hb_event_listener_buffer_size(void) {
unsigned long succession_buffer = (unsigned long)__builtin_alloca(42);
msg_set_buf((const int*)succession_buffer);
}
$ LANG=C /nix/store/...-gcc-wrapper-12.0.0/bin/gcc -fno-strict-aliasing -Wall
-std=gnu99 -o a.o -c a.c.c -O2
a.c.c: In function 'clustering_hb_event_listener_buffer_size':
a.c.c:4:3: warning: '' may be used uninitialized
[-Wmaybe-uninitialized]
4 | msg_set_buf((const int*)succession_buffer);
| ^~
a.c.c:1:6: note: by argument 1 of type 'const int *' to 'msg_set_buf' declared
here
1 | void msg_set_buf(const int *);
| ^~~
There are two issues here (both are probably related):
1. '' location is reported instead of some form of 'succession_buffer'
reference
2. there should be no warning about uninitialized data, it's the same pointer
passed around
$ LANG=C /nix/store/...-gcc-wrapper-12.0.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/nix/store/...-gcc-12.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/...-gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210919 (experimental) (GCC)
Affected compilers:
- 12.0.0 20210919 snapshot
- 11.1.0 release
Unaffected compilers:
- 10.3.0 release
[Bug c/102539] [11/12 regression] -Wmaybe-uninitialized false positive, invalid location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102539 --- Comment #1 from Sergei Trofimovich --- Created attachment 51524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51524&action=edit a.c.c.orig a.c.c.orig is the unreduced preprocessed file with the same warning
[Bug tree-optimization/102539] [11/12 regression] -Wmaybe-uninitialized false positive, invalid location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102539
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|--- |11.3
Last reconfirmed||2021-09-30
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Keywords||diagnostic
--- Comment #2 from Andrew Pinski ---
The reduced testcase does not match at all the original testcase really.
Here is one which closer represents the original testcase:
void msg_set_buf(const int *);
void clustering_hb_event_listener_buffer_size(int a) {
void* succession_buffer = a>16? __builtin_malloc (a) : __builtin_alloca(a);
msg_set_buf((const int*)succession_buffer);
if (a>16) __builtin_free (succession_buffer);
}
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #10 from Andrew Pinski --- Starting in GCC 8, we warn about this: :5:5: warning: built-in function 'clog' declared as non-function [-Wbuiltin-declaration-mismatch] int clog=0; ^~~~ I noticed that LLVM's libc++ does not call clog but just log.
[Bug tree-optimization/102540] New: Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
Bug ID: 102540
Summary: Dead Code Elimination Regression at -O3 (trunk vs
11.2.0)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodoridisgr at gmail dot com
Target Milestone: ---
cat test.c
static long a;
static unsigned b;
void foo(void);
int main() {
long c, e;
c = b = a;
e = c ? 2 / (c + 1) : 0;
if (e && !b)
foo();
a = 0;
}
11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:
gcc-11 -v
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
gcc-11 test.c -S -O3
cat test.s
.file "test.c"
.text
.section.text.startup,"ax",@progbits
.p2align 4
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
movq$0, a(%rip)
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size main, .-main
.local a
.comm a,8,8
.ident "GCC: (GNU) 11.2.0"
.section.note.GNU-stack,"",@progbits
gcc-trunk -v
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210930 (experimental) (GCC)
gcc-trunk test.c -S -O3
cat test.s
.file "test.c"
.text
.section.text.startup,"ax",@progbits
.p2align 4
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
movqa(%rip), %rcx
movq%rcx, %rsi
andl$4294967295, %esi
je .L13
movl$2, %eax
addq$1, %rsi
cqto
idivq %rsi
testb $1, %al
je .L13
testl %ecx, %ecx
je .L17
.L13:
movq$0, a(%rip)
xorl%eax, %eax
ret
.L17:
pushq %rax
.cfi_def_cfa_offset 16
callfoo
xorl%edx, %edx
xorl%eax, %eax
movq%rdx, a(%rip)
popq%rcx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.local a
.comm a,8,8
.ident "GCC: (GNU) 12.0.0 20210930 (experimental)"
.section.note.GNU-stack,"",@progbits
[Bug fortran/102541] New: [12 Regression] runtime error: load of value 208393040, which is not a valid value for type 'ar_type' since r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102541 Bug ID: 102541 Summary: [12 Regression] runtime error: load of value 208393040, which is not a valid value for type 'ar_type' since r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: burnus at gcc dot gnu.org Blocks: 63426 Target Milestone: --- The following is causing UBSAN: $ cat ar.f90 type t end type class(T), allocatable :: ac(:) call bar(ac) contains subroutine bar(x) type(t) x(..) end end $ /dev/shm/objdir2/gcc/xgcc -B /dev/shm/objdir2/gcc gcc/ar.f90 -c /home/marxin/Programming/gcc2/gcc/fortran/trans-expr.c:6558:23: runtime error: load of value 208393040, which is not a valid value for type 'ar_type' #0 0x1127f3f in gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) /home/marxin/Programming/gcc2/gcc/fortran/trans-expr.c:6558 #1 0x1247a6c in gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) /home/marxin/Programming/gcc2/gcc/fortran/trans-stmt.c:425 #2 0xfe9298 in trans_code /home/marxin/Programming/gcc2/gcc/fortran/trans.c:1986 #3 0xfe9a29 in gfc_trans_code(gfc_code*) /home/marxin/Programming/gcc2/gcc/fortran/trans.c:2270 #4 0x10d2dbb in gfc_generate_function_code(gfc_namespace*) /home/marxin/Programming/gcc2/gcc/fortran/trans-decl.c:6905 #5 0xfe9ac5 in gfc_generate_code(gfc_namespace*) /home/marxin/Programming/gcc2/gcc/fortran/trans.c:2287 #6 0xdf8eca in translate_all_program_units /home/marxin/Programming/gcc2/gcc/fortran/parse.c:6572 #7 0xdfa1e8 in gfc_parse_file() /home/marxin/Programming/gcc2/gcc/fortran/parse.c:6841 #8 0xfa231c in gfc_be_parse_file /home/marxin/Programming/gcc2/gcc/fortran/f95-lang.c:216 #9 0x2b0eb5a in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:458 #10 0x2b19eee in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2233 #11 0x2b1a670 in toplev::main(int, char**) /home/marxin/Programming/gcc2/gcc/toplev.c:2372 #12 0x7496c80 in main /home/marxin/Programming/gcc2/gcc/main.c:39 #13 0x76f1453f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #14 0x76f145eb in __libc_start_main_impl ../csu/libc-start.c:409 #15 0xb03274 in _start (/dev/shm/objdir2/gcc/f951+0xb03274) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug fortran/102541] [12 Regression] runtime error: load of value 208393040, which is not a valid value for type 'ar_type' since r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102541 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||12.0 Status|UNCONFIRMED |NEW Known to work||11.2.0 Target Milestone|--- |12.0 Last reconfirmed||2021-09-30
[Bug tree-optimization/102505] [10/11/12 Regression] ICE in verify_sra_access_forest with 16 byte aligned field and virtual inheritance since r10-6321-g636e80eea24b780f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102505 Martin Liška changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11/12 Regression] ICE |in verify_sra_access_forest |in verify_sra_access_forest |with 16 byte aligned field |with 16 byte aligned field |and virtual inheritance |and virtual inheritance ||since ||r10-6321-g636e80eea24b780f CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- No, it started with r10-6321-g636e80eea24b780f.
[Bug debug/102507] ICE in btf_finalize when compiling with -gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102507 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Is it fixed now?
[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 Martin Liška changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-30
[Bug testsuite/102509] [12 regression] new test case gcc.c-torture/compile/attr-complex-method.c is unresolved after r12-3901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102509 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Mine then.
[Bug middle-end/102518] [11/12 regression] ICE during GIMPLE pass: einline in gimplify_modify_expr at -O2 since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102518 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|[11/12 regression] ICE |[11/12 regression] ICE |during GIMPLE pass: einline |during GIMPLE pass: einline |in gimplify_modify_expr at |in gimplify_modify_expr at |-O2 |-O2 since ||r11-165-geb72dc663e9070b2 --- Comment #2 from Martin Liška --- Started with r11-165-geb72dc663e9070b2.
[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Can we close it as fixed, please?
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #11 from Jonathan Wakely --- Libc++ uses complex<_Tp>(log(abs(__x)), arg(__x)); Even for C++11, which is based on C99, ::clog is not a reserved name in C++ because C++ specifies that just includes the C++ header, so defines std::complex and none of the C99 complex routines exist in C++. This is not a universally popular feature of C++. But it does mean that a strictly conforming C++ program can use ::clog for whatever purpose it wants. However, in practice, our implementation doesn't exist in a vacuum and depends on an underlying system library (which is usually based on POSIX) and so those symbols are essentially reserved too, even if the C++ standard doesn't say so. E.g. if you define a symbol called ::fdopen or ::open you're asking for trouble, even though those are not in ISO C++. If you want a pure ISO C++ environment that doesn't rely on additional features of POSIX and C99, maybe you need to look elsewhere.
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #12 from Jonathan Wakely --- tl;dr I'm tempted to close this as WONTFIX.
[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |12.0 Last reconfirmed||2021-09-30 Summary|Dead Code Elimination |[12 Regression] Dead Code |Regression at -O3 (trunk vs |Elimination Regression at |11.2.0) |-O3 since ||r12-476-gd846f225c25c5885 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-476-gd846f225c25c5885.
[Bug tree-optimization/102542] New: [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542
Bug ID: 102542
Summary: [12 Regression] ICE Segmentation fault since
r12-3876-g4a960d548b7d7d94
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: marxin at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
Target Milestone: ---
The following crashes:
$ cat block-5.c
int a[200][200];
int b_j;
void b() {
int i;
b_j = 1;
for (; b_j < 200; b_j++) {
i = 0;
for (; i < 200; i++)
a[i][b_j] = a[i][b_j - 1];
}
}
$ gcc block-5.c -c -fno-tree-ch -O3 -c
during GIMPLE pass: unrolljam
block-5.c: In function ‘b’:
block-5.c:5:6: internal compiler error: Segmentation fault
5 | void b() {
| ^
0xf053da crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x7789979f ???
/usr/src/debug/glibc-2.34-1.2.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x107a35c tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-manip.c:1425
0x1b6324b tree_loop_unroll_and_jam
/home/marxin/Programming/gcc/gcc/gimple-loop-jam.c:590
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-30 Known to work||11.2.0 Known to fail||12.0 Ever confirmed|0 |1 Target Milestone|--- |12.0
[Bug target/102543] New: -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543
Bug ID: 102543
Summary: -march=cascadelake performs odd alignment peeling
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For gcc.dg/torture/pr65270-1.c we choose to misalign an aligned store + load
combo for runtime aligning a single load because we have (skylake_cost):
{6, 6, 6, 10, 20},/* cost of loading SSE register
in 32bit, 64bit, 128bit, 256bit and
512bit */
{8, 8, 8, 12, 24},/* cost of storing SSE register
in 32bit, 64bit, 128bit, 256bit and
512bit */
{6, 6, 6, 10, 20},/* cost of unaligned loads. */
{8, 8, 8, 8, 16}, /* cost of unaligned stores. */
which means that an unaligned store is cheaper than an aligned store for
%ymm and even more so for %zmm!??
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #1 from Richard Biener --- same for icelake_cost.
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102385 --- Comment #1 from Andrew Pinski --- Most likely the same bug as PR 102385 and its related ones.
[Bug target/102544] New: GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 Bug ID: 102544 Summary: GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-' Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, caplanr at predsci dot com, jules at gcc dot gnu.org Target Milestone: --- Target: GCN Ron Caplan (in CC) is always eager to try his computational codes with GCC (in addition to other/proprietary/vendor-provided compilers), and I very much appreciate him providing feedback of any kind, which I find is always constructive. He's recently reported that "using Ubuntu 20.04 with the latest rocm and a Radeon VII", they got GCN offloading "to compile but when we run it we get: 'libgomp: target function wasn't mapped'". He sent me 'rocm-smi' and 'rocminfo' output, and comparing his vs. that of our amd_ryzen3 system, I find the following differences: -/+ Agent [...] *** Name:gfx906 -/+ Uuid:[...] - Marketing Name: Vega 20 + Marketing Name: Vega 20 [Radeon VII] Vendor Name: AMD [...] - Node:1 + Node:2 Device Type: GPU Cache Info: L1: 16(0x10) KB +L2: 8192(0x2000) KB Chip ID: 26287(0x66af) Cacheline Size: 64(0x40) -/+ Max Clock Freq. (MHz): [...] - BDFID: 2816 + BDFID: 33536 - Internal Node ID:1 + Internal Node ID:2 Compute Unit:60 SIMDs per CU:4 Shader Engines: 4 @@ -128,7 +188,7 @@ Agent 2 Accessible by all: FALSE ISA Info: ISA 1 - Name:amdgcn-amd-amdhsa--gfx906:sramecc-:xnack- + Name:amdgcn-amd-amdhsa--gfx906:sramecc+:xnack- The very last item, I suppose, is the crucial one: 'sramecc-' vs. 'sramecc+' -- Andrew? (a) How do we improve upon the run-time 'libgomp: target function wasn't mapped' error reporting mode? (b) What needs to be done to make this work?
[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Aldy Hernandez --- > (In reply to Aldy Hernandez from comment #11) >> This looks mighty suspicious ;-) >> >> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c >> index 69a3ab0ea9d..c24c67f8874 100644 >> --- a/gcc/tree-vrp.c >> +++ b/gcc/tree-vrp.c >> @@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader () >>delete m_threader; >>delete m_state; >>delete m_ranger; >> + delete m_query; >> >>scev_finalize (); >>loop_optimizer_finalize (); > > FWIW, all the patches so far proposed have been pushed to trunk, if you want > to > try again. This has done the trick: current master bootstraps again on i386-pc-solaris2.11. Thanks.
[Bug c++/102545] New: inlining constexpr is required yet it should not be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102545
Bug ID: 102545
Summary: inlining constexpr is required yet it should not be.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: e9leyland at outlook dot com
Target Milestone: ---
I module file rev.cpp there is the following,
module;
export import ;
export import ;
export module rev;
namespace rev {
export inline constexpr auto FAV_TEST_VAL = u8'9';
}
In the consumer file, main.cpp there is this,
import rev;
import ;
int
main(int, char**)
{
auto TEST_VAL = rev::FAV_TEST_VAL;
std::cout << std::hex << int(TEST_VAL) << std::endl;
}
The makefile has,
$ cat Makefile
.PHONY: default
default: main ;
gcmcache:
g++ -fmodules-ts -std=c++20 -x c++-system-header concepts
g++ -fmodules-ts -std=c++20 -x c++-system-header limits
g++ -fmodules-ts -std=c++20 -x c++-system-header iostream
rev.o: rev.cpp
g++ -c -std=c++20 -fmodules-ts rev.cpp
main: main.cpp rev.o
g++ -fmodules-ts -std=c++20 -o main main.cpp rev.o
clean:
rm rev.o main.exe rm -rf gcm.cache
The constexpr must be given the inline specifier to work, because if it is not
there the following error occurs.
$ make
g++ -c -std=c++20 -fmodules-ts rev.cpp
g++ -fmodules-ts -std=c++20 -o main main.cpp rev.o
main.cpp: In function ‘int main(int, char**)’:
main.cpp:7:26: error: ‘FAV_TEST_VAL’ is not a member of ‘rev’
7 | auto TEST_VAL = rev::FAV_TEST_VAL;
| ^~~~
make: *** [Makefile:13: main] Error 1
Shouldn't the constexpr be sufficient to inline the function from the standard?
In comparison to VS2022 the inline is not required, nor should it be.
[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Aldy Hernandez --- fixed
[Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |12.0 Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed||2021-09-30 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe --- (In reply to Matt Jacobson from comment #0) > I am working on a NeXTv2-ABI-compatible Objective-C runtime for a non-Darwin > platform (AVR micros). I'd like my Objective-C code to make use of the most > modern ABI features, namely those guarded in the code by `flag_next_runtime > >= USE_FIXUP_BEFORE`. > > However, there appears to be no way to control `flag_next_runtime` (short of > modifying the compiler source). I can set it to zero with `-fgnu-runtime` > or one with `-fnext-runtime`, but `USE_FIXUP_BEFORE` is an encoded Mac OS X > version (namely 100600, referring to Snow Leopard). by current design, there are enough bits in the value so that ne can have N MSBs representing the platform and N representing the version. > There is Darwin-specific option parsing code (`darwin_override_options()`) > that appears to set `flag_next_runtime` based on `-mmacosx-version-min`, but > obviously that doesn't run for non-Darwin targets. Most targets have an equivalent "override options" section where they could make a similar selection. A simplistic case would be to say any value >99 is not Darwin (i.e we make the Darwin platform part of the runtime value == 0 and then any other platform that wants to take an encoding takes a value higher; this would default to the next runtime just using "latest and greatest" - but that might not be what you want in say 2 years time... ... however, it would be better to use bit boundaries rather than arbitrary decimal. maybe ... 0xff00 masks the platform 0x00ff masks the version selector and Darwin is platform 0 for this purpose. so as a quick fix you could just say AVR is platform 1 and set it to 0x0100 in your platform flags override ... > I could imagine a few approaches to fixing this: > > 1. Parse `-mmacosx-version-min` even when the target is not Darwin, whenever > we're compiling Objective-C. On non-Darwin, this would be interpreted as > requesting Objective-C codegen compatible with the Objective-C ABI of the > specified release of Mac OS X. I do not think that is going to fly ;) > 2. Allow an argument to `-fnext-runtime`, with the meaning approximately the > same as in #1. > > 3. Instead of using `flag_next_runtime` as a version number, switch it back > to being zero or one, and use a separate flag (perhaps the existing > `-fobjc-abi-version`?) to differentiate ABIs. These two were both thoughts during the development but I suspect that the mapping to values is a build-time decision and ought to be done in the flags override code. thoughts?
[Bug ipa/102474] [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
[Bug testsuite/102509] [12 regression] new test case gcc.c-torture/compile/attr-complex-method.c is unresolved after r12-3901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102509 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:c3d11a1e9528b6140c65a66d47225a0b6a8814e0 commit r12-3982-gc3d11a1e9528b6140c65a66d47225a0b6a8814e0 Author: Martin Liska Date: Thu Sep 30 14:12:35 2021 +0200 testsuite: Skip a test-case when LTO is used [PR102509] PR testsuite/102509 gcc/testsuite/ChangeLog: * gcc.c-torture/compile/attr-complex-method.c: Skip if LTO is used. * gcc.c-torture/compile/attr-complex-method-2.c: Likewise.
[Bug testsuite/102509] [12 regression] new test case gcc.c-torture/compile/attr-complex-method.c is unresolved after r12-3901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102509 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 --- Comment #1 from Andrew Stubbs --- Please set "export GCN_DEBUG=1", try it again, and post the output.
[Bug c++/102104] parameter packs not expanded with '...' for operator conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102104 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com
Blocks||85316
Version|unknown |12.0
--- Comment #2 from Richard Biener ---
FRE1 has the following difference, simplifying the (unsigned int) truncation.
:
a.0_1 = a;
_2 = (unsigned int) a.0_1;
b = _2;
- c_10 = (long int) _2;
+ _6 = a.0_1 & 4294967295;
+ c_10 = _6;
if (c_10 != 0)
goto ; [INV]
else
where the EVRP which now uses ranger retains (diff from GCC 11 to trunk):
:
a.0_1 = a;
_2 = (unsigned int) a.0_1;
b = _2;
- c_10 = (long int) _2;
+ _6 = a.0_1 & 4294967295;
+ c_10 = _6;
if (c_10 != 0)
goto ; [INV]
else
-goto ; [INV]
+goto ; [INV]
:
_4 = c_10 + 1;
iftmp.2_12 = 2 / _4;
+ if (iftmp.2_12 != 0)
+goto ; [INV]
+ else
+goto ; [INV]
:
+ if (_2 == 0)
+goto ; [INV]
+ else
+goto ; [INV]
+
+ :
+ foo ();
+
+ :
a = 0;
return 0;
after EVRP we have
+ # RANGE [0, 4294967295] NONZERO 4294967295
c_10 = _6;
...
+ # RANGE [2, 4294967296] NONZERO 8589934591
_4 = c_10 + 1;
+ # RANGE [0, 1] NONZERO 1
iftmp.2_12 = 2 / _4;
if (iftmp.2_12 != 0)
what we did in GCC 11 is simplified the following check
:
if (_2 == 0)
goto ; [INV]
else
goto ; [INV]
based on iftmp.2_12 == [1, 1] via ranger and
evrp visiting BB4
Visiting controlling predicate if (iftmp.2_12 != 0)
Adding assert for iftmp.2_12 from iftmp.2_12 != 0
Intersecting
long int ~[0, 0] EQUIVALENCES: { iftmp.2_12 } (1 elements)
and
long int [0, 1]
to
long int [1, 1] EQUIVALENCES: { iftmp.2_12 } (1 elements)
Intersecting
long int [0, 1]
and
long int [1, 1]
to
long int [1, 1]
pushing new range for iftmp.2_12: long int [1, 1] EQUIVALENCES: { iftmp.2_12 }
(1 elements)
evrp visiting stmt if (_2 == 0)
Folding statement: if (_2 == 0)
Visiting conditional with predicate: if (_2 == 0)
With known ranges
_2: unsigned int [1, +INF] EQUIVALENCES: { _2 } (1 elements)
Predicate evaluates to: 0
Folded into: if (0 != 0)
that's now missing, somehow due to the folded IL if the bisect is correct.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug c++/102530] Warn about non-extended temporary passed to a function returning a reference in temp-extending context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102530 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- Would this warning go under a new flag, or an existing one?
[Bug middle-end/102518] [11/12 regression] ICE during GIMPLE pass: einline in gimplify_modify_expr at -O2 since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102518 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I will have a look. We're getting # VUSE <.MEM> _2 = MEM[(struct A *)&&i].x; when mapping &i into [local count: 1073741824]: _1 = MEM[(struct A *)&c].x; _2 = _1 != 0B; _4 = (int) _2; return _4; here what's the difference is that 'c' is no longer TREE_ADDRESSABLE because we can now mark it with DECL_NOT_GIMPLE_REG. That means the "obvious" fix would be to amend the !TREE_ADDRESSABLE check in if (TREE_READONLY (p) && !TREE_ADDRESSABLE (p) && value && !TREE_SIDE_EFFECTS (value) && !def) with a !DECL_NOT_GIMPLE_REG check.
[Bug tree-optimization/102546] New: Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
Bug ID: 102546
Summary: Missed Dead Code Elimination regression (trunk vs
11.2.0) at -O3
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 missed_case.c
static int a;
static char b, c, d;
void bar(void);
void foo(void);
int main() {
int f = 0;
for (; f <= 5; f++) {
bar();
b = b && f;
d = f << f;
if (!(a >= d || f))
foo();
c = 1;
for (; c; c = 0)
;
}
}
11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:
gcc-trunk -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210930 (experimental) (GCC)
gcc-trunk -O3 -S missed_case.c
main:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
xorl%ebx, %ebx
.L6:
callbar
cmpb$0, b(%rip)
je .L2
testl %ebx, %ebx
jne .L5
movb$0, b(%rip)
movl$1, %ebx
movb$0, c(%rip)
callbar
cmpb$0, b(%rip)
je .L4
.L5:
movb$1, b(%rip)
.L4:
addl$1, %ebx
movb$0, c(%rip)
cmpl$6, %ebx
jne .L6
xorl%eax, %eax
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L2:
.cfi_restore_state
movl%ebx, %eax
movl%ebx, %ecx
sall%cl, %eax
testb %al, %al
jle .L4
testl %ebx, %ebx
jne .L4
callfoo
movb$0, c(%rip)
movl$1, %ebx
callbar
cmpb$0, b(%rip)
jne .L5
jmp .L2
.cfi_endproc
gcc-11 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
cat missed_case.s
main:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$5, %ebx
callbar
movb$0, b(%rip)
movb$0, c(%rip)
.p2align 4,,10
.p2align 3
.L2:
callbar
cmpb$0, b(%rip)
movb$0, c(%rip)
setne b(%rip)
subl$1, %ebx
jne .L2
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
[Bug tree-optimization/102546] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 --- Comment #1 from Theodoros Theodoridis --- It bisects to 2e96b5f14e4025691b57d2301d71aa6092ed44bc
[Bug c++/102545] [modules] inlining constexpr is required yet it should not be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102545 --- Comment #1 from Emily Leyland --- Good question, there seems to be some debate. From en.cppreference.com/w/cpp/language/constexpr, A constexpr specifier used in a function or static data member (since C++17) declaration implies inline.
[Bug c++/102545] [modules] inlining constexpr is required yet it should not be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102545 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- But the above is not a static data member, so it is not inline by default.
[Bug c++/101355] incorrect `this' in destructor calls when compiling coroutines with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101355 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Would it be possible to backport this to gcc 11 too?
[Bug c++/102535] __is_trivially_constructible rejects some trivial cases in aggregate initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102535 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-30 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Patrick Palka --- Confirmed.
[Bug c++/101355] incorrect `this' in destructor calls when compiling coroutines with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101355 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |11.3 --- Comment #7 from Iain Sandoe --- (In reply to Marek Polacek from comment #6) > Would it be possible to backport this to gcc 11 too? it's on my TODO to back port the correctness fixes to 11 (and where feasible 10).
[Bug c++/94197] __is_constructible gives an access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94197 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.0 CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 10+
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 Bug 94033 depends on bug 94197, which changed state. Bug 94197 Summary: __is_constructible gives an access error https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94197 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/93642] [Coroutines] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8070 using co_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93642 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Sandoe --- works OK on gcc-10 gcc-11 and gcc-12 branches as of today.
[Bug c++/102363] source_location in await_transform has function_name referring to internal coroutine funclet rather than source-level function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102363 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-09-30 Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- source location information needs some work in the synthesis - the defaults are not the most useful.
[Bug c++/96517] ICE in is_this_parameter when accessing constexpr method of a field inside coroutine lambda (with optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96517 Iain Sandoe changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed||2021-09-30 Target Milestone|--- |10.4 Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 Aldy Hernandez changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Aldy Hernandez --- A little -fdbg-cnt bisecting magic shows that the first jump thread causes some sort of reaction downstream in unrolljam: ./cc1 a.c -quiet -O3 -fno-tree-ch -fdbg-cnt=registered_jump_thread:1-1 ***dbgcnt: lower limit 1 reached for registered_jump_thread.*** ***dbgcnt: upper limit 1 reached for registered_jump_thread.*** during GIMPLE pass: unrolljam a.c: In function ‘b’: a.c:5:6: internal compiler error: Segmentation fault So it's the first threading path that is causing an issue. Setting a breakpoint at path registering yields this: Breakpoint 5, jt_path_registry::register_jump_thread (this=0x391f150, Python Exception There is no member or method named m_vecpfx.: path=0x3a09430) at /home/aldyh/src/gcc/gcc/tree-ssa-threadupdate.c:2838 (gdb) p ::debug(path) [1] Registering jump thread: (8, 4) incoming edge; (4, 3) normal; It's threading 8->4->3, which looks perfectly reasonable: [local count: 1073741824]: # i_5 = PHI <0(8), i_12(3)> if (i_5 != 200) goto ; [99.00%] else goto ; [1.00%] Note that i_5 is known to be 0 on the 8->4 edge. The loop info says that bb8 is the pre-header to loop 2 which starts at bb4. So this technically crosses loops into bb4, but is allowed as there's an exception when the first BB is in another block: // The first entry represents the block with an outgoing edge // that we will redirect to the jump threading path. Thus we // don't care about that block's loop father. Similarly in the back threader profitability code: /* Remember, blocks in the path are stored in opposite order in the PATH array. The last entry in the array represents the block with an outgoing edge that we will redirect to the jump threading path. Thus we don't care about that block's loop father, nor how many statements are in that block because it will not be copied or whether or not it ends in a multiway branch. */ For reference, here is the full IL: int i; int _1; int _2; int _3; int b_j.3_4; [local count: 1327096]: b_j = 1; goto ; [100.00%] [local count: 1063004409]: _1 = b_j.3_4 + -1; _2 = a[i_5][_1]; a[i_5][b_j.3_4] = _2; i_12 = i_5 + 1; [local count: 1073741824]: # i_5 = PHI <0(8), i_12(3)> if (i_5 != 200) goto ; [99.00%] else goto ; [1.00%] [local count: 10737416]: _3 = b_j.3_4 + 1; b_j = _3; [local count: 12064512]: b_j.3_4 = b_j; if (b_j.3_4 <= 199) goto ; [89.00%] else goto ; [11.00%] [local count: 10737416]: goto ; [100.00%] [local count: 1327096]: return; I think this is a problem elsewhere.
[Bug c++/102547] New: g++ 11. ICE with NTTPs and partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547
Bug ID: 102547
Summary: g++ 11. ICE with NTTPs and partial specialization
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bob.steagall.cpp at gmail dot com
Target Milestone: ---
The following C++ source code:
---
template
struct vals {};
template
struct vals_client {};
template
struct vals_client, A> {};
template
struct vals_client, void> {};
void testfn()
{
vals_client, int> ci; //- OK
vals_client, void> cv; //- "sorry, unimplemented..., ICE"
}
---
When compiled with gcc 11.X generates this error:
nttp_test.cpp: In function 'void testfn()':
nttp_test.cpp:18:36: sorry, unimplemented: unexpected AST of kind
nontype_argument_pack
18 | vals_client, void> cv; //- "sorry, unimplemented..."
|^~
nttp_test.cpp:18: confused by earlier errors, bailing out
---
When compiled with gcc trunk on godbolt.org, it elicits an ICE:
: In function 'void testfn()':
:23:36: sorry, unimplemented: unexpected AST of kind
nontype_argument_pack
23 | vals_client, void> cv; //- "sorry, unimplemented...,
ICE"
|^~
:23:36: internal compiler error: in potential_constant_expression_1, at
cp/constexpr.c:9051
0x1fe73f9 internal_error(char const*, ...)
???:0
0x7d40a7 fancy_abort(char const*, int, char const*)
???:0
0x8475ff potential_constant_expression(tree_node*)
???:0
0xa21bd7 instantiation_dependent_expression_p(tree_node*)
???:0
0xa21c46 uses_template_parms(tree_node*)
???:0
0xa72888 most_specialized_partial_spec(tree_node*, int)
???:0
0xa7f834 instantiate_class_template(tree_node*)
???:0
0x89e107 start_decl_1(tree_node*, bool)
???:0
0x8c552f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0xa08395 c_parse_file()
???:0
0xb8f562 c_common_parse_file()
???:0
Please submit a full bug report, ...
---
Testing with various version on godbolt.org reveals that the ICE does not
occur with 10.X, 9.X, 8.X, or 7.X (that's as far back as I went).
[Bug d/102476] d: Options -fmain and -fno-druntime do not work together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102476 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:d46a29d919058fb383d19fe35c234fab58286f71 commit r12-3985-gd46a29d919058fb383d19fe35c234fab58286f71 Author: Iain Buclaw Date: Fri Sep 24 10:59:47 2021 +0200 libphobos: Define main function as extern(C) when compiling without D runtime (PR102476) The default supplied main function as read when compiling with `-fmain' has extern(D) linkage. However this does not work when mixing this option together with `-fno-druntime'. PR d/102476 gcc/testsuite/ChangeLog: * gdc.dg/pr102476.d: New test. libphobos/ChangeLog: * libdruntime/__main.di: Define main function as extern(C) when compiling without D runtime.
[Bug d/102476] d: Options -fmain and -fno-druntime do not work together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102476 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fix committed.
[Bug fortran/84007] [OOP] ICE with SAME_TYPE_AS and CLASS(*) entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84007 --- Comment #5 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383 commit r12-3990-g643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383 Author: Tobias Burnus Date: Thu Sep 30 19:08:25 2021 +0200 Fortran: Fix same_type_as A test for CLASS(*) + assumed rank was missing; adding a test to unlimited_polymorphic_1.f03 showed an ICE as backend_decl wasn't set. While gfc_get_symbol_decl would fix it, the code also assumed that the class(*) was a variable and could not be a subobject of a derived type. PR fortran/71703 PR fortran/84007 gcc/fortran/ChangeLog: * trans-intrinsic.c (gfc_conv_same_type_as): Fix handling of UNLIMITED_POLY. * trans.h (gfc_vtpr_hash_get): Renamed prototype to ... (gfc_vptr_hash_get): ... this to match function name. gcc/testsuite/ChangeLog: * gfortran.dg/c-interop/c535b-1.f90: Remove wrong comment. * gfortran.dg/unlimited_polymorphic_1.f03: Extend. * gfortran.dg/unlimited_polymorphic_32.f90: New test.
[Bug fortran/71703] [9/10/11/12 Regression] [OOP] ICE in wide_int_to_tree, at tree.c:1488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71703 --- Comment #16 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383 commit r12-3990-g643e8f4ee3a2a59a9b96fbcd1ffa8bacbda5b383 Author: Tobias Burnus Date: Thu Sep 30 19:08:25 2021 +0200 Fortran: Fix same_type_as A test for CLASS(*) + assumed rank was missing; adding a test to unlimited_polymorphic_1.f03 showed an ICE as backend_decl wasn't set. While gfc_get_symbol_decl would fix it, the code also assumed that the class(*) was a variable and could not be a subobject of a derived type. PR fortran/71703 PR fortran/84007 gcc/fortran/ChangeLog: * trans-intrinsic.c (gfc_conv_same_type_as): Fix handling of UNLIMITED_POLY. * trans.h (gfc_vtpr_hash_get): Renamed prototype to ... (gfc_vptr_hash_get): ... this to match function name. gcc/testsuite/ChangeLog: * gfortran.dg/c-interop/c535b-1.f90: Remove wrong comment. * gfortran.dg/unlimited_polymorphic_1.f03: Extend. * gfortran.dg/unlimited_polymorphic_32.f90: New test.
[Bug tree-optimization/102546] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com --- Comment #2 from Aldy Hernandez --- By VRP1 we seem to be calculating the following: (f_8 << f_8) && (f_8 == 0) This would fold to false, which would elide the foo(): [local count: 59055800]: b = 0; _3 = f_8 << f_8; _4 = (char) _3; _5 = (int) _4; if (_4 > 0) goto ; [64.06%] else goto ; [35.94%] [local count: 34842922]: if (f_8 == 0) goto ; [71.10%] else goto ; [28.90%] [local count: 12809203]: foo (); So from the outset, it seems like this is a missing relation in range-ops. That is if we know f_8 << f_8 is non-zero, then we know f_8 cannot be 0. This looks like an easy fix, however... What I fail to see is how "a" got removed entirely from the IL, making this scenario possible: if (!(a >= d || f)) foo(); Am I missing something obvious here?
[Bug target/89954] missed optimization for signed extension for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954 --- Comment #11 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6f4459c478b1c09e4b5e7d629fbf46d2a4fe4560 commit r12-3991-g6f4459c478b1c09e4b5e7d629fbf46d2a4fe4560 Author: Uros Bizjak Date: Thu Sep 30 19:33:49 2021 +0200 i386: Eliminate sign extension after logic operation [PR89954] Convert (sign_extend:WIDE (any_logic:NARROW (memory, immediate))) to (any_logic:WIDE (sign_extend (memory)), (sign_extend (immediate))). This eliminates sign extension after logic operation. 2021-09-30 Uroš Bizjak gcc/ PR target/89954 * config/i386/i386.md (sign_extend:WIDE (any_logic:NARROW (memory, immediate)) splitters): New splitters. gcc/testsuite/ PR target/89954 * gcc.target/i386/pr89954.c: New test.
[Bug target/89954] missed optimization for signed extension for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Uroš Bizjak --- Implemented for gcc-12.
[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540 --- Comment #3 from Aldy Hernandez --- To elide the foo(), _2 must be non-zero on the 2->3 edge dominating the call. Interestingly, a.0_1 is non-zero on the 2->3 edge, and we have: _2 = (unsigned int) a.0_1 but somehow we have no knowledge of _2. Andrew, wanna take a stab at this? === BB 2 Imports: a.0_1 Exports: a.0_1 _6 c_10 _2 : a.0_1(I) _6 : a.0_1(I) c_10 : a.0_1(I) _6 Equivalence set : [] Equivalence set : [_6, c_10] : a.0_1 = a; _2 = (unsigned int) a.0_1; b = _2; _6 = a.0_1 & 4294967295; c_10 = _6; if (c_10 != 0) goto ; [INV] else goto ; [INV] _6 : long int [0, 4294967295] c_10 : long int [0, 4294967295] 2->3 (T) a.0_1 : long int [-INF, -1][1, +INF] 2->3 (T) _6 : long int [1, 4294967295] 2->3 (T) c_10 :long int [1, 4294967295] 2->6 (F) a.0_1 : long int [-INF, -4294967296][0, +INF] 2->6 (F) _6 : long int [0, 0] 2->6 (F) c_10 :long int [0, 0]
[Bug tree-optimization/102546] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 --- Comment #3 from Aldy Hernandez --- > What I fail to see is how "a" got removed entirely from the IL, making this > scenario possible: > > if (!(a >= d || f)) > foo(); What I meant to say is that I don't understand how "a" got removed from the IL representing this: if (!(a >= d || f)) foo(); Because it's the missing "a" which opens the door for the un-folded expression here: (f_8 << f_8) && (f_8 == 0)
[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0212bcfc31a938d4b2f247dc42f75b1d523bb1ef commit r11-9047-g0212bcfc31a938d4b2f247dc42f75b1d523bb1ef Author: Harald Anlauf Date: Wed Sep 29 20:11:53 2021 +0200 Fortran: fix error recovery for invalid constructor gcc/fortran/ChangeLog: PR fortran/102520 * array.c (expand_constructor): Do not dereference NULL pointer. gcc/testsuite/ChangeLog: PR fortran/102520 * gfortran.dg/pr102520.f90: New test. (cherry picked from commit 5e2adfeed21ee584a82cdcdfa7eed41202eb67cd)
[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f653f612a95ab9d54e005fba7ac6bb40ec14ffb9 commit r10-10155-gf653f612a95ab9d54e005fba7ac6bb40ec14ffb9 Author: Harald Anlauf Date: Wed Sep 29 20:11:53 2021 +0200 Fortran: fix error recovery for invalid constructor gcc/fortran/ChangeLog: PR fortran/102520 * array.c (expand_constructor): Do not dereference NULL pointer. gcc/testsuite/ChangeLog: PR fortran/102520 * gfortran.dg/pr102520.f90: New test. (cherry picked from commit 5e2adfeed21ee584a82cdcdfa7eed41202eb67cd)
[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on affected branches. Closing. Thanks for the report!
[Bug c++/102548] New: gcc segmentation fault in cc1plus (with repro case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102548 Bug ID: 102548 Summary: gcc segmentation fault in cc1plus (with repro case) Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ulatekh at yahoo dot com Target Milestone: --- Created attachment 51525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51525&action=edit Preprocessed source Found this with the current MSYS2 MinGW compiler (building a bleeding-edge version of cmake), but it also crashes on my Fedora 33 machine when running "g++ -march=x86-64 -m32 cmTimestamp.ii".
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #14 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b19bbfb1482505367dd19ae4ab1ea19e36802b6a commit r12-3993-gb19bbfb1482505367dd19ae4ab1ea19e36802b6a Author: Harald Anlauf Date: Thu Sep 30 20:29:31 2021 +0200 Fortran: resolve expressions during SIZE simplification gcc/fortran/ChangeLog: PR fortran/102458 * simplify.c (simplify_size): Resolve expressions used in array specifications so that SIZE can be simplified. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458b.f90: New test.
[Bug c/102549] New: Incorrect optimization if argument is SNAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102549
Bug ID: 102549
Summary: Incorrect optimization if argument is SNAN
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Serge.Pavlov.at.gnu at gmail dot com
Target Milestone: ---
GCC was taken at https://godbolt.org, the reported version is:
gcc
(Compiler-Explorer-Build-gcc-d6a87d96d7473cbd2404d5dcc7eef36a7f53b2b2-binutils-2.36.1)
12.0.0 20210929 (experimental)
The program is:
extern int printf(const char *fmt, ...);
union {
double f;
long long i;
} val;
double add_zero(double x) {
return x + -0.0;
}
int main(int arc, char *argv[]) {
val.i = 0x7ff4LL; // SNaN
val.f = add_zero(val.f);
printf("%llx\n", val.i);
return 0;
}
Compiled with options "-O2" this program prints
(https://godbolt.org/z/YE13qEhf9):
7ff4
This is incorrect as this is SNaN, but according to IEEE 754-2008, 6.2:
Under default exception handling, any operation signaling an invalid operation
exception and for which a
floating-point result is to be delivered shall deliver a quiet NaN.
Signaling NaNs shall be reserved operands that, under default exception
handling, signal the invalid
operation exception (see 7.2) for every general-computational and
signaling-computational operation except
for the conversions described in 5.12.
And according to the latest standard draft
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf), F.3p1:
C operators, functions, and function-like macros provide operations specified
by IEC 60559 as shown
in the following table. ... The C specifications are
intended to match IEC 60559, unless stated otherwise.
So a QNaN is expected here.
If "-0.0" is replaced with the positive zero:
double add_zero(double x) {
return x + 0.0;
}
the behavior is as expected, the program prints:
7ffc
which is QNaN.
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:39b948a8f404aa0bfb632d7b26bb0692b18f60c9 commit r10-10156-g39b948a8f404aa0bfb632d7b26bb0692b18f60c9 Author: Harald Anlauf Date: Mon Sep 13 19:28:10 2021 +0200 Fortran - ensure simplification of bounds of array-valued named constants gcc/fortran/ChangeLog: PR fortran/82314 * decl.c (add_init_expr_to_sym): For proper initialization of array-valued named constants the array bounds need to be simplified before adding the initializer. gcc/testsuite/ChangeLog: PR fortran/82314 * gfortran.dg/pr82314.f90: New test. (cherry picked from commit 104c05c5284b7822d770ee51a7d91946c7e56d50)
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3a70195d7da49fe793ce3eb0e839b9ceea96c97a commit r9-9749-g3a70195d7da49fe793ce3eb0e839b9ceea96c97a Author: Harald Anlauf Date: Mon Sep 13 19:28:10 2021 +0200 Fortran - ensure simplification of bounds of array-valued named constants gcc/fortran/ChangeLog: PR fortran/82314 * decl.c (add_init_expr_to_sym): For proper initialization of array-valued named constants the array bounds need to be simplified before adding the initializer. gcc/testsuite/ChangeLog: PR fortran/82314 * gfortran.dg/pr82314.f90: New test. (cherry picked from commit 104c05c5284b7822d770ee51a7d91946c7e56d50)
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |9.5 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 --- Comment #15 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:97a5a41dbfef1722fdaf4dc979e8b9c274b4404d commit r9-9750-g97a5a41dbfef1722fdaf4dc979e8b9c274b4404d Author: Harald Anlauf Date: Thu Sep 9 21:34:01 2021 +0200 Fortran - out of bounds in array constructor with implied do loop gcc/fortran/ChangeLog: PR fortran/98490 * trans-expr.c (gfc_conv_substring): Do not generate substring bounds check for implied do loop index variable before it actually becomes defined. gcc/testsuite/ChangeLog: PR fortran/98490 * gfortran.dg/bounds_check_23.f90: New test. (cherry picked from commit 5fe0865ab788bdc387b284a3ad57e5a95a767b18)
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.5 --- Comment #16 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99710 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-09-30 CC||iains at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe --- indeed we should reject this
[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99710
--- Comment #2 from Iain Sandoe ---
#include
struct task {
struct promise_type {
std::suspend_always initial_suspend();
std::suspend_always final_suspend() noexcept;
task get_return_object();
void return_void();
void unhandled_exception();
};
};
task
my_coro ()
{
try
{ }
catch (...)
{
// [expr.await]
co_await std::suspend_always{}; // { dg-error "We should have an error
here" }
}
}
[Bug c++/102547] g++ 11. ICE with NTTPs and partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-09-30 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed.
[Bug c/102549] Incorrect optimization if argument is SNAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102549 --- Comment #1 from Andrew Pinski --- I think you need -fsignaling-nans
[Bug libstdc++/59769] please add ios_base::__noreplace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59769 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-09-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- I have started a discussion about getting this into the standard.
[Bug c/102549] Incorrect optimization if argument is SNAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102549 --- Comment #2 from Andrew Pinski --- Note also from the docs: This option is experimental and does not currently guarantee to disable all GCC optimizations that affect signaling NaN behavior.
[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e3ad4c45d128c1f4a69f86116a36312aa593554c commit r9-9751-ge3ad4c45d128c1f4a69f86116a36312aa593554c Author: Harald Anlauf Date: Tue Sep 7 20:51:49 2021 +0200 Fortran - improve error recovery determining array element from constructor gcc/fortran/ChangeLog: PR fortran/101327 * expr.c (find_array_element): When bounds cannot be determined as constant, return error instead of aborting. gcc/testsuite/ChangeLog: PR fortran/101327 * gfortran.dg/pr101327.f90: New test. (cherry picked from commit 2a1537a19cb2fa85823cfa18ed40baa4b259b4e3)
[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.5 Status|NEW |RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #9 from qinzhao at gcc dot gnu.org --- the direct cause of the ICE is because: MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1); in the above, the fb.3 is in REG instead MEM: 8451 gcc_assert (MEM_P (result)); (gdb) call debug_tree(exp) unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe9463348 precision:8 min max > TI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe9463498 domain DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe94633f0 precision:64 min max > pointer_to_this > used ignored TI pr82421.c:10:7 size unit-size align:128 warn_if_not_align:0 context (reg:TI 84 [ fb.3 ])> fb.3 is introduced by CCP transformation, disabling tree-ccp cures the failure by adding -fno-tree-ccp. I suspect that ccp might have a bug that does not mark TREE_ADDRESSABLE correctly for fb.3.
[Bug c++/93320] internal compiler error: in is_base_type, at dwarf2out.c:12987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Comment #8 from Luke Dalessandro ---
I'm still seeing failures on this line in 12/trunk with the following invalid
code with std=c++17, **but not with -std=c++20**. Don't think architecture is
important.
```
struct A {
A(decltype(auto)... xs) {}
};
```
https://godbolt.org/z/neKc1M6sd
[Bug c++/102547] g++ 11. ICE with NTTPs and partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547 Patrick Palka changed: What|Removed |Added Known to work||10.3.0 CC||mpolacek at gcc dot gnu.org Summary|g++ 11. ICE with NTTPs and |[11/12 Regression] g++ 11. |partial specialization |ICE with NTTPs and partial ||specialization Keywords||rejects-valid Known to fail||11.2.0, 12.0 Target Milestone|--- |11.3 --- Comment #2 from Patrick Palka --- Started with r11-4671.
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) > So instead of doing *((T[0:] *)&a[ubound])[-idx] for accesses do > a[ubound - idx]? I think this assumption is correct. Of course 'a' could have a non-trivial stride (i.e. being /= 1), which is provided by the array descriptor. That should hopefully been respected by the suggested change.
[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99575 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-30 CC||iains at gcc dot gnu.org
[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99575 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- I think I have a potential fix -- replace the problematic call to uses_template_parms with dependent_template_arg_p: --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -23587,7 +23587,7 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict, even if ARG == PARM, since we won't record unifications for the template parameters. We might need them if we're trying to figure out which of two things is more specialized. */ - if (arg == parm && !uses_template_parms (parm)) + if (arg == parm && !dependent_template_arg_p (parm)) return unify_success (explain_p); /* Handle init lists early, so the rest of the function can assume So mine I suppose.
[Bug c++/101144] Coroutine compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101144 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- duplicate of 98056 *** This bug has been marked as a duplicate of bug 98056 ***
[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 Iain Sandoe changed: What|Removed |Added CC||victor.burckel at gmail dot com --- Comment #12 from Iain Sandoe --- *** Bug 101144 has been marked as a duplicate of this bug. ***
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #10 from qinzhao at gcc dot gnu.org ---
commented the following transformation in tree-ssa-ccp.c:
2733 #if 0
2734 /* The heuristic of fold_builtin_alloca_with_align differs before
and
2735after inlining, so we don't require the arg to be changed into
a
2736constant for folding, but just to be constant. */
2737 if (gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
2738 || gimple_call_builtin_p (stmt,
BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
2739 {
2740 tree new_rhs = fold_builtin_alloca_with_align (stmt);
2741 if (new_rhs)
2742 {
2743 gimplify_and_update_call_from_tree (gsi, new_rhs);
2744 tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
2745 insert_clobbers_for_var (*gsi, var);
2746 return true;
2747 }
2748 }
2749 #endif
cures the ICE. "fb.3" is a new temp variable that is created inside
"fold_builtin_alloca_with_align".
[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #2 from Iain Sandoe --- the preprocessed file compiles for me using current gcc-10, 11 and master - could you provide a little more info? (does it still fail for your case?)
[Bug middle-end/102549] Incorrect optimization if argument is SNAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102549 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Yes you need to use -fsignaling-nans.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #11 from David Binderman ---
(In reply to qinzhao from comment #10)
> 2734 /* The heuristic of fold_builtin_alloca_with_align differs
git blame says:
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2732) /*
The heuristic of fold_builtin_alloca_with_align differs before and
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2733)
after inlining, so we don't require the arg to be changed into a
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2734)
constant for folding, but just to be constant. */
9e878cf1bae7 (Eric Botcazou 2017-10-19 15:58:05 + 2735) if
(gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
9e878cf1bae7 (Eric Botcazou 2017-10-19 15:58:05 + 2736)||
gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
1fed1006552c (Tom de Vries 2011-08-31 07:04:25 + 2737)
{
13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2738)
tree new_rhs = fold_builtin_alloca_with_align (stmt);
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2739)
if (new_rhs)
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2740) {
52a5515ed661 (Richard Biener 2021-04-14 13:40:58 +0200 2741)
gimplify_and_update_call_from_tree (gsi, new_rhs);
2f31f742a693 (Tom de Vries 2011-12-17 11:39:43 + 2742)
tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
2f31f742a693 (Tom de Vries 2011-12-17 11:39:43 + 2743)
insert_clobbers_for_var (*gsi, var);
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2744)
return true;
5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2745) }
1fed1006552c (Tom de Vries 2011-08-31 07:04:25 + 2746)
}
so at least Tom, Eric and Richard have been in there.
[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547 --- Comment #4 from Bob Steagall --- I have applied this tentative change to line 23436 of gcc/cp/pt.c from the gcc-11.2.0 source tarball, and can confirm that the test case compiles for me. The code I was working on also compiles, links, and appears to run correctly. I don't know if this is the final fix, but it is progress.
[Bug debug/102534] RFE epilog is not reliably a statement with inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534 --- Comment #4 from Ben Woodard --- There continues to be an instruction after the completion of the inlining, the next instruction in the sequence, At the time when the inlining occurs why can’t the .loc 1 6 1 be placed there as part of the process of folding the instructions for the inlined code into the calling function. This is analogous to the placement of loc 1 5 4 for the first first line inside the function in every location where the the function is called. It just gets attached to the next instruction after the function’s completion. In other words we argue that .loc 1 6 1 should be attached to the instructions at: 401081 401094 4010a4 Another case that we would like to see work even though it optimizes to no machine instructions which we tried to include in this fragment of source is the case where we call a function that gets completely optimized away to a call for another function. Even when that happens, we would like the residue of its former existence to be in the line map matrix. That is why we included both a static and a potentially external function, were this to be compiled as PIE then the unused function could still be called. We thought that the two situations while highly related, were different. Also you didn’t explain why the main() function at line 25 did not get a breakpoint associated with the closing brace for it. It does have a ret instruction and it is not inlined. If that needs to be a separate PR, I do not mind splitting it off.
