[Bug tree-optimization/101139] Unable to remove double byteswap in fast path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101139 --- Comment #5 from Andrew Pinski --- Created attachment 57993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57993&action=edit Patch but it does not work for the code in this testcase I have to look into why it is not working for the testcase in comment #0 (factor_out_conditional_operation is not even called) but it does work for: ``` short f(int a, short b, short c) { if (a) return __builtin_bswap16(b); return __builtin_bswap16(c); } ```
[Bug tree-optimization/114787] New: wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Bug ID: 114787 Summary: wrong code at -O1 on x86_64-linux-gnu (the generated code hangs) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhendong.su at inf dot ethz.ch Target Milestone: --- It appears to be a recent regression and does not reproduce with 13.2 and earlier. Compiler Explorer: https://godbolt.org/z/6sbh8Wr1e [663] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.1 20240420 (experimental) (GCC) [664] % [664] % gcctk -O0 small.c; ./a.out [665] % [665] % gcctk -O1 small.c [666] % timeout -s 9 10 ./a.out Killed [667] % [667] % cat small.c int a, b, c, d, e = -1, f, g, h, j, k, n, o, p; int main() { int i, l = 2, m; for (b = 0; b < 1; b++) l = 0; for (; a >= 0; a--) for (m = 3; m; m--) { k = g; i = 0; for (; i < 1; i++) for (; f < 1; f++) h = g; n = 2 & ((e ^ d) | 1) * j; o = ~(e & n); q: if (c <= e) return 0; e = o; } p = l; l = 0; if (p) goto q; return 0; }
[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Jakub Jelinek changed: What|Removed |Added Version|unknown |14.0 Last reconfirmed||2024-04-20 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Summary|wrong code at -O1 on|[14 Regression] wrong code |x86_64-linux-gnu (the |at -O1 on x86_64-linux-gnu |generated code hangs) |(the generated code hangs) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r14-7138-g05e8ef2a05b477589cae25af3311bad0f68a90fe
[Bug c++/114764] noexcept on a friend complains about incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764 --- Comment #7 from Giuseppe D'Angelo --- I get it :) If you wanted an actual use-case (rather than a synthetic testcase), we stumbled upon this bug from implementing a friend operator==: ``` class S { bool comparesEqual(S, S) noexcept; // pass by value, object is small/trivially copyable friend inline bool operator==(S a, S b) noexcept(noexcept(comparesEqual(S, S))) { returns comparesEqual(a, b); } }; ``` which is the result of some macro expansions through which we support C++20's comparisons in C++17 in Qt. The problem is the pass by value -- changing it to pass by const-ref fixes it, but generates different linting about not passing a small TC object by value...
[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112893 --- Comment #9 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:f9a48fe7032d9894e88d0d121ba6f75b08ea5dcb commit r14-10053-gf9a48fe7032d9894e88d0d121ba6f75b08ea5dcb Author: Gaius Mulley Date: Sat Apr 20 14:35:18 2024 +0100 PR modula2/112893 full type checking between proctype and procedure not implemented This patch implements full type checking between proctype and procedures. The change implements an associated proc type built for each procedure. M2Check.mod will request GetProcedureProcType if it encounters a procedure. Before this patch a procedure was associated with the type ADDRESS in the type checking module M2Check. The gm2/pim/pass/proccard.mod have been corrected now this assumption has been removed. gcc/m2/ChangeLog: PR modula2/112893 * gm2-compiler/M2Check.mod (GetProcedureProcType): Import. (getType): Return value using GetProcedureProcType if sym is a procedure. * gm2-compiler/M2Range.mod (FoldTypeExpr): Remove quad if expression is type compatible. * gm2-compiler/SymbolTable.def (GetProcedureProcType): New procedure function. * gm2-compiler/SymbolTable.mod (Procedure): Add ProcedureType. (MakeProcedure): Initialize ProcedureType. (PutParam): Call AddProcedureProcTypeParam. (PutVarParam): Call AddProcedureProcTypeParam. (AddProcedureProcTypeParam): New procedure. (GetProcedureProcType): New procedure function. gcc/testsuite/ChangeLog: PR modula2/112893 * gm2/pim/pass/another.mod: Correct bug exposed by type checker. Swap ProcA and ProcB assignments. * gm2/pim/pass/proccard.mod: Use VAL to convert procedure into a cardinal. * gm2/iso/const/fail/castproctype.mod: New test. * gm2/pim/fail/badproctype.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112893 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #10 from Gaius Mulley --- Closing now the patch has been applied.
[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug ada/114636] actual does not match formal in instantiation with formal package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114636 Eric Botcazou changed: What|Removed |Added Summary|Actual does not match |actual does not match |formal in generic |formal in instantiation |instantiation |with formal package Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-04-20 CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- This comes from the formal discrete types and has probably never worked.
[Bug ada/114636] actual does not match formal in instantiation with formal package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114636 --- Comment #2 from Eric Botcazou --- This appears to be sufficient: diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb index e7b759c4e88..c06377ab4c9 100644 --- a/gcc/ada/sem_ch12.adb +++ b/gcc/ada/sem_ch12.adb @@ -6696,8 +6696,12 @@ package body Sem_Ch12 is then -- If the formal is a tagged type the corresponding class-wide -- type has been generated as well, and it must be skipped. +-- Likewise, for a formal discrete type, the base type has been +-- generated as well (see Analyze_Formal_Discrete_Type). -if Is_Type (E2) and then Is_Tagged_Type (E2) then +if Is_Type (E2) + and then (Is_Tagged_Type (E2) or else Is_Enumeration_Type (E2)) +then Next_Entity (E2); end if;
[Bug ada/114636] actual does not match formal in instantiation with formal package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114636 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Eric Botcazou --- I'll test the above fixlet.
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:c2cb625eb141cacd0bee6c6ce5888d673ac38ca4 commit r12-10361-gc2cb625eb141cacd0bee6c6ce5888d673ac38ca4 Author: Francois-Xavier Coudert Date: Sat Aug 19 23:22:06 2023 +0200 Testsuite: fix analyzer tests on Darwin On macOS, system headers redefine by default some macros (memcpy, memmove, etc) to checked versions, which defeats the analyzer. We want to turn this off. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 gcc/testsuite/ChangeLog: PR analyzer/104042 * gcc.dg/analyzer/analyzer.exp: Pass -D_FORTIFY_SOURCE=0 on Darwin. (cherry picked from commit ce33bbfcbc7dd3afc6c96fb48a19ed00f0c598ce)
[Bug ada/114640] ICE on elsif part of if-statement containing if-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640 Eric Botcazou changed: What|Removed |Added Summary|ICE on 'elsif' with complex |ICE on elsif part of |function call |if-statement containing ||if-expression Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-20 --- Comment #2 from Eric Botcazou --- Indeed, way too many chained/nested ifs here. :-)
[Bug ada/114640] ICE on elsif part of if-statement containing if-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640 --- Comment #3 from Eric Botcazou --- This appears to be sufficient: diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb index 04d114694ab..71cfdd718e0 100644 --- a/gcc/ada/exp_util.adb +++ b/gcc/ada/exp_util.adb @@ -6549,6 +6549,7 @@ package body Exp_Util is | N_Aggregate | N_Delta_Aggregate | N_Extension_Aggregate +| N_Elsif_Part and then Nkind (Parent (Par)) not in N_Function_Call | N_Procedure_Call_Statement | N_Entry_Call_Statement
[Bug ada/114640] ICE on elsif part of if-statement containing if-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- I'll test the above fixlet.
[Bug ada/114708] [12/13/14 regression] internal error on access to an incomplete formal in generic package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114708 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|Creating access to an |[12/13/14 regression] |incomplete formal in a |internal error on access to |generic package sometimes |an incomplete formal in |causes GNAT to crash|generic package Last reconfirmed||2024-04-20 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed as a regression in GCC 12 and later.
[Bug ada/114708] [12/13/14 regression] internal error on access to an incomplete formal in generic package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114708 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug ada/114708] [12/13/14 regression] internal error on access to an incomplete formal in generic package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114708 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- I'll have a look.
[Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766 --- Comment #2 from Tamar Christina --- (In reply to Vladimir Makarov from comment #1) > (In reply to Tamar Christina from comment #0) > > The documentation for ^ states: > > If it works for you, we could try to use the patch (although it needs some > investigation how other targets uses the hint). In any case, the > documentation should be modified or made more clear depending on applying or > not applying the patch. Yeah, using the patch gives us the behavior we expected, we added a workaround for now so we can investigate what other targets do in GCC 15. But while looking at this we also got some unexpected behavior with using ? For instance we have the pattern: ;; Equal width integer to fp conversion. (define_insn "2" [(set (match_operand:GPF 0 "register_operand") (FLOATUORS:GPF (match_operand: 1 "register_operand")))] "TARGET_FLOAT" {@ [ cons: =0 , 1 ; attrs: type , arch ] [ w, w ; neon_int_to_fp_ , simd ] cvtf\t%0, %1 [ w, ?r ; f_cvti2f, fp] cvtf\t%0, %1 }) for modeling floating point conversions. We had expected ? to make the alternative more expensive, but still possible. However again during IRA the entire register class is blocked: r103: preferred FP_REGS, alternative NO_REGS, allocno FP_REGS I would have expected that the additional penalty should never make an alternative impossible. We thought maybe the move costs were an issue, but we tried with various big and small numbers but it looks like the move costs have little to no effect. Since the original value in this case was in r: Choosing alt 0 in insn 7: (0) =rk (1) %rk (2) I {*adddi3_aarch64} I would have expected the cost for FP_REGS not to be 0, as there's a register file move involved: r103 costs: W8_W11_REGS:2000 W12_W15_REGS:2000 TAILCALL_ADDR_REGS:2000 STUB_REGS:2000 GENERAL_REGS:2000 FP_LO8_REGS:0 FP_LO_REGS:0 FP_REGS:0 POINTER_AND_FP_REGS:7000 MEM:9000 In this particular pattern the ? isn't needed so we're removing it, but the behavior is still unexpected.
[Bug ada/114710] temporary object finalized too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114710 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Summary|Temporary object finalized |temporary object finalized |too late, causing deadlock |too late Last reconfirmed||2024-04-20 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Yes, this works as expected in simpler cases, but not here.
[Bug rtl-optimization/114788] New: ICE on valid code at -O{2,3} on x86_64-linux-gnu (during RTL pass: sched2): in move_exprs_to_boundary, at sel-sched.cc:5236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114788 Bug ID: 114788 Summary: ICE on valid code at -O{2,3} on x86_64-linux-gnu (during RTL pass: sched2): in move_exprs_to_boundary, at sel-sched.cc:5236 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhendong.su at inf dot ethz.ch Target Milestone: --- It is a regression from 12.*, and affects 13.* and later. Compiler Explorer: https://godbolt.org/z/n4MvPos5n [679] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.1 20240420 (experimental) (GCC) [680] % [680] % gcctk -O3 -fno-guess-branch-probability -fselective-scheduling2 -fno-tree-sink -fschedule-insns -c small.c during RTL pass: sched2 small.c: In function ‘main’: small.c:32:1: internal compiler error: in move_exprs_to_boundary, at sel-sched.cc:5236 32 | } | ^ 0x8424f2 move_exprs_to_boundary ../../gcc-trunk/gcc/sel-sched.cc:5236 0x8424f2 schedule_expr_on_boundary ../../gcc-trunk/gcc/sel-sched.cc:5444 0x1125588 fill_insns ../../gcc-trunk/gcc/sel-sched.cc:5586 0x1125588 schedule_on_fences ../../gcc-trunk/gcc/sel-sched.cc:7361 0x1125588 sel_sched_region_2 ../../gcc-trunk/gcc/sel-sched.cc:7499 0x1126c78 sel_sched_region_1 ../../gcc-trunk/gcc/sel-sched.cc:7541 0x1128a19 sel_sched_region(int) ../../gcc-trunk/gcc/sel-sched.cc:7642 0x1128a19 sel_sched_region(int) ../../gcc-trunk/gcc/sel-sched.cc:7627 0x1129a21 run_selective_scheduling() ../../gcc-trunk/gcc/sel-sched.cc:7728 0x1106c0d rest_of_handle_sched2 ../../gcc-trunk/gcc/sched-rgn.cc:3741 0x1106c0d execute ../../gcc-trunk/gcc/sched-rgn.cc:3888 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. [681] % cat small.c extern void r(); int b, d, g, l; char c, e, f; volatile char h; int main() { int k, i, m, q; for (; b && i; i++) { int n = k; L1: k = 0 || d; while (n < e) ; } b = f; L2: if (h) r(); if (l) { int a, j = f / g, o = (j / c && f) % d, p = (f % q * ~h && c && j) / k; if (h) { a = d; p = m; k = k / l / (2 * f % 3); m = o & c / ((m && a) ^ (p && 2 / g) | f); if (m) goto L1; } m = p; goto L2; } return 0; }
[Bug c/114789] New: False positive -Wmaybe-uninitialized at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114789 Bug ID: 114789 Summary: False positive -Wmaybe-uninitialized at -O2 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jb999 at gmx dot de Target Milestone: --- This test case produces a false positive -Wmaybe-uninitialized warning with PARTS set to 2 or higher, but not with PARTS set to 1 or at -O instead of -O2: #include #define PARTS 2 void foo(void **); void grab (char *line) { void *item[1]; unsigned int part = 1; do { while (*line && *line == ' ') line++; if (part == 1) item[0] = line; while (*line && *line != ' ') line++; } while (++part <= PARTS); if (*line) *line++ = 0; if (strlen(item[0])) foo(item); } Output: Using built-in specs. COLLECT_GCC=/tmp/gcc14/usr/bin/gcc Target: i686-pc-linux-gnu Configured with: /tmp/gcc/configure --prefix=/tmp/gcc14/usr --sysconfdir=/tmp/gcc14/etc --sharedstatedir=/tmp/gcc14/var/state --localstatedir=/tmp/gcc14/var/state --enable-shared --disable-static --disable-nls --enable-languages=c,c++ --with-system-zlib --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.1 20240416 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c' '-mtune=generic' '-march=pentiumpro' /tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/cc1 -E -quiet -v testcase.c -mtune=generic -march=pentiumpro -Wuninitialized -O2 -fpch-preprocess -o testcase.i ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/include /tmp/gcc14/usr/include /tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c' '-mtune=generic' '-march=pentiumpro' /tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/cc1 -fpreprocessed testcase.i -quiet -dumpbase testcase.c -dumpbase-ext .c -mtune=generic -march=pentiumpro -O2 -Wuninitialized -version -o testcase.s GNU C17 (GCC) version 14.0.1 20240416 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 14.0.1 20240416 (experimental), GMP version 6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 2da1b27980967f452f520dd3eb2f4c0a testcase.c: In function 'grab': testcase.c:23:18: warning: 'item' may be used uninitialized [-Wmaybe-uninitialized] 23 | if (strlen(item[0])) foo(item); | ^~~ testcase.c:9:9: note: 'item' declared here 9 | void *item[1]; | ^~~~ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c' '-mtune=generic' '-march=pentiumpro' as -v --32 -o testcase.o testcase.s GNU assembler version 2.29.1 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.29.1 COMPILER_PATH=/tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/:/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c' '-mtune=generic' '-march=pentiumpro'
[Bug target/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Component|tree-optimization |target --- Comment #2 from Andrew Pinski --- The first difference besides prediction/counts on the BB is in the register allocator. The code for aarch64 looks ok too.
[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Andrew Pinski changed: What|Removed |Added Component|target |tree-optimization --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > The first difference besides prediction/counts on the BB is in the register > allocator. > > The code for aarch64 looks ok too. So I was wrong (and now even more confused than before). In that sometimes even GCC 13.2.0 code generation is broken. But I don't understand what the conditions are which cause it (adding -fdump-tree-optimized-all or something like that seems to cause different code generation).
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||12.1.0 Target Milestone|14.0|13.3 Known to fail||13.1.0 Summary|[14 Regression] wrong code |[13/14 Regression] wrong |at -O1 on x86_64-linux-gnu |code at -O1 on |(the generated code hangs) |x86_64-linux-gnu (the ||generated code hangs) --- Comment #4 from Andrew Pinski --- So with GCC 13, with `-fdump-tree-all-all`, we get the same wrong code as on the trunk. This is why I was I misunderstood thinking it was a target issue as I was comparing the dumps between GCC 13 and the trunk with -all enabled but it was broken in GCC 13 too. Anyways I tested GCC 12.3.0 and it looks to be working there. It would be useful to get another bisect done this time with `-O1 -fdump-tree-all-all` .
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #5 from Andrew Pinski --- The first difference (in GCC 13) with/without -fdump-tree-all-all comes from cunroll: Broken: ``` Loop 3 iterates 2 times. Loop 3 iterates at most 1 times. Loop 3 likely iterates at most 1 times. Analyzing # of iterations of loop 3 exit condition [2, + , 4294967295] != 0 bounds on difference of bases: -2 ... -2 result: # of iterations 2, bounded by 2 Removed pointless exit: if (ivtmp_43 != 0) ``` Working: ``` Loop 3 iterates 2 times. Loop 3 iterates at most 2 times. Loop 3 likely iterates at most 2 times. ```
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > The first difference (in GCC 13) with/without -fdump-tree-all-all comes from > cunroll: I should note that -fdump-tree-cunroll-all still produces the correct code generation for GCC 13 which makes this bug even odder.
[Bug lto/114790] New: ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790 Bug ID: 114790 Summary: ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 57994 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57994&action=edit ze.exports Initially reported downstream in Gentoo at https://bugs.gentoo.org/930199. ``` $ g++-14 -fPIC -O2 -flto=auto -shared -Wl,--version-script=ze.exports -o libze_intel_gpu.so.1.3.29138 tracing_imp.cpp.ii tracing_copy_imp.cpp.ii tracing_device_imp.cpp.ii /var/tmp/portage/dev-libs/intel-compute-runtime-24.13.29138.7/work/compute-runtime-24.13.29138.7/level_zero/experimental/source/tracing/tracing_copy_imp.cpp: In function ‘zeCommandListAppendMemoryCopyTracing’: /var/tmp/portage/dev-libs/intel-compute-runtime-24.13.29138.7/work/compute-runtime-24.13.29138.7/level_zero/experimental/source/tracing/tracing_copy_imp.cpp:41:35: error: direct call to releaseActivetracersList/1531 in speculative call sequence has no speculative flag 41 | return L0::apiTracerWrapperImp(driverDdiTable.coreDdiTable.CommandList.pfnAppendMemoryCopy, | ^ _ZN2L019apiTracerWrapperImpIPF12_ze_result_tP25_ze_command_list_handle_tPvPKvmP18_ze_event_handle_tjPS8_EP44_ze_command_list_append_memory_copy_params_tPFvSD_S1_S4_PS4_ESt6vectorINS_25APITracerCallbackStateImpISG_EESaISJ_EESL_JRS3_RS4_RS6_RmRS8_RjRS9_EEES1_T_T0_T1_T2_T3_DpOT4_.isra.0/10477 (apiTracerWrapperImp.isra) Type: function definition analyzed Visibility: artificial References: _ZN2L019APITracerContextImp24releaseActivetracersListEv/1531 (addr) (speculative) _ZTHN2L017tracingInProgressE/5374 (addr) _ZN2L017tracingInProgressE/1237 (write) _ZN2L025globalAPITracerContextImpE/1490 (addr) Referring: Read from file: /tmp/cciN484G.ltrans0.o Function apiTracerWrapperImp.isra/10477 is inline copy in zeCommandListAppendMemoryCopyTracing/3756 Availability: local Unit id: 3 Function flags: count:143044205 (estimated locally) body local Called by: zeCommandListAppendMemoryCopyTracing/3756 (inlined) (143044205 (estimated locally),0.50 per call) Calls: _ZN2L019APITracerContextImp24releaseActivetracersListEv/1531 (114435364 (estimated locally),0.40 per call) _ZNSt6vectorIPvSaIS0_EE6resizeEm.constprop.0/11584 (inlined) (143044205 (estimated locally),0.50 per call) (can throw external) _ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/10833 (inlined) (1157357666 (estimated locally),4.05 per call) (can throw external) _ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/4315 (inlined) (618839143 (estimated locally),2.16 per call) (can throw external) _ZNSt6vectorIPvSaIS0_EEixEm.isra.0/11478 (inlined) (618839143 (estimated locally),2.16 per call) _ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/11133 (inlined) (618839143 (estimated locally),2.16 per call) (can throw external) _ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/10733 (inlined) (1157357666 (estimated locally),4.05 per call) (can throw external) _ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/11033 (inlined) (618839143 (estimated locally),2.16 per call) (can throw external) _ZNSt6vectorIPvSaIS0_EEixEm.isra.0/11462 (inlined) (618839143 (estimated locally),2.16 per call) _ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/10933 (inlined) (618839143 (estimated locally),2.16 per call) (can throw external) _ZTHN2L017tracingInProgressE/5374 (76485736 (estimated locally),0.27 per call) (can throw external) _ZNSt12_Vector_baseIPvSaIS0_EED2Ev.isra.0/11539 (inlined) (143044205 (estimated locally),0.50 per call) _ZNSt12_Vector_baseIPvSaIS0_EED2Ev.isra.0/10508 (0 (precise),0.00 per call) Indirect call(618839143 (estimated locally),2.16 per call) (can throw external) num speculative call targets: 0 Indirect call(143044205 (estimated locally),0.50 per call) (can throw external) num speculative call targets: 0 Indirect call(618839143 (estimated locally),2.16 per call) (can throw external) num speculative call targets: 0 Indirect call(speculative) (28608841 (estimated locally),0.10 per call) (can throw external) num speculative call targets: 1 during IPA pass: inline /
[Bug lto/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790 --- Comment #1 from Sam James --- Created attachment 57995 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57995&action=edit tracing_imp.cpp.ii.xz
[Bug lto/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790 --- Comment #2 from Sam James --- Created attachment 57996 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57996&action=edit tracing_device_imp.cpp.ii.xz
[Bug lto/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790 --- Comment #3 from Sam James --- Created attachment 57997 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57997&action=edit tracing_copy_imp.cpp.ii.xz
[Bug ipa/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790 --- Comment #4 from Sam James --- I'm going to kick off a reduction but don't count on me either, as I hate doing LTO ones.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #39 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cb277dea557aaa25fdced201f7c45c753c709dfa commit r13-8623-gcb277dea557aaa25fdced201f7c45c753c709dfa Author: Jakub Jelinek Date: Tue Apr 2 13:40:27 2024 +0200 Fix up postboot dependencies [PR106472] On Wed, Mar 13, 2024 at 10:13:37AM +0100, Jakub Jelinek wrote: > While the first Makefile.tpl hunk looks obviously ok, the others look > completely wrong to me. > There is nothing special about libgo vs. libbacktrace/libatomic > compared to any other target library which is not bootstrapped vs. any > of its dependencies which are in the bootstrapped set. > So, Makefile.tpl shouldn't hardcode such dependencies. Here is my version of the fix. The dependencies in the toplevel Makefile simply didn't take into account that some target modules could be in a bootstrapped build built in some configurations as bootstrap modules (typically as dependencies of other target bootstrap modules), while in other configurations just as dependencies of non-bootstrap target modules and so not built during the bootstrap, but after it. Makefile.tpl arranges for those postboot target module -> target module dependencies to be emitted only inside of an @unless gcc-bootstrap block, while for @if gcc-bootstrap it just emits configure-target-whatever: stage_last dependencies which ensure those postbootstrap target modules are only built after everything that is bootstrapped has been. Now, the libbacktrace/libatomic target modules have bootstrap=true target_modules = { module= libbacktrace; bootstrap=true; }; target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; }; because those modules are dependencies of libphobos target module, so when d is included among bootstrapped languages, those are all bootstrapped and everything works correctly. While if d is not included, libphobos target module is disabled, libbacktrace/libatomic target modules aren't bootstrapped, nothing during bootstrap needs them, but post bootstrap libgo target module depends on the libatomic and libbacktrace target modules, libgfortran target module depends on the libbacktrace target module and libgm2 target module depends on the libatomic target module, but those dependencies were emitted only @unless gcc-bootstrap. There is a similar theoretical problem for zlib target module if GCJ would be ressurected, libphobos as bootstrap target module depends on the zlib target module, but if d is not configured, fastjar also depends on it. The following patch arranges for the @if gcc-bootstrap case to emit also target module -> target module dependencies, but conditionally on the on dependency not being bootstrapped. In the generated Makefile.in you can see what the Makefile.tpl change produces and that it just adds extra dependencies which weren't there before in the @if gcc-bootstrap case. I've bootstrapped without this patch with ../configure --enable-languages=c,c++,go; make on x86_64-linux (note, make -j2 or higher usually worked) which failed as described in the PR, then with this patch with the same command which built fine and the Makefile difference between the two builds being diff -up obj40{a,b}/Makefile --- obj40a/Makefile 2024-03-31 00:35:22.243791499 +0100 +++ obj40b/Makefile 2024-03-31 22:40:38.143299144 +0200 @@ -29376,6 +29376,14 @@ configure-bison: stage_last configure-flex: stage_last configure-m4: stage_last +configure-target-fastjar: maybe-configure-target-zlib +all-target-fastjar: maybe-all-target-zlib +all-target-libgo: maybe-all-target-libbacktrace +all-target-libgo: maybe-all-target-libatomic +all-target-libgm2: maybe-all-target-libatomic +configure-target-libgfortran: maybe-all-target-libbacktrace +configure-target-libgo: maybe-all-target-libbacktrace + # Dependencies for target modules on other target modules are # described by lang_env_dependencies; the defaults apply to anything which I believe are exactly the extra dependencies we want. Plus I've done normal x86_64-linux and i686-linux bootstraps/regtests which in my case include --enable-languages=default,ada,obj-c++,lto,go,d,rust,m2 for x86_64 and the same except ada for i686; those with my usual make -j32. The Makefile difference in those builds vs. unpatched case is just an extra empty line. 2024-04-02 Jakub Jelinek PR bootstrap/106472 * Makefile.tpl (make-postboot-target-dep): New lambda. Use it to add --enable-bootstrap dependencies of target modules on other target modules if the latter aren't bootstrapped. * Makefile.in: Regenerate.
[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cc39bd532d4de1ba0b2785246fb6fdd63ec2e92c commit r13-8625-gcc39bd532d4de1ba0b2785246fb6fdd63ec2e92c Author: Jakub Jelinek Date: Wed Apr 3 10:02:35 2024 +0200 libquadmath: Don't assume the storage for __float128 arguments is aligned [PR114533] With the register_printf_type/register_printf_modifier/register_printf_specifier APIs the C library is just told the size of the argument and is provided with a callback to fetch the argument from va_list using va_arg into C library provided memory. The C library isn't told what alignment requirement it has, but we were using direct load of a __float128 value from that memory which assumes __alignof (__float128) alignment. The following patch fixes that by using memcpy instead. I haven't been able to reproduce an actual crash, tried #include #include #include int main () { __float128 r; int prec = 20; int width = 46; char buf[128]; r = 2.0q; r = sqrtq (r); int n = quadmath_snprintf (buf, sizeof buf, "%+-#*.20Qe", width, r); if ((size_t) n < sizeof buf) printf ("%s\n", buf); /* Prints: +1.41421356237309504880e+00 */ quadmath_snprintf (buf, sizeof buf, "%Qa", r); if ((size_t) n < sizeof buf) printf ("%s\n", buf); /* Prints: 0x1.6a09e667f3bcc908b2fb1366ea96p+0 */ n = quadmath_snprintf (NULL, 0, "%+-#46.*Qe", prec, r); if (n > -1) { char *str = malloc (n + 1); if (str) { quadmath_snprintf (str, n + 1, "%+-#46.*Qe", prec, r); printf ("%s\n", str); /* Prints: +1.41421356237309504880e+00 */ } free (str); } printf ("%+-#*.20Qe\n", width, r); printf ("%Qa\n", r); printf ("%+-#46.*Qe\n", prec, r); printf ("%d %Qe %d %Qe %d %Qe\n", 1, r, 2, r, 3, r); return 0; } In any case, I think memcpy for loading from it is right. 2024-04-03 Simon Chopin Jakub Jelinek PR libquadmath/114533 * printf/printf_fp.c (__quadmath_printf_fp): Use memcpy to copy __float128 out of args. * printf/printf_fphex.c (__quadmath_printf_fphex): Likewise. Signed-off-by: Simon Chopin (cherry picked from commit 8455d6f6cd43b7b143ab9ee19437452fceba9cc9)
[Bug middle-end/114552] [13 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba6fd407891fd83648ad803c85b607dc09e23be4 commit r13-8624-gba6fd407891fd83648ad803c85b607dc09e23be4 Author: Jakub Jelinek Date: Wed Apr 3 09:59:45 2024 +0200 expr: Fix up emit_push_insn [PR114552] r13-990 added optimizations in multiple spots to optimize during expansion storing of constant initializers into targets. In the load_register_parameters and expand_expr_real_1 cases, it checks it has a tree as the source and so knows we are reading that whole decl's value, so the code is fine as is, but in the emit_push_insn case it checks for a MEM from which something is pushed and checks for SYMBOL_REF as the MEM's address, but still assumes the whole object is copied, which as the following testcase shows might not always be the case. In the testcase, k is 6 bytes, then 2 bytes of padding, then another 4 bytes, while the emit_push_insn wants to store just the 6 bytes. The following patch simply verifies it is the whole initializer that is being stored, I think that is best thing to do so late in GCC 14 cycle as well for backporting. For GCC 15, perhaps the code could stop requiring it must be at offset zero, nor that the size is equal, but could use get_symbol_constant_value/fold_ctor_reference gimple-fold APIs to actually extract just part of the initializer if we e.g. push just some subset (of course, still verify that it is a subset). For sizes which are power of two bytes and we have some integer modes, we could use as type for fold_ctor_reference corresponding integral types, otherwise dunno, punt or use some structure (e.g. try to find one in the initializer?), whatever. But even in the other spots it could perhaps handle loading of COMPONENT_REFs or MEM_REFs from the .rodata vars. 2024-04-03 Jakub Jelinek PR middle-end/114552 * expr.cc (emit_push_insn): Only use store_constructor for immediate_const_ctor_p if int_expr_size matches size. * gcc.c-torture/execute/pr114552.c: New test. (cherry picked from commit 03039744f368a24a452e4ea8d946e9c2cedaf1aa)
[Bug c++/114537] bit_cast does not work NSDMI of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a297f9bbb9611414fe48f6d61a8829bf5808bd2c commit r13-8626-ga297f9bbb9611414fe48f6d61a8829bf5808bd2c Author: Jakub Jelinek Date: Thu Apr 4 10:47:52 2024 +0200 fold-const: Handle NON_LVALUE_EXPR in native_encode_initializer [PR114537] The following testcase is incorrectly rejected. The problem is that for bit-fields native_encode_initializer expects the corresponding CONSTRUCTOR elt value must be INTEGER_CST, but that isn't the case here, it is wrapped into NON_LVALUE_EXPR by maybe_wrap_with_location. We could STRIP_ANY_LOCATION_WRAPPER as well, but as all we are looking for is INTEGER_CST inside, just looking through NON_LVALUE_EXPR seems easier. 2024-04-04 Jakub Jelinek PR c++/114537 * fold-const.cc (native_encode_initializer): Look through NON_LVALUE_EXPR if val is INTEGER_CST. * g++.dg/cpp2a/bit-cast16.C: New test. (cherry picked from commit 1baec8deb014b8a7da58879a407a4c00cdeb5a09)
[Bug c++/114634] [11/12/13 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2c85e8def0efd4b0d9d312a1f0cbbee332b4e0d1 commit r13-8633-g2c85e8def0efd4b0d9d312a1f0cbbee332b4e0d1 Author: Jakub Jelinek Date: Mon Apr 15 10:25:22 2024 +0200 attribs: Don't crash on NULL TREE_TYPE in diag_attr_exclusions [PR114634] The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions assumes that all decls must have types. I think it is better in something as unimportant as diag_attr_exclusions to be more robust, if there is no type, it can just diagnose exclusions on the DECL_ATTRIBUTES, like for types it only diagnoses it on TYPE_ATTRIBUTES. 2024-04-15 Jakub Jelinek PR c++/114634 * attribs.cc (diag_attr_exclusions): Set attrs[1] to NULL_TREE for decls with NULL TREE_TYPE. * g++.dg/ext/attrib68.C: New test. (cherry picked from commit 7ec54f5fdfec298812a749699874db4d6a7246bb)
[Bug sanitizer/114743] ICE in build_check_stmt at asan.cc:2707 while compiling gcc.dg/ubsan/pr112709-2.c with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cd8e2137462d9ae1723fa193b6062ec65d164457 commit r13-8634-gcd8e2137462d9ae1723fa193b6062ec65d164457 Author: Jakub Jelinek Date: Wed Apr 17 10:24:18 2024 +0200 asan: Don't instrument .ABNORMAL_DISPATCHER [PR114743] .ABNORMAL_DISPATCHER is currently the only internal function with ECF_NORETURN, and asan likes to instrument ECF_NORETURN calls by adding some builtin call before them, which breaks the .ABNORMAL_DISPATCHER discovery added in gsi_safe_*. The following patch fixes asan not to instrument .ABNORMAL_DISPATCHER calls, like it doesn't instrument a couple of specific builtin calls as well. 2024-04-17 Jakub Jelinek PR sanitizer/114743 * asan.cc (maybe_instrument_call): Don't instrument calls to .ABNORMAL_DISPATCHER. * gcc.dg/asan/pr112709-2.c (freddy): New function from gcc.dg/ubsan/pr112709-2.c version of the test. (cherry picked from commit 299d14a54672a4d12c1abbe4031a732bb56cddaa)
[Bug sanitizer/114687] [13 Regression] ICE: in edge_before_returns_twice_call, at gimple-iterator.cc:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a1a52934a2ab9ac9205a3a4d5b82a672fefba7e commit r13-8631-g7a1a52934a2ab9ac9205a3a4d5b82a672fefba7e Author: Jakub Jelinek Date: Fri Apr 12 10:59:54 2024 +0200 Limit special asan/ubsan/bitint returns_twice handling to calls in bbs with abnormal pred [PR114687] The tree-cfg.cc verifier only diagnoses returns_twice calls preceded by non-label/debug stmts if it is in a bb with abnormal predecessor. The following testcase shows that if a user lies in the attributes (a function which never returns can't be pure, and can't return twice when it doesn't ever return at all), when we figure it out, we can remove the abnormal edges to the "returns_twice" call and perhaps whole .ABNORMAL_DISPATCHER etc. edge_before_returns_twice_call then ICEs because it can't find such an edge. The following patch limits the special handling to calls in bbs where the verifier requires that. 2024-04-12 Jakub Jelinek PR sanitizer/114687 * gimple-iterator.cc (gsi_safe_insert_before): Only use edge_before_returns_twice_call if bb_has_abnormal_pred. (gsi_safe_insert_seq_before): Likewise. * gcc.dg/asan/pr114687.c: New test. (cherry picked from commit c9e94ae448ba309dba74de3ee1974a3ed9248889)
[Bug c/114780] Using C23 nullptr as sentinel gives missing sentinel warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e802786436851b1f5efca21a14d4f41c83c83f4f commit r13-8637-ge802786436851b1f5efca21a14d4f41c83c83f4f Author: Jakub Jelinek Date: Sat Apr 20 00:12:36 2024 +0200 c-family: Allow arguments with NULLPTR_TYPE as sentinels [PR114780] While in C++ the ellipsis argument conversions include "An argument that has type cv std::nullptr_t is converted to type void*" in C23 a nullptr_t argument is not promoted in any way, but va_arg description says: "the type of the next argument is nullptr_t and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type." So, while in C++ check_function_sentinel will never see NULLPTR_TYPE, for C23 it can see that and currently we incorrectly warn about those. The only question is whether we should warn on any argument with nullptr_t type or just about nullptr (nullptr_t argument with integer_zerop value). Through undefined behavior guess one could pass non-NULL pointer that way, say by union { void *p; nullptr_t q; } u; u.p = &whatever; and pass u.q to ..., but valid code should always pass something that will read as (char *) 0 when read using va_arg (ap, char *), so I think it is better not to warn rather than warn in those cases. Note, clang seems to pass (void *)0 rather than expression of nullptr_t type to ellipsis in C23 mode as if it did the C++ ellipsis argument conversions, in that case guess not warning about that would be even safer, but what GCC does I think follows the spec more closely, even when in a valid program one shouldn't be able to observe the difference. 2024-04-20 Jakub Jelinek PR c/114780 * c-common.cc (check_function_sentinel): Allow as sentinel any argument of NULLPTR_TYPE. * gcc.dg/format/sentinel-2.c: New test. (cherry picked from commit 2afdecccbaf5c5b1c7a235509b37092540906c02)
[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:910fa4d9df8f72d16279324cca2bf1f2649aa68b commit r13-8627-g910fa4d9df8f72d16279324cca2bf1f2649aa68b Author: Jakub Jelinek Date: Fri Apr 5 09:31:28 2024 +0200 c++: Fix ICE with weird copy assignment operator [PR114572] While ctors/dtors don't return anything (undeclared void or this pointer on arm) and copy assignment operators normally return a reference to *this, it isn't invalid to return uselessly some class object which might need destructing, but the OpenMP clause handling code wasn't expecting that. The following patch fixes that. 2024-04-05 Jakub Jelinek PR c++/114572 * cp-gimplify.cc (cxx_omp_clause_apply_fn): Call build_cplus_new on build_call_a result if it has class type. * testsuite/libgomp.c++/pr114572.C: New test. (cherry picked from commit 592536eb3c0a97a55b1019ff0216ef77e6ca847e)
[Bug c++/114691] [11/12/13 Regression] Bogus ignoring loop annotation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ed7be7ba6f125cfda7ad07263213cbe02b7e7ced commit r13-8632-ged7be7ba6f125cfda7ad07263213cbe02b7e7ced Author: Jakub Jelinek Date: Fri Apr 12 20:53:10 2024 +0200 c++: Fix bogus warnings about ignored annotations [PR114691] The middle-end warns about the ANNOTATE_EXPR added for while/for loops if they declare a var inside of the loop condition. This is because the assumption is that ANNOTATE_EXPR argument is used immediately in a COND_EXPR (later GIMPLE_COND), but simplify_loop_decl_cond wraps the ANNOTATE_EXPR inside of a TRUTH_NOT_EXPR, so it no longer holds. The following patch fixes that by adding the TRUTH_NOT_EXPR inside of the ANNOTATE_EXPR argument if any. 2024-04-12 Jakub Jelinek PR c++/114691 * semantics.cc (simplify_loop_decl_cond): Use cp_build_unary_op with TRUTH_NOT_EXPR on ANNOTATE_EXPR argument (if any) rather than ANNOTATE_EXPR itself. * g++.dg/ext/pr114691.C: New test. (cherry picked from commit 91146346f57cc54dfeb2669347edd0eb3d13af7f)
[Bug tree-optimization/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #18 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:38af0d59043da4cc07cd62c17da599e43668e3be commit r13-8628-g38af0d59043da4cc07cd62c17da599e43668e3be Author: Jakub Jelinek Date: Fri Apr 5 14:56:14 2024 +0200 vect: Don't clear base_misaligned in update_epilogue_loop_vinfo [PR114566] The following testcase is miscompiled, because in the vectorized epilogue the vectorizer assumes it can use aligned loads/stores (if the base decl gets alignment increased), but it actually doesn't increase that. This is because r10-4203-g97c1460367 added the hunk following patch removes. The explanation feels reasonable, but actually it is not true as the testcase proves. The thing is, we vectorize the main loop with 64-byte vectors and the corresponding data refs have base_alignment 16 (the a array has DECL_ALIGN 128) and offset_alignment 32. Now, because of the offset_alignment 32 rather than 64, we need to use unaligned loads/stores in the main loop (and ditto in the first load/store in vectorized epilogue). But the second load/store in the vectorized epilogue uses only 32-byte vectors and because it is a multiple of offset_alignment, it checks if we could increase alignment of the a VAR_DECL, the function returns true, sets base_misaligned = true and says the access is then aligned. But when update_epilogue_loop_vinfo clears base_misaligned with the assumption that the var had to have the alignment increased already, the update of DECL_ALIGN doesn't happen anymore. Now, I'd think this base_alignment = false was needed before r10-4030-gd2db7f7901 change was committed where it incorrectly overwrote DECL_ALIGN even if it was already larger, rather than just always increasing it. But with that change in, it doesn't make sense to me anymore. Note, the testcase is latent on the trunk, but reproduces on the 13 branch. 2024-04-05 Jakub Jelinek PR tree-optimization/114566 * tree-vect-loop.cc (update_epilogue_loop_vinfo): Don't clear base_misaligned. * gcc.target/i386/avx512f-pr114566.c: New test. (cherry picked from commit a844095e17c1a5aada1364c6f6eaade87ead463c)
[Bug c++/114580] Bogus warning on if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ae3b6dea0445f9650cf1a684527efac06497f1b4 commit r13-8629-gae3b6dea0445f9650cf1a684527efac06497f1b4 Author: Jakub Jelinek Date: Tue Apr 9 09:31:42 2024 +0200 c++: Fix up maybe_warn_for_constant_evaluated calls [PR114580] When looking at maybe_warn_for_constant_evaluated for the trivial infinite loops patch, I've noticed that it can emit weird diagnostics for if constexpr in templates, first warn that std::is_constant_evaluted() always evaluates to false (because the function template is not constexpr) and then during instantiation warn that std::is_constant_evaluted() always evaluates to true (because it is used in if constexpr condition). Now, only the latter is actually true, even when the if constexpr is in a non-constexpr function, it will still always evaluate to true. So, the following patch fixes it to call maybe_warn_for_constant_evaluated always with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument rather than true if it is if constexpr with non-dependent condition etc. 2024-04-09 Jakub Jelinek PR c++/114580 * semantics.cc (finish_if_stmt_cond): Call maybe_warn_for_constant_evaluated with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument, rather than true/false depending on if it is if constexpr with non-dependent constant expression with bool type. * g++.dg/cpp2a/is-constant-evaluated15.C: New test. (cherry picked from commit cfed80b9e4f562c99679739548df9369117dd791)
[Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 --- Comment #24 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a16d90ec302e588dab5d7d31ccdd7b3fd5c6214e commit r13-8630-ga16d90ec302e588dab5d7d31ccdd7b3fd5c6214e Author: Jakub Jelinek Date: Thu Apr 11 11:12:11 2024 +0200 asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027] On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote: > > > So, try to add some other variable with larger size and smaller alignment > > > to the frame (and make sure it isn't optimized away). > > > > > > alignb above is the alignment of the first partition's var, if > > > align_frame_offset really needs to depend on the var alignment, it probably > > > should be the maximum alignment of all the vars with alignment > > > alignb * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT > > > > > In asan_emit_stack_protection, when it allocated fake stack, it assume > bottom of stack is also aligned to alignb. And the place violated this > is the first var partition. which is 32 bytes offsets, it should be > BIGGEST_ALIGNMENT / BITS_PER_UNIT. > So I think we need to use MAX (BIGGEST_ALIGNMENT / > BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) for the first var partition. Your first patch aligned offsets[0] to maximum of alignb and ASAN_RED_ZONE_SIZE. But as I wrote in the reply to that mail, alignb there is the alignment of just a single variable which is the first one to appear in the sorted list and is placed in the highest spot in the stack frame. That is not necessarily the largest alignment, the sorting ensures that it is a variable with the largest size in the frame (and only if several of them have equal size, largest alignment from the same sized ones). Your second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using -mno-avx512f - offsets[0] is still just 32-byte aligned in that case relative to top of frame, just changes the -mavx512f case to be 64-byte aligned offsets[0] (aka offsets[0] is then either 0 or -64 instead of either 0 or -32). That will not help if any variable in the frame needs 128-byte, 256-byte, 512-byte ... 4096-byte alignment. If you want to fix the bug in the spot you've touched, you'd need to walk all the stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those where the loop would do anything (i.e. stack_vars[i2].representative == i2 && TREE_CODE (decl2) == SSA_NAME ? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX : DECL_RTL (decl2) == pc_rtx and the pred applies (but that means also walking the earlier ones! because with -fstack-protector* the vars can be processed in several calls) and alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT and compute maximum of those alignments. That maximum is already computed, data->asan_alignb = MAX (data->asan_alignb, alignb); computes that, but you get the final result only after you do all the expand_stack_vars calls. You'd need to compute it before. Though, that change would be still in the wrong place. The thing is, it would be a waste of the precious stack space when it isn't needed at all (e.g. when asan will not at compile time do the use after return checking, or if it won't do it at runtime, or even if it will do at runtime it will waste the space on the stack). The following patch fixes it solely for the __asan_stack_malloc_N allocations, doesn't enlarge unnecessarily further the actual stack frame. Because asan is only supported on FRAME_GROWS_DOWNWARD architectures (mips, rs6000 and xtensa are conditional FRAME_GROWS_DOWNWARD arches, which for -fsanitize=address or -fstack-protector* use FRAME_GROWS_DOWNWARD 1, otherwise 0, others supporting asan always just use 1), the assumption for the dynamic stack realignment is that the top of the stack frame (aka offset 0) is aligned to alignb passed to the function (which is the maximum of alignb of all the vars in the frame). As checked by the assertion in the patch, offsets[0] is 0 most of the time and so that assumption is correct, the only case when it is not 0 is if -fstack-protector* is on together with -fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack guard. That is the only variable which is allocated in the stack frame right away, for all others with -fsanitize=address defer_stack_allocation (or -fstack-protector*) returns true and so they aren't allocated immediately but handled during the frame layout phases. So, the original frame_offset of 0 is changed because of the stack guard to -pointer_size_in_bytes and later a
[Bug middle-end/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:10f689596ad1633f4f5de1852c8f82a993fe948e commit r13-8635-g10f689596ad1633f4f5de1852c8f82a993fe948e Author: Jakub Jelinek Date: Thu Apr 18 09:45:14 2024 +0200 internal-fn: Temporarily disable flag_trapv during .{ADD,SUB,MUL}_OVERFLOW etc. expansion [PR114753] __builtin_{add,sub,mul}_overflow{,_p} builtins are well defined for all inputs even for -ftrapv, and the -fsanitize=signed-integer-overflow ifns shouldn't abort in libgcc but emit the desired ubsan diagnostics or abort depending on -fsanitize* setting regardless of -ftrapv. The expansion of these internal functions uses expand_expr* in various places (e.g. MULT_EXPR at least in 2 spots), so temporarily disabling flag_trapv in all those spots would be hard. The following patch disables it around the bodies of 3 functions which can do the expand_expr calls. If it was in the C++ FE, I'd use some RAII sentinel, but I don't think we have one in the middle-end. 2024-04-18 Jakub Jelinek PR middle-end/114753 * internal-fn.cc (expand_mul_overflow): Save flag_trapv and temporarily clear it for the duration of the function, then restore previous value. (expand_vector_ubsan_overflow): Likewise. (expand_arith_overflow): Likewise. * gcc.dg/pr114753.c: New test. (cherry picked from commit 6c152c9db3b5b9d43e12846fb7a44977c0b65fc2)
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ab3b83afc149edda11fa3c7cbb3815606731003b commit r13-8636-gab3b83afc149edda11fa3c7cbb3815606731003b Author: Jakub Jelinek Date: Fri Apr 19 08:47:53 2024 +0200 rtlanal: Fix set_noop_p for volatile loads or stores [PR114768] On the following testcase, combine propagates the mem/v load into mem store with the same address and then removes it, because noop_move_p says it is a no-op move. If it was the other way around, i.e. mem/v store and mem load, or both would be mem/v, it would be kept. The problem is that rtx_equal_p never checks any kind of flags on the rtxes (and I think it would be quite dangerous to change it at this point), and set_noop_p checks side_effects_p on just one of the operands, not both. In the MEM <- MEM set, it only checks it on the destination, in store to ZERO_EXTRACT only checks it on the source. The following patch adds the missing side_effects_p checks. 2024-04-19 Jakub Jelinek PR rtl-optimization/114768 * rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM sets if src has side-effects or for stores into ZERO_EXTRACT if ZERO_EXTRACT operand has side-effects. * gcc.dg/pr114768.c: New test. (cherry picked from commit 9f295847a9c32081bdd0fe908ffba58e830a24fb)
[Bug analyzer/114791] New: analyzer: file-leak not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114791 Bug ID: 114791 Summary: analyzer: file-leak not detected Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: urs at akk dot org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Created attachment 57998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57998&action=edit minimal test case False negative -Wanalyzer-file-leak gcc build from git @ ef2392236ec629351496d7f299d6a0956080e4d9 gcc-14 -D_DEFAULT_SOURCE -Wall -Wextra -fanalyzer -O2 -v -save-temps -freport-bug -g -std=c11 -o fleak file-leak.c doesn't give a warning but it should (value of fp may be overwritten before released).
[Bug analyzer/114791] analyzer: file-leak not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114791 --- Comment #1 from Urs Janßen --- Created attachment 57999 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57999&action=edit preprocessed example
[Bug analyzer/114791] analyzer: file-leak not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114791 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Last reconfirmed||2024-04-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug analyzer/114791] analyzer: file-leak not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114791 --- Comment #3 from Urs Janßen --- Comment on attachment 57998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57998 minimal test case >#include >#include >#include >#include > >int main(void); > >int main(void) { >FILE *fp = (FILE *) 0; >int i = 0; >static const char *list[] = { "/tmp/", "/tmp/a", "/tmp/b", NULL }; >struct stat st; > >while (list[i] != NULL) { >if ((fp = fopen(list[i], "r")) != NULL) { should be if ((fp = fopen(list[i++], "r")) != NULL) { >if (fstat(fileno(fp), &st) != -1) { >if ((st.st_mode & (S_IFREG | S_IFLNK)) && st.st_size > 0L) >break; >} >/* missing: >fclose(fp); >fp = NULL; >here */ >} >} > >if (fp) >fclose(fp); >}
[Bug analyzer/114791] analyzer: file-leak not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114791 --- Comment #4 from Andrew Pinski --- Interesting, with -O0, there is a warning but that can be turned into a false positive if you enable the "missing:" section.