From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 894DB385800B for ; Thu, 28 Jul 2022 11:09:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 894DB385800B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.93,196,1654588800"; d="scan'208";a="80453147" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 28 Jul 2022 03:09:07 -0800 IronPort-SDR: ymaFgzFrIDC2MohtX8A4OdIZuSuRoL7U8UyU3XBVJfM+oOWtzGs+uTJHpR88DZ4INQzNKF4501 dn6B6UZd9rOmxe1WLXmPkSEy5X3UUGXrhL/WMSvoOZGSHIKGI5ozpnewmKNIxKok0XpjCHuRnm jPYaKFcHkZAhgTDpOD3mQb1OEIa3y4hQaSb+Vr5FjQrhurm2mqyNoHQLm1SdjeSmT6UUpF/8Tz +r51BYUMvG4+hM7IC4nFYVTxlJQX77EMyixMENhcsTfdwsWgDqra2SrHLtp2fW3GrGBGnao6g0 kAc= From: Thomas Schwinge To: Philip Herron CC: , Philip Herron , SimplyTheOther Subject: Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64 In-Reply-To: References: <20220727134040.843750-1-philip.herron@embecosm.com> <20220727134040.843750-3-philip.herron@embecosm.com> <878roda5f5.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Thu, 28 Jul 2022 13:08:59 +0200 Message-ID: <8735ellcj8.fsf@dem-tschwing-1.ger.mentorg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 11:09:10 -0000 Hi Phil! On 2022-07-28T11:51:37+0100, Philip Herron wro= te: > I think you are right here. There are parts in > libstd/liballoc/libpanic which start to look for what CPU features are > available iirc. Aha, good. That -- once we get there ;-) -- shall then guide us on the target options we implement, in addition to what we find generally necessary for a conforming Rust programming language implementation (as I'd mentioned). > libcore [...] just > cares about target pointer width and endienness which is more > generally available as macros. Right, and these are already implemented in 'gcc/rust/rust-session-manager.cc:Session::init'. (..., but also should get some test cases added; I'll have a look at some point.) > It seems more clear now that maybe for this v1 set of patches, > possibly this stuff doesn't really matter right now until we compile > libstd which seems like a much better approach in order to review the > front-end code. I think i will apply your patch and revert these > changes for now since we have the git history for them we can look at > this more closely when we need it. Unless this issue is time-critical, let me offer that instead of my "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'", I'll cook up a proper patch, removing the implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc., but keeping the general infrastructure in place (if I find that makes sense)? Gr=C3=BC=C3=9Fe Thomas > On Thu, 28 Jul 2022 at 11:38, Thomas Schwinge w= rote: >> >> Hi! >> >> On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" wrote: >> > This patch introduces a new set of interfaces to define the target inf= o as >> > expected by the rust front-end. It takes advantage of the information >> > within gcc/config/target directories which gets called by the front-en= d >> > to populate rust front-end datastructures by calling into: >> > builtin_rust_info. This patch has been isolated to find if we are >> > approaching this in an idiomatic way and is compilable without the >> > rust-front-end code. >> >> I suppose the general approach may be fine, as is similarly implemented >> by other languages' front ends in GCC. >> >> > We have received many patches here which gives us the target hook info= for >> > most platforms >> >> But this is all so much WIP and full of TODO notes, and has no test case= s >> at all!, that I still don't really see much value in keeping the current >> implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc. >> Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'" >> that I've attached, we're not seeing any change in 'make check-rust' >> results, for example. >> >> In my opinion, the current implementation should be backed out from the >> main development branch (would also reduce pain in merges from GCC >> upstream, as mentioned before), and then be developed (quite possibly >> based on the current implementation) individually for all GCC >> configurations that we'd like to support (with 'sorry' otherwise), in a >> coherent way, instead of trying to guess all possible target options as >> done by the current implementation. And, with all relevant test cases >> getting added, of course. That is, at this time, restrict outselves to >> GCC configurations that we're actually supporting and testing. >> >> Have we even figured out which of those target options are actually >> mandated for a conforming Rust programming language implementation (that >> is, users would potentially rely on these)? >> >> As far as I can tell, 'rustc' defines target options here: >> , >> and you may use 'rustc --print=3Dcfg' to dump for the current >> configuration? >> >> > but getting the normal x86 done correctly will define if >> > the other patches are done correctly. >> >> Yes -- but I'm not sure this is it really, in its current WIPy, >> un-tested, un-verified form: >> >> > gcc/config/ChangeLog: >> >> > * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO >> > * dragonfly.h: define TARGET_RUST_OS_INFO >> > * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO >> > * freebsd.h: define guard for TARGET_RUST_OS_INFO >> > * fuchsia.h: define TARGET_RUST_OS_INFO >> > * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO >> > * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO >> > * linux-android.h: define ANDROID_TARGET_RUST_OS_INFO >> > * linux.h: define GNU_USER_TARGET_RUST_OS_INFO >> > * netbsd.h: define NETBSD_TARGET_RUST_OS_INFO >> > * openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO >> > * phoenix.h: define TARGET_RUST_OS_INFO >> > * sol2.h: define TARGET_RUST_OS_INFO >> > * vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO >> > * vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO >> > >> > gcc/config/i386/ChangeLog: >> > >> > * crtdll.h: define EXTRA_TARGET_RUST_OS_INFO >> > * cygming.h: define TARGET_RUST_OS_INFO >> > * cygwin.h: define EXTRA_TARGET_RUST_OS_INFO >> > * darwin.h: define TARGET_RUST_OS_INFO >> > * djgpp.h: likewise >> > * gnu-user-common.h: define TARGET_RUST_OS_INFO >> > * i386-protos.h: prototype for ix86_rust_target_cpu_info >> > * i386-rust.cc: new file to generate the rust target host info >> > * i386.h: define TARGET_RUST_CPU_INFO hook >> > * linux-common.h: define hooks for target info >> > * lynx.h: likewise >> > * mingw32.h: likewise >> > * netbsd-elf.h: likewise >> > * netbsd64.h: likewise >> > * nto.h: likewise >> > * openbsdelf.h: likewise >> > * rdos.h: likewise >> > * rtemself.h: likewise >> > * t-i386: add makefilke rule for i386-rust.cc >> > * vxworks.h: define TARGET_RUST_OS_INFO >> >> >> Gr=C3=BC=C3=9Fe >> Thomas >> >> >> ----------------- >> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe = 201, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch= =C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellsc= haft: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955 ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955