From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by sourceware.org (Postfix) with ESMTPS id E4B753858C27; Mon, 6 Sep 2021 07:06:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4B753858C27 Received: by mail-io1-xd2d.google.com with SMTP id m11so7458324ioo.6; Mon, 06 Sep 2021 00:06:22 -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:from:date :message-id:subject:to:cc; bh=pc3s4B5brCUv91J7q06QxmuNjyFZfCkfc83lsoiAF+g=; b=dXDDV0oze+V52EMZQJCHbEkQe5AsnncfBQqrjeD0u92sS/zlBC7ZF1kuHS7BTVSpZL kHS1SdLcmemxcx/CT6LvwQgbsu1Szqa1CQHG/oJdjrvYga2jctUW+lChWaIOwCnU4bzn jHH2y7pD07TijakyjWGSZaV0llPKjScZWmtn8FCLNkzBF0w7ll5okIRVVqxCATsbISrr MbyxcXZedTzCaH1IwqPgkBLLgaWmd9nkWEaN6VxXOcue3+5yJ1kDWNMl7yyflZ+5bOwd rF4IWQ2UORl8K0OQfLGDC1dbrIYQnGqwcqAcuXPZHjSvlmOFIvBtZC2+k++UuwZctssy OkAQ== X-Gm-Message-State: AOAM532lVHhl71Xfqnudef9S/7n9jgf736kq9aeTIZYb4eQGIpAsK+fg 9mcLwdpEmd69IdX5XEO//Uzlg9FjnsljQRY/Gu0= X-Google-Smtp-Source: ABdhPJzHtPuVR3FmWDnxNUcN7YtA7yaARScCy+kOB6tiWzHyOjEV5kZ+Dd1+KYLegnTXHapQI7M/loCe9pGss8ZjNDg= X-Received: by 2002:a05:6638:1646:: with SMTP id a6mr9701173jat.27.1630911982167; Mon, 06 Sep 2021 00:06:22 -0700 (PDT) MIME-Version: 1.0 References: <25e1007e-f23c-d7b6-b2cc-7490e69d2f9f@codesourcery.com> In-Reply-To: From: Christophe Lyon Date: Mon, 6 Sep 2021 09:06:11 +0200 Message-ID: Subject: Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h To: Sandra Loosemore Cc: "H.J. Lu" , "fortran@gcc.gnu.org" , "gcc-patches@gcc.gnu.org" , Sunil K Pandey X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 07:06:24 -0000 On Mon, Sep 6, 2021 at 7:21 AM Sandra Loosemore wrote: > On 9/5/21 7:29 PM, H.J. Lu wrote: > > On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore > > wrote: > >> > >> On 9/5/21 7:31 AM, H.J. Lu wrote: > >>> On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore < > sandra@codesourcery.com> wrote: > >>>> > >>>> The testcase gfortran.dg/PR100914.f90 that I recently checked in > >>>> (originally written by Jos=C3=A9 Rui Faustino de Sousa) depends on t= he > >>>> header file to obtain a typedef for __complex128. It > >>>> appears not to be possible to define an equivalent type in a portabl= e > >>>> way in the testcase itself (see > >>>> https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Floating-Types.html) s= o > >>>> this patch skips the test entirely on targets where quadmath.h is no= t > >>>> available. > >>>> > >>>> The target-supports.exp change was cut-and-pasted from similar code = in > >>>> that file, but I haven't figured out how to test this change in a > build > >>>> that doesn't provide quadmath.h (e.g., my aarch64-linux-gnu toolchai= n > >>>> build attempt croaked with an unrelated compilation error in glibc). > >>>> Perhaps someone who previously encountered the FAILs on this testcas= e > >>>> can confirm that it's skipped with this change? > >>> > >>> Since libqaudmath provides , I prefer either of 2 patches > >>> enclosed here. > >> > >> Of these two, the first one looks better to me, and seems to work OK i= n > >> my x86 build. But, I'm not sure it is the right thing for ARM/Aarch64 > >> targets, which apparently have _Float128 support without the __float12= 8 > >> type or libquadmath. It's pretty clear quadmath.h depends on having > >> __float128. > > > > The only used by GCC is the one in libquadmath. I > > will check in my first patch tomorrow if there are no objections. > > > >> See Christophe's mail here: > >> > >> https://gcc.gnu.org/pipermail/fortran/2021-September/056467.html > >> > >> As I said in my last mail, I ran into some problems getting an aarch64 > >> toolchain built so I haven't been able to do any testing or experiment= s > >> on that target myself yet. :-( > > I finally got an aarch64-linux-gnu toolchain built and confirmed that it > is still broken there: it indeed does not define __float128, and > including quadmath.h results in a gazillion errors like > > /path/to/quadmath.h:47:8: error: unknown type name '__float128' > > I also observed that _Float128 is the same type as long double on this > target. > > Unless the aarch64 maintainers think it is a bug that __float128 is not > supported, I think the right solution here is the one I was thinking of > previously, to fix the Fortran front end to tie the C_FLOAT128 kind to > _Float128 rather than __float128, and fix the runtime support and test > cases accordingly. Then there should be no need to depend on quadmath.h > at all. C_FLOAT128 is a GNU extension and _Float128 is supported on a > superset of targets that __float128 is, so there should be no issue with > backward compatibility. > > I'm not really in a position to make a comment, but any patch aiming at skipping pr100914.f90 only will have no effect on the other errors I reported, which are related to __float128 vs _Float128. Christophe > -Sandra >