https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126844
Bug ID: 126844
Summary: gcc -march=native tuning defaults to baseline on
aarch64 systems with > 2 core types
Product: gcc
Version: 16.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: vivek at etla dot org
Target Milestone: ---
Created attachment 65324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65324&action=edit
/proc/cpuinfo from the system that revealed the bug
gcc -march=native tuning for an aarch64 system with 3 core types does not
curently work.
This is for three reasons:
- Commit 00c22ba69d8e738a4789b30165ff9c925c508fc1 introduced a regression
- Commit 06f64b95bafc06c318efc7b6d7c03cd34fe4be78 introduced a regression
- The aarch64 driver only allowed for two different core types
----
Problem 1: commit 00c22ba69d8e738a4789b30165ff9c925c508fc1 added a
leading 'V' to aarch64-arches.def names (so they could be used to
form valid C identifiers).
It also altered _most_ paths that inaspected those names to ignore
the new leading 'V', but it was not stripped from the call to
get_arch_from_id
in
host_detect_local_cpu in the -march path, which broke.
----
Problem 2: commit 06f64b95bafc06c318efc7b6d7c03cd34fe4be78 made
host_detect_local_cpu
give up if `processed_exts` was unset, but `processed_exts` was never
set if -mtune=… was passed
----
Problem 3: The aarch64 driver was only written to support 1 and 2 core type
setups (where a core type was defined by the implementer and part-id).
This was probably true when the driver was written, but there's at least
one shipping device with 3 core types.
----
This was discovered while testing on a system where there were 3 core types:
a520, a720, & x4.
I have written tests and fixes for these problems which I will attach now.
