[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384 Andi Kleen changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099 Bug 85099 depends on bug 63384, which changed state. Bug 63384 Summary: scheduler loops on endless fence list with -fselective-scheduling2 on x86 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384 What|Removed

[Bug tree-optimization/115484] [13/14/15 regression] if-to-switch prevents AVX vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484 --- Comment #6 from Andi Kleen --- As an interesting but irrelevant side comment clang seems to have the same bug.

[Bug bootstrap/115584] Boot strap comparison failure on trunk with --enable-checking=release

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115584 Andi Kleen changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug bootstrap/115584] New: Boot strap comparison failure on trunk with --enable-checking=release

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115584 Bug ID: 115584 Summary: Boot strap comparison failure on trunk with --enable-checking=release Product: gcc Version: unknown Status: UNCONFIRMED Severity:

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #14 from Andi Kleen --- Latest patchkit is here, but stalled due to lack of reviewers: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653319.html

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496 --- Comment #6 from Andi Kleen --- Yes a # check would need to be target dependent.

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496 --- Comment #3 from Andi Kleen --- When writing inline assembler an alternative to \n is to use ; as separator e.g. asm("movl $1,%eax ; " "movl %eax,%ebx") there can be also comment mistake here like asm("movl $1,%eax # comment ;"

[Bug c/115496] RFE: new warning to detect suspicious multline string literals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496 --- Comment #2 from Andi Kleen --- It would need some heuristic that if the line nearly fills a standard line length (how defined) don't trigger it. Otherwise people breaking the string due to line length restrictions might trigger it

[Bug tree-optimization/115484] New: AVX vectorization is limited to 3 comparisons

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484 Bug ID: 115484 Summary: AVX vectorization is limited to 3 comparisons Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug rtl-optimization/113723] switch (jump) tables don't get along with -freorder-blocks-and-partition on non-x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org ---

[Bug middle-end/63556] gcc should dedup string postfixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556 --- Comment #7 from Andi Kleen --- I'm not sure how it would speed up the linker if gcc did it. The linker would still need to do it because there might be matches between different .o files. Also linker wouldn't know if the compiler supported

[Bug c++/68615] Unhelpful location when missing a semi-colon on a function declaration at the end of a header

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68615 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment

[Bug c/82013] better error message for missing semicolon in prototype

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82013 Andi Kleen changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED

[Bug target/80742] attribute target no- does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80742 Andi Kleen changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING

[Bug middle-end/63556] gcc should dedup string postfixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556 Andi Kleen changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW

[Bug rtl-optimization/30688] Branch registers loaded too late on ia64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30688 Andi Kleen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug lto/80379] Redundant note: code may be misoptimized unless -fno-strict-aliasing is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80379 --- Comment #5 from Andi Kleen --- This bug is about printing a unnecessary message. If your code is actually miscompiled even with -fno-strict-aliasing set (so it is ignored somewhere) it is something different and you would need a test case to

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 --- Comment #7 from Andi Kleen --- The patch can be even more minimized. The thumb2_reorg change is not needed because nothing does df_verify() after it (I just noticed it because I added some extra for debugging). So even though thumb2_reorg

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 --- Comment #6 from Andi Kleen --- Created attachment 58324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58324=edit patch to fix arm sibcalls with -O0 Better patch that uses the existing cfun flag for tail calls.

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 --- Comment #4 from Andi Kleen --- Created attachment 58323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58323=edit hack patch to fix arm sibcalls at -O0 The attached patch makes the test case pass on arm. - Some of the sibcall

[Bug target/115255] New: sibcall at -O0 causes ICE in df_refs_verify on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 Bug ID: 115255 Summary: sibcall at -O0 causes ICE in df_refs_verify on arm Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/115091] New: Support value speculation in frontend

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091 Bug ID: 115091 Summary: Support value speculation in frontend Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug gcov-profile/113765] ICE: autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765 --- Comment #3 from Andi Kleen --- -O1 fixes it, so an easy patch would be diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc index 63d0c3dc36df..180ed7a8260f 100644 --- a/gcc/auto-profile.cc +++ b/gcc/auto-profile.cc @@ -1758,7 +1758,7

[Bug gcov-profile/113765] autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765 --- Comment #1 from Andi Kleen --- Seems to be a regression, I tested the same setup on gcc 13 and the test passes there: 55:PASS: gcc.dg/tree-prof/val-profiler-threads-1.c compilation, -fprofile-generate -D_PROFILE_GENERATE 59:PASS:

[Bug gcov-profile/113765] New: autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765 Bug ID: 113765 Summary: autofdo: val-profiler-threads-1.c compilation, error: probability of edge from entry block not initialized Product: gcc Version: unknown

[Bug lto/107779] Support implicit references from inline assembler to compiler symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779 --- Comment #4 from Andi Kleen --- This whole manual annotation idea (which is equivalent to marking the symbols global and visible and that is what a large part of the kernel LTO patchkit) is dead on arrival because the kernel people already

[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 --- Comment #5 from Andi Kleen --- config/i386/i386.h:#define SLOW_BYTE_ACCESS 0 You mean it doesn't define it?

[Bug middle-end/111743] shifts in bit field accesses don't combine with other shifts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 --- Comment #2 from Andi Kleen --- Okay then it doesn't understand that SHL_signed and SHR_unsigned can be combined when one the values came from a shorter unsigned.

[Bug middle-end/111743] New: shifts in bit field accesses don't combine with other shifts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743 Bug ID: 111743 Summary: shifts in bit field accesses don't combine with other shifts Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug lto/107779] New: Support implicit references from inline assembler to compiler symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779 Bug ID: 107779 Summary: Support implicit references from inline assembler to compiler symbols Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug lto/107014] flatten+lto fails the kernel build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org ---

[Bug preprocessor/45227] libcpp Makefile does not enable instrumentation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227 --- Comment #5 from Andi Kleen --- I think it was the method from the info file. But I can't quite remember. If you cannot reproduce it I guess it's ok to close. Maybe I made some mistake.

[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment

[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #3 from Andi Kleen --- So what do you want to fix in the kernel? Use a wrapper for taking the address of the memcpy? (I hope nothing in gcc would remove such a wrapper)