Add -mbmi flag to Abseil for GCC versions greater than 14.

[fruffy]

No description provided.

[vlstill]

This is quite weird. The BMI (bit manipulation instructions) seems to have been introduced in Intel Haswell. While that is 11 years old now, there are definitely computers running older HW still present around. I would expect GCC to be able lower the builtin to something else without the -mbmi. If we compiler with -mbmi we risk users hitting invalid instruction.

[vlstill]

This is quite confusing. There is a GCC issue saying this builtin (__builtin_ctzs) will not be added: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789. Yet apparently the compiler used on fedore somehow reports it has it, even when it does not actually: https://github.com/abseil/abseil-cpp/blob/master/absl/numeric/internal/bits.h#L306C23-L306C37.

[vlstill]

Also, GCC 14 is not yet released officially. I don't think we should be testing with it. Are we using a released version of Fedora?

[vlstill]

Yep, fedora 40 is shipping unreleased GCC version. Too bad abseil does not have any way to override the check.

[ChrisDodd]

Not clear why only fedora gives this error -- the default target for gcc on most machines is generic x86_64 (ie, no additional extensions over what was in the original), so it would not be using or requiring bmi instructions before. Has something changed with abseil such that it does thing with shorts that weren't being done before? We use __builtin_ctz in our bitvec code, but only for int/long/long long, not for short

[fruffy]

This is quite weird. The BMI (bit manipulation instructions) seems to have been introduced in Intel Haswell. While that is 11 years old now, there are definitely computers running older HW still present around. I would expect GCC to be able lower the builtin to something else without the -mbmi. If we compiler with -mbmi we risk users hitting invalid instruction.

It could be the CI infrastructure changing. I can add a flag that this is only added with GCC >14 and some checks. First, I need to get this to work at all.

[fruffy]

I do not understand how changing the flags for Abseil can cause -werror to be set for ubpf program compilation. I guess -Wno-error was set previously?

[fruffy]

This PR is ready now. The fix to the failing uBPF programs is in #4644.

[asl]

@fruffy This smells like a mainline bug. Not sure where, actually. But maybe start with Abseil?

[fruffy]

@fruffy This smells like a mainline bug. Not sure where, actually. But maybe start with Abseil?

abseil/abseil-cpp#1664 but unclear whether things will be resolved there.

[asl]

@fruffy This smells like a mainline bug. Not sure where, actually. But maybe start with Abseil?

abseil/abseil-cpp#1664 but unclear whether things will be resolved there.

Thanks! Yes, let's see what is there. IIRC -march=native was not quite compatible with arm64/clang, but it's only for GCC, so I'd guess we are fine for now.

[vlstill]

Maybe add a cmake warning there? This could produce surprise incompatibilities in the binary. And it might not be that far in future before someone tries to build a release binary with GCC 14.

[vlstill]

Also it might be good to reference the abseil issue in a comment here. Hopefully we will be able to remove this hack in future.

[vlstill]

#4643 make me think about this a bit more. I suggest enabling just the minimal set of flags (i.e. -mbmi) for the GCC 14 case. We should still try to preserve as much compatibility as we can.

[vlstill]

Looks good to me now. I just suggest a minor extension of the warning.