Wilco Dijkstra writes:
> Hi Richard,
>
>>> Essentially anything covered by HWCAP doesn't need an explicit check. So I
>>> kept
>>> the LS64 and PREDRES checks since they don't have a HWCAP allocated (I'm not
>>> entirely convinced we need these, let alone having 3 individual bits for
>>> LS64, b
Hi Richard,
>> Essentially anything covered by HWCAP doesn't need an explicit check. So I
>> kept
>> the LS64 and PREDRES checks since they don't have a HWCAP allocated (I'm not
>> entirely convinced we need these, let alone having 3 individual bits for
>> LS64, but
>> that's something for the A
Wilco Dijkstra writes:
> Hi Richard,
>
> I've reworded the commit message a bit:
>
> The CPU features initialization code uses CPUID registers (rather than
> HWCAP). The equality comparisons it uses are incorrect: for example FEAT_SVE
> is not set if SVE2 is available. Using HWCAPs for these is
Hi Richard,
I've reworded the commit message a bit:
The CPU features initialization code uses CPUID registers (rather than
HWCAP). The equality comparisons it uses are incorrect: for example FEAT_SVE
is not set if SVE2 is available. Using HWCAPs for these is both simpler and
correct. The initi
Wilco Dijkstra writes:
> Fix CPU features initialization. Use HWCAP rather than explicit accesses
> to CPUID registers. Perform the initialization atomically to avoid multi-
> threading issues.
Please describe the problem that the patch is fixing. I think the
PR description would make a better
Fix CPU features initialization. Use HWCAP rather than explicit accesses
to CPUID registers. Perform the initialization atomically to avoid multi-
threading issues.
Passes regress, OK for commit and backport?
libgcc:
PR target/115342
* config/aarch64/cpuinfo.c (__init_cpu_featu
