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: <5ef016a9-c1bb-91dd-454d-504d26074477@roeck-us.net>
Date:   Mon, 25 Jul 2022 15:40:40 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Segher Boessenkool <segher@...nel.crashing.org>,
        Timothy Pearson <tpearson@...torengineering.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dan HorĂ¡k <dan@...ny.cz>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        amd-gfx <amd-gfx@...ts.freedesktop.org>,
        Alex Deucher <alexdeucher@...il.com>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc

On 7/25/22 13:42, Segher Boessenkool wrote:
> On Mon, Jul 25, 2022 at 02:34:08PM -0500, Timothy Pearson 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...
> 
> The compiler emits the same code (DFmode things, double precision float)
> in both cases, and it itself does not see any difference anymore fairly
> early in the pipeline.  Compare to int and long on most 32-bit targets,
> both are SImode, the compiler will not see different types anymore:
> there *are* no types, except in the compiler frontend.
> 
> It only happens for powerpc64le things, and not for powerpc64 builds.
> 
> It is probably a GCC problem.  I don't see what forces the GCC build
> here to use 64-bit long double either btw?  Compilers build via buildall
> have all kinds of unnecessary things disabled, but not that, not
> directly at least.
> 

 From what little documentation I can find, there appears to be
"--with-long-double-128" and "--with-long-double-format=ieee".
That looks like something that would need to be enabled, not disabled.

FWIW, depending on compiler build options such as the above for kernel
builds seems to be a little odd to me, and I am not sure I'd want to
blame gcc if the kernel wants to be built with 128-bit floating point
as default. At the very least, that should be documented somewhere,
and if possible the kernel should refuse to build if the compiler build
options don't meet the requirements.

Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ