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
