public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/111787] [14 regression] r14-4592-g0d00385eaf72cc breaks build Date: Thu, 12 Oct 2023 15:11:57 +0000 [thread overview] Message-ID: <bug-111787-4-0vupwdaiEi@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-111787-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111787 --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Does 2023-10-12 Jakub Jelinek <jakub@redhat.com> PR bootstrap/111787 * tree.h (wi::int_traits <unextended_tree>::needs_write_val_arg): New static data member. (int_traits <extended_tree <N>>::needs_write_val_arg): Likewise. (wi::ints_for): Provide separate partial specializations for generic_wide_int <extended_tree <N>> and INL_CONST_PRECISION or that and CONST_PRECISION, rather than using int_traits <extended_tree <N> >::precision_type as the second template argument. * rtl.h (wi::int_traits <rtx_mode_t>::needs_write_val_arg): New static data member. * double-int.h (wi::int_traits <double_int>::needs_write_val_arg): Likewise. --- gcc/tree.h.jj 2023-10-12 16:01:04.000000000 +0200 +++ gcc/tree.h 2023-10-12 16:52:51.977954615 +0200 @@ -6237,6 +6237,7 @@ namespace wi static const enum precision_type precision_type = VAR_PRECISION; static const bool host_dependent_precision = false; static const bool is_sign_extended = false; + static const bool needs_write_val_arg = false; }; template <int N> @@ -6262,6 +6263,7 @@ namespace wi = N == ADDR_MAX_PRECISION ? INL_CONST_PRECISION : CONST_PRECISION; static const bool host_dependent_precision = false; static const bool is_sign_extended = true; + static const bool needs_write_val_arg = false; static const unsigned int precision = N; }; @@ -6293,8 +6295,14 @@ namespace wi tree_to_poly_wide_ref to_poly_wide (const_tree); template <int N> - struct ints_for <generic_wide_int <extended_tree <N> >, - int_traits <extended_tree <N> >::precision_type> + struct ints_for <generic_wide_int <extended_tree <N> >, INL_CONST_PRECISION> + { + typedef generic_wide_int <extended_tree <N> > extended; + static extended zero (const extended &); + }; + + template <int N> + struct ints_for <generic_wide_int <extended_tree <N> >, CONST_PRECISION> { typedef generic_wide_int <extended_tree <N> > extended; static extended zero (const extended &); @@ -6532,8 +6540,15 @@ wi::to_poly_wide (const_tree t) template <int N> inline generic_wide_int <wi::extended_tree <N> > wi::ints_for <generic_wide_int <wi::extended_tree <N> >, - wi::int_traits <wi::extended_tree <N> >::precision_type - >::zero (const extended &x) + wi::INL_CONST_PRECISION>::zero (const extended &x) +{ + return build_zero_cst (TREE_TYPE (x.get_tree ())); +} + +template <int N> +inline generic_wide_int <wi::extended_tree <N> > +wi::ints_for <generic_wide_int <wi::extended_tree <N> >, + wi::CONST_PRECISION>::zero (const extended &x) { return build_zero_cst (TREE_TYPE (x.get_tree ())); } --- gcc/rtl.h.jj 2023-09-29 22:04:44.463012421 +0200 +++ gcc/rtl.h 2023-10-12 16:54:59.915240074 +0200 @@ -2270,6 +2270,7 @@ namespace wi /* This ought to be true, except for the special case that BImode is canonicalized to STORE_FLAG_VALUE, which might be 1. */ static const bool is_sign_extended = false; + static const bool needs_write_val_arg = false; static unsigned int get_precision (const rtx_mode_t &); static wi::storage_ref decompose (HOST_WIDE_INT *, unsigned int, const rtx_mode_t &); --- gcc/double-int.h.jj 2023-10-12 16:01:04.260164202 +0200 +++ gcc/double-int.h 2023-10-12 16:53:41.401292272 +0200 @@ -442,6 +442,7 @@ namespace wi { static const enum precision_type precision_type = INL_CONST_PRECISION; static const bool host_dependent_precision = true; + static const bool needs_write_val_arg = false; static const unsigned int precision = HOST_BITS_PER_DOUBLE_INT; static unsigned int get_precision (const double_int &); static wi::storage_ref decompose (HOST_WIDE_INT *, unsigned int, fix this? It works for me in stage3 gcc subdir, but that worked fine without it too (I've been using g++ 12 as stage1 compiler).
next prev parent reply other threads:[~2023-10-12 15:11 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-12 15:08 [Bug bootstrap/111787] New: [14 regression] xxx " seurer at gcc dot gnu.org 2023-10-12 15:11 ` jakub at gcc dot gnu.org [this message] 2023-10-12 15:23 ` [Bug bootstrap/111787] [14 regression] r14-4592-g0d00385eaf72cc " seurer at gcc dot gnu.org 2023-10-12 15:24 ` cvs-commit at gcc dot gnu.org 2023-10-13 6:48 ` rguenth 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-111787-4-0vupwdaiEi@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).