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 c++/107097] Implement floating point excess precision in C++
Date: Wed, 05 Oct 2022 16:47:31 +0000	[thread overview]
Message-ID: <bug-107097-4-3lkXYRe3qP@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-107097-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107097

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems in that case we loose the precision in:
#0  fold_convert_loc (loc=0, type=<real_type 0x7fffea1582a0 float>,
arg=<real_cst 0x7fffea2af480>) at ../../gcc/fold-const.cc:2436
#1  0x000000000049c414 in cxx_eval_constant_expression (ctx=0x7fffffffcc90,
t=<excess_precision_expr 0x7fffea290960>, lval=vc_prvalue,
non_constant_p=0x7fffffffcdaf, 
    overflow_p=0x7fffffffcdae, jump_target=0x0) at
../../gcc/cp/constexpr.cc:7541
#2  0x000000000049e566 in cxx_eval_outermost_constant_expr
(t=<excess_precision_expr 0x7fffea290960>, allow_non_constant=true,
strict=true, manifestly_const_eval=false, 
    constexpr_dtor=false, object=<tree 0x0>) at ../../gcc/cp/constexpr.cc:7970
#3  0x000000000049f3b3 in maybe_constant_value (t=<excess_precision_expr
0x7fffea290960>, decl=<tree 0x0>, manifestly_const_eval=false) at
../../gcc/cp/constexpr.cc:8240
#4  0x00000000004e0a81 in cp_fully_fold (x=<excess_precision_expr
0x7fffea290960>) at ../../gcc/cp/cp-gimplify.cc:2367
#5  0x00000000004ef3ad in cp_convert_and_check (type=<real_type 0x7fffea1583f0
long double>, expr=<excess_precision_expr 0x7fffea290960>, complain=3) at
../../gcc/cp/cvt.cc:666
#6  0x000000000042b4e1 in convert_like_internal (convs=0x3b516a0,
expr=<excess_precision_expr 0x7fffea290960>, fn=<tree 0x0>, argnum=0,
issue_conversion_warnings=true, 
    c_cast_p=false, complain=3) at ../../gcc/cp/call.cc:8549
#7  0x000000000042b765 in convert_like (convs=0x3b516a0,
expr=<excess_precision_expr 0x7fffea290960>, fn=<tree 0x0>, argnum=0,
issue_conversion_warnings=true, c_cast_p=false, 
    complain=3) at ../../gcc/cp/call.cc:8604
#8  0x000000000042b7d8 in convert_like (convs=0x3b516a0,
expr=<excess_precision_expr 0x7fffea290960>, complain=3) at
../../gcc/cp/call.cc:8616
#9  0x000000000043da51 in perform_implicit_conversion_flags (type=<real_type
0x7fffea1583f0 long double>, expr=<excess_precision_expr 0x7fffea290960>,
complain=3, flags=262149)
    at ../../gcc/cp/call.cc:12999
#10 0x0000000000845343 in convert_for_assignment (type=<real_type
0x7fffea29abd0 long double>, rhs=<excess_precision_expr 0x7fffea290960>,
errtype=ICR_INIT, fndecl=<tree 0x0>, 
    parmnum=0, complain=3, flags=262149) at ../../gcc/cp/typeck.cc:10332
#11 0x00000000008459f4 in convert_for_initialization (exp=<tree 0x0>,
type=<real_type 0x7fffea29abd0 long double>, rhs=<excess_precision_expr
0x7fffea290960>, flags=262149, 
    errtype=ICR_INIT, fndecl=<tree 0x0>, parmnum=0, complain=3) at
../../gcc/cp/typeck.cc:10423
#12 0x000000000085075d in digest_init_r (type=<real_type 0x7fffea29abd0 long
double>, init=<excess_precision_expr 0x7fffea290960>, nested=0, flags=262149,
complain=3)
    at ../../gcc/cp/typeck2.cc:1276
#13 0x0000000000850e84 in digest_init_flags (type=<real_type 0x7fffea29abd0
long double>, init=<excess_precision_expr 0x7fffea290960>, flags=262149,
complain=3)
    at ../../gcc/cp/typeck2.cc:1380
#14 0x000000000084eaff in store_init_value (decl=<var_decl 0x7fffea13be10
ld11f>, init=<excess_precision_expr 0x7fffea290960>, cleanups=0x7fffffffd668,
flags=262149)
    at ../../gcc/cp/typeck2.cc:829
#15 0x00000000005270c3 in check_initializer (decl=<var_decl 0x7fffea13be10
ld11f>, init=<excess_precision_expr 0x7fffea290960>, flags=5,
cleanups=0x7fffffffd668)
    at ../../gcc/cp/decl.cc:7466
#16 0x000000000052d248 in cp_finish_decl (decl=<var_decl 0x7fffea13be10 ld11f>,
init=<excess_precision_expr 0x7fffea290960>, init_const_expr_p=true,
asmspec_tree=<tree 0x0>, 
    flags=5) 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 the !=
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?

  parent reply	other threads:[~2022-10-05 16:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-30 13:32 [Bug c++/107097] New: " jason at gcc dot gnu.org
2022-09-30 13:33 ` [Bug c++/107097] " jason at gcc dot gnu.org
2022-10-04 17:20 ` jakub at gcc dot gnu.org
2022-10-04 17:27 ` mpolacek at gcc dot gnu.org
2022-10-04 17:30 ` jakub at gcc dot gnu.org
2022-10-05 16:33 ` jakub at gcc dot gnu.org
2022-10-05 16:47 ` jakub at gcc dot gnu.org [this message]
2022-10-05 17:29 ` jakub at gcc dot gnu.org
2022-10-14  7:32 ` cvs-commit at gcc dot gnu.org
2022-10-14  7:34 ` cvs-commit at gcc dot gnu.org
2022-10-14  7:38 ` 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-107097-4-3lkXYRe3qP@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: link
Be 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).