public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34 Date: Fri, 07 Oct 2022 07:00:21 +0000 [thread overview] Message-ID: <bug-107059-4-IZ1hIdWGZv@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107059-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059 --- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:62ec780ac0b4d109f2a3c8c4597cb19a82f6188d commit r13-3147-g62ec780ac0b4d109f2a3c8c4597cb19a82f6188d Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Oct 7 08:56:04 2022 +0200 fixincludes: Fix up powerpc floatn.h tweaks [PR107059] On Wed, Sep 28, 2022 at 12:23:31AM +0000, Joseph Myers wrote: > In general the changes match those made by fixincludes, though I think > the ones in sysdeps/powerpc/bits/floatn.h, where the header tests > __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing > fixincludes patterns. You're right, missed that. The header has: /* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1. */ # if __HAVE_FLOAT128 # if __LDBL_MANT_DIG__ == 113 && defined __cplusplus typedef long double _Float128; # define __CFLOAT128 _Complex long double # elif !__GNUC_PREREQ (7, 0) || defined __cplusplus /* The type _Float128 exist for powerpc only since GCC 7.0. */ typedef __float128 _Float128; /* Add a typedef for older GCC and C++ compilers which don't natively support _Complex _Float128. */ typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__))); # define __CFLOAT128 __cfloat128 # else # define __CFLOAT128 _Complex _Float128 # endif # endif and my current rules don't do anything about that. The following patch fixes that. I've run additionally MACRO_LIST=`pwd`/../gcc/macro_list TARGET_MACHINE=x86_64-pc-linux-gnu \ ../fixincludes/fixinc.sh /tmp/include-fixed \ `echo /usr/src/libc | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` in the builddir/fixincludes directory where /usr/src/libc is latest glibc trunk checkout and seems the remaining defined __cplusplus cases in the floatn.h and floatn-common.h headers are ok or acceptable. The remaining cases are: #if __GNUC_PREREQ (7, 0) && !defined __cplusplus # define __HAVE_FLOATN_NOT_TYPEDEF 1 #else # define __HAVE_FLOATN_NOT_TYPEDEF 0 #endif which is IMHO ok because this is only used in tgmath.h or tgmath-like math.h stuff which is C only, as C++ doesn't have _Generic. Another case are the following 3 snippets: # if !__GNUC_PREREQ (7, 0) || defined __cplusplus # error "_Float128X supported but no constant suffix" # else # define __f128x(x) x##f128x # endif ... # if !__GNUC_PREREQ (7, 0) || defined __cplusplus # error "_Float128X supported but no complex type" # else # define __CFLOAT128X _Complex _Float128x # endif ... # if !__GNUC_PREREQ (7, 0) || defined __cplusplus # error "_Float128x supported but no type" # endif but as no target has _Float128x right now and don't see it coming soon, it isn't a big deal (on the glibc side it is of course ok to adjust those). OT, besides floatn.h and floatn-common.h headers, the only one remaining in /tmp/include-fixed is sysdeps/arm/unwind.h, perhaps -#if defined(linux) || defined(__NetBSD__) +#if defined(__linux__) || defined(__NetBSD__) should be done in that header (and libgcc/config/arm/unwind-arm.h too). 2022-10-07 Jakub Jelinek <jakub@redhat.com> PR bootstrap/107059 * inclhack.def (glibc_cxx_floatn_2): Handle #elif the same as #if. (glibc_cxx_floatn_4): New. * fixincl.x: Regenerated. * tests/base/bits/floatn.h: Regenerated.
next prev parent reply other threads:[~2022-10-07 7:00 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-27 16:46 [Bug bootstrap/107059] New: " seurer at gcc dot gnu.org 2022-09-27 17:10 ` [Bug bootstrap/107059] " jakub at gcc dot gnu.org 2022-09-27 17:28 ` marxin at gcc dot gnu.org 2022-09-27 17:37 ` jakub at gcc dot gnu.org 2022-09-27 18:40 ` seurer at gcc dot gnu.org 2022-09-27 18:50 ` jakub at gcc dot gnu.org 2022-09-27 18:52 ` seurer at gcc dot gnu.org 2022-09-27 19:13 ` jakub at gcc dot gnu.org 2022-09-27 19:20 ` seurer at gcc dot gnu.org 2022-09-27 19:26 ` jakub at gcc dot gnu.org 2022-09-27 19:59 ` seurer at gcc dot gnu.org 2022-09-27 20:22 ` jakub at gcc dot gnu.org 2022-09-28 9:45 ` tnfchris at gcc dot gnu.org 2022-09-28 9:46 ` jakub at gcc dot gnu.org 2022-09-28 10:12 ` jakub at gcc dot gnu.org 2022-09-28 10:59 ` burnus at gcc dot gnu.org 2022-09-28 11:18 ` burnus at gcc dot gnu.org 2022-09-28 11:26 ` burnus at gcc dot gnu.org 2022-09-28 11:37 ` jakub at gcc dot gnu.org 2022-09-28 12:58 ` burnus at gcc dot gnu.org 2022-09-28 13:10 ` burnus at gcc dot gnu.org 2022-09-28 13:12 ` jakub at gcc dot gnu.org 2022-09-28 17:16 ` joseph at codesourcery dot com 2022-09-28 18:40 ` burnus at gcc dot gnu.org 2022-09-28 18:47 ` jakub at gcc dot gnu.org 2022-09-28 18:57 ` burnus at gcc dot gnu.org 2022-09-28 19:04 ` jakub at gcc dot gnu.org 2022-09-28 19:20 ` manuel.lauss at googlemail dot com 2022-09-29 8:07 ` rguenth at gcc dot gnu.org 2022-09-29 10:06 ` cvs-commit at gcc dot gnu.org 2022-09-29 10:14 ` jakub at gcc dot gnu.org 2022-10-03 15:29 ` seurer at gcc dot gnu.org 2022-10-03 15:33 ` jakub at gcc dot gnu.org 2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org [this message] 2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org 2022-10-07 7:01 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-107059-4-IZ1hIdWGZv@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).