From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AD405385734D; Wed, 5 Oct 2022 16:47:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD405385734D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664988452; bh=JG+Pn3deJkjj7NT+UGG0rk3Xfh5ztupxudLAiOCVFYM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=balyPOKbc3dzIVBkJxnJsGNtr5N/bAmtbDUPU1lUSMsIT1skYunw3Bxwr/zAwgpB4 PHv7ZLE/mfW/wQ9/LtBy3O1CqGTVCEdQ1lHSQZb8LFK/hpu1vEUWYm/T1l90vzzeTu wTmq2N4BeRQAe7frvwEE69Hd/KB/KAL2pQKtG5JQ= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/107097] Implement floating point excess precision in C++ Date: Wed, 05 Oct 2022 16:47:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107097 --- Comment #5 from Jakub Jelinek --- Seems in that case we loose the precision in: #0 fold_convert_loc (loc=3D0, type=3D, arg=3D) at ../../gcc/fold-const.cc:2436 #1 0x000000000049c414 in cxx_eval_constant_expression (ctx=3D0x7fffffffcc9= 0, t=3D, lval=3Dvc_prvalue, non_constant_p=3D0x7fffffffcdaf,=20 overflow_p=3D0x7fffffffcdae, jump_target=3D0x0) at ../../gcc/cp/constexpr.cc:7541 #2 0x000000000049e566 in cxx_eval_outermost_constant_expr (t=3D, allow_non_constant=3Dtrue, strict=3Dtrue, manifestly_const_eval=3Dfalse,=20 constexpr_dtor=3Dfalse, object=3D) at ../../gcc/cp/constexpr.= cc:7970 #3 0x000000000049f3b3 in maybe_constant_value (t=3D, decl=3D, manifestly_const_eval=3Dfalse) at ../../gcc/cp/constexpr.cc:8240 #4 0x00000000004e0a81 in cp_fully_fold (x=3D) at ../../gcc/cp/cp-gimplify.cc:2367 #5 0x00000000004ef3ad in cp_convert_and_check (type=3D, expr=3D, complain=3D3) = at ../../gcc/cp/cvt.cc:666 #6 0x000000000042b4e1 in convert_like_internal (convs=3D0x3b516a0, expr=3D, fn=3D, argnum=3D0, issue_conversion_warnings=3Dtrue,=20 c_cast_p=3Dfalse, complain=3D3) at ../../gcc/cp/call.cc:8549 #7 0x000000000042b765 in convert_like (convs=3D0x3b516a0, expr=3D, fn=3D, argnum=3D0, issue_conversion_warnings=3Dtrue, c_cast_p=3Dfalse,=20 complain=3D3) at ../../gcc/cp/call.cc:8604 #8 0x000000000042b7d8 in convert_like (convs=3D0x3b516a0, expr=3D, complain=3D3) at ../../gcc/cp/call.cc:8616 #9 0x000000000043da51 in perform_implicit_conversion_flags (type=3D, expr=3D, complain=3D3, flags=3D262149) at ../../gcc/cp/call.cc:12999 #10 0x0000000000845343 in convert_for_assignment (type=3D, rhs=3D, errtype=3DICR_INIT, fndecl=3D,=20 parmnum=3D0, complain=3D3, flags=3D262149) at ../../gcc/cp/typeck.cc:10= 332 #11 0x00000000008459f4 in convert_for_initialization (exp=3D, type=3D, rhs=3D, flags=3D262149,=20 errtype=3DICR_INIT, fndecl=3D, parmnum=3D0, complain=3D3) at ../../gcc/cp/typeck.cc:10423 #12 0x000000000085075d in digest_init_r (type=3D, init=3D, nested=3D0, flags= =3D262149, complain=3D3) at ../../gcc/cp/typeck2.cc:1276 #13 0x0000000000850e84 in digest_init_flags (type=3D, init=3D, flags=3D262149, complain=3D3) at ../../gcc/cp/typeck2.cc:1380 #14 0x000000000084eaff in store_init_value (decl=3D, init=3D, cleanups=3D0x7ffffff= fd668, flags=3D262149) at ../../gcc/cp/typeck2.cc:829 #15 0x00000000005270c3 in check_initializer (decl=3D, init=3D, flags=3D5, cleanups=3D0x7fffffffd668) at ../../gcc/cp/decl.cc:7466 #16 0x000000000052d248 in cp_finish_decl (decl=3D, init=3D, init_const_expr_p=3Dtrue, asmspec_tree=3D,=20 flags=3D5) at ../../gcc/cp/decl.cc:8468 Supposedly we should somewhere (temporarily) strip away the EXCESS_PRECISION_EXPR and readd it after conversion, but it is unclear to me where and under what conditions. Somewhere where we know it is an implicit conversion (because explicit conversion should round to semantic type)? And only when converting (implicitly) to some other REAL_TYPE/COMPLEX_TYPE? I mean, if we say try to initialize a class from some floating point value,= we should determine that conversion from the semantic type. On the other side, e.g. for implicit conversion to bool, shouldn't we do th= e !=3D 0 comparison in excess precision? The C patch strips EXCESS_PRECISION_EXPR unconditionally at the start of the function. So perhaps strip it in convert_for_assignment or perform_implicit_conversion_flags if type is arithmetic type (dunno about enums) only?=