[Bug target/86677] popcount builtin detection is breaking some kernel build

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Fri Oct 12 17:21:00 GMT 2018


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On October 12, 2018 6:57:44 PM GMT+02:00, "wilco at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
>
>Wilco <wilco at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>               CC|                            |wilco at gcc dot gnu.org
>
>--- Comment #6 from Wilco <wilco at gcc dot gnu.org> ---
>(In reply to rguenther@suse.de from comment #5)
>> On Wed, 10 Oct 2018, ktkachov at gcc dot gnu.org wrote:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
>> > 
>> > ktkachov at gcc dot gnu.org changed:
>> > 
>> >            What    |Removed                     |Added
>> >
>----------------------------------------------------------------------------
>> >                  CC|                            |ktkachov at gcc
>dot gnu.org
>> > 
>> > --- Comment #3 from ktkachov at gcc dot gnu.org ---
>> > GCC does disable some pattern recognition with
>> > -fno-tree-loop-distribute-patterns, which is implied by
>-ffreestanding (used by
>> > the kernel). Wouldn't it be consistent to disable this pattern
>recognition in
>> > that setup as well? popcount is not such a fundamental helper
>function like
>> > e.g. DImode shifts, after all
>> 
>> I am not against adding a new switch for this (not sure if we really
>> should overload -fno-tree-loop-distribute-patterns with this since
>> this will disable popcount recognition at anything below -O3).
>
>Would it not make sense to check that the popcount optab is implemented
>and
>enabled before using it? Calling a library function that does a similar
>loop
>will be slower than keeping the original loop.

Sure. There's a thread on gcc patches for this.


More information about the Gcc-bugs mailing list