https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124577
Bug ID: 124577
Summary: ARMv7: Default -ftree-slp-vectorize at -O2 may
generate unaligned stores without explicit user
awareness, risking runtime failures on systems without
unaligned access support
Product: gcc
Version: 14.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangxuezhi2 at huawei dot com
Target Milestone: ---
Environment:
GCC Version: 14
Target: ARMv7 (-march=armv7-a -mtune=cortex-a15)
Optimization: -O2 (enables -ftree-slp-vectorize by default)
goldbolt url:https://godbolt.org/z/Y4h7fWWd5
I encountered a case where GCC 14 (with -O2 -march=armv7-a -mtune=cortex-a15)
generates an unaligned store instruction when compiling the following code:
~~~c
#include <stdio.h>
#include <stdint.h>
#include <math.h>
#define M_common (0 << 16)
#define M_common_NULL_POINTER (M_common | 7)
#define U32 unsigned int
#define U8 unsigned char
#define U16 unsigned short
typedef struct tagCPBSP_SYSTIME {
U16 uwYear;
U8 ucMonth; /* 1-12 */
U8 ucDate; /* 1-31 */
U8 ucHour; /* 0-23 */
U8 ucMinute; /* 0-59 */
U8 ucSecond; /* 0-59 */
U8 ucWeek; /* 0-6 */
} CPBSP_SYSTIME_STRU;
typedef struct tagSYSTEM_TIME {
U32 ulYear;
U32 ulMonth;
U32 ulDay;
U32 ulHour;
U32 ulMinute;
U32 ulSecond;
} SYSTEM_TIME_STRU;
U32 CPBSP_GetBoardTime(CPBSP_SYSTIME_STRU *pstrBoardTime) {
SYSTEM_TIME_STRU rtcTime = {0};
U8 week = 0;
U32 ret = 0;
if (NULL == pstrBoardTime) {
return M_common_NULL_POINTER;
}
pstrBoardTime->uwYear = (U16)rtcTime.ulYear;
pstrBoardTime->ucMonth = (U8)rtcTime.ulMonth;
pstrBoardTime->ucDate = (U8)rtcTime.ulDay;
pstrBoardTime->ucHour = (U8)rtcTime.ulHour;
pstrBoardTime->ucMinute = (U8)rtcTime.ulMinute;
pstrBoardTime->ucSecond = (U8)rtcTime.ulSecond;
pstrBoardTime->ucWeek = (U8)week;
return ret;
}
~~~
The resulting assembly includes an unaligned store (str r2, [r3, #2] @
unaligned):
~~~txt
CPBSP_GetBoardTime:
subs r3, r0, #0
beq .L3
mov r2, #0
mov r0, r2
strh r2, [r3] @ movhi
str r2, [r3, #2] @ unaligned ; <-- Unaligned store
strh r2, [r3, #6] @ movhi
bx lr
.L3:
mov r0, #7
bx lr
~~~
This unaligned store is generated due to the default enabling of
-ftree-slp-vectorize at -O2 in GCC 14. However, users may not be aware of this
optimization, and if their runtime environment (e.g., certain ARM systems) does
not support unaligned memory accesses, it could lead to runtime failures (e.g.,
alignment faults).
Here are my questions:
1. Awareness of Memory Type: For ARM targets, the compiler cannot automatically
discern whether user-allocated memory is normal memory (which may tolerate
unaligned access) or device memory (which often requires strict alignment).
Default optimizations that introduce unaligned accesses might be too
aggressive, especially when the target hardware constraints are unknown. Should
GCC consider being more conservative by default for architectures like ARMv7
where unaligned support is not universal?
2. Compiler’s Ability to Detect Alignment Constraints: Can the compiler’s
awareness of alignment issues only rely on data types and user-provided
attributes (e.g., aligned)? Is it feasible to deeper integrate knowledge about
the hardware system’s alignment requirements during compilation?
3. If -munaligned-access is enabled by default for ARMv7-A, ARMv7-R, ARMv7-M,
and ARMv8 architecture-based processors, is this behavior somewhat aggressive?
Thank you for your insights!
