Bug 200671

Summary:	Linux kernel build fails with gcc trunk
Product:	Other	Reporter:	Kugan (kuganv)
Component:	Other	Assignee:	other_other
Status:	NEW ---
Severity:	normal	CC:	aspriel, kuganv, mliska, will.deacon
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.10.3	Subsystem:
Regression:	No	Bisected commit-id:

Description Kugan 2018-07-27 23:34:07 UTC

Building Linux arm64 kernel with latest gcc trunk results in build error:

ERROR: "__popcountsi2"
[drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined!

This is because gcc now detects __builtin_popcount patterns for optimisation.

When it is not provided by the backend (with the appropriate md pattern in gcc), libgcc provides the optimized implementation.

Since the kernel is not linked with libgcc, it is expected that the kernel provides this.

Please refer to the gcc discussion at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677

Comment 1 Will Deacon 2018-10-18 12:45:15 UTC

Whilst providing an implementation of __popcountsi2 will fix the build, won't this end up with worse code generation compared to a compiler which doesn't do this idiom recognition?

If I understand this correctly, an in-line integer popcount implementation in the code can be spotted by the compiler and replaced  by a branch to an out-of-line integer popcount implementation.

Please can we have an option to disable this idiom recognition? It really doesn't seem to make sense in an environment where the SIMD registers aren't readily accessible.

Comment 2 Kugan 2018-11-27 00:51:29 UTC

GCC trunk, as of now, do not detect popcount buitins if the back end does not defines popcount. I have committed the changes to GCC so that Linux kernel builds fine. This primarily done because there isn't much (or no) benefit in-terms of performance in those cases. However, gcc plans to enable this when optimizing for size (there is still code size benefit) in the next GCC development cycle.