[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #5 from Andrew Pinski ---
I am 99% sure there is aliasing violations in this code too:
#if _MSC_VER
#define GETU32(p) SWAP(*((u32 *)(p)))
#define PUTU32(ct, st) \
{ \
*((u32 *)(ct)) = SWAP((st));\
}
#else /* _MSC_VER */
# if __BYTE_ORDER == __BIG_ENDIAN
#define GETU32(p) *((u32*)(p))
#define PUTU32(ct, st) *((u32*)(ct)) = (st)
#else /* BIG_ENDIAN */
#if 0 //def HAVE_LINUX_SWAB_H
#define GETU32(p) __swab32(*((u32*)(p)))
#define PUTU32(ct, st) *((u32*)(ct)) = __swab32((st))
#else /* __GNUC__ */
#include
#define GETU32(p) ntohl(*((u32*)(p)))
#define PUTU32(ct, st) *((u32*)(ct)) = htonl((st))
#endif /* __GNUC__ */
#endif /* BIG_ENDIAN */
#endif /*_MSC_VER */
#if 0
#define GETU32(pt) (((u32)(pt)[0] << 24) ^ ((u32)(pt)[1] << 16) ^ ((u32)(pt)[2]
<< 8) ^ ((u32)(pt)[3]))
#define PUTU32(ct, st) \
{ \
(ct)[0] = (u8)((st) >> 24); \
(ct)[1] = (u8)((st) >> 16); \
(ct)[2] = (u8)((st) >> 8); \
(ct)[3] = (u8)(st); \
}
#endif
A few other places too ...
[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695 --- Comment #4 from Martin Liška --- (In reply to Andrew Pinski from comment #2) > Also does adding -fno-strict-aliasing help? Yes, it helps.
[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695 --- Comment #3 from Martin Liška --- (In reply to Andrew Pinski from comment #1) > We need a better testcase than the direction on how to build a full package. Sure, I'll try to reduce it.
[Bug tree-optimization/108710] New: Recognizing "rounding down to the nearest power of two"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108710
Bug ID: 108710
Summary: Recognizing "rounding down to the nearest power of
two"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
In the code
#include
#include
#include
uint64_t foo (uint64_t x)
{
x = x | (x >> 1);
x = x | (x >> 2);
x = x | (x >> 4);
x = x | (x >> 8);
x = x | (x >> 16);
x = x | (x >> 32);
return x - (x >> 1);
}
uint64_t bar (uint64_t x)
{
if (x == 0)
return 0;
else
return 1ul << (63 - __builtin_clzl(x));
}
void tst (uint64_t a)
{
uint64_t r_foo, r_bar;
r_foo = foo(a);
r_bar = bar(a);
printf ("%20lu %20lu %20lu\n", a, r_foo, r_bar);
if (r_foo != r_bar)
abort();
}
int main()
{
tst(0ul);
for (uint64_t i = 1; i<64; i++) {
for (uint64_t j = 0; j
[Bug testsuite/108709] FAIL: gcc.dg/analyzer/pipe-glibc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108709 --- Comment #1 from nightstrike --- Perhaps these are separate bugs, but: 1) gcc.dg/analyzer/pipe-manpages.c will need similar improvements 2) gcc.dg/analyzer/pipe-void-return.c passes with an incorrect declaration for pipe(), implying that we won't test whether it captures using uninitialized file descriptors when _pipe() fails
[Bug analyzer/108709] New: FAIL: gcc.dg/analyzer/pipe-glibc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108709
Bug ID: 108709
Summary: FAIL: gcc.dg/analyzer/pipe-glibc.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
This test fails on Windows for lack of fork. It actually fails for not having
pipe(), also, but _pipe() does the job well enough, so that fix is a simple
#define. It is not very apparent what the test is doing, since it doesn't get
executed and doesn't appear to have analyzer calls, but the following poor
man's solution does result in a test that executes correctly on
x86_64-redhat-linux (EL8) and x86_64-w64-mingw32 under Wine.
git diff ../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
diff --git a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
index a8546ea9549..3b93212f56d 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
@@ -30,6 +30,30 @@ write_to_pipe (int file)
fclose (stream);
}
+#ifdef WIN32
+// Use native _pipe with a thread on windows, as forks don't exist
+// This requires that the pipes remain open, so disable close()
+
+#include
+#include
+#define pipe(FD) _pipe(FD, 256, O_BINARY)
+#define close(X)
+
+#include
+#include
+static __cdecl void
+fake_fork (void * arg)
+{
+int * mypipe = arg;
+read_from_pipe (mypipe[0]);
+}
+
+#define fork() _beginthread(fake_fork, 0, mypipe)
+#define wait(X) WaitForSingleObject((void *)pid, INFINITE)
+#else
+#include
+#endif
+
int
main (void)
{
@@ -66,6 +90,7 @@ main (void)
Close other end first. */
close (mypipe[0]);
write_to_pipe (mypipe[1]);
+ wait(NULL);
return EXIT_SUCCESS;
}
}
[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705 --- Comment #1 from Rimvydas (RJ) --- Using assumed shape arrays "p(:),s(:)" in bar() requires longer chain of calls to foo() and all time spent moves to "tree VRP", but produced assembly is more cluttered than with assumed size array declarations. Original code trips on both variants in different ltrans partitions during LTO link.
[Bug analyzer/108708] New: __analyzer_dump_named_constant fails with derived values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108708 Bug ID: 108708 Summary: __analyzer_dump_named_constant fails with derived values Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- The analyzer test fd-access-mode-target-headers.c fails on mingw-w64 due to the following: FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 55) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 56) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for excess errors) Excess errors: gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:55:3: warning: named constant 'O_ACCMODE' has unknown value gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:56:3: warning: named constant 'O_RDONLY' has unknown value gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:57:3: warning: named constant 'O_WRONLY' has unknown value This fails, because on mingw-w64, we define these macros indirectly: #define _O_RDONLY 0x #define _O_WRONLY 0x0001 #define _O_RDWR 0x0002 #define _O_ACCMODE (_O_RDONLY|_O_WRONLY|_O_RDWR) ... #define O_RDONLY _O_RDONLY #define O_WRONLY _O_WRONLY #define O_ACCMODE _O_ACCMODE If I modify the test to do "#undef O_ACCMODE; #define O_ACCMODE 42", it works as expected (and the other tests in the testsuite that test this also pass). I didn't flag this as a testsuite issue, though, because it seems that the issue is within the ability of __analyzer_dump_named_constant() to handle a macro value that references another macro or is some other valid expression. I also don't think it's specific to Windows. Perhaps related is that these tests also fail: FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 19) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 27) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 39) I assume this is related to the analyzer not being able to deduce the permissions passed to open().
[Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707
Hongtao.liu changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
--- Comment #1 from Hongtao.liu ---
It's related to memory_move_cost, in RA
1466 /* If this insn loads a parameter from its stack slot, then it
1467 represents a savings, rather than a cost, if the parameter is
1468 stored in memory. Record this fact.
1469
1470 Similarly if we're loading other constants from memory (constant
1471 pool, TOC references, small data areas, etc) and this is the only
1472 assignment to the destination pseudo.
1473
1474 Don't do this if SET_SRC (set) isn't a general operand, if it is
1475 a memory requiring special instructions to load it, decreasing
1476 mem_cost might result in it being loaded using the specialized
1477 instruction into a register, then stored into stack and loaded
1478 again from the stack. See PR52208.
1479
1480 Don't do this if SET_SRC (set) has side effect. See PR56124. */
1481 if (set != 0 && REG_P (SET_DEST (set)) && MEM_P (SET_SRC (set))
1482 && (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
1483 && ((MEM_P (XEXP (note, 0))
1484 && !side_effects_p (SET_SRC (set)))
1485 || (CONSTANT_P (XEXP (note, 0))
1486 && targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
1487XEXP (note, 0))
1488 && REG_N_SETS (REGNO (SET_DEST (set))) == 1))
1489 && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set)))
1490 /* LRA does not use equiv with a symbol for PIC code. */
1491 && (! ira_use_lra_p || ! pic_offset_table_rtx
1492 || ! contains_symbol_ref_p (XEXP (note, 0
1493{
1494 enum reg_class cl = GENERAL_REGS;
1495 rtx reg = SET_DEST (set);
1496 int num = COST_INDEX (REGNO (reg));
1497
1498 COSTS (costs, num)->mem_cost
1499-= ira_memory_move_cost[GET_MODE (reg)][cl][1] * frequency;
1500 record_address_regs (GET_MODE (SET_SRC (set)),
1501 MEM_ADDR_SPACE (SET_SRC (set)),
1502 XEXP (SET_SRC (set), 0), 0, MEM, SCRATCH,
1503 frequency * 2);
1504 counted_mem = true;
we use GENERAL_REGS for E_V16SFmode move cost which should be inaccurate, i
think when preferred regclass is unknown, we'd better use NO_REGS.
588/* Costs for NO_REGS are used in cost calculation on the
589 1st pass when the preferred register classes are not
590 known yet. In this case we take the best scenario. */
[Bug rtl-optimization/108707] New: suboptimal allocation with same memory op for many different instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707
Bug ID: 108707
Summary: suboptimal allocation with same memory op for many
different instructions.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
#include
void
foo (__m512* pv, float* __restrict ps, int n, __m512* pdest,
__m512* p1, __m512* p2, __m512* p3)
{
__m512 a = _mm512_setzero_ps ();
__m512 b = a;
__m512 c = a;
for (int i = 0; i != n ;i++)
{
a = _mm512_fmadd_ps (p1[i], pv[i], a);
b = _mm512_fmadd_ps (p2[i], pv[i], b);
c = _mm512_fmadd_ps (p3[i], pv[i], c);
}
pdest[0] = a;
pdest[1] = b;
pdest[2] = c;
}
g++ -O2 -mavx512f -S
got
.L3:
vmovaps (%r8,%rax), %zmm3
vmovaps (%r9,%rax), %zmm4
vmovaps (%rsi,%rax), %zmm5
vfmadd231ps (%rdi,%rax), %zmm3, %zmm2
vfmadd231ps (%rdi,%rax), %zmm4, %zmm1
vfmadd231ps (%rdi,%rax), %zmm5, %zmm0
addq$64, %rax
cmpq%rax, %rdx
jne .L3
It would be better to load (%rdi, %rax) into a zmm then
.L3:
vmovaps (%rdi,%rax), %zmm0
vfmadd231ps (%r8,%rax), %zmm0, %zmm3
vfmadd231ps (%r9,%rax), %zmm0, %zmm2
vfmadd231ps (%rsi,%rax), %zmm0, %zmm1
addq$64, %rax
cmpq%rax, %rdx
jne .L3
[Bug c++/108706] New: [13 Regression] Indefinite recursion when compiling gcc/testsuite/g++.dg/cpp23/static-operator-call5.C w/ -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108706 Bug ID: 108706 Summary: [13 Regression] Indefinite recursion when compiling gcc/testsuite/g++.dg/cpp23/static-operator-call5.C w/ -g Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc 13.0.1 20230205 snapshot (g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef) ICEs when compiling gcc/testsuite/g++.dg/cpp23/static-operator-call5.C w/ -std=c++23 -g: % g++-13 -std=c++23 -g -c gcc/testsuite/g++.dg/cpp23/static-operator-call5.C g++-13: internal compiler error: Segmentation fault signal terminated program cc1plus (gdb) where 20 #0 0x00caca07 in ggc_internal_alloc (size=size@entry=48, f=f@entry=0x0, s=s@entry=0, n=n@entry=1) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/ggc-page.cc:1278 #1 0x00ea2939 in ggc_internal_cleared_alloc (size=48, f=f@entry=0x0, s=s@entry=0, n=n@entry=1) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/ggc-common.cc:114 #2 0x014e210e in ggc_internal_cleared_alloc (s=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/ggc.h:149 #3 ggc_alloc_cleared_tree_node_stat (s=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/ggc.h:325 #4 make_node (code=code@entry=BASELINK) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree.cc:1218 #5 0x00ba1b6c in build_baselink (binfo=0x77961720, access_binfo=0x77961720, functions=0x7797a4c0, optype=0x0) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/search.cc:1082 #6 0x00ba2f99 in lookup_member (xbasetype=, name=, protect=protect@entry=0, want_type=want_type@entry=false, complain=complain@entry=3, afi=afi@entry=0x0) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/search.cc:1224 #7 0x00a671a2 in lambda_function (lambda=lambda@entry=0x7797c690) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/lambda.cc:179 #8 0x00a75974 in write_closure_type_name (type=0x7797c690) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1804 #9 write_unqualified_name (decl=0x77976688) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1511 #10 0x00a76c9d in write_local_name (entity=, local_entity=, function=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:2175 #11 write_name (decl=0x77976688, ignore_local_scope=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1057 #12 0x00a77213 in write_class_enum_type (type=0x7797c690) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree.h:3654 #13 write_type (type=0x7797c690) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:2337 #14 0x00a7747e in write_type (type=0x7797cb28) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:2413 #15 0x00a7911f in write_method_parms (parm_types=0x7797e168, method_p=, decl=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:2897 #16 0x00a75a78 in write_closure_type_name (type=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1819 #17 write_unqualified_name (decl=0x77976688) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1511 #18 0x00a76c9d in write_local_name (entity=, local_entity=, function=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:2175 #19 write_name (decl=0x77976688, ignore_local_scope=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1057 (More stack frames follow...) (gdb) where -20 #1082279 0x00a7911f in write_method_parms (parm_types=0x7797e168, method_p=, decl=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:2897 #1082280 0x00a75a78 in write_closure_type_name (type=) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1819 #1082281 write_unqualified_name (decl=0x77976688) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cp/mangle.cc:1511 #1082282 0x00a7f1cd in write_prefix (node=0x7797c690) at /var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-
[Bug testsuite/107602] dump-noaddr testcases fail when running the testsuite with already built installed toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107602 --- Comment #2 from nightstrike --- Better link(In reply to nightstrike from comment #1) > Reverting 186d43a78e945ebe9fbe217fc341847af7f95d30 fixes this problem at > least for me Better link: r255433
[Bug testsuite/107602] dump-noaddr testcases fail when running the testsuite with already built installed toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107602 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #1 from nightstrike --- Reverting 186d43a78e945ebe9fbe217fc341847af7f95d30 fixes this problem at least for me
[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog Target Milestone|--- |13.0 Summary|Unexpected CPU time usage |[13 Regression] Unexpected |with LTO in ranger |CPU time usage with LTO in |propagation |ranger propagation
[Bug tree-optimization/108705] New: Unexpected CPU time usage with LTO in ranger propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
Bug ID: 108705
Summary: Unexpected CPU time usage with LTO in ranger
propagation
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Very trivialized reduced testcase that still works with
--enable-checking=release configured trunk.
$ cat hog.f90 # foo() and bar() are in separate units in original case
subroutine bar(n,m,p,s) ! in bar.f90
implicit none
integer :: n,m
real,intent(inout) :: p(n),s(*)
!real,intent(inout) :: p(:),s(:) ! gives slower growth
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
! ...
!call foo(n,m,p,s)
end subroutine bar
subroutine foo(n,m,p,b) ! in foo.f90
implicit none
integer :: n,m,j
real,intent(inout) :: p(n),b(*)
do j=1,n
b(m+j-1)=p(j)
enddo
m=m+n ! < problematic part
end subroutine foo
$ gfortran -Wall -Wextra -O2 -flto -c hog.f90 # mimic ccBemfcW.ltrans23.o
$ lto1 -ftime-report -fchecking=0 hog.o # -fltrans /tmp/ccBemfcW.ltrans23.o
Reading object files: hog.o {GC 2518k} {heap 1028k}
Reading the symbol table:
Merging declarations: {GC 2520k} {heap 1028k}
Reading summaries: {GC 2520k} {heap 1028k} {GC 2520k}
{heap 1028k} {GC 2520k} {heap 1028k} {GC 2530k} {heap
1168k} {GC 2530k} {heap 1168k} {GC 2532k} {heap 1168k}
{GC 2532k}
Merging symbols: {heap 1168k}Reading function bodies:
Performing interprocedural optimizations
{heap 1168k} {heap 1168k} {heap
1168k} {heap 1360k} {heap 1360k} {heap 1360k} {heap
1360k} {heap 1360k} {heap 1360k} {heap 1360k}
{heap 1360k} {heap 1360k} {heap 1360k}
{heap 1360k} {heap 1360k}Assembling functions:
{heap 1360k} foo in:foo_ bar in:bar_
Time variable usr sys wall
GGC
phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%)
2583k ( 67%)
phase opt and generate :1490.95 (100%) 0.00 ( 0%)1491.02 (100%)
1230k ( 32%)
callgraph functions expansion :1490.95 (100%) 0.00 ( 0%)1491.02 (100%)
1201k ( 31%)
tree VRP : 5.08 ( 0%) 0.00 ( 0%) 5.07 ( 0%)
84k ( 2%)
dominator optimization :1485.85 (100%) 0.00 ( 0%)1485.92 (100%)
16k ( 0%)
tree canonical iv : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%)
71k ( 2%)
tree loop distribution : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%)
115k ( 3%)
dead store elim1 : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%)
2304 ( 0%)
combiner : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%)
42k ( 1%)
initialize rtl : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%)
12k ( 0%)
TOTAL :1490.95 0.00 1491.02
3846k
For 10+ calls adding extra new call adds to total time: 0.21, 1.07, 6.29,
38.74, 238.24, 1490.95, 9424.12, ... seconds of CPU time.
This is not a problem for non-LTO builds since objects need to be compiled only
once for all executables in the project. However with LTO it means that for
any executable having problematic subroutines in call graph *and* having such
unit pairs in the same ltrans partition would need to be compiled from scratch
over and over. In original case final LTO link of a first executable with
-flto=20 was still compiling last 3 ltrans partitions after 25h+ (gcc-12 is
fine).
It is quite hard to say where lto1 gets "stuck" (as in infinite loop, no new
output gets added to assembly outputs either). One has to ps(1) the full
command line, grab /tmp/ccBemfcW.ltrans23.o and manually invoke lto1 to see
where problematic code units could be. Also there are no support for
attributes to deal with such problems e.g.:
!GCC$ ATTRIBUTES noclone,noinline :: foo
while LTO is getting better at detecting "strategically placed debug write()
statements".
[Bug analyzer/108704] [13 Regression] Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704 --- Comment #2 from David Malcolm --- Adding -fno-analyzer-state-purge fixes the false positive, looks like it's erroneously pruning the value of fp0 immediately after the first assignment.
[Bug analyzer/108704] [13 Regression] Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704 David Malcolm changed: What|Removed |Added Target Milestone|--- |13.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-02-07 Summary|Many|[13 Regression] Many |-Wanalyzer-use-of-uninitial |-Wanalyzer-use-of-uninitial |ized-value false positives |ized-value false positives |seen in qemu's softfloat.c |seen in qemu's softfloat.c Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Doesn't seem to affect gcc 12.2 so marking as a regression.
[Bug analyzer/108704] New: Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704 Bug ID: 108704 Summary: Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 54425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54425&action=edit Reduced reproducer Trunk shows many (dozens?) of -Wanalyzer-use-of-uninitialized-value false positives on qemu's softfloat.c https://godbolt.org/z/MTe9597Eh shows: : In function 'test': :27:9: warning: use of uninitialized value 'fp0' [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 27 | fp0 = floatx80_add(fp0, float32_to_floatx80((0x3F80))); | ^~~~ 'test': events 1-3 | | 24 | floatx80 fp0; | |^~~ | || | |(1) region created on stack here | |(2) capacity: 16 bytes |.. | 27 | fp0 = floatx80_add(fp0, float32_to_floatx80((0x3F80))); | | | | | | | (3) use of uninitialized value 'fp0' here | Compiler returned: 0 where fp0 appears to have been initialized on the line above.
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #145 from lucier at math dot purdue.edu --- Created attachment 54424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54424&action=edit CPU and Memory usage reports for mainline 13.0.1 (mainline) Thank you for looking at this issue again. I built today's mainline and ran three tests: /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report compiler.i -save-temps >& report-compiler4 /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report all.i -save-temps >& report-all4 /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report _num.i -save-temps >& report-_num4 The reports are collected here. Compiling compiler.i required over 30GB at certain points. I haven't really studied these types of reports in a while, so I can offer little analysis.
[Bug c/108694] need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694 --- Comment #4 from Bruno Haible --- (In reply to Aaron Ballman from comment #3) OK. So, except for this unlucky (*) choice of attribution in case of a conflict between function declaration and function definition, the '-Wdeprecated-non-prototype' warning is actually usable. What we need is thus: * -Wdeprecated-non-prototype, * combined with a kind of -Wfuture-incompatible-function-pointer-types, that considers the interpretation according to C23 instead of the interpretation according to the currently chosen standard. (*) Reported as a clang bug at https://github.com/llvm/llvm-project/issues/60592 .
[Bug analyzer/108661] [13 Regression] -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug fortran/69636] ICE(s) on using option -fmodule-private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- The ICE for the reduced testcase in comment#2 is fixed by: diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc index 68f481473b4..97ff1d640d7 100644 --- a/gcc/fortran/intrinsic.cc +++ b/gcc/fortran/intrinsic.cc @@ -5419,7 +5419,9 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec *ts) gcc_assert (expr->ts.type == BT_CHARACTER && ts->type == BT_CHARACTER); sym = find_char_conv (&expr->ts, ts); - gcc_assert (sym); + if (sym == NULL) +return false; +// gcc_assert (sym); /* Insert a pre-resolved function call to the right function. */ old_where = expr->where;
[Bug analyzer/108661] [13 Regression] -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:c300e251f5b22d15b126f3c643cd55a119994e48 commit r13-5733-gc300e251f5b22d15b126f3c643cd55a119994e48 Author: David Malcolm Date: Tue Feb 7 16:10:20 2023 -0500 analyzer: fix -Wanalyzer-use-of-uninitialized-value false +ve on "read" [PR108661] My integration testing shows many false positives from -Wanalyzer-use-of-uninitialized-value. One cause turns out to be that as of r13-1404-g97baacba963c06 fd_state_machine::on_stmt recognizes calls to "read", and returns true, so that region_model::on_call_post doesn't call handle_unrecognized_call on them, and so the analyzer erroneously "thinks" that the buffer pointed to by "read" is never touched by the "read" call. This works for "fread" because sm-file.cc implements kf_fread, which handles calls to "fread" by clobbering the buffer pointed to. In the long term we should probably be smarter about this and bifurcate the analysis to consider e.g. errors vs full reads vs partial reads, etc (which I'm tracking in PR analyzer/108689). In the meantime, this patch adds a kf_read for "read" analogous to the one for "fread", fixing 6 false positives seen in git-2.39.0 and 2 in haproxy-2.7.1. gcc/analyzer/ChangeLog: PR analyzer/108661 * sm-fd.cc (class kf_read): New. (register_known_fd_functions): Register "read". * sm-file.cc (class kf_fread): Update comment. gcc/testsuite/ChangeLog: PR analyzer/108661 * gcc.dg/analyzer/fread-pr108661.c: New test. * gcc.dg/analyzer/read-pr108661.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/108689] RFE: more precise handling of "fread"-style functions in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108689 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:c300e251f5b22d15b126f3c643cd55a119994e48 commit r13-5733-gc300e251f5b22d15b126f3c643cd55a119994e48 Author: David Malcolm Date: Tue Feb 7 16:10:20 2023 -0500 analyzer: fix -Wanalyzer-use-of-uninitialized-value false +ve on "read" [PR108661] My integration testing shows many false positives from -Wanalyzer-use-of-uninitialized-value. One cause turns out to be that as of r13-1404-g97baacba963c06 fd_state_machine::on_stmt recognizes calls to "read", and returns true, so that region_model::on_call_post doesn't call handle_unrecognized_call on them, and so the analyzer erroneously "thinks" that the buffer pointed to by "read" is never touched by the "read" call. This works for "fread" because sm-file.cc implements kf_fread, which handles calls to "fread" by clobbering the buffer pointed to. In the long term we should probably be smarter about this and bifurcate the analysis to consider e.g. errors vs full reads vs partial reads, etc (which I'm tracking in PR analyzer/108689). In the meantime, this patch adds a kf_read for "read" analogous to the one for "fread", fixing 6 false positives seen in git-2.39.0 and 2 in haproxy-2.7.1. gcc/analyzer/ChangeLog: PR analyzer/108661 * sm-fd.cc (class kf_read): New. (register_known_fd_functions): Register "read". * sm-file.cc (class kf_fread): Update comment. gcc/testsuite/ChangeLog: PR analyzer/108661 * gcc.dg/analyzer/fread-pr108661.c: New test. * gcc.dg/analyzer/read-pr108661.c: New test. Signed-off-by: David Malcolm
[Bug c++/107079] [10/11/12/13 Regression] ICE initializing lifetime-extended constexpr variable that stores its this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079
--- Comment #4 from Marek Polacek ---
The ICE could be fixed with
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13604,9 +13604,13 @@ set_up_extended_ref_temp (tree decl, tree expr,
vec **cleanups,
init = NULL_TREE;
}
else
-/* Create the INIT_EXPR that will initialize the temporary
- variable. */
-init = split_nonconstant_init (var, expr);
+{
+ /* Create the INIT_EXPR that will initialize the temporary
+variable. */
+ init = split_nonconstant_init (var, expr);
+ replace_placeholders (init, var);
+}
+
if (at_function_scope_p ())
{
add_decl_expr (var);
but it'll result in
error: modification of ‘’ is not a constant expression
because the INIT_EXPR is
_ZGR1x_.x = (const struct X *) &_ZGR1x_
but _ZGR1x_ isn't in our constexpr context.
[Bug c/108694] need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694 --- Comment #3 from Aaron Ballman --- (In reply to Bruno Haible from comment #2) > But '-Wdeprecated-non-prototype' does not exactly have the behaviour you > want: while it warns for 'func1 (1);' and 'func3 (3);' (good!), it warns > also for 'void func3 ();', that is, where you don't want to see a warning. FWIW, the reason you get a warning on the declaration of `func3` in Clang is because of the definition of `func3` that is invalid in C2x but was valid in prior standards modes. If you do not provide a problematic conflicting definition, the diagnostic is silenced: https://godbolt.org/z/aMPrvWz1j
[Bug c/108694] need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
--- Comment #2 from Bruno Haible ---
(In reply to Florian Weimer from comment #1)
> “()” is going to be fine when matched with an empty parameter list in a
> definition, or an empty argument list in a call. I don't think it's
> necessary to warn in those cases. It distracts from the real issue.
OK. So let's see what we get with this approach where 'void func3 ();' doesn't
warn and only the wrong uses of func3 produce diagnostics. Here's a test case,
annotated with 'error' in those places where 'clang15 -std=c2x' produces an
error:
=
/* Function definitions: */
void func1 () {}
void func2 (void) {}
/* Function declarations: */
void func3 ();
void func4 (void);
void code ()
{
void (*fp) (void);
void (*fp1) (int);
fp = func1;
fp = func2;
fp = func3;
fp = func4;
fp1 = func3;
func1 (1); /* error */
func2 (2); /* error */
func3 (3); /* error */
func4 (4); /* error */
(void) fp;
(void) fp1;
}
void func3 (int x, int y) {} /* error */
=
When compiling this in -std=c17 or older mode, we would like to get a warning
- in those places where we get an error in C23 mode, and
- in those places where there are unsafe conversions or parameter passing going
on in C23 or in C17 or older.
In detail, the desired behaviour in -std=c17 or older mode is:
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* No warning */
void func4 (void); /* No warning */
void code ()
{
void (*fp) (void);
void (*fp1) (int);
fp = func1; /* No warning */
fp = func2; /* No warning */
fp = func3; /* No warning */
fp = func4; /* No warning */
fp1 = func3; /* warning */
func1 (1); /* warning (if -std=c17) or error (if -std=c23) */
func2 (2); /* error */
func3 (3); /* warning (if -std=c17) or error (if -std=c23) */
func4 (4); /* error */
(void) fp;
(void) fp1;
}
void func3 (int x, int y) {} /* warning (if -std=c17) or error (if -std=c23) */
=
In the line 'fp1 = func3;' a warning should be shown because it's an unsafe
function pointer conversion in C23. (Even though in C17 it is not dangerous
code and even though in C23 it's not an error!) 'clang15 -std=c2x
-Wincompatible-function-pointer-types' does show a "warning: incompatible
function pointer types" there.
> Clang now has -Wdeprecated-non-prototype apparently
But '-Wdeprecated-non-prototype' does not exactly have the behaviour you want:
while it warns for 'func1 (1);' and 'func3 (3);' (good!), it warns also for
'void func3 ();', that is, where you don't want to see a warning.
So, no existing GCC or clang warning option has the desired behaviour. What we
need (and even independently of programming style) is
* a part of -Wdeprecated-non-prototype: do warn in function call positions,
don't warn in function declaration/type positions,
* combined with a kind of -Wfuture-incompatible-function-pointer-types, that
considers the interpretation according to C23 instead of the interpretation
according to the currently chosen standard.
[Bug fortran/108693] Update shared character array inside OpenMP critical section causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108693 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Ever confirmed|0 |1 Last reconfirmed||2023-02-07 --- Comment #1 from anlauf at gcc dot gnu.org --- The code has a simple bug, as it violates array bounds as threads are counted starting from 0, not 1. This is fixed by replacing thread_id = OMP_GET_THREAD_NUM() by thread_id = OMP_GET_THREAD_NUM() + 1 The ICE seems to occur only for deferred character length variables. A small modification to use an array of character(len=1) seems to work.
[Bug tree-optimization/108582] [12 Regression] ICE on valid code at -Os and above with "-fno-tree-ccp -fno-tree-dce": tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Andrew Pinski --- Fixed.
[Bug tree-optimization/108582] [12 Regression] ICE on valid code at -Os and above with "-fno-tree-ccp -fno-tree-dce": tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:6f23c9077feebb29c2a28ffe89b287286df27d6d commit r12-9114-g6f23c9077feebb29c2a28ffe89b287286df27d6d Author: Andrew Pinski Date: Sat Jan 28 18:27:08 2023 + Fix PR 108582: ICE due to PHI-OPT removing a still in use ssa_name. This patch adds a check in match_simplify_replacement to make sure the middlebb does not have any phi-nodes as we don't currently move those. This was just a thinko from before. Committed on the GCC 12 branch after a bootstrap/test on x86_64-linux-gnu. PR tree-optimization/108582 gcc/ChangeLog: * tree-ssa-phiopt.cc (match_simplify_replacement): Add check for middlebb to have no phi nodes. gcc/testsuite/ChangeLog: * gcc.dg/pr108582-1.c: New test. (cherry picked from commit 876b3e0514bc8cb2256c44db56255403bedfa52d)
[Bug tree-optimization/108522] [12 Regression] ICE in tree-object-size when struct has VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108522 Siddhesh Poyarekar changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Siddhesh Poyarekar --- Fixed on master as well as gcc-12 now.
[Bug tree-optimization/108684] [12/13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684 --- Comment #10 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #9) > I think that is how inline asm always behaved. If it is not ok to be DCEd > when the result is dead, one needs to use volatile keyword. Oh you are right I always forgot that (yes I double checked the manual this time around), anyways I am going to test (the other) Andrew's patch and will submit it.
[Bug tree-optimization/108522] [12 Regression] ICE in tree-object-size when struct has VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108522 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:45b346664c0af57053e77276cd030015eb21f851 commit r12-9113-g45b346664c0af57053e77276cd030015eb21f851 Author: Siddhesh Poyarekar Date: Thu Jan 26 07:07:03 2023 -0500 tree-optimization/108522 Use component_ref_field_offset Instead of using TREE_OPERAND (expr, 2) directly, use component_ref_field_offset instead, which does scaling for us. The function also substitutes PLACEHOLDER_EXPRs but it is not relevant for tree-object-size. gcc/ChangeLog: PR tree-optimization/108522 * tree-object-size.cc (compute_object_offset): Make EXPR argument non-const. Call component_ref_field_offset. gcc/testsuite/ChangeLog: PR tree-optimization/108522 * gcc.dg/builtin-dynamic-object-size-0.c (DEFSTRUCT): New macro. (test_dynarray_struct_member_b, test_dynarray_struct_member_c, test_dynarray_struct_member_d, test_dynarray_struct_member_subobj_b, test_dynarray_struct_member_subobj_c, test_dynarray_struct_member_subobj_d): New tests. (main): Call them. Signed-off-by: Siddhesh Poyarekar (cherry picked from commit 0573a0778af88e805f7630ac8640ecd67d692665)
[Bug tree-optimization/108522] [12 Regression] ICE in tree-object-size when struct has VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108522 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:4526562a305b3bfc18485a2aa017500aa22aa14b commit r12-9112-g4526562a305b3bfc18485a2aa017500aa22aa14b Author: Siddhesh Poyarekar Date: Tue Jan 24 19:47:05 2023 -0500 tree-optimization/108522 Use COMPONENT_REF offset when available Use the offset in TREE_OPERAND(component_ref, 2) when available instead of DECL_FIELD_OFFSET when trying to compute offset for a COMPONENT_REF. Co-authored-by: Jakub Jelinek gcc/ChangeLog: PR tree-optimization/108522 * tree-object-size.cc (compute_object_offset): Use TREE_OPERAND(ref, 2) for COMPONENT_REF when available. gcc/testsuite/ChangeLog: PR tree-optimization/108522 * gcc.dg/builtin-dynamic-object-size-0.c (test_dynarray_struct_member): New test. (main): Call it. Signed-off-by: Siddhesh Poyarekar (cherry picked from commit b851ee9fdf0f3023635f0cb1f7c607b2d6801053)
[Bug tree-optimization/108684] [12/13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #8)
> I think simple_dce_from_worklist is incorrect of removing this inline-asm in
> the first place.
> Take:
> ```
> static int t;
>
> int f (int *a)
> {
> int t1;
> asm (" " : "=r" (t1) : : "memory");
> t = t1;
> return *a;
> }
> ```
> The inline-asm could have written to *a but now it has been removed.
I think that is how inline asm always behaved. If it is not ok to be DCEd when
the result is dead, one needs to use volatile keyword.
[Bug tree-optimization/108684] [12/13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Keywords||wrong-code
--- Comment #8 from Andrew Pinski ---
I think simple_dce_from_worklist is incorrect of removing this inline-asm in
the first place.
Take:
```
static int t;
int f (int *a)
{
int t1;
asm (" " : "=r" (t1) : : "memory");
t = t1;
return *a;
}
```
The inline-asm could have written to *a but now it has been removed.
Let me look into fixing that.
Note my patch (r12-4598-g113860301f46d14a255bd) exposed this even before VRP
exposed this so I feel like I should fix this.
[Bug tree-optimization/108697] constructing a path-range-query is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697 --- Comment #5 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > But yes, your observation about m_has_cache_entry is correct - if that has > any value (it makes reset_path "cheap"), then it should be also relied on > upon > growth. Maybe make this bitmap an optional feature of the cache itself > and handle it transparently there? BTW, if putting the bitmap in the ssa_global_cache itself works, that's fine as well, especially if it makes the ranger's cache faster :).
[Bug c++/108698] [13 Regression] decltype ((T() + ‘excess_precision_expr’ not supported by dump_expr)) median(ndarray) [with T = double]’: since r13-3290-g98e341130f87984a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698 --- Comment #3 from Jakub Jelinek --- I mean in mangling...
[Bug c++/108698] [13 Regression] decltype ((T() + ‘excess_precision_expr’ not supported by dump_expr)) median(ndarray) [with T = double]’: since r13-3290-g98e341130f87984a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698 --- Comment #2 from Jakub Jelinek --- Created attachment 54423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54423&action=edit gcc13-pr108698.patch Actually, if it is just EXCESS_PRECISION_EXPR around REAL_CST, that one can be handled easily compatibly with what it used to do before. I haven't been able to get EXCESS_PRECISION_EXPR with other operands so far.
[Bug fortran/103259] [11/12/13 Regression] ICE in resolve_common_vars, at fortran/resolve.c:956 since r11-3866-g4d2a56a0f7135469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103259 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 #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-February/058893.html
[Bug target/108703] New: ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: movhi_insn) on sparc64 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703
Bug ID: 108703
Summary: ICE: in extract_constrain_insn, at recog.cc:2692 (insn
does not satisfy its constraints: movhi_insn) on
sparc64 at -O1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: sparc64-unknown-linux-gnu
Created attachment 54422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54422&action=edit
reduced testcase
Compiler output:
$ sparc64-unknown-linux-gnu-gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: error: insn does not satisfy its constraints:
9 | }
| ^
(insn 10 15 11 2 (set (reg:HI 33 %f1)
(reg:HI 35 %f3)) "testcase.c":8:3 114 {*movhi_insn}
(expr_list:REG_EQUAL (const_int 13107 [0x])
(nil)))
during RTL pass: reload
testcase.c:9:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x6cb2b9 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x6cb33f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x6b8611 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0xd3b414 check_rtl
/repo/gcc-trunk/gcc/lra.cc:2126
0xd40516 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.cc:2544
0xcf1179 do_reload
/repo/gcc-trunk/gcc/ira.cc:5941
0xcf1179 execute
/repo/gcc-trunk/gcc/ira.cc:6127
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/108690] -Wstrict-prototypes too picky for C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108690 --- Comment #2 from Sam James --- Please add https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694 to See Also.
[Bug tree-optimization/108684] [12/13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Macleod from comment #6) > Fixes the issue... huh how long has THAT been there Since r8-5124-g23ffbafe3a39 when simple_dce_from_worklist was added. Though simple_dce_from_worklist only started to much more usage in GCC 12 (starting with r12-4598-g113860301f46d14a255bd).
[Bug tree-optimization/108684] [12/13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
--- Comment #6 from Andrew Macleod ---
diff --git a/gcc/tree-ssa-dce.cc b/gcc/tree-ssa-dce.cc
index b2fe9f4f55e..752785541e4 100644
--- a/gcc/tree-ssa-dce.cc
+++ b/gcc/tree-ssa-dce.cc
@@ -2140,6 +2140,7 @@ simple_dce_from_worklist (bitmap worklist)
remove_phi_node (&gsi, true);
else
{
+ unlink_stmt_vdef (t);
gsi_remove (&gsi, true);
release_defs (t);
}
Fixes the issue... huh how long has THAT been there
[Bug tree-optimization/108684] [12/13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
Andrew Pinski changed:
What|Removed |Added
Summary|[13 Regression] ICE:|[12/13 Regression] ICE:
|verify_ssa failed |verify_ssa failed
Target Milestone|13.0|12.3
Known to fail||12.1.0
--- Comment #5 from Andrew Pinski ---
New testcase which shows this is indepdent of VRP, fails in GCC 12.x also:
```
static int t;
int f (int a)
{
int t1;
asm (" " : "=r" (t1) : : "eax", "memory");
t = t1;
if (a)
return 0;
__builtin_unreachable();
}
```
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 --- Comment #11 from apjo at tuta dot io --- (In reply to Andrew Pinski from comment #10) Okay now that looks like a clang bug. Clang is supposed to diagnose misleading indentation like that (see: https://godbolt.org/z/1fv4rEseo).
[Bug ipa/108702] New: [13 Regression] ICE in get_partitioning_class, at symtab.cc:2096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108702
Bug ID: 108702
Summary: [13 Regression] ICE in get_partitioning_class, at
symtab.cc:2096
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: lto
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcc 13.0.1 20230205 snapshot (g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef) ICEs
when compiling gcc/testsuite/g++.dg/ext/stmtexpr19.C w/ -flto:
% g++-13 -flto -c gcc/testsuite/g++.dg/ext/stmtexpr19.C
during IPA pass: modref
gcc/testsuite/g++.dg/ext/stmtexpr19.C:17:12: internal compiler error: in
get_partitioning_class, at symtab.cc:2096
17 | int main(){}
|^
0x79f533 symtab_node::get_partitioning_class()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/symtab.cc:2096
0x1061f27 lto_output_varpool_node
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/lto-cgraph.cc:631
0x1061f27 output_symtab()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/lto-cgraph.cc:999
0x1079c3b lto_output()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/lto-streamer-out.cc:2825
0x1107d61 write_lto
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/passes.cc:2777
0x1107d61 ipa_write_summaries_1
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/passes.cc:2841
0x1107d61 ipa_write_summaries()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/passes.cc:2897
0xd3c19e ipa_passes
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cgraphunit.cc:2249
0xd3c19e symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cgraphunit.cc:2322
0xd3ebc7 symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cgraphunit.cc:2302
0xd3ebc7 symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/cgraphunit.cc:2574
[Bug tree-optimization/108684] [13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684 --- Comment #4 from Andrew Pinski --- Hmm, simple_dce_from_worklist. It might be the case you could hit this issue without VRP then ... Let me try.
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701
--- Comment #10 from Andrew Pinski ---
That is clang does not warn about this case here (changed all tabs to spaces to
indepdent of -ftabstop option):
```
int randBytesGet()
{
int t;
while (true) {
if (true)
return 0;
#if 0
int random = rand();
#endif
t = 0;
}
return t;
}
```
GCC correctly warns about the `t = 0;` statement:
```
: In function 'int randBytesGet()':
:8:13: warning: this 'if' clause does not guard...
[-Wmisleading-indentation]
8 | if (true)
| ^~
:13:17: note: ...this statement, but the latter is misleadingly
indented as if it were guarded by the 'if'
13 | t = 0;
| ^
```
[Bug tree-optimization/108684] [13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
--- Comment #3 from Andrew Macleod ---
OK, its been a while. Why is there a VUSE on the return? this is the IL
right from into-ssa:
int f (int a)
{
int _4;
:
# .MEM_2 = VDEF <.MEM_1(D)>
__asm__(" " : "=X" a_3 : : "memory");
if (a_3 != 0)
goto ; [INV]
else
goto ; [INV]
:
_4 = 0;
// predicted unlikely by early return (on trees) predictor.
# VUSE <.MEM_2>
return _4;
:
__builtin_unreachable ();
}
The problem is that in VRP, we change a_3's global range to be ~[0,0], rewrite
the condition to remove the block with the builtin_unreachable... which there
leaves the IL something like:
[local count: 1073741824]:
# .MEM_2 = VDEF <.MEM_1(D)>
__asm__(" " : "=X" a_3 : : "memory");
[local count: 1073741824]:
# VUSE <.MEM_2>
return 0;
and since there are no more uses of a_3, the asm is considered dead and removed
by simple_dce_from_worklist.
BUt it does not adjust the vdefs at all.. so we when its deleted, we are still
eft with:
[local count: 1073741824]:
# VUSE <.MEM_2>
return 0;
but now there is no longer a definition of MEM_2 and verify_ssa fails.
I can fix it by not trying to dce any defs that have VDEFS on them... but that
doesnt seem like the correct long term solution... Why is there a VUSE on that
return anyway? to keep it from being hoisted above the asm?
Whats the correct thing to do here? Im surprised that somewhere in the stmt
deletion process, it doesnt rewrite all uses of MEM_2 to MEM_1 before deliting
it. Or is that a manual step?
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #9 from Andrew Pinski --- clang is not even warning for -Wmisleading-indentation so it is not doing it right or wrong there ...
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 apjo at tuta dot io changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #8 from apjo at tuta dot io --- Clang can do it right so GCC should be able to too.
[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107 --- Comment #11 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c36f3da534e7f411c5bc48c5b6b660e238167480 commit r13-5732-gc36f3da534e7f411c5bc48c5b6b660e238167480 Author: Harald Anlauf Date: Mon Feb 6 20:59:51 2023 +0100 Fortran: ASSOCIATE variables should not be TREE_STATIC [PR95107] gcc/fortran/ChangeLog: PR fortran/95107 * trans-decl.cc (gfc_finish_var_decl): With -fno-automatic, do not make ASSOCIATE variables TREE_STATIC. gcc/testsuite/ChangeLog: PR fortran/95107 * gfortran.dg/save_7.f90: New test.
[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #11 from Mikael Pettersson --- Bisected on x86_64-linux-gnu: dc477ffb4aba21e9cf47de22a4df6f2b23849505 is the first bad commit commit dc477ffb4aba21e9cf47de22a4df6f2b23849505 Author: Richard Biener Date: Thu Jul 21 10:13:46 2022 +0200 tree-optimization/106378 - DSE of LEN_STORE and MASK_STORE The following enhances DSE to handle LEN_STORE (optimally) and MASK_STORE (conservatively). PR tree-optimization/106378 * tree-ssa-dse.cc (initialize_ao_ref_for_dse): Handle LEN_STORE, add mode to initialize a may-def and handle MASK_STORE that way. (dse_optimize_stmt): Query may-defs. Handle internal functions LEN_STORE and MASK_STORE similar to how we handle memory builtins but without byte tracking.
[Bug c/108700] false _Noreturn error with -Werror=old-style-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700 --- Comment #3 from Andreas Schwab --- The grammar doesn't tell everything, though currently only storage-class specifiers are expected to occur at the beginning. >From c-parser.cc:c_parser_declspecs: /* TODO: Distinguish between function specifiers (inline, noreturn) and storage class specifiers, either here or in declspecs_add_scspec. */
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #7 from Andrew Pinski --- I don't know how clang is not warning. Maybe they don't take into account spaces vs tabs ...
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 apjo at tuta dot io changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #6 from apjo at tuta dot io --- Also, thanks Andrew for the prompt reply and solution. I had a couple follow up questions: - How is clang getting this right? I guess it defaults to 4 space tab (heretics!). - So is this 'basically not a bug'?
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 apjo at tuta dot io changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #5 from apjo at tuta dot io --- (In reply to Andrew Pinski from comment #2) > -ftabstop=4 fixes the warning. > Looks like godbolt is using 4 spaces/tab in their editor but GCC defaults to > 8 spaces per tab. > > I suspect you need to supply -ftabstop=4 to override GCC's defaults if you > are using 4space/tabs. Interesting. I only ever use \t tabs for indentations and 1 \t == 8 spaces on my editors, but Godbolt's default behavior is this weird thing I guess.
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 --- Comment #4 from Andrew Pinski --- Also once you change godbolt to be 8 spaces/tab, it becomes obvious the warning is correct for the default.
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- The documentation is clear too: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wmisleading-indentation In the case of mixed tabs and spaces, the warning uses the -ftabstop= option to determine if the statements line up (defaulting to 8).
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-02-07 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- -ftabstop=4 fixes the warning. Looks like godbolt is using 4 spaces/tab in their editor but GCC defaults to 8 spaces per tab. I suspect you need to supply -ftabstop=4 to override GCC's defaults if you are using 4space/tabs.
[Bug c/108701] Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 --- Comment #1 from Andrew Pinski --- Created attachment 54421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54421&action=edit testcase
[Bug c/108701] New: Incorrect -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108701 Bug ID: 108701 Summary: Incorrect -Wmisleading-indentation Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: apjo at tuta dot io Target Milestone: --- Godbolt link (GCC 12.2.0) demonstrating the occurance of the issue : https://godbolt.org/z/Gx4677oPj Godbolt link of Clang 15.0.0 with the same input & options not having the incorrect warning : https://godbolt.org/z/rWrnGnj7d This is self-explanatory and completely reproducible. Do let me know if there's any more assistance I can offer.
[Bug c++/108698] [13 Regression] decltype ((T() + ‘excess_precision_expr’ not supported by dump_expr)) median(ndarray) [with T = double]’: since r13-3290-g98e341130f87984a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698
--- Comment #1 from Jakub Jelinek ---
Simpler testcase:
template
decltype (T () * T () + 1.0) foo ()
{
return T () * T () + 1.0;
}
void
bar ()
{
foo ();
foo ();
foo ();
}
The question is if the excess precision should be visible in the mangling in
some way or not.
[Bug c/108694] need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694 Andrew Pinski changed: What|Removed |Added Target|x86_64-linux-gnu| Host|x86_64-linux-gnu| Build|x86_64-linux-gnu| Severity|normal |enhancement
[Bug c/108700] false _Noreturn error with -Werror=old-style-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700 --- Comment #2 from Vincent Lefèvre --- And there's the same issue with "inline" instead of "_Noreturn" (these are the only two function specifiers).
[Bug c/108700] false _Noreturn error with -Werror=old-style-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700 --- Comment #1 from Andrew Pinski --- This has been warning since _Noreturn support was added back in r177881 .
[Bug target/108316] [13 Regression] ICE in maybe_gen_insn via expand_SCATTER_STORE when vectorizing for SVE since r13-2737-g4a773bf2f08656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108316 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 CC||rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org --- Mine. We rely on pattern recognition to make the types match, but in this case an earlier pattern takes priority. Fixing that properly is stage 1 material, so I think we'll have to prevent the optimisation for GCC 13.
[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695 Andrew Pinski changed: What|Removed |Added Keywords||lto --- Comment #2 from Andrew Pinski --- Also does adding -fno-strict-aliasing help?
[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING Keywords||needs-reduction --- Comment #1 from Andrew Pinski --- We need a better testcase than the direction on how to build a full package.
[Bug c/108700] New: false _Noreturn error with -Werror=old-style-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700
Bug ID: 108700
Summary: false _Noreturn error with
-Werror=old-style-declaration
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc-12 (Debian 12.2.0-14) 12.2.0 (but this error was already present in
GCC 4.8):
cventin% echo 'int _Noreturn does_not_return (void) { for (;;) continue; }' |
gcc-12 -xc -c -Werror=old-style-declaration -
:1:1: error: ‘_Noreturn’ is not at beginning of declaration
[-Werror=old-style-declaration]
cc1: some warnings being treated as errors
This error is incorrect. The grammar in ISO C17 is
function-definition:
declaration-specifiers declarator declaration-listopt compound-statement
declaration-specifiers:
storage-class-specifier declaration-specifiersopt
type-specifier declaration-specifiersopt
type-qualifier declaration-specifiersopt
function-specifier declaration-specifiersopt
alignment-specifier declaration-specifiersopt
where "int" is part of type-specifier and "_Noreturn" is part of
function-specifier, so that they can be in any order.
Note that the
int _Noreturn does_not_return (void) { for (;;) continue; }
comes from one of the autoconf tests, which fails as a consequence.
[Bug c++/106656] [C++23] P2513 - char8_t Compatibility and Portability Fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106656 --- Comment #4 from Marek Polacek --- (In reply to Dimitrij Mijoski from comment #3) > The documentation for CLI flag -fchar8_t should be updated > https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html . Oh right, this is not an error anymore: char ca[] = u8"xx"; I'll fix, thanks. > Is there any chance that this fix gets backported because it is treated as > defect report to C++20? I wasn't really planning to do that.
[Bug tree-optimization/108697] constructing a path-range-query is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
--- Comment #4 from Aldy Hernandez ---
Created attachment 54420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54420&action=edit
reuse path_range_query SSA cache for all of back_threader class
Off of the top of my head (i.e. probably very broken ;-)), this is what I had
in mind... Share a cache between subsequent instantiations of
path_range_query.
Note the change to the set_cache:
path_range_query::set_cache (const vrange &r, tree name)
{
unsigned v = SSA_NAME_VERSION (name);
- bitmap_set_bit (m_has_cache_entry, v);
+ if (bitmap_set_bit (m_has_cache_entry, v))
+m_cache->clear_global_range (name);
m_cache->set_global_range (name, r);
}
Since we're sharing the cache, make sure we nuke whatever it had there before,
otherwise set_global_range will try to reuse the slot if it thinks it fits.
Although...maybe that's not even necessary. I'm not sure...you'd have to play
around with it, but I think the general idea would work.
[Bug target/108699] New: gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699
Bug ID: 108699
Summary: gcc.c-torture/execute/builtin-bitops-1.c fails on
power 9 BE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
This fails for 32 bits powerpc64 BE on a power 9 (only) and it fails for trunk
and gcc 12, 11, and 10.
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
execute.exp=gcc.c-torture/execute/builtin-bitops-1.c"
FAIL: gcc.c-torture/execute/builtin-bitops-1.c -Os execution test
# of expected passes15
# of unexpected failures1
spawn -ignore SIGHUP
^M
PASS: gcc.c-torture/execute/builtin-bitops-1.c -Os (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]^M
FAIL: gcc.c-torture/execute/builtin-bitops-1.c -Os execution test
(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/builtin-bitops-1.exe
Program received signal SIGABRT, Aborted.
0x0fd737a0 in ?? () from /lib32/libc.so.6
(gdb) where
#0 0x0fd737a0 in ?? () from /lib32/libc.so.6
#1 0x0fd15424 in raise () from /lib32/libc.so.6
#2 0x0fcfa428 in abort () from /lib32/libc.so.6
#3 0x1408 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/execute/builtin-bitops-1.c:182
There are a bunch of aborts in this test but the reported line # must be off.
[Bug tree-optimization/108692] [11/12/13 Regression] Miscompilation of orc_test.c since r11-5160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692 --- Comment #3 from Jakub Jelinek --- Created attachment 54419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54419&action=edit gcc13-pr108692.patch Untested fix.
[Bug c++/106656] [C++23] P2513 - char8_t Compatibility and Portability Fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106656 Dimitrij Mijoski changed: What|Removed |Added CC||dmjpp at hotmail dot com --- Comment #3 from Dimitrij Mijoski --- The documentation for CLI flag -fchar8_t should be updated https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html . Is there any chance that this fix gets backported because it is treated as defect report to C++20?
[Bug tree-optimization/108697] constructing a path-range-query is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697 --- Comment #3 from Richard Biener --- But yes, your observation about m_has_cache_entry is correct - if that has any value (it makes reset_path "cheap"), then it should be also relied on upon growth. Maybe make this bitmap an optional feature of the cache itself and handle it transparently there?
[Bug tree-optimization/108697] constructing a path-range-query is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697 --- Comment #2 from Richard Biener --- Created attachment 54418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54418&action=edit replace vector with hash_map it's the clearing that shows up on the profile, I've experimented with the attached which removes it but the -ftime-report didn't change. Maybe that this function is top in the profile is an artifact of callgrind (I'm usually using that because you get nice coverage & call traces) still, an O(num-ssa-names) operation for each possible thread is a source of "quadraticness"
[Bug tree-optimization/108697] constructing a path-range-query is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697 --- Comment #1 from Aldy Hernandez --- Sharing a cache with say the ranger is a no go, because the path_range_query's cache is specific to the path, but perhaps we could share the path's cache between constructions providing a constructor that takes the cache as you suggest. The path query has a bitmap to determine if a cache entry is used (m_has_cache_entry), so I think we could reuse a dirty cache since the bitmap gets cleared at construction. I assume the main culprit is the path_range_query's being instantiated from class back_threader? If so, there could be one cache per back_threader? Hmmm, perhaps we'd have to call ssa_global_cache::clear_global_range() before each set_global_range() for reused caches otherwise the latter would try to reuse slots (fits_p and all that). Also, is it the clearing part of safe_grow_cleared() that is taking up the time, or just safe_grow. Cause ISTM we don't need to clear the cache for use in path_range_query. So we could even add a flag to use safe_grow() instead of safe_grow_cleared() for the path query?
[Bug tree-optimization/108692] [11/12/13 Regression] Miscompilation of orc_test.c since r11-5160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692
--- Comment #2 from Jakub Jelinek ---
So, on simplified -O2 -ftree-vectorize testcase with trunk:
int
foo (signed char *x, signed char *y, int n)
{
int i, r = 0;
signed char a, b;
for (i = 0; i < n; i++)
{
a = x[i];
b = y[i];
int c = (unsigned char) a - (unsigned char) b;
r = r + (c < 0 ? -c : c);
}
return r;
}
everything looks ok to me until vect_recog_sad_pattern is called.
The interesting part of the loop in question is:
[local count: 955630225]:
# i_22 = PHI
# r_23 = PHI
...
a.0_5 = (unsigned char) a_15;
_6 = (int) a.0_5;
b.1_7 = (unsigned char) b_17;
_8 = (int) b.1_7;
c_18 = _6 - _8;
_9 = ABS_EXPR ;
r_19 = _9 + r_23;
with 15/17 having signed char type, 5/7 unsigned char and everything else int.
Now, when vect_recog_sad_pattern is called, it sees as diff_stmt_vinfo->stmt
patt_34 = (a.0_5) w- (b.1_7);
which is reasonable, abs_stmt_vinfo was
patt_30 = ABS_EXPR ;
where 30 is signed short, patt_33 too set to (signed short) patt_34 and 34
unsigned short. Still, the widening subtraction is done with zero extensions
from unsigned char operands to unsigned short.
But vect_recog_sad_pattern calls
1325 if (!vect_widened_op_tree (vinfo, diff_stmt_vinfo, MINUS_EXPR,
WIDEN_MINUS_EXPR,
1326 false, 2, unprom, &half_type))
1327return NULL;
and instead of returning a.0_5 and b.1_7 as the unpromoted operands and
unsigned char as half_type, it returns a_15 and b_17 as the unpromoted operands
and signed char as half_type.
I'd think if in vect_widened_op_tree after the early checks rhs_code != code we
shouldn't look through further promotions and just accept what we have.
as
[Bug tree-optimization/108698] [13 Regression] decltype ((T() + ‘excess_precision_expr’ not supported by dump_expr)) median(ndarray) [with T = double]’: since r13-3290-g98e341130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698 Martin Liška changed: What|Removed |Added Target Milestone|--- |13.0 Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org Priority|P3 |P1 Last reconfirmed||2023-02-07 Status|UNCONFIRMED |NEW
[Bug tree-optimization/108698] New: [13 Regression] decltype ((T() + ‘excess_precision_expr’ not supported by dump_expr)) median(ndarray) [with T = double]’: since r13-3290-g98e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698
Bug ID: 108698
Summary: [13 Regression] decltype ((T() +
‘excess_precision_expr’ not supported by
dump_expr)) median(ndarray) [with
T = double]’: since r13-3290-g98e341130f87984a
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
The following is isolated from python-scipy package:
$ cat scipy.ii
template struct ndarray {};
template decltype(T() + 1.) median(ndarray);
struct Trans_NS_functor_median {
template void operator()(Types...) { median(Types()...);
}
};
struct siegelslopes {
void operator()(siegelslopes, double, void()) {
ndarray __trans_tmp_9;
Trans_NS_functor_median{}(__trans_tmp_9);
}
} siegelslopes0_y;
double siegelslopes0_x;
void siegelslopes0_method() {
siegelslopes()(siegelslopes0_y, siegelslopes0_x, siegelslopes0_method);
}
$ g++ scipy.ii -c -m32 -std=c++14
scipy.ii: In instantiation of ‘decltype ((T() + ‘excess_precision_expr’ not
supported by dump_expr)) median(ndarray) [with T =
double]’:
scipy.ii:2:39: sorry, unimplemented: mangling excess_precision_expr
2 | template decltype(T() + 1.) median(ndarray);
| ^~
$ g++-12 scipy.ii -c -m32 -std=c++14
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Richard Biener --- I will have a look.
[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108688 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/108685] [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685 Richard Biener changed: What|Removed |Added Keywords||ice-checking Target Milestone|--- |13.0
[Bug tree-optimization/108684] [13 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/103541] unnecessary spills around const functions calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541 --- Comment #5 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:f661c0bb6371f355966a67b5ce71398e80792948 commit r13-5730-gf661c0bb6371f355966a67b5ce71398e80792948 Author: Vladimir N. Makarov Date: Tue Feb 7 08:27:36 2023 -0500 RA: Implement reuse of equivalent memory for caller saves optimization The test case shows opportunity to reuse memory with constant address for caller saves optimization for constant or pure function call. The patch implements the memory reuse. PR rtl-optimization/103541 gcc/ChangeLog: * ira.h (struct ira_reg_equiv_s): Add new field caller_save_p. * ira.cc (validate_equiv_mem): Check memref address variance. (update_equiv_regs): Define caller save equivalence for valid_combine. (setup_reg_equiv): Clear defined_p flag for caller save equivalence. * lra-constraints.cc (lra_copy_reg_equiv): Add new arg call_save_p. Use caller save equivalence depending on the arg. (split_reg): Adjust the call. gcc/testsuite/ChangeLog: * gcc.target/i386/pr103541.c: New.
[Bug tree-optimization/108692] [11/12/13 Regression] Miscompilation of orc_test.c since r11-5160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #144 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:295adfc9ed20468cdaba3afe258d57b58a8df792 commit r13-5729-g295adfc9ed20468cdaba3afe258d57b58a8df792 Author: Richard Biener Date: Tue Feb 7 13:01:12 2023 +0100 tree-optimization/26854 - compile-time hog in SSA forwprop The following addresses tree forward propagate : 12.41 ( 9%) seen with the compile.i testcase of this PR which points at the has_use_on_stmt function which, for SSA names with many uses is slow. The solution is to instead of immediate uses, look at stmt operands to identify whether a name has a use on a stmt. That improves SSA forwprop to tree forward propagate : 1.30 ( 0%) for this testcase. PR tree-optimization/26854 * gimple-fold.cc (has_use_on_stmt): Look at stmt operands instead of immediate uses.
[Bug tree-optimization/108697] New: constructing a path-range-query is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
Bug ID: 108697
Summary: constructing a path-range-query is expensive
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Looking at the profile of the compiler.i testcase from PR26854 one can see
ssa_global_cache::set_global_range very high in the profile, specifically
the clearing of m_tab:
bool
ssa_global_cache::set_global_range (tree name, const vrange &r)
{
unsigned v = SSA_NAME_VERSION (name);
if (v >= m_tab.length ())
m_tab.safe_grow_cleared (num_ssa_names + 1);
note this cache is allocated freshly each time a path_range_query is
allocated which makes this process (in case any global range is registered)
O(num-ssa-names) which for large functions can be very expensive.
None of the path_range_query CTORs supports sharing the cache (and I'm not
sure that would be "correct"). For the testcase at hand nearly all
ssa_global_cache objects are allocated from path_range_query and the
backwards threader. But there are CTOR calls from the ranger_cache CTOR
as well - the backwards threader also has a ranger instance, so I wonder
if one can take the global cache from that (co-incidentially the path-range
query instance gets a reference to a ranger instance ...).
Maybe ssa_global_cache is just a very bad representation for the path
range query.
[Bug tree-optimization/108696] New: querying relations is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108696 Bug ID: 108696 Summary: querying relations is slow Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- With the compiler.i testcase from PR26854 I notice we do quite a lot of bitmap intersections via dom_oracle::query_relation for the case (which hits 99% of the time) when a SSA name doesn't have any relation but equiv_set () returns a newly allocated bitmap with just the self-equivalence recorded. The self-equivalence case isn't used to prune the work done by query_relation it seems. Maybe find_relation_dom does that via // IF either name does not occur in a relation anywhere, there isnt one. if (!bitmap_bit_p (m_relation_set, v1) || !bitmap_bit_p (m_relation_set, v2)) return VREL_VARYING; but we still get all the way to the query_relation overload which eventually does the intersection with m_relation_set which is a lot more expensive than this. A naiive diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc index f5b1e67e420..f58d5050bdb 100644 --- a/gcc/value-relation.cc +++ b/gcc/value-relation.cc @@ -1373,6 +1373,10 @@ dom_oracle::query_relation (basic_block bb, tree ssa1, tree ssa2) unsigned v2 = SSA_NAME_VERSION (ssa2); if (v1 == v2) return VREL_EQ; + + // IF either name does not occur in a relation anywhere, there isnt one. + if (!bitmap_bit_p (m_relation_set, v1) || !bitmap_bit_p (m_relation_set, v2)) +return VREL_VARYING; // Check for equivalence first. They must be in each equivalency set. const_bitmap equiv1 = equiv_set (ssa1, bb); cuts dominator optimization : 17.35 ( 15%) down to dominator optimization : 16.17 ( 14%) note almost all of the DOM time is spent in ranger for this testcase.
[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695 Martin Liška changed: What|Removed |Added Last reconfirmed||2023-02-07 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1
[Bug ipa/108695] New: [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695 Bug ID: 108695 Summary: [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Since the r13-5215-gb1f30bf42d8d47 revision, I noticed dd_rescue package test fail: $ wget http://www.garloff.de/kurt/linux/ddrescue/dd_rescue-1.99.12.tar.bz2 $ tar xvjf dd_rescue-1.99.12.tar.bz2 $ cd dd_rescue-1.99.12 $ sed -i 's/-Os/-O2 -flto=auto/' Makefile $ ./autogen.sh $ make test_aes -j16 $ ./test_aes AES192-CBC 10 0 16 CPU Features: SSE2 1 SSE4.2 1 AES 1 RDRAND 1 AVX2 1 VAES 1 Memcpy: 0.000s ( 634MB/s) ===> AES tests/benchmark (16) PAD_ZERO <=== * AES_C AES192-CBC (192, 12, 208) pad 0/0 EKey setup: 0.000s ( 1236MB/s) 746789bcfa469b85 Encrypt : 0.000s (32MB/s) 16->16: 0 a6fb0b9db874a15a DKey setup: 0.000s ( 1236MB/s) 8547a0ecb2d90b74 Decrypt : 0.000s ( 3200MB/s) 16->16: 0 a6fb0b9db874a15a Miscompare (AES_C) @ 0: 00 00 00 00 <-> 67 45 8b 6b * OSSL AES192-CBC (192, 12, 8) pad 0/0 EKey setup: 0.001s ( 5MB/s) f000 Encrypt : 0.000s (13MB/s) 16->16: 0 1b5874991e39ca6e Miscompare (encr vs prev) @ 0: 6e ca 39 1e <-> 5a a1 74 b8 DKey setup: 0.000s ( 830MB/s) f000 Decrypt : 0.000s (27MB/s) 16->16: 0 1b5874991e39ca6e * VAES AES192-CBC (192, 12, 208) pad 0/0 EKey setup: 0.000s ( 4119MB/s) 546c673889b172da Encrypt : 0.000s (79MB/s) 16->16: 0 1b5874991e39ca6e DKey setup: 0.000s ( 4119MB/s) daf3e486ec803854 Decrypt : 0.000s ( 8000MB/s) 16->16: 0 1b5874991e39ca6e * 2 inconsistencies found
[Bug c/108694] need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1 from Florian Weimer --- Clang now has -Wdeprecated-non-prototype apparently: https://discourse.llvm.org/t/unresolved-issues-from-the-llvm-15-x-release/66071/36 This is probably not very useful as a warning: > void func3 (); /* warning: an empty parameter list in function declarators > will have a different meaning in ISO C23 */ “()” is going to be fine when matched with an empty parameter list in a definition, or an empty argument list in a call. I don't think it's necessary to warn in those cases. It distracts from the real issue.
[Bug tree-optimization/106809] [12 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106809 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:051f78a5c1d6994c10ee7c35453ff0ccee94e5c6 commit r10-11201-g051f78a5c1d6994c10ee7c35453ff0ccee94e5c6 Author: Richard Biener Date: Fri Sep 2 13:36:13 2022 +0200 tree-optimization/106809 - compile time hog in VN The dominated_by_p_w_unex function is prone to high compile time. With GCC 12 we introduced a VN run for uninit diagnostics which now runs into a degenerate case with bison generated code. Fortunately this case is easy to fix with a simple extra check - a more general fix needs more work. PR tree-optimization/106809 * tree-ssa-sccvn.c (dominaged_by_p_w_unex): Check we have more than one successor before doing extra work. * gcc.dg/torture/pr106809.c: New testcase. (cherry picked from commit be1b42de9c151d46c89f9a8f82d4c5839a19ea94)
[Bug c++/108646] nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 --- Comment #5 from Jonny Grant --- (In reply to Jonathan Wakely from comment #4) > (In reply to Jonny Grant from comment #3) > > Is it worth -Wnonnull emitting a warning message that it needs optimization > > to get the needed data flow analysis? > > No, there are dozens of warnings that work poorly, or not at all, unless > optimization is enabled. It's in the manual. > > "The effectiveness of some warnings depends on optimizations also being > enabled. For example -Wsuggest-final-types is more effective with link-time > optimization and some instances of other warnings may not be issued at all > unless optimization is enabled. While optimization in general improves the > efficacy of control and data flow sensitive warnings, in some cases it may > also cause false positives." Ok I see. Thank you for clarifying.
[Bug tree-optimization/106809] [12 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106809 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:5125737077adc2110b9f17f06141e8f76ccab9b9 commit r11-10510-g5125737077adc2110b9f17f06141e8f76ccab9b9 Author: Richard Biener Date: Fri Sep 2 13:36:13 2022 +0200 tree-optimization/106809 - compile time hog in VN The dominated_by_p_w_unex function is prone to high compile time. With GCC 12 we introduced a VN run for uninit diagnostics which now runs into a degenerate case with bison generated code. Fortunately this case is easy to fix with a simple extra check - a more general fix needs more work. PR tree-optimization/106809 * tree-ssa-sccvn.c (dominaged_by_p_w_unex): Check we have more than one successor before doing extra work. * gcc.dg/torture/pr106809.c: New testcase. (cherry picked from commit be1b42de9c151d46c89f9a8f82d4c5839a19ea94)
[Bug c/108694] New: need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
Bug ID: 108694
Summary: need a new warning option for preparing migration to
ISO C 23
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
The use of () to denote an unknown or varargs parameter list in function
declarations and function types, a language feature from K&R C, is finally
disallowed in ISO C 23. Instead, () as a parameter list denotes a list of zero
arguments, the same as (void), in ISO C 23.
The set of warnings that were added to GCC over the years, regarding function
prototypes, were designed at a time when the migration target was still
unknown. Now that the migration target, ISO C 23, is known, some projects want
to have the following programming style, for code that compiles OK both in C99
and C23:
- (1) In function definitions, use () to denote argument lists with zero
arguments.
- (2) In function declarations and function types, use (void) to denote
argument lists with zero arguments.
See https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00055.html and
https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00062.html for details
of the rationale.
As a programmer, I would like to have an easy way to get warnings when this
programming style is not followed.
There are two ways such a warning could be added to GCC:
(A) A warning that applies when compiling for a language standard older than
C23 (e.g. -std=gnu99).
In which situations would this warning be emitted?
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* warning: an empty parameter list in function declarators will
have a different meaning in ISO C23 */
void func4 (void); /* No warning */
=
Looking through the existing warning options of GCC and clang:
Warning options from https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Option Not adequate because ...
---
-Wall Does not warn for func3.
-Wstrict-prototypes Warns for func1 as well.
-Wold-style-declaration Does not warn for func3.
-Wold-style-definition Does not warn for func3. Warns for func1.
-Wmissing-prototypesDoes not warn for func3. Warns for func1 and func2.
-Wmissing-declarations Does not warn for func3. Warns for func1 and func2.
-Wpedantic Does not warn for func3.
Warning options from https://clang.llvm.org/docs/DiagnosticsReference.html
Option Not adequate because ...
---
-Wall Does not warn for func3.
-Wdeprecated-declarations Does not warn for func3.
-Wdeprecated-non-prototype Does not warn for func3.
-Wmissing-prototypesDoes not warn for func3. Warns for func1 and func2.
-Wpedantic Warns for func1 as well.
So, none of these existing warning options fits the need. A new warning option
is needed.
(B) A warning that applies when compiling for C23 (e.g. -std=gnu23).
The situations would be the same as above. Only the diagnostic's message would
refer to *older* standard versions, such as:
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* warning: an empty parameter list in function declarators
denotes a varargs parameter list in ISO C17 and older; use (void) to
disambiguate */
void func4 (void); /* No warning */
=
[Bug tree-optimization/108692] [11/12/13 Regression] Miscompilation of orc_test.c since r11-5160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692 --- Comment #1 from Jakub Jelinek --- Before the r11-5160 change, the innermost loop was an unsigned char x 16 -> int x 4 SAD_EXPR: [local count: 567644343]: # vect_var12_i_49.13_90 = PHI # ivtmp.57_149 = PHI vect_var32_32.16_95 = MEM [(const signed char *)vectp.15_91 + ivtmp.57_149 * 1]; vect_var33_33.19_100 = MEM [(const signed char *)vectp.18_96 + ivtmp.57_149 * 1]; vect_var32.20_101 = VIEW_CONVERT_EXPR(vect_var32_32.16_95); vect_var33.21_102 = VIEW_CONVERT_EXPR(vect_var33_33.19_100); vect_patt_46.22_103 = SAD_EXPR ; ivtmp.57_150 = ivtmp.57_149 + 16; if (ivtmp.57_150 != _166) goto ; [83.33%] else goto ; [16.67%] with vect_patt_46.22_103/vect_var12_i_49.13_90 type being vector(4) int. After the change it is signed char x 16 -> int x 4 SAD_EXPR instead: [local count: 567644343]: # vect_var12_i_49.13_99 = PHI # ivtmp.55_156 = PHI vect_var32_32.16_104 = MEM [(const signed char *)vectp.15_100 + ivtmp.55_156 * 1]; vect_var33_33.19_109 = MEM [(const signed char *)vectp.18_105 + ivtmp.55_156 * 1]; vect_patt_39.20_110 = SAD_EXPR ; ivtmp.55_157 = ivtmp.55_156 + 16; if (ivtmp.55_157 != _173) goto ; [83.33%] else goto ; [16.67%]
