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

2025-03-11 Thread lis8215 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #13 from Siarhei Volkau --- Moreover, I think that the patches deal for limited possible cases. E.g. if upper or lower part of DI memory shall be set to zero the patch won't help. It seems feasible to make a special code path for zer

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

2025-03-11 Thread lis8215 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #12 from Siarhei Volkau --- Hi Jeffrey, Thanks for your interest in those patches. But unfortunately I'm not sure that I can and will pass all required steps to make these patches ready for review. I have no experience with the RV32

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

2025-03-02 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #11 from Jeffrey A. Law --- Siarhei, it's fine to attach potential patches to bugzilla entries, but once you're ready for them to be reviewed and potentially integrated, they really need to be posted to gcc-patches. They are highly

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

2024-12-24 Thread lis8215 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #10 from Siarhei Volkau --- Created attachment 59965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59965&action=edit MIPS patch Ditto for 32-bit MIPS. MIPS emits: move$3,$0 move$2,$0 sw $3

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

2024-12-24 Thread lis8215 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Siarhei Volkau changed: What|Removed |Added CC||lis8215 at gmail dot com --- Comment #9

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

2020-04-18 Thread law at redhat dot com
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

2016-09-13 Thread sch...@linux-m68k.org
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

2016-04-06 Thread jakub at gcc dot gnu.org
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

2016-04-06 Thread acahalan at gmail dot com
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 synta

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

2016-04-06 Thread acahalan at gmail dot com
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 one

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

2016-04-06 Thread jakub at gcc dot gnu.org
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

2016-04-06 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Component|