From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ibuclaw@gdcproject.org>
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152])
	by sourceware.org (Postfix) with ESMTPS id 003513858D28
	for <gcc-patches@gcc.gnu.org>; Sun, 23 Oct 2022 11:35:54 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 003513858D28
Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gdcproject.org
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gdcproject.org
Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4MwGNj6XXZz9sQK;
	Sun, 23 Oct 2022 13:35:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gdcproject.org;
	s=MBO0001; t=1666524949;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dqa9aN8BrokyjewCeoyraGtkmxWjPDr0RIGz2n14YGw=;
	b=apwMXxYB8i3Q5DNd0WV0cOiP+4lP1Do9KDTY+gmlCrLZL+fRTDdAxUUQz6tcsV3mg4aEuU
	a5Gxp4wNcMe8Z2XXoXX0mX4fnrabpJSJ/qEJghBAo1Y6+3pcw/kAaU3/uOf0YkHTabnB4m
	bB5rv0kGl3TmjboQIHrrEixM7aweH5dILehMdqagN2xqs/cEkiYUbhVDYNcd3mbvToKe3T
	GgrO63oIGFSkslQfnbKkyPf26osCUq7yA2w6DECCQI9TggJxyroFs1/l84zlnI+T9VjS6k
	SWeBIXI70kIc9yWXco5he1mSBzNEkjzwmBhPni2jhibajurNOCorB7Qa2zuuvA==
Date: Sun, 23 Oct 2022 13:35:49 +0200 (CEST)
From: ibuclaw@gdcproject.org
To: gcc-patches@gcc.gnu.org
Cc: "jlaw@ventanamicro.com" <jlaw@ventanamicro.com>,
	"rguenther@suse.de" <rguenther@suse.de>
Message-ID: <1090795211.238603.1666524949489@office.mailbox.org>
In-Reply-To: <20221017180844.3492051-1-ibuclaw@gdcproject.org>
References: <20221017180844.3492051-1-ibuclaw@gdcproject.org>
Subject: Re: [PATCH] d: Remove D-specific version definitions from target
 headers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Rspamd-Queue-Id: 4MwGNj6XXZz9sQK
X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>

> On 17/10/2022 20:08 CEST Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> 
>  
> Hi,
> 
> This splits up the targetdm sources so that each file only handles one
> target platform.
> 
> Having all logic kept in the headers means that they could become out of
> sync when a new target is added (loongarch*-*-linux*) or accidentally
> broken if some headers in tm_file are omitted or changed about.
> 
> There might be an open bikeshed question as to appropriate names for
> some of the platform sources (kfreebsd-d.cc or kfreebsd-gnu-d.cc).
> 
> Bootstrapped and regression tested on x86_64-linux-gnu, and also built
> i686-cygwin, i686-gnu, i686-kfreebsd-gnu, i686-kopensolaris-gnu,
> x86_64-cygwin, x86_64-w64-mingw32 cross compilers, the dumps of all
> predefined version identifiers remain correct in all configurations.
> 
> OK?
> 

Ping?

I'll apply this tomorrow, but there is a general open question about whether taking logic out of target headers and putting it in config.gcc is the right approach moving forward for non C/C++ front-ends.  This is also relevant for Rust, which initially put all their target support definitions in headers, and have since removed the entire tangled mess that created.

Regards,
Iain.