[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