linux-kernel - Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1446417444.13111032.1658777648586.JavaMail.zimbra@raptorengineeringinc.com>
Date:   Mon, 25 Jul 2022 14:34:08 -0500 (CDT)
From:   Timothy Pearson <tpearson@...torengineering.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Michael Ellerman <mpe@...erman.id.au>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        Alex Deucher <alexdeucher@...il.com>,
        amd-gfx <amd-gfx@...ts.freedesktop.org>, linux@...ck-us.net,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Dan Horák <dan@...ny.cz>
Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc



----- Original Message -----
> From: "Linus Torvalds" <torvalds@...ux-foundation.org>
> To: "Michael Ellerman" <mpe@...erman.id.au>
> Cc: "linuxppc-dev" <linuxppc-dev@...ts.ozlabs.org>, "Alex Deucher" <alexdeucher@...il.com>, "amd-gfx"
> <amd-gfx@...ts.freedesktop.org>, linux@...ck-us.net, "linux-kernel" <linux-kernel@...r.kernel.org>, "Dan Horák"
> <dan@...ny.cz>, "Timothy Pearson" <tpearson@...torengineering.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@...erman.id.au> wrote:
>>
>> Further digging shows that the build failures only occur with compilers
>> that default to 64-bit long double.
> 
> Where the heck do we have 'long double' things anywhere in the kernel?
> 
> 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.
> 
> Strange.

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

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