Bug 24080 - Definition of "haswell" platform is inconsistent with GCC
Summary: Definition of "haswell" platform is inconsistent with GCC
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: 2.33
Assignee: Florian Weimer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-10 05:52 UTC by Florian Weimer
Modified: 2020-12-04 08:49 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Weimer 2019-01-10 05:52:21 UTC
"haswell" is currently defined as:

      if (platform == NULL
	  && CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable)
	  && CPU_FEATURES_ARCH_P (cpu_features, FMA_Usable)
	  && CPU_FEATURES_CPU_P (cpu_features, BMI1)
	  && CPU_FEATURES_CPU_P (cpu_features, BMI2)
	  && CPU_FEATURES_CPU_P (cpu_features, LZCNT)
	  && CPU_FEATURES_CPU_P (cpu_features, MOVBE)
	  && CPU_FEATURES_CPU_P (cpu_features, POPCNT))
	platform = "haswell";

XSAVE, FXSR, MMX, SSE2 are probably implied.

On the GCC side, -march=haswell also has AES, RDRND, PCLMUL, XSAVEOPT, SSE3, SSE4_1, SSE4_2, SSSE3, HLE, F16C, FSGSBASE, CMPXCHG16B.

I think the glibc and GCC definitions need to be consistent.
Comment 1 Richard Biener 2019-09-09 07:55:00 UTC
IMHO adding "haswell" was a mistake (with this particular name).  Do we really
want to have gazillions of $arch directories to be searched, and in what
particular order if an "exact match" (define that!) is not found?  That's
especially difficult with Intels segmentation of SKUs where there's not
a clear ordering of architectures is possible if an exact match is not found.

I agree that "haswell" suggests you can put in -march=haswell binaries
(which you can't as you point out).

The directory should have been named avx2_fma_bmi12_lzcnt_movbe_popcnt.

Or rather binaries/libraries should use ifunc relocations because x86 is a mess.
Comment 2 Florian Weimer 2020-05-11 15:08:49 UTC
Somewhat relevant discussion: <https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html>

Fixes to "haswell" (under whatever name) would probably come under that new umbrella, with the existing selection remaining unchanged (until it is deprecated and then removed).
Comment 3 Florian Weimer 2020-12-04 08:49:16 UTC
I consider this fixed by:

commit f267e1c9dd7fb8852cc32d6eafd96bbcfd5cbb2b
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Dec 4 09:13:43 2020 +0100

    x86_64: Add glibc-hwcaps support
    
    The subdirectories match those in the x86-64 psABI:
    
    https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9a6b9396884b67c7c
    
    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

“x86-64-v3” is more or less a replacement for the “haswell” AT_PLATFORM subdirectory.