Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp321117imn; Mon, 25 Jul 2022 17:52:23 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vFCCimjmvsbPslI9i/mXL/H6bhPqUki+FYOqEnxvaZKG/xQYIn8zsWNN5FAuCgjKpNlKcw X-Received: by 2002:a17:90b:380d:b0:1f2:2fb4:2e87 with SMTP id mq13-20020a17090b380d00b001f22fb42e87mr16534319pjb.13.1658796742921; Mon, 25 Jul 2022 17:52:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658796742; cv=none; d=google.com; s=arc-20160816; b=D22Kpi7j1nf9eE62ndmj+OItb2MiE827payqb1ZEJBW2QI26XK/jtpBnAgL3BSOVt4 Qau50oGWQrnf/HLAXZI2M15tewf1+xgEnMcjFlGEdQPDlOw9iGrAnfhR7iVYbhFVszzB gORI5nKvXeoMyqDcNWLRPjwSLNxcuRHZGNrCZ6cjUX1uf8sFDnj9E9tnNKs8Zd5UwJ6E OWjtOkDG/wNiJN8d+9ddFmWkkT87iAV8nezcNEhgHhwcRpURAk75D0DXEx8SL3KO1uEf KiRCwW8S/X/PO21jn6xDGI4UU3fmUS90D64izyxpxoiveb7cWghj1GsSDMaNqUaz5b+i iBYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=x1QoQ5IMLukzFE1NYwMzkU1nlwiC0d1CNPNg/XV68Ao=; b=CPmod5v2+QGxW5rhY/4jnd+iQrFQU0k5aa2iYWvoO/450o65cgsM3QoWvNVc1cx3G+ YYqJUruoa7+SnQlPDhL/0FhUNIk2IsXXFmKTMmjgTaa3FaGkUDxOZtmG8+Ss3LbNAn0y IedvmYLXpBW01VFsiY3cdACv6PIIYyCrD2hv++0Sb6c1ehmPTFGQVAxyQ0+tMr+sKtQv qIWI6cijadfaw6oyvCjxZBs6FCKvnqY90+0THMxTaMer7LayChEhPKLPqFczmtbPqsM7 gZSd2lVarT5QPz/uFZ+83PWrl8rRtJ3Hdjufw/8KiPP11fq2ALoi9f7o+1ip1LDTjZJX 8NnA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o15-20020a170902778f00b0016c4d8abcb2si13757058pll.423.2022.07.25.17.52.06; Mon, 25 Jul 2022 17:52:22 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230411AbiGZAhp (ORCPT + 99 others); Mon, 25 Jul 2022 20:37:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229755AbiGZAhn (ORCPT ); Mon, 25 Jul 2022 20:37:43 -0400 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1FA73237DA for ; Mon, 25 Jul 2022 17:37:39 -0700 (PDT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 26Q0VHtb006919; Mon, 25 Jul 2022 19:31:17 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 26Q0VFhh006916; Mon, 25 Jul 2022 19:31:15 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 25 Jul 2022 19:31:15 -0500 From: Segher Boessenkool To: Guenter Roeck Cc: Timothy Pearson , Linus Torvalds , Dan =?iso-8859-1?Q?Hor=E1k?= , linux-kernel , amd-gfx , Alex Deucher , linuxppc-dev Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc Message-ID: <20220726003115.GW25951@gate.crashing.org> References: <20220725123918.1903255-1-mpe@ellerman.id.au> <1446417444.13111032.1658777648586.JavaMail.zimbra@raptorengineeringinc.com> <20220725204217.GU25951@gate.crashing.org> <5ef016a9-c1bb-91dd-454d-504d26074477@roeck-us.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ef016a9-c1bb-91dd-454d-504d26074477@roeck-us.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On Mon, Jul 25, 2022 at 03:40:40PM -0700, Guenter Roeck wrote: > On 7/25/22 13:42, Segher Boessenkool wrote: > >>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. Look in the GCC toplevel configure.ac for (some of!) the actual rules (and some more in config.gcc, and there are more at different levels). If your target is not *-linux* you likely end up with a 64-bit long double by default, and if it is, you do. But it depends on various things configure can determine about your C library. buildall uses --without-headers, but something makes GCC still use 128-bit long double on powerpc64-linux, but it uses 64-bit on powerpc64le-linux. Curious. I suppose things work better on Linux userland when you do not use the spartan build flags buildall uses :-) If you set it explicitly (--with-long-double-128) it just works. > FWIW, depending on compiler build options such as the above for kernel > builds seems to be a little odd to me, Yes. It should be (and was!) possible to build the kernel with pretty much any compiler. Usual were *-linux* compilers of course, but *-elf also works, and for powerpc in particular any kind of biarch or not "just works". > 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. It always was the rule that the kernel did not use floating point at all. If that is changed it can no longer be built on targets that use soft float for example (they need libgcc, which the kernel build is allergic to for some reason). It is non-trivial to handle floating point in the kernel itself as well of course (mostly arch stuff). The problem here was that some objects are built with soft float and some with hard float, incompatible ABIs that ld does not want to link together (without further coercing). Segher