[Bug target/111557] New: [RISC-V] The macro __riscv_unaligned_fast should be __riscv_misaligned_fast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111557 Bug ID: 111557 Summary: [RISC-V] The macro __riscv_unaligned_fast should be __riscv_misaligned_fast Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: no

[Bug target/111555] New: [AArch64] __ARM_FEATURE_UNALIGNED should be undefined with -mstrict-align

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555 Bug ID: 111555 Summary: [AArch64] __ARM_FEATURE_UNALIGNED should be undefined with -mstrict-align Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: no

[Bug middle-end/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 --- Comment #5 from Lasse Collin --- If I understood correctly, PR 50417 is about wishing that GCC would infer that a pointer given to memcpy has alignment higher than one. In my examples the alignment of the uint8_t *b argument is one and thus

[Bug target/111502] Suboptimal unaligned 2/4-byte memcpy on strict-align targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 --- Comment #2 from Lasse Collin --- Byte access by default is good when the compiler doesn't know if unaligned is fast on the target processor. There is no disagreement here. What I suspect is a bug is the instruction sequence used for byte ac

[Bug tree-optimization/111502] New: Suboptimal unaligned 2/4-byte memcpy on strict-align targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502 Bug ID: 111502 Summary: Suboptimal unaligned 2/4-byte memcpy on strict-align targets Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal