public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations
@ 2023-10-10 5:20 kuzume at axell dot co.jp
2023-10-10 5:24 ` [Bug target/111755] " pinskia at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: kuzume at axell dot co.jp @ 2023-10-10 5:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
Bug ID: 111755
Summary: The built-in memset function in GCC inadvertently
generates code like "vst1.8 {d8-d9}, [sp:64]", which
assumes an 8-byte alignment on the stack pointer $sp,
leading to alignment violations
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kuzume at axell dot co.jp
Target Milestone: ---
The built-in memset function in GCC inadvertently generates code like
"vst1.8 {d8-d9}, [sp:64]"
which assumes an 8-byte alignment on the stack pointer $sp, leading to
alignment violations.
While the issue can be temporarily circumvented using the -fno-builtin-memset
option to inhibit the use of the built-in functions, the stack pointer $sp is
4-byte aligned during C function calls. This might be a bug related to GCC's
built-in function handling.
By the way, the problem can also be resolved by generating assembly listings
without alignment specification, like "vst1.8 {d8-d9}, [sp]". Although, from an
alignment perspective, this is not the optimal performance solution.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations
2023-10-10 5:20 [Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations kuzume at axell dot co.jp
@ 2023-10-10 5:24 ` pinskia at gcc dot gnu.org
2023-10-10 5:49 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 5:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-10-10
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations.
Isn't that the ABI?
What target is this for?
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations
2023-10-10 5:20 [Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations kuzume at axell dot co.jp
2023-10-10 5:24 ` [Bug target/111755] " pinskia at gcc dot gnu.org
@ 2023-10-10 5:49 ` pinskia at gcc dot gnu.org
2023-10-10 6:11 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 5:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also can you attach the testcase where this happens?
Please read https://gcc.gnu.org/bugs/ on what information we need.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations
2023-10-10 5:20 [Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations kuzume at axell dot co.jp
2023-10-10 5:24 ` [Bug target/111755] " pinskia at gcc dot gnu.org
2023-10-10 5:49 ` pinskia at gcc dot gnu.org
@ 2023-10-10 6:11 ` pinskia at gcc dot gnu.org
2023-10-12 9:03 ` kuzume at axell dot co.jp
2023-10-12 15:46 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 6:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The ARM EABI says the stack is always aligned to 8 byte so unless you change
GCC to be do this, this is exacted and the incoming stack needs to be aligned
correctly.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations
2023-10-10 5:20 [Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations kuzume at axell dot co.jp
` (2 preceding siblings ...)
2023-10-10 6:11 ` pinskia at gcc dot gnu.org
@ 2023-10-12 9:03 ` kuzume at axell dot co.jp
2023-10-12 15:46 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: kuzume at axell dot co.jp @ 2023-10-12 9:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
--- Comment #4 from kuzume <kuzume at axell dot co.jp> ---
I apologize, but I will retract this report. I've realized that the IRQ handler
call of a certain RTOS I'm using is invoking with $sp as a multiple of 4, not
8. This violates the ARM ABI convention.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations
2023-10-10 5:20 [Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations kuzume at axell dot co.jp
` (3 preceding siblings ...)
2023-10-12 9:03 ` kuzume at axell dot co.jp
@ 2023-10-12 15:46 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-12 15:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-10-12 15:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-10 5:20 [Bug c/111755] New: The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment violations kuzume at axell dot co.jp
2023-10-10 5:24 ` [Bug target/111755] " pinskia at gcc dot gnu.org
2023-10-10 5:49 ` pinskia at gcc dot gnu.org
2023-10-10 6:11 ` pinskia at gcc dot gnu.org
2023-10-12 9:03 ` kuzume at axell dot co.jp
2023-10-12 15:46 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).