From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by sourceware.org (Postfix) with ESMTPS id 5C5AD3858405 for ; Thu, 10 Feb 2022 18:27:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C5AD3858405 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-f51.google.com with SMTP id b9so12058859lfq.6 for ; Thu, 10 Feb 2022 10:27:09 -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=04Rd0G9yVjdby0XcWEfkLALXwI/2n1tdxnTWDZXtC3k=; b=K48cie+K4juNGCRYe0ayPGHbCM5OZhogmsLaELm+Q4pBPUAwNko8mvnPaUeOOrhow5 5pbGWBrtPHoUMcefyxgnl+RdWZysm10ncwOLH9T1VTC0bZdrxho6V1IVPVjjRJsDQkFX CrxmG7aQDoID4LyP4aQIktq1FZTD7/GcHASrCIs2TM7rjAIR5Lfo9Icm30zNWRI2dE5Q o36Z6X1iVp6dFSN80ooMwFBKj4v2z5fJNLDxeCIMs8nGYuU2uLRKl+UHiKo/8JjtdbWf A7nIUlBnQpiZzNxIpR+eo+e/KhKUqfyTJbqlN3MBBBTH9lZfcdqePAI4Cp7Q0n3jSm6L pmGw== X-Gm-Message-State: AOAM532YQQpIEFYcWAPgwM6hc86dbPb70GXIAwGWGJ9+LXHPb5LY+U/q mFzN49wSEHsEE8b+C0tDJoz0ia9bye9hMA== X-Google-Smtp-Source: ABdhPJwaLmtlpujW0TfQ3/mdYS6Id97SUsKxqd1GDRVBmARZL4mkGkcbPQ7CfL0s6s/Milov0a9f5w== X-Received: by 2002:a05:6512:3e1c:: with SMTP id i28mr5711527lfv.83.1644517627521; Thu, 10 Feb 2022 10:27:07 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id f10sm2853045lfk.209.2022.02.10.10.27.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Feb 2022 10:27:07 -0800 (PST) Received: by mail-lf1-f47.google.com with SMTP id bu29so6835024lfb.0 for ; Thu, 10 Feb 2022 10:27:07 -0800 (PST) X-Received: by 2002:a05:6512:3f8e:: with SMTP id x14mr5794566lfa.2.1644517627059; Thu, 10 Feb 2022 10:27:07 -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: Thu, 10 Feb 2022 12:26:55 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] newlib: remove unused fenv flags To: C Howland Cc: Newlib Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3037.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Thu, 10 Feb 2022 18:27:11 -0000 On Thu, Feb 10, 2022 at 12:03 PM C Howland wrote: > > > > > > > ------------------------------ > > *From:* Newlib on > > behalf of Corinna Vinschen > > *Sent:* Thursday, February 10, 2022 10:04 AM > > *To:* newlib@sourceware.org > > *Subject:* Re: [PATCH] newlib: remove unused fenv flags > > > > > > > > On Feb 10 00:53, Mike Frysinger wrote: > > > These look like they were just copied & pasted from common/Makefile.am. > > > The funcs in this dir are all stubs that don't actually call any math > > > or builtin functions, and a simple compile shows they produce identical > > > object code. So delete to simplify the build rules. > > > --- > > > newlib/libm/fenv/Makefile.am | 3 -- > > > newlib/libm/fenv/Makefile.in | 90 +++--------------------------------- > > > 2 files changed, 6 insertions(+), 87 deletions(-) > > > > > > diff --git a/newlib/libm/fenv/Makefile.am b/newlib/libm/fenv/Makefile.am > > > index 50b59004c17e..66755e394cb7 100644 > > > --- a/newlib/libm/fenv/Makefile.am > > > +++ b/newlib/libm/fenv/Makefile.am > > > @@ -6,11 +6,8 @@ src = feclearexcept.c fe_dfl_env.c fegetenv.c > > fegetexceptflag.c \ > > > fegetround.c feholdexcept.c feraiseexcept.c fesetenv.c \ > > > fesetexceptflag.c fesetround.c fetestexcept.c feupdateenv.c > > > > > > -lib_a_CFLAGS = -fbuiltin -fno-math-errno > > > - > > > noinst_LIBRARIES = lib.a > > > lib_a_SOURCES = $(src) > > > -lib_a_CFLAGS += $(AM_CFLAGS) > > > > > > # A partial dependency list. > > > > > > -- > > > 2.34.1 > > > > Ok. > > > > > > Thanks, > > Corinna > > > > > No, not OK, it doesn't sound like. The fenv functions are all > machine-specific and the files in the libm/fenv directory are all stubs > (which they clearly state internally). Unless all targets were checked > (and it doesn't sound like they were), the conclusion is faulty that no > difference happens. Taking away -fbuiltin would definitely break any > machine source relying on it, but not the stubs. I think these are analogous to the default implementations of str* and mem* methods. All libm builds should get a stub if they don't provide an architecture specific override. And the only way to get a functional implementation AFAIK is to have an architecture specific version. I know I helped add a lot of these implementations but I'm drawing a blank beyond that. --joel > Craig