From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 780EE3857C43; Fri, 4 Mar 2022 13:46:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 780EE3857C43 From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux Date: Fri, 04 Mar 2022 13:46:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: segher at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Fri, 04 Mar 2022 13:46:42 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99708 --- Comment #20 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #19) > I'd guess that else ieee128_float_type_node =3D ibm128_float_type_node =3D > long_double_type_node; > is there so that we don't ICE during the builtins creation Probably. But is is completely wrong, and causes pretty bad problems for a tiny short-term benefit, as this whole affair shows. > Looking at other uses: > rs6000_type_string does: > else if (type_node =3D=3D ibm128_float_type_node) > return "__ibm128"; > could add type_node && to it. Yes. > And it also makes me wonder why there is no ieee128_float_type_node case. Good question :-( > Rest of rs6000-builtin.cc is just the setup and could live without > else ieee128_float_type_node =3D ibm128_float_type_node =3D > long_double_type_node; Or =3D 0 even. Yes. > Also, why do we have ptr_*_float_type_node at all when nothing uses those? Maybe the old builtin stuff used that? Dunno, just guessing. > rs6000.cc will be fine even with *128_float_type_node NULL, > long_double_type_node is presumably always non-NULL. I sure hope so, it is a required type after all :-) > rs6000-c.cc is what this PR talks about, so actually needs those to be NU= LL > if not supported > (but, we still want to move the __SIZEOF_FLOAT128__ handling next to > __float128 macro IMNSHO, > if we add also __SIZEOF_IEEE128__ it could stay where __SIZEOF_FLOAT128__= is > defined now). I'm not sure what that would look like? I certainly do agree that the code= is a bit of a mess and could use some improvement. > And finally the generated rs6000-builtins.cc, it does: > tree df_ftype_if_ci > =3D build_function_type_list (double_type_node, > ibm128_float_type_node, > integer_type_node, > NULL_TREE); > tree if_ftype_df_df > =3D build_function_type_list (ibm128_float_type_node, > double_type_node, > double_type_node, > NULL_TREE); > rs6000_builtin_info[RS6000_BIF_PACK_IF].fntype > =3D if_ftype_df_df; > rs6000_builtin_decls[(int)RS6000_BIF_PACK_IF] =3D t > =3D add_builtin_function ("__builtin_pack_ibm128", > if_ftype_df_df, > (int)RS6000_BIF_PACK_IF, BUILT_IN_MD, > NULL, NULL_TREE); > TREE_READONLY (t) =3D 1; > TREE_NOTHROW (t) =3D 1; > rs6000_builtin_info[RS6000_BIF_UNPACK_IF].fntype > =3D df_ftype_if_ci; > rs6000_builtin_decls[(int)RS6000_BIF_UNPACK_IF] =3D t > =3D add_builtin_function ("__builtin_unpack_ibm128", > df_ftype_if_ci, > (int)RS6000_BIF_UNPACK_IF, BUILT_IN_MD, > NULL, NULL_TREE); > TREE_READONLY (t) =3D 1; > TREE_NOTHROW (t) =3D 1; > Unfortunately it is a generated file. Dunno what is best for that, > not registering the builtins at all if ibm128_float_type_node is NULL, > or keep doing what it used to, register those with some other type. Either choice will not change the semantics of any valid program, so that is good. Of course it isn't very friendly to ICE on incorrect programs ;-) Maybe we can register the builtins with zero type just like we do already, or maybe a void type or such? Is there an explicit "error" type we could u= se?=