Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 25 Jul 2022 14:34:08 -0500 (CDT)
From:   Timothy Pearson <tpearson@raptorengineering.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Michael Ellerman <mpe@ellerman.id.au>,
        linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
        Alex Deucher <alexdeucher@gmail.com>,
        amd-gfx <amd-gfx@lists.freedesktop.org>, linux@roeck-us.net,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Dan =?utf-8?Q?Hor=C3=A1k?= <dan@danny.cz>
Message-ID: <1446417444.13111032.1658777648586.JavaMail.zimbra@raptorengineeringinc.com>
In-Reply-To: <CAHk-=wihON4Ytte5zLHWNQtTapUvCpkToxY06OjX-_2B+Gq6Gg@mail.gmail.com>
References: <20220725123918.1903255-1-mpe@ellerman.id.au> <CAHk-=wihON4Ytte5zLHWNQtTapUvCpkToxY06OjX-_2B+Gq6Gg@mail.gmail.com>
Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: drm/amdgpu: Re-enable DCN for 64-bit powerpc
Thread-Index: bYJinp50nUzyW/1gBugq0G+Et27Ikw==
Precedence: bulk


----- Original Message -----
> From: "Linus Torvalds" <torvalds@linux-foundation.org>
> To: "Michael Ellerman" <mpe@ellerman.id.au>
> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>, "Alex Deucher" <alexd=
eucher@gmail.com>, "amd-gfx"
> <amd-gfx@lists.freedesktop.org>, linux@roeck-us.net, "linux-kernel" <linu=
x-kernel@vger.kernel.org>, "Dan Hor=C3=A1k"
> <dan@danny.cz>, "Timothy Pearson" <tpearson@raptorengineering.com>
> Sent: Monday, July 25, 2022 2:19:57 PM
> Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc

> On Mon, Jul 25, 2022 at 5:39 AM Michael Ellerman <mpe@ellerman.id.au> wro=
te:
>>
>> Further digging shows that the build failures only occur with compilers
>> that default to 64-bit long double.
>=20
> Where the heck do we have 'long double' things anywhere in the kernel?
>=20
> I tried to grep for it, and failed miserably. I found some constants
> that would qualify, but they were in the v4l colorspaces-details.rst
> doc file.
>=20
> Strange.

We don't, at least not that I can see.  The affected code uses standard dou=
bles.

What I'm wondering is if the compiler is getting confused between standard =
and long doubles when they are both the same bit length...