On Mon, Oct 5, 2026 at 12:55 PM Richard Earnshaw (foss) <[email protected]> wrote: > > On 01/10/2026 12:21, Richard Biener wrote: > > 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' :/ > > Yeah, given BITS_PER_UNIT, that's just bizarre. > > Wouldn't GET_MODE_ELEM_SIZE be a better name for a vector element?
I think most cases are just mistakes like the above but where it doesn't matter since for scalar modes GET_MODE_UNIT_SIZE == GET_MODE_SIZE ... So I'd support wiping out GET_MODE_UNIT_SIZE (41 uses!) and, as we have on the tree level only extern unsigned int element_precision (const_tree); extern machine_mode element_mode (const_tree); extern machine_mode vector_type_mode (const_tree); extern unsigned int vector_element_bits (const_tree); extern tree vector_element_bits_tree (const_tree); attempt to get away with GET_MODE_ELEM_BITSIZE? But I guess existing paths might be all always-scalar (and thus bogous use) or always-vector (replace with GET_MODE_SIZE (GET_MODE_INNER (..))) Richard. > > R. > > > > >> 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 >
