From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) by sourceware.org (Postfix) with ESMTPS id 9BB423844038 for ; Fri, 3 Jul 2020 13:12:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9BB423844038 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joel.sherrill@gmail.com Received: by mail-ej1-f68.google.com with SMTP id l12so34135312ejn.10 for ; Fri, 03 Jul 2020 06:12:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=t8Yu3udyCoDcbIlZOQO7sd6vaiT5oEJygX1pP2r4VI8=; b=px835rrdraGwbOCgrM6oZnKhZUrL73grkH5GR3wW1GPa+5zBM8IiyBZyUBpR0wgdq1 ukJeuBt5sWiKlzre7uMHiAecwekxcli+U0oltY7vJopFwsH9STmZV7fti73g0ATcl3ki UxyI28oxaBG2WLksWMQOIAzCMg8+uWJgmaucP7aH/ICYnMAciJ2f6x9qaoCIO2JvKgdb s3JGMRCNuxWkki1qpoN3cRftIJ1e/TRa7Pv90Wf8Un/BgKGcc8TcI3LKnUn0JhWHS5G+ 5mKXh3QEIRCeAbz00OHJSEkYM9tBsEVEusW4n30KqLPdAmb+ehiksrTKzIO8ejyk2slb /UOA== X-Gm-Message-State: AOAM530gqpEPQhcGXZpa0Re0WOly1PBrUpx/8E8aO/i7+uVJrfMbaYl1 5akQWHgxpaiG1NBuVDPFZYr/EBZc X-Google-Smtp-Source: ABdhPJyD4pF8xE521hX4cktk8H01ozVLUoP/15hMtenRkXRTLd3KHIJC4LVf3T/8857WaaMwm5eSMw== X-Received: by 2002:a17:906:784c:: with SMTP id p12mr32109298ejm.123.1593781973101; Fri, 03 Jul 2020 06:12:53 -0700 (PDT) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com. [209.85.208.49]) by smtp.gmail.com with ESMTPSA id x10sm9579131ejc.46.2020.07.03.06.12.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jul 2020 06:12:52 -0700 (PDT) Received: by mail-ed1-f49.google.com with SMTP id d18so22030497edv.6 for ; Fri, 03 Jul 2020 06:12:52 -0700 (PDT) X-Received: by 2002:a50:c8c9:: with SMTP id k9mr39355510edh.157.1593781972395; Fri, 03 Jul 2020 06:12:52 -0700 (PDT) MIME-Version: 1.0 References: <20200603174509.18606-1-eshandhawan51@gmail.com> <20200603174509.18606-2-eshandhawan51@gmail.com> <20200702121131.GE22681@arm.com> <20200703091411.GA14424@arm.com> In-Reply-To: <20200703091411.GA14424@arm.com> Reply-To: joel@rtems.org From: Joel Sherrill Date: Fri, 3 Jul 2020 08:12:40 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/1] fenv support arm To: Szabolcs Nagy Cc: Eshan dhawan , Newlib , jeol@rtems.org X-Spam-Status: No, score=-3032.2 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_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 03 Jul 2020 13:12:56 -0000 On Fri, Jul 3, 2020 at 4:14 AM Szabolcs Nagy wrote: > The 07/02/2020 17:33, Joel Sherrill wrote: > > Szabolcs, is the code in question compiled with any feature flags set? > > feature flags are not relevant to my issue. > > > > > I see on Linux that the prototypes would be triggered by _GNU_SOURCE > while > > in newlib, it is _BSD_SOURCE. Is that possibly contributing? > > (feenableexcept should be hidden when compiling > in standard conform mode, _BSD_VISIBLE is a bit > misleading as it is historically a gnu extension > not BSD, but it does not matter: _GNU_SOURCE > exposes _BSD_VISISBLE code.) > In FreeBSD, it is under _BSD_SOURCE but the Cygwin source brought over for x86_64 and i386 has _GNU_SOURCE. Should a sweep be made to make this consistent across the architectures? > > > > Can you post a test case? The command line that is failing would also > help. > > the problem is simply that sys/fenv.h has no > function declarations at all with hard float > abi. (fenv.h still has declarations but only > the standard apis) e.g. > > echo '#include > void *p = (void*)feenableexcept;' | \ > arm-none-eabi-gcc -march=armv5te+fp -mfloat-abi=hard -include fenv.h -xc > -c - > > :2:16: error: 'feenableexcept' undeclared here (not in a function); > did you mean 'feraiseexcept'? > > echo '#include > void *p = (void*)feraiseexcept;' | \ > arm-none-eabi-gcc -march=armv5te+fp -mfloat-abi=hard -include fenv.h -xc > -c - > > :2:16: error: 'feraiseexcept' undeclared here (not in a function) > > > > > > I'd like to not guess at what's wrong. > > i can submit a patch for removing the VFP ifndef > but i wanted to understand why is it there? > The original FreeBSD code used some name remapping magic based on VFP or soft-float or whatever to map the names of the methods appropriately. The port to newlib simplified that since multilib results in only having one version of the methods in the library. This is just a remnant of the FreeBSD approach and should be removed. Feel free to remove it. --joel > > > > > --joel > > > > On Thu, Jul 2, 2020 at 10:48 AM Joel Sherrill wrote: > > > > > > > > > > > On Thu, Jul 2, 2020 at 7:11 AM Szabolcs Nagy > > > wrote: > > > > > >> The 06/03/2020 23:15, Eshan dhawan via Newlib wrote: > > >> > --- /dev/null > > >> > +++ b/newlib/libc/machine/arm/sys/fenv.h > > >> ... > > >> > +#ifndef __ARM_PCS_VFP > > >> > + > > >> > +int feclearexcept(int excepts); > > >> > +int fegetexceptflag(fexcept_t *flagp, int excepts); > > >> > +int fesetexceptflag(const fexcept_t *flagp, int excepts); > > >> > +int feraiseexcept(int excepts); > > >> > +int fetestexcept(int excepts); > > >> > +int fegetround(void); > > >> > +int fesetround(int round); > > >> > +int fegetenv(fenv_t *envp); > > >> > +int feholdexcept(fenv_t *envp); > > >> > +int fesetenv(const fenv_t *envp); > > >> > +int feupdateenv(const fenv_t *envp); > > >> > +#if __BSD_VISIBLE > > >> > +int feenableexcept(int __mask); > > >> > +int fedisableexcept(int __mask); > > >> > +int fegetexcept(void); > > >> > +#endif /* __BSD_VISIBLE */ > > >> > + > > >> > +#endif /* __ARM_PCS_VFP */ > > >> > > >> why are these declarations conditional? > > >> > > > > > > The prototypes for the POSIX methods are in the shared fenv.h. > > > > > > Since the ARM has the BSD_VISIBLE extras, those should be left in the > arm > > > specific sys/fenv.h. > > > > > > But (I don't think) they need a ARM_PCS_VFP wrapper since there should > be > > > an implementation for all multilibs. We could discuss the BSD_VISIBLE > > > prototypes being moved to and removed from all the > architecture > > > > > > but that was also how the code I moved from Cygwin to newlib libm was > done > > > so > > > maybe there is a reason that I don't know to leave it here. > > > > > >> > > >> i get build failures e.g. in libgfortran > > >> because configure detects the availability > > >> of feenableexcept in libm.a so it starts > > >> using it but then fenv.h does not have the > > >> declaration so compilation fails. > > >> > > >> it seems there is vfp code for all this > > >> so why are the declarations removed? > > >> > > > > > > The FreeBSD headers rely on the architecture sys/fenv.h prototypes > > > even for POSIX standard methods. Most of the block of code is removed > > > because the prototypes were in which is where this file is > > > included > > > from. > > > > > > Eshan... re-add the BSD_VISIBLE block please and resubmit. It also > > > looks like the test code isn't exercising those methods so that should > > > be updated after this patch is updated. We don't want libfortran broken > > > for longer than neccessary. > > > > > > --joel > > > > > -- >