On Tue, Mar 31, 2026 at 06:19:49PM +0700, John Naylor wrote:
> I've only checked paths with objdump and debugging printouts (no perf
> testing), but this seems to work in v3. My main concern now is whether
> it's a maintenance hazard to overwrite CFLAGS_CRC in a separate check.
>
> In master, we can have one of:
>
> CFLAGS_CRC=""
> CFLAGS_CRC="-march=armv8-a+crc+simd"
> CFLAGS_CRC="-march=armv8-a+crc"
>
> ...and then based on that we set either USE_ARMV8_CRC32C or
> USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK, and set PG_CRC32C_OBJS.
>
> But below that, v3 runs a new test for pmull instructions with the
> flag "-march=armv8-a+crc+simd+crypto" and if it links, it will reset
> CFLAGS_CRC to that set of flags. That doesn't seem like the right
> thing to do, but I don't see a good alternative. I suppose I could
> sidestep that with function attributes, but that's not as well
> supported. Another idea would be to turn the relevant line here
>
> if test x"$Ac_cachevar" = x"yes"; then
> CFLAGS_CRC="$1"
> pgac_arm_pmull_intrinsics=yes
> fi
>
> ...into CFLAGS_CRC="CFLAGS_CRC$1", where in this case $1 is just
> "+crypto". That seems even more fragile, though.
Appending +crypto to the current CFLAGS_CRC seems like the right thing to
do to me. I'm trying to understand why you are concerned about fragility.
I suppose someone could add something else between the existing checks and
the one you're adding that appends a different option or something, but
besides that, I'd think merely appending +crypto to the -march value
wouldn't invalidate previous tests or anything like that.
--
nathan
