From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 437C6386F82C; Tue, 21 Apr 2020 16:25:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 437C6386F82C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1587486304; bh=MEMqoUcSpsBdz3OParfIomrUr2SwuGNgM2xdHXMHajo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=p4snePXkoM1wsnJc0WJXZ3ttQ1yxEiEwLlnsJKui7vmfXJw5yIPwe3LlCYPz7Ow32 bV6HTm4vf/2zzmzCV2fGc6n6s39W4dmftDoQx1zFhz0vn3PFKxy73mJiVmiS3IEgqu rwQzQTYDNYeg1pSDCrIumsdoY63IScVB6UkLAGxY= From: "foreese at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib) Date: Tue, 21 Apr 2020 16:25:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: foreese at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 16:25:04 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94694 Fritz Reese changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |foreese at gcc dot gnu.org --- Comment #8 from Fritz Reese --- (In reply to Jakub Jelinek from comment #7) > So, I meant something like: > --- libgfortran/configure.ac.jj 2020-01-24 22:34:36.340641225 +0100 > +++ libgfortran/configure.ac 2020-04-21 18:03:02.494598615 +0200 > @@ -392,6 +392,9 @@ GCC_CHECK_MATH_FUNC([cabsl]) > GCC_CHECK_MATH_FUNC([floorf]) > GCC_CHECK_MATH_FUNC([floor]) > GCC_CHECK_MATH_FUNC([floorl]) > +GCC_CHECK_MATH_FUNC([fmaf]) > +GCC_CHECK_MATH_FUNC([fma]) > +GCC_CHECK_MATH_FUNC([fmal]) > GCC_CHECK_MATH_FUNC([fmodf]) > GCC_CHECK_MATH_FUNC([fmod]) > GCC_CHECK_MATH_FUNC([fmodl]) [...] >=20 > except that the test in configure for HAVE_INLINE_BUILTIN_COPYSIGN still > needs to be written. I like this solution in principle but we would need to add fabsl, fmal, and copysignl, right? And then we are still left with the question: what do we = do if HAVE_INLINE_BUILTIN_COPYSIGN, HAVE_FMOD, or similar are not satisfied at= the lowest level? (In reply to Richard Biener from comment #2) > Note in another bug it was said that libgfortran requires a C99 runtime, > when that's not available you should disable gfortran build. GCC (or > libgfortran) > is in no position to disable parts of its features and AFAICS for QOI iss= ues > the _frontend_ would need to reject programs making use of disabled libra= ry > functionality, otherwise programs are going to only fail to link. >=20 > IMHO failure at runtime when the disabled functionality is actually invok= ed > isn't good QOI either. [...] Yes, I agree. The FE should notify the user for intrinsics which would not = be implemented in the library, if we indeed selectively disable such intrinsic= s.=20 Note that, there is currently precedent for this in the library without concurrence of the FE: libgfortran/intrinsic/symlnk.c contains the definiti= ons of the SYMLNK intrinsic (symlnk_iX_sub) guarded by "#ifdef HAVE_SYMLINK". T= here is no parallel check in the FE, so I imagine that on a system for which HAVE_SYMLINK is not defined one would experience a link failure (if there is any such system on which gfortran can be built). (In reply to Richard Earnshaw from comment #5) > (In reply to Richard Biener from comment #2) > > [...] > > Since Fortran isn't release critical the only P1-ish part is that fortr= an > > build is enabled on aarch64-elf and thus we can resolve this by adding > > aarch64-elf-*) to > > [...] > > technically aarch64-elf isn't a primary architecture. >=20 > Well in that case it should *test* the run time for compatibility. It > shouldn't assume it's incompatible just because of the target triplet. >=20 > aarch64-elf is a secondary platform. It should still build. I concur. Perhaps a narrower solution is to disable REAL(1[06]) support on = the platform if the *l math functions are not available... Though I prefer Jaku= b's solution of providing the missing functions in c99_functions.c so long as t= he core functionailty is available on the system.=