On Thu, Oct 1, 2026 at 10:03 AM Torbjorn SVENSSON <[email protected]> wrote: > > > > On 2026-10-01 08:40, Richard Biener wrote: > > On Wed, Sep 30, 2026 at 8:06 PM Torbjorn SVENSSON > > <[email protected]> wrote: > >> > >> > >> > >> On 2026-09-30 10:01, Richard Biener wrote: > >>> On Tue, Sep 29, 2026 at 3:32 PM Torbjorn SVENSSON > >>> <[email protected]> wrote: > >>>> > >>>> > >>>> > >>>> On 2026-09-29 14:57, Richard Biener wrote: > >>>>> On Tue, Sep 29, 2026 at 9:52 AM Torbjorn SVENSSON > >>>>> <[email protected]> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2026-09-24 15:56, Richard Biener wrote: > >>>>>>> On Thu, Sep 24, 2026 at 3:34 PM Torbjorn SVENSSON > >>>>>>> <[email protected]> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2026-09-24 15:25, Richard Biener wrote: > >>>>>>>>> On Thu, Sep 24, 2026 at 2:24 PM Torbjorn SVENSSON > >>>>>>>>> <[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2026-09-23 15:40, Richard Biener wrote: > >>>>>>>>>>> On Wed, Sep 2, 2026 at 1:18 PM Torbjörn Svensson via Sourceware > >>>>>>>>>>> Forge > >>>>>>>>>>> <[email protected]> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> From: Torbjörn SVENSSON <[email protected]> > >>>>>>>>>>>> > >>>>>>>>>>>> vect_slp_v2qi_store_unalign tests whether the vectorizer handles > >>>>>>>>>>>> a V2QI > >>>>>>>>>>>> store through a byte-aligned base, but some -Wstringop-overflow > >>>>>>>>>>>> tests > >>>>>>>>>>>> instead depend on a V2QI store at a known one-byte misalignment > >>>>>>>>>>>> from a > >>>>>>>>>>>> defined object. > >>>>>>>>>>>> > >>>>>>>>>>>> These two variants are not the same on armv7ve with > >>>>>>>>>>>> -mfloat-abi=hard. > >>>>>>>>>>>> Add a separate effective target for the latter case. > >>>>>>>>>>> > >>>>>>>>>>> Can you again explain why they are not the same? I'm guessing > >>>>>>>>>>> it's > >>>>>>>>>>> about knowing the misalignment vs. unknown misalignment but then > >>>>>>>>>>> vect_slp_v2qi_store_misalign vs. _unalign is not obvious. Maybe > >>>>>>>>>>> _unknown_misalign vs. _known_misalign? But I'm still curious > >>>>>>>>>>> why a target choses to allow one but not the other (for stores > >>>>>>>>>>> there's > >>>>>>>>>>> no dr_explicit_realign[_optimized])? > >>>>>>>>>> > >>>>>>>>>> Unless I've completly missunderstood the sequence, it should stem > >>>>>>>>>> from > >>>>>>>>>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/arm.cc;hb=refs/heads/trunk#l30984 > >>>>>>>>>> > >>>>>>>>>> After another bisect, I identified that the first failing commit is > >>>>>>>>>> r16-4314-g5e9eecc6686 (for r16-4315 and later, > >>>>>>>>>> r16-4355-g53085a46e7f162 > >>>>>>>>>> is also needed to build). > >>>>>>>>>> > >>>>>>>>>> I think the reason for the regression is that the value of "align" > >>>>>>>>>> is > >>>>>>>>>> not the same for TYPE_ALIGN_UNIT(type) and > >>>>>>>>>> GET_MODE_UNIT_SIZE(mode). > >>>>>>>>>> > >>>>>>>>>> In the v2qi tests, mode would match HImode, thus: > >>>>>>>>>> > >>>>>>>>>> - GET_MODE_UNIT_SIZE(HImode) would return 2. > >>>>>>>>>> - TYPE_ALIGN_UNIT(type) would return 1 for char. > >>>>>>>>>> > >>>>>>>>>> So, maybe my patch is not correct and instead the function should > >>>>>>>>>> simply be like this since NEON apparently accepts unknown > >>>>>>>>>> alignment: > >>>>>>>>>> > >>>>>>>>>> static bool > >>>>>>>>>> arm_builtin_support_vector_misalignment (machine_mode mode, > >>>>>>>>>> int misalignment, > >>>>>>>>>> bool is_packed, > >>>>>>>>>> bool > >>>>>>>>>> is_gather_scatter) > >>>>>>>>>> { > >>>>>>>>>> if (TARGET_NEON && !BYTES_BIG_ENDIAN && unaligned_access) > >>>>>>>>>> { > >>>>>>>>>> HOST_WIDE_INT align = GET_MODE_UNIT_SIZE (mode); > >>>>>>>>>> > >>>>>>>>>> if (is_gather_scatter) > >>>>>>>>>> return true; > >>>>>>>>>> > >>>>>>>>>> if (is_packed) > >>>>>>>>>> return align == 1; > >>>>>>>>>> > >>>>>>>>>> /* NEON supports access regardless of the alignment. > >>>>>>>>>> */ > >>>>>>>>>> return true; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> return default_builtin_support_vector_misalignment (mode, > >>>>>>>>>> misalignment, > >>>>>>>>>> > >>>>>>>>>> is_packed, > >>>>>>>>>> > >>>>>>>>>> is_gather_scatter); > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> WDYT? > >>>>>>>>> > >>>>>>>>> Yeah, the current code is > >>>>>>>>> > >>>>>>>>> /* If the misalignment is unknown, we should be able to > >>>>>>>>> handle the access > >>>>>>>>> so long as it is not to a member of a packed data > >>>>>>>>> structure. */ > >>>>>>>>> if (misalignment == -1) > >>>>>>>>> return true; > >>>>>>>>> > >>>>>>>>> /* Return true if the misalignment is a multiple of the > >>>>>>>>> natural alignment > >>>>>>>>> of the vector's element type. This is probably > >>>>>>>>> always going to be > >>>>>>>>> true in practice, since we've already established > >>>>>>>>> that this isn't a > >>>>>>>>> packed access. */ > >>>>>>>>> return ((misalignment % align) == 0); > >>>>>>>>> > >>>>>>>>> which says it accepts any misalignment (misalignment == -1) but not > >>>>>>>>> a known misalignment, of say 3. That's just odd. > >>>>>>>>> > >>>>>>>>>> Also, the check "align == 1" in the is_packed branch is probably > >>>>>>>>>> not > >>>>>>>>>> doing the right thing since the value in "align" is the size(?) > >>>>>>>>>> and not > >>>>>>>>>> the alignment. > >>>>>>>>> > >>>>>>>>> yeah, a vector mode of size 1 probably does not exist. Iff we > >>>>>>>>> accept misalignment == -1 there's no reason to reject "is_packed". > >>>>>>>>> is_packed just means we cannot reach alignment by peeling. > >>>>>>>>> There's no good reason to check is_packed. > >>>>>>>> > >>>>>>>> So, based on this, maybe the function body could be reduced to: > >>>>>>>> > >>>>>>>> { > >>>>>>>> if (TARGET_NEON && !BYTES_BIG_ENDIAN && unaligned_access) > >>>>>>>> return true; > >>>>>>>> > >>>>>>>> return default_builtin_support_vector_misalignment (mode, > >>>>>>>> misalignment, > >>>>>>>> > >>>>>>>> is_packed, > >>>>>>>> > >>>>>>>> is_gather_scatter); > >>>>>>>> } > >>>>>>>> > >>>>>>>> I can do this change and do a regression test run on it to see if it > >>>>>>>> causes > >>>>>>>> any regressions if you think this is better. > >>>>>>> > >>>>>>> Looks reasonable. Note the aarch64 variant does > >>>>>>> > >>>>>>> if (TARGET_SIMD && STRICT_ALIGNMENT) > >>>>>>> { > >>>>>>> if (is_gather_scatter) > >>>>>>> return true; > >>>>>>> > >>>>>>> /* Return if movmisalign pattern is not supported for this > >>>>>>> mode. */ > >>>>>>> if (optab_handler (movmisalign_optab, mode) == > >>>>>>> CODE_FOR_nothing) > >>>>>>> return false; > >>>>>>> > >>>>>>> /* Misalignment factor is unknown at compile time. */ > >>>>>>> if (misalignment == -1) > >>>>>>> return false; > >>>>>>> } > >>>>>>> return default_builtin_support_vector_misalignment (mode, > >>>>>>> misalignment, > >>>>>>> is_packed, > >>>>>>> > >>>>>>> is_gather_scatter); > >>>>>>> > >>>>>>> so basically defaults for !STRICT_ALIGNMENT. I suppose the equivalent > >>>>>>> is unaligned_access > >>>>>>> on the arm side. Compared to your variant with 'return true' it falls > >>>>>>> through to the > >>>>>>> default (which tests for movmisalign support of the mode). So if arm > >>>>>>> can do that for all > >>>>>>> vector modes a return true sounds good, if not, fallthru to the > >>>>>>> default hook looks safer. > >>>>>> > >>>>>> I tried to use the aarch64 approach, but replaced TARGET_SIMD with > >>>>>> TARGET_NEON. > >>>>>> This works for the test in question, but it causes other regressions > >>>>>> for the > >>>>>> vect-early-break. > >>>>>> Then I tried to simply return true for any TARGET_NEON, same result. > >>>>>> > >>>>>> After having tried all these ways, I got lazy and simply asked AI if > >>>>>> it was > >>>>>> possible to solve this without having the "type" parameter and the > >>>>>> conclusion > >>>>>> it gave me was: > >>>>>> > >>>>>> There is no generic way for this hook to exactly reproduce > >>>>>> `TYPE_ALIGN_UNIT(type)` from only `mode`, `misalignment`, and the > >>>>>> flags: two > >>>>>> accesses can have the same hook arguments but different element-type > >>>>>> alignment. > >>>>>> The broad NEON `return true` passes `Wstringop-overflow-2.c` but adds > >>>>>> four > >>>>>> `vect-early-break` failures. The mode-unit rule with an HImode > >>>>>> adjustment still > >>>>>> adds those failures; the full comparison is also affected by different > >>>>>> non-GCC > >>>>>> components in the prebuilt baseline versus this build. > >>>>>> > >>>>>> > >>>>>> I think it's safe to say that this might be an unsolvable problem. > >>>>> > >>>>> But what matters for the target is the mode, not the type. So IMO the > >>>>> AI is misleading > >>>>> here or the vectorizer asks for a non-natural aligned vector type > >>>>> which it should not. > >>>> > >>>> I'm not so worried about the diagnostic part of the failure, but I > >>>> presume that this > >>>> function also controls what code that might be generated. Thus, this > >>>> could potentially > >>>> lead to wrong code or suboptimal code. > >>>> Obvious, I would like the failure to go away since it's about 160 > >>>> fail/xpass for these > >>>> 2 tests. > >>>> > >>>> What would you say is the next step to figure out what is going wrong > >>>> here? > >>>> > >>>> In r16-4314-g5e9eecc6686, I see that riscv might also have a similar > >>>> problem based on > >>>> this change: > >>>> > >>>> { > >>>> /* If we know that misalignment is a multiple of the element > >>>> size, we're > >>>> good. */ > >>>> - if (misalignment % TYPE_ALIGN_UNIT (type) == 0) > >>>> + if (misalignment % (GET_MODE_UNIT_SIZE (mode)) == 0) > >>>> return true; > >>>> } > >>>> > >>>> Have you heard anyone in the riscv gang that noticed a problem here? > >>> > >>> Oh, but that is changing misalignment % alignment for misalignment % size > >>> (which is more conservative). I'd expect TYPE_ALIGN and > >>> GET_MODE_ALIGNMENT > >>> to agree (also size!) and if you put an assert to that near the > >>> single(?) caller of the > >>> hook that should never fire. > >>> > >>> Does it for the testcases you point out regress? > >> > >> Sorry, but it can't even get that far... > >> > >> I used r16-4313-gb52a90e7a03fef as a baseline and added this change on top: > >> > >> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc > >> index 8b951f3d4a6..0ec5eca0497 100644 > >> --- a/gcc/config/arm/arm.cc > >> +++ b/gcc/config/arm/arm.cc > >> @@ -30670,6 +30670,9 @@ arm_builtin_support_vector_misalignment > >> (machine_mode mode, > >> { > >> HOST_WIDE_INT align = TYPE_ALIGN_UNIT (type); > >> > >> + HOST_WIDE_INT mode_unit_size = GET_MODE_UNIT_SIZE (mode); > >> + gcc_assert (align == mode_unit_size); > > > > That's not what I suggested. You were suggesting to re-instantiate > > the 'type' argument > > which was removed as redundant, so I suggested to assert type and mode size > > and > > alignment agree, not that alignment and size agree. > > Oh, sorry. I misunderstood your request. > > > I did another run with this change on top of the same commit: > > diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc > index 8b951f3d4a6..1ac4140cc22 100644 > --- a/gcc/config/arm/arm.cc > +++ b/gcc/config/arm/arm.cc > @@ -30670,6 +30670,26 @@ arm_builtin_support_vector_misalignment > (machine_mode mode, > { > HOST_WIDE_INT align = TYPE_ALIGN_UNIT (type); > > + HOST_WIDE_INT mode_align = GET_MODE_ALIGNMENT (mode); > + HOST_WIDE_INT mode_unit_size = GET_MODE_UNIT_SIZE (mode); > + HOST_WIDE_INT mode_size = GET_MODE_SIZE (mode); > + HOST_WIDE_INT type_size = tree_to_shwi (TYPE_SIZE (type)); > + HOST_WIDE_INT type_unit_size = tree_to_shwi (TYPE_SIZE_UNIT (type)); > + if (mode_size * BITS_PER_UNIT != type_size || mode_unit_size != > type_unit_size) > + { > + fprintf (stderr, "mode_unit_size = " HOST_WIDE_INT_PRINT_DEC > + ", mode_size = " HOST_WIDE_INT_PRINT_DEC > + ", mode_align = " HOST_WIDE_INT_PRINT_DEC > + ", type_unit_size = " HOST_WIDE_INT_PRINT_DEC > + ", type_size = " HOST_WIDE_INT_PRINT_DEC > + ", type_align_unit = " HOST_WIDE_INT_PRINT_DEC > + "\n", > + mode_unit_size, mode_size, mode_align, > + type_unit_size, type_size, align); > + fflush(stderr); > + abort(); > + } > + > if (is_gather_scatter) > return true; > > > > and the result is (while building newlib for the arm-none-eabi toolchain): > > CC libm/math/libm_a-k_rem_pio2.o > mode_unit_size = 4, mode_size = 16, mode_align = 64, type_unit_size = 4, > type_size = 32, type_align_unit = 4
GET_MODE_SIZE is in bytes, there's also GET_MODE_BITSIZE. GET_MODE_UNIT_SIZE is, I think, the size of a vector component (so GET_MODE_SIZE (GET_MODE_INNER (...))) in bytes, it's very confusing use of 'UNIT' :/ > during GIMPLE pass: vect > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/newlib/newlib/libm/math/k_rem_pio2.c: > In function '__kernel_rem_pio2': > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/newlib/newlib/libm/math/k_rem_pio2.c:166:13: > internal compiler error: in arm_builtin_support_vector_misalignment, at > config/arm/arm.cc:30690 > 166 | int __kernel_rem_pio2(double *x, double *y, int e0, int nx, > int prec, const __int32_t *ipio2) > | ^~~~~~~~~~~~~~~~~ > 0x1b8ddc9 internal_error(char const*, ...) > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/diagnostic-global-context.cc:786 > 0x6f5939 fancy_abort(char const*, int, char const*) > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/diagnostics/context.cc:1803 > 0x113ecf1 arm_builtin_support_vector_misalignment > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/config/arm/arm.cc:30690 > 0x1ac6fae vect_supportable_dr_alignment(vec_info*, dr_vec_info*, tree_node*, > int, bool) > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-data-refs.cc:6643 > 0x1ac9229 vect_enhance_data_refs_alignment(_loop_vec_info*) > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-data-refs.cc:2565 > 0x1055ee5 vect_analyze_loop_2 > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-loop.cc:2408 > 0x1056c4d vect_analyze_loop_1 > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-loop.cc:2888 > 0x10573e7 vect_analyze_loop(loop*, gimple*, vec_info_shared*) > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-loop.cc:3069 > 0x10a313b try_vectorize_loop_1 > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vectorizer.cc:1097 > 0x10a313b try_vectorize_loop > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vectorizer.cc:1217 > 0x10a3a14 execute > > /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vectorizer.cc:1331 > Please submit a full bug report, with preprocessed source (by using > -freport-bug). > Please include the complete backtrace with any bug report. > See <https://gcc.gnu.org/bugs/> for instructions. > Makefile:38578: recipe for target 'libm/math/libm_a-k_rem_pio2.o' failed > make[6]: *** [libm/math/libm_a-k_rem_pio2.o] Error 1 > > > > >> + > >> if (is_gather_scatter) > >> return true; > >> > >> > >> When I try to build newlib with this (just building a full arm-none-eabi > >> toolchain), I get the following ICE: > >> > >> CC libc/stdlib/libc_a-arc4random.o > >> during GIMPLE pass: slp > >> /build/r16-4313-gb52a90e7a03fef/src/newlib/newlib/libc/stdlib/arc4random.c: > >> In function '_rs_stir': > >> /build/r16-4313-gb52a90e7a03fef/src/newlib/newlib/libc/stdlib/arc4random.c:94:1: > >> internal compiler error: in arm_builtin_support_vector_misalignment, at > >> config/arm/arm.cc:30674 > >> 94 | _rs_stir(void) > >> | ^~~~~~~~ > >> 0x1b8dcb9 internal_error(char const*, ...) > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/diagnostic-global-context.cc:786 > >> 0x6f5939 fancy_abort(char const*, int, char const*) > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/diagnostics/context.cc:1803 > >> 0x113ebfc arm_builtin_support_vector_misalignment > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/config/arm/arm.cc:30674 > >> 0x1ac6e9e vect_supportable_dr_alignment(vec_info*, dr_vec_info*, > >> tree_node*, int, bool) > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-data-refs.cc:6643 > >> 0x10187a6 get_load_store_type > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-stmts.cc:2343 > >> 0x102c1f3 vectorizable_load > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-stmts.cc:9448 > >> 0x103b23e vect_analyze_stmt(vec_info*, _slp_tree*, _slp_instance*, > >> vec<stmt_info_for_cost, va_heap, vl_ptr>*) > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-stmts.cc:12665 > >> 0x108d8e7 vect_slp_analyze_node_operations_1 > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8065 > >> 0x108d8e7 vect_slp_analyze_node_operations > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8334 > >> 0x108d857 vect_slp_analyze_node_operations > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8311 > >> 0x108f6eb vect_slp_analyze_operations(vec_info*) > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8738 > >> 0x1094e35 vect_slp_analyze_bb_1 > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:9785 > >> 0x1094e35 vect_slp_region > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:9832 > >> 0x1095e6d vect_slp_bbs > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:10055 > >> 0x10964eb vect_slp_function(function*) > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:10177 > >> 0x10a04fe execute > >> > >> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vectorizer.cc:1568 > >> Please submit a full bug report, with preprocessed source (by using > >> -freport-bug). > >> Please include the complete backtrace with any bug report. > >> See <https://gcc.gnu.org/bugs/> for instructions. > >> Makefile:22030: recipe for target 'libc/stdlib/libc_a-arc4random.o' failed > >> > >> > >> Does this give you any ideas? > >> > >> Would it help to provide the scalar_mode along with the machine_mode to > >> arm_builtin_support_vector_misalignment in any way? > > Is this still on the table, or is this a bad idea? > > Kind regards, > Torbjörn
