This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Fix recent popcount change is breaking
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Kugan Vivekanandarajah <kugan dot vivekanandarajah at linaro dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 10 Jul 2018 08:42:23 -0600
- Subject: Re: [RFC] Fix recent popcount change is breaking
- References: <CAELXzTOijCYcUUuhUjvsXQMDahdYRx4RhHWGjeAAz5FiHRvW+A@mail.gmail.com> <CAFiYyc07h=+N9O5_iZFL_euup1P+8S_c2PoUpWKyH6CS4HMWWg@mail.gmail.com>
On 07/10/2018 07:17 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> <email@example.com> wrote:
>> Jeff told me that the recent popcount built-in detection is causing
>> kernel build issues as
>> ERROR: "__popcountsi2"
>> [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined!
>> I could also reproduce this. AFIK, we should check if the libfunc is
>> defined while checking popcount?
>> I am testing the attached RFC patch. Is this reasonable?
> It doesn't work that way, all targets have this libfunc in libgcc. This means
> the kernel has to provide it. The only thing you could do is restrict
> replacement of CALL_EXPRs (in SCEV cprop) to those the target
> natively supports.
I can certainly live with that, but I think we should reach out to the
kernel developers to proactively make them aware of the requirement to