[Bug target/70557] uint64_t zeroing on 32-bit hardware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/70557] uint64_t zeroing on 32-bit hardware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #7 from Andreas Schwab --- When compiling for m68k the compiler already generates the latter.

[Bug target/70557] uint64_t zeroing on 32-bit hardware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #6 from Jakub Jelinek --- In that case it is a backend enhancement request. Backends have many ways how to deal with this, starting from specialized patterns, or using the lower subreg passes, using their own splitters etc. and many

[Bug target/70557] uint64_t zeroing on 32-bit hardware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #5 from Albert Cahalan --- This example shows the most simple form of the problem: unsigned long long ull; void simple64(void){ ull = 0; } NOTE: In the assembly below, I might have missing/excess parentheses. Assembler

[Bug target/70557] uint64_t zeroing on 32-bit hardware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #4 from Albert Cahalan --- Mostly it's more like PR58741 because of the long long issue. PR22141 (and PR23684 which is a better match) is about merging small things. Two of the six examples here show that problem, those being the

[Bug target/70557] uint64_t zeroing on 32-bit hardware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3

[Bug target/70557] uint64_t zeroing on 32-bit hardware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Richard Biener changed: What|Removed |Added Keywords||missed-optimization