From: Michael Ellerman <mpe@ellerman.id.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dan@danny.cz, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, tpearson@raptorengineering.com,
alexdeucher@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux@roeck-us.net
Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc
Date: Tue, 26 Jul 2022 10:56:07 +1000 [thread overview]
Message-ID: <87k080bsk8.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <CAHk-=wihON4Ytte5zLHWNQtTapUvCpkToxY06OjX-_2B+Gq6Gg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Jul 25, 2022 at 5:39 AM Michael Ellerman <mpe@ellerman.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?
There's one or two uses, but not in any code that's relevant to this
issue AFAICS.
> 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.
It doesn't seem to matter if you use long double or not. It's just that
if the long double size is 64-bits the linker refuses to link a mixture
of soft/hard-float objects.
The 64-bit ABI says long double is 128-bits, so the compilers that are
using 64-bit long double are either not built correctly, or we are not
passing the correct flags to them.
There's an -mlong-double-128 flag which we can pass at build time which
seems to do the right thing, I will probably add that to the kernel
CFLAGS, but I want that to get a bit more testing.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linuxppc-dev@lists.ozlabs.org, alexdeucher@gmail.com,
amd-gfx@lists.freedesktop.org, linux@roeck-us.net,
linux-kernel@vger.kernel.org, dan@danny.cz,
tpearson@raptorengineering.com
Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc
Date: Tue, 26 Jul 2022 10:56:07 +1000 [thread overview]
Message-ID: <87k080bsk8.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <CAHk-=wihON4Ytte5zLHWNQtTapUvCpkToxY06OjX-_2B+Gq6Gg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Jul 25, 2022 at 5:39 AM Michael Ellerman <mpe@ellerman.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?
There's one or two uses, but not in any code that's relevant to this
issue AFAICS.
> 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.
It doesn't seem to matter if you use long double or not. It's just that
if the long double size is 64-bits the linker refuses to link a mixture
of soft/hard-float objects.
The 64-bit ABI says long double is 128-bits, so the compilers that are
using 64-bit long double are either not built correctly, or we are not
passing the correct flags to them.
There's an -mlong-double-128 flag which we can pass at build time which
seems to do the right thing, I will probably add that to the kernel
CFLAGS, but I want that to get a bit more testing.
cheers
next prev parent reply other threads:[~2022-07-26 12:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 12:39 [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc Michael Ellerman
2022-07-25 12:39 ` Michael Ellerman
2022-07-25 15:45 ` Dan Horák
2022-07-25 15:45 ` Dan Horák
2022-07-25 18:12 ` Deucher, Alexander
2022-07-25 19:19 ` Linus Torvalds
2022-07-25 19:19 ` Linus Torvalds
2022-07-25 19:34 ` Timothy Pearson
2022-07-25 19:34 ` Timothy Pearson
2022-07-25 19:34 ` Timothy Pearson
2022-07-25 20:42 ` Segher Boessenkool
2022-07-25 20:42 ` Segher Boessenkool
2022-07-25 22:40 ` Guenter Roeck
2022-07-25 22:40 ` Guenter Roeck
2022-07-26 0:31 ` Segher Boessenkool
2022-07-26 0:31 ` Segher Boessenkool
2022-07-26 0:47 ` Michael Ellerman
2022-07-26 0:56 ` Michael Ellerman [this message]
2022-07-26 0:56 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k080bsk8.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dan@danny.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=torvalds@linux-foundation.org \
--cc=tpearson@raptorengineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.