https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
CC| |jsm28 at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I suspect we fail to round at parsing time. I see we get to see
<excess_precision_expr 0x7ffff6bb6500
type <real_type 0x7ffff6a33888 __bf16 BF
size <integer_cst 0x7ffff6a2d108 constant 16>
unit-size <integer_cst 0x7ffff6a2d120 constant 2>
align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6a33888 precision:16>
arg:0 <real_cst 0x7ffff6be06f0
type <real_type 0x7ffff6a332a0 float SF
size <integer_cst 0x7ffff6a2d198 constant 32>
unit-size <integer_cst 0x7ffff6a2d1b0 constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6a332a0 precision:32
pointer_to_this <pointer_type 0x7ffff6a33930>>
constant 2.57e+2>
and then upon processing the (int) cast simply strip the excess_precision_expr.
#0 convert (type=<integer_type 0x7ffff6a2b5e8 int>,
expr=<real_cst 0x7ffff6be0930>)
at /home/rguenther/src/trunk/gcc/c/c-convert.cc:253
#1 0x0000000000d8e9e2 in build_c_cast (loc=263296,
type=<integer_type 0x7ffff6a2b5e8 int>, expr=<real_cst 0x7ffff6be0930>)
at /home/rguenther/src/trunk/gcc/c/c-typeck.cc:6387
#2 0x0000000000d8f01c in c_cast_expr (loc=263296, type_name=0x46c6760,
expr=<excess_precision_expr 0x7ffff6bb6640>)
at /home/rguenther/src/trunk/gcc/c/c-typeck.cc:6461
/* Build an expression representing a cast to type TYPE of expression EXPR.
LOC is the location of the cast-- typically the open paren of the cast. */
tree
build_c_cast (location_t loc, tree type, tree expr)
{
tree value;
bool int_operands = EXPR_INT_CONST_OPERANDS (expr);
if (TREE_CODE (expr) == EXCESS_PRECISION_EXPR)
expr = TREE_OPERAND (expr, 0);
But maybe that's correct behavior here? Or we shouldn't have an
excess_precision_expr in the first place for BF16?
