From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by sourceware.org (Postfix) with ESMTPS id 9B4D53858D3C for ; Mon, 14 Feb 2022 17:51:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B4D53858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-f46.google.com with SMTP id m14so10914590lfu.4 for ; Mon, 14 Feb 2022 09:51:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=UFDjAoTu9t7tB3EWodytTH36Uc77HMBdLWQ2UCopRYI=; b=LKfWnFJmOzzF07iJZcVkzB5LJoUC2FTS6827TK7A84EwJsm6gweC3Hxgn95Njxw13T ixSHoO4erGEx1STufglOeH2j6BJlWwGO/kwJnHrHBlbtnKYV1yqj4b9vj8Q11gIZyNRc 3qeVw34cyy4mbDk9/qEPVV76J+nkNCHqoAnBaeOn9AQyvj+HGC1A1WhSnt/20O9afc8P sW/Omq8bNpjKGhlZFM9dAka60x961nK1QWaBcXb6WBB+r/tY0oWzc0hPVziBxndIuGsG 6MTyVNyaldVRp9wRTvPJsTUW14hRc20YLQlTDBgapZgrvbuPRuYikMylrWw5I3fCIm5j PibQ== X-Gm-Message-State: AOAM533XlM4stE146MyzkmbomjODWJzylp3nVwDnF6vkHvW4y8nYIiaO V6I8feIVlfNwbTZ4YTr+30LQVzPaXs6mwA== X-Google-Smtp-Source: ABdhPJw3JdhoP+ul5t5woQIo7yvUf9aRVWfUfvjivtql4rTl9pt2NFZWaCVBk2FMuGXXpqGTVXtnKg== X-Received: by 2002:a19:ae0d:: with SMTP id f13mr120625lfc.398.1644861079113; Mon, 14 Feb 2022 09:51:19 -0800 (PST) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com. [209.85.208.171]) by smtp.gmail.com with ESMTPSA id i28sm388700ljn.124.2022.02.14.09.51.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Feb 2022 09:51:18 -0800 (PST) Received: by mail-lj1-f171.google.com with SMTP id d2so1038178ljl.1 for ; Mon, 14 Feb 2022 09:51:18 -0800 (PST) X-Received: by 2002:a2e:a5cb:: with SMTP id n11mr547689ljp.361.1644861077582; Mon, 14 Feb 2022 09:51:17 -0800 (PST) MIME-Version: 1.0 References: <20220210055347.24825-1-vapier@gentoo.org> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Mon, 14 Feb 2022 11:51:06 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] newlib: remove unused fenv flags To: C Howland Cc: Newlib X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 17:51:23 -0000 On Mon, Feb 14, 2022, 10:50 AM C Howland wrote: > On Sat, 12 Feb 2022 at 15:42, Mike Frysinger wrote: > > > On 11 Feb 2022 11:10, C Howland wrote: > > > On Fri, 11 Feb 2022 at 05:09, Mike Frysinger wrote: > > > > On 10 Feb 2022 14:18, C Howland wrote: > > > > > First, would be if a machine directory can override just some > > files > > > > > from the main--as if viewpathed--and this can also apply to the > > makefile. > > > > > (Does the machine directory totally replace the main branch > > directory, or > > > > > can it be supplemental? My impression was a viewpath model, which > > can be > > > > > supplementary or replace all.) If I'm wrong about this, no > problem, > > no > > > > > objection for this specific reason. > > > > > > > > assuming "viewpathed" means "VPATH in the makefile", then no, that's > > not > > > > how newlib works. that is how glibc works, so maybe you're thinking > > of that. > > > > newlib compiles all objects in all subdirs in isolation. it then > > assembles > > > > the final libm.a/libc.a in a specific order (with the machine dir > > last). > > > > so it adds fenv/*.o to libm.a by basename, then replaces any existing > > ones > > > > with machine/$arch/*.o. > > > > > > Yes, I meant as in VPATH in a makefile with individual file > granularity. > > > So, yes, I was thinking not the right thing for newlib, sorry for > > > conflating Newlib with other things. > > > > i'm not sure pulling off a vpath build in newlib would be that easy. or > at > > least, it would require writing more custom logic that we get for free > when > > we use automake. at this point, with the size of newlib, i'm not sure we > > would gain that much. yes, we double compile the common code, but since > > the > > files are small and so few, so eh. > > > > > OK, neither you nor Joel think templating for the makefile to be of > much > > > use, that makes a majority in comments so far and I'll go along. > (Since > > > fenv is special and tricky I think we would be better off with better > > > instructions for this one particularly, as it would encourage/help > people > > > to add new targets.) > > > I agree that these specific compiler options do need care taken. But > > > that's part of the reason they're good examples for the fenv > environment, > > > as that's a tricky subject that needs special attention and might need > > > things like them. But at the same time I agree that they are also for > > the > > > same reason potentially dangerous to suggest. > > > > with the new unified non-recursive automake patch i posted, it actually > > would be feasible to put compiler settings in one makefile and have them > > apply to others (by declaring the flags by filename). but the question > > of whether we even want to do that in the first place is still open. > > -mike > > > > > Given the "take whole machine directory" model, it's probably best to take > this patch as proposed. The thoughts about templating fenv to keep it easy > for people not familiar with automake stuff, trying to avoid that aspect > being an impediment to people taking on doing fenv for a new platform, can > be handled separately by adding some separate notes. > I don't know that any of the fenv implementations would have benefited from a template approach anyway. All the ones I was involved in ported from some other existing source. We just tried to minimize the changes as we merged it into the newlib structure. Certainly if someone does implement it from scratch for newlib first, they can always copy from an existing implementation. But unless it is unusual embedded only architecture, will probably always port from another project. --joel Craig >