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?