This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Fix recent popcount change is breaking
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Kugan Vivekanandarajah <kugan dot vivekanandarajah at linaro dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Tue, 10 Jul 2018 15:27:10 +0200
- Subject: Re: [RFC] Fix recent popcount change is breaking
- References: <CAELXzTOijCYcUUuhUjvsXQMDahdYRx4RhHWGjeAAz5FiHRvW+A@mail.gmail.com> <CAFiYyc07h=+N9O5_iZFL_euup1P+8S_c2PoUpWKyH6CS4HMWWg@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> > 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.
Yeah, that is what we've done in the past in other cases, e.g. PR82981
is somewhat similar. So perhaps just check the optab and use it only if it