From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34910 invoked by alias); 16 May 2019 12:58:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 34749 invoked by uid 89); 16 May 2019 12:58:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=frustrating, damage, measures, origins X-HELO: esa6.hgst.iphmx.com Received: from esa6.hgst.iphmx.com (HELO esa6.hgst.iphmx.com) (216.71.154.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 May 2019 12:58:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1558011535; x=1589547535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qBqHpGS2/BJ5NjmTZ5s3YzKjbrFLixmKa4qvDKjcZM8=; b=dHl7oVTF1NgbfMNtzEuNkU0snaVRJqUThPGyvSUcp77Nh34Y7EVMckhm O8z2/XMnHmKy2B+9dxn2+nHO+zq7ZHZs2gRDduGaEoop5dUA3Odpnfl87 /kJGAXnCOcz4/mzTSualsorFdDAUJdrmuGZHM5G7ObJPvpjMPmD4rObry slxlggpNo2t11aoli7lLjn7bSLS8h/sQB/AphuD5/czTRBN2dX0sEa2Vv RdF5Q2se733r2FLumODZSI/UlL7DQh/SQNGzXMvX6Pa/oB86rmvPtVsJ/ v0kzhOlEhERZs+Cqp4roItZZlCvcDoCq5YeD5GF502FjCU5eZloGdwjTv g==; Received: from mail-bl2nam02lp2058.outbound.protection.outlook.com (HELO NAM02-BL2-obe.outbound.protection.outlook.com) ([104.47.38.58]) by ob1.hgst.iphmx.com with ESMTP; 16 May 2019 20:58:52 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharedspace.onmicrosoft.com; s=selector1-wdc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bl1CTIw31de/O5a1oqm7zbmwrwOIFap2mLZk5dbA4RA=; b=VHd3wqx+BDg3tDlziiLsUesyZ0dF/gTYWx5p9Zzd9VlXp3HolbdhyAoLQpCOjkX1yBMxUjh9SOdrw+jQKe4bhbpeaMVLCOdZBsjAtVyp42IIGa+27Ce3Oe6CAU0eR52YBa8jxdgIG4toqj/hDgEZ7gZKY1dCSgJ1bzFNmwSbMA4= Received: from BYAPR04MB6262.namprd04.prod.outlook.com (20.178.235.160) by BYAPR04MB5591.namprd04.prod.outlook.com (20.178.207.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.25; Thu, 16 May 2019 12:58:50 +0000 Received: from BYAPR04MB6262.namprd04.prod.outlook.com ([fe80::31ee:c691:33ca:b46b]) by BYAPR04MB6262.namprd04.prod.outlook.com ([fe80::31ee:c691:33ca:b46b%3]) with mapi id 15.20.1878.028; Thu, 16 May 2019 12:58:50 +0000 From: "Maciej W. Rozycki" To: Jacob Bachmeyer CC: "gcc-patches@gcc.gnu.org" , "dejagnu@gnu.org" , Pierre-Marie de Rodat , Arnaud Charlet , Eric Botcazou Subject: Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada Date: Thu, 16 May 2019 12:58:00 -0000 Message-ID: References: <5CDCA82D.8090204@gmail.com> In-Reply-To: <5CDCA82D.8090204@gmail.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=macro@wdc.com; wdcipoutbound: EOP-TRUE x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-SW-Source: 2019-05/txt/msg00949.txt.bz2 On Wed, 15 May 2019, Jacob Bachmeyer wrote: > This patch really exposes a significant deficiency in our current=20 > implementation of default_target_compile: the order of various flags=20 > can be significant, but we only have that order implicitly expressed in=20 > the code, which goes all the way back to (of course) the "Initial=20 > revision" that is probably from a time before Tcl had the features that=20 > will allow significant cleanup in here. I suspect the origins may be different, however as valuable as your=20 observation is functional problems have precedence over issues with code=20 structuring, so we need to fix the problem at hand first. I'm sure=20 DejaGNU maintainers will be happy to review your implementation of code=20 restructuring afterwards. > Some of these could probably be combined and I may have combined=20 > categories that should be separate in the above list. The GNU toolchain= =20 > has always been a kind of "magic box that just works" (until it doesn't=20 > and the manual explains the problem) for me, so I am uncertain what the=20 > ordering rules for combining these categories should be. Anyone know=20 > the traditional rules and, perhaps more importantly, what systems need=20 > which rules? The ordering rules are system-specific I'm afraid and we have to be=20 careful not to break working systems out there. People may be forced to a= =20 DejaGNU upgrate, due to a newer version of a program being tested having=20 such a requirement, and can legitimately expect their system to continue=20 working. NB I have been repeatedly observing cases where a forced upgrade of a=20 system component I neither care nor I am competent about, triggered by an=20 upgrade of a component I do care about, caused the system to malfunction=20 in a way that I find both unacceptable and extremely hard to debug. It=20 seems to have become more frequent in the recent years, and I find this=20 both very frustrating and have wasted lots of time trying to fix the=20 damage caused. I would therefore suggest to take all the measures=20 possible to save people from going through such an experience. FWIW, Maciej