[Bug target/105932] New: Small structures returned incorrectly in i386 Microsoft ABI

Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Consider this C code: struct foo { int x, y; }; extern int x, y; struct foo f(void

[Bug c/105875] New: Toggling an atomic_bool is inefficient

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64-pc-linux-gnu Consider this C code: #include atomic_bool b; atomic_char c; _Bool b2; void f1(void) { b

[Bug c++/103091] New: Can't jump into scope of a variable with a nontrivial destructor in C++20

: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- The C++17 standard says "A program that jumps from a point where a var

[Bug debug/102442] Incorrect debug info for C89-style function parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102442 Joseph C. Sible changed: What|Removed |Added CC||josephcsible at gmail dot com

[Bug c++/101465] New: Poorly worded error from a call to a pointer-to-member function not wrapped in parentheses

Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Consider this C++ code: struct foo *x; void (foo::*myfuncptr)(); void f

[Bug c/101432] New: NULL dereferences aren't assumed to be unreachable even with -fdelete-null-pointer-checks -fno-isolate-erroneous-paths-dereference

Version: 11.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone

[Bug c/101358] New: Warn when saving a pointer to an object with temporary lifetime

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Consider this C code: typedef struct { int x[1]; } foo; foo f(void); int g(void) { int *p = f

[Bug middle-end/100861] False positive -Wmismatched-new-delete with destroying operator delete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861 --- Comment #2 from Joseph C. Sible --- Wait, if it's just checking whether the calls to operator new and operator delete match up, then why does adding "virtual ~Widget() {}" make the warning go away?

[Bug c++/100861] New: False positive -Wmismatched-new-delete with destroying operator delete

: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Currently, code like "Base *b = new Derived; delete b;" gives a -Wmismatched-new-dele

[Bug c++/91859] Using destroying delete should not clobber stores to the object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91859 --- Comment #5 from Joseph C. Sible --- The real problem mentioned in comment 2 still happens as of GCC 11.1. I've narrowed it down somewhat to the optimization flags "-Og -ftree-dse -ftree-pta". Removing any one of those will make it behave

[Bug c++/97820] New: VLAs in function declarations fail to compile

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Consider these 4 attempts at declaring a function: void f1(int rows, int cols, int arr[rows][cols]); void f2(int rows, int cols, int

[Bug tree-optimization/96468] Warn when an empty while loop could have been a do-while

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96468 --- Comment #5 from Joseph C. Sible --- I didn't have termination checking in mind at all for this. I envisioned the warning triggering any time a "while" loop's body was just a semicolon, when the "while" isn't the first statement in its block.

[Bug c/96468] Warn when an empty while loop could have been a do-while

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96468 --- Comment #3 from Joseph C. Sible --- I didn't intend to restrict this to only volatile control variables. If you have "_Bool canMoveOn(void);", I'd like "while(!canMoveOn());" in place of "while(!signaled);" to warn too for the exact same

[Bug c/96468] New: Warn when an empty while loop could have been a do-while

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Consider this C code: typedef int sig_atomic_t; volatile sig_atomic_t signaled; _Bool getX(int *); void

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 Joseph C. Sible changed: What|Removed |Added CC||josephcsible at gmail dot com

[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507 Joseph C. Sible changed: What|Removed |Added CC||josephcsible at gmail dot com

[Bug target/96289] New: Unnecessary saving and re-testing of the carry flag with __builtin_usub_overflow

Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64-linux-gnu Consider this C code: unsigned f(unsigned x, unsigned y

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96235 Joseph C. Sible changed: What|Removed |Added CC||josephcsible at gmail dot com

[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96245 Joseph C. Sible changed: What|Removed |Added CC||josephcsible at gmail dot com

[Bug target/96062] Partial register stall caused by avoidable use of SETcc, and useless MOVZBL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96062 --- Comment #2 from Joseph C. Sible --- (In reply to Uroš Bizjak from comment #1) > Just declare "_Bool carry". There is no need for int. While that indeed makes my first suggestion happen, it feels unsatisfying that doing so is necessary.

[Bug target/96062] New: Partial register stall caused by avoidable use of SETcc, and useless MOVZBL

: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64 Consider this C code: long ps4_syscall0(long n

[Bug ipa/96040] [10/11 Regression] Compiled code causes SIGBUS at -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040 --- Comment #2 from Joseph C. Sible --- Andrew Gierth posted this to the Lua mailing list: > I think I see what's happening here, but I don't think I have an account > on the gcc bug tracker to post it there (feel free to forward this). > It's

[Bug c/96040] New: Compiled code causes SIGBUS at -O2

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64-linux-gnu Consider this C code: int puts(const char *); int snprintf(char *, unsigned long, const char *, ...); unsigned long

[Bug target/95941] New: Passing a struct by value wastes 16 bytes on the stack

: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64-linux-gnu Consider this C code: extern struct foo { long x, y, z; } s; void f(struct

[Bug target/95791] New: Unnecessary vzeroupper when only using zmm16 through zmm31

-optimization, ssemmx Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64-linux-gnu Consider this C code: void f(void) { __asm__

[Bug target/95783] New: Inefficient use of the stack when a function takes the address of its argument

: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64-linux-gnu Consider this C code: void g(long

[Bug target/95732] Use CPU dispatching to support mixing -fcf-protection with -mindirect-branch and -mfunction-return

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95732 --- Comment #1 from Joseph C. Sible --- Thinking about this a bit more, it's a win for performance even if we ignore CET completely. In particular, it would let a single binary use retpolines only on CPUs that have the Spectre vulnerabilities

[Bug target/95732] New: Use CPU dispatching to support mixing -fcf-protection with -mindirect-branch and -mfunction-return

: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64 The thunks generated by -mindirect-branch and -mfunction-return

[Bug middle-end/95674] New: Unnecessary move when doing division-by-multiplication

: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- When GCC does division-by-multiplication, it seems to forget that multiplication is commutative. It moves

[Bug tree-optimization/95643] New: Optimizer fails to realize that a variable tested twice in a row is the same both times

Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Consider this code, compiled at -O3: extern int e; void

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121 --- Comment #3 from Joseph C. Sible --- Also, is that documented to work that way anywhere? I didn't notice anything in the manual to that effect.

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121 --- Comment #2 from Joseph C. Sible --- Does this mean that Clang is wrong, then? Because it works the way I wanted/expected.

[Bug inline-asm/95121] New: Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Consider this function: char f(void