https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127848
Bug ID: 127848
Summary: Incorrect tail call optimization with _BitInt return
types
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
unsigned _BitInt(15) foo ();
unsigned short bar () { return foo (); }
unsigned _BitInt(16) baz ();
signed _BitInt(16) qux () { return baz (); }
is miscompiled on e.g. x86_64-linux (bar) at -O2 or could be miscompiled on
some of the bitint_ext_{full,partial} targets in qux.
We can't tail call in bar on x86_64, because it is bitint_ext_undef target and
while on that particular target upper bits of unsigned short are also
undefined, bit 15 needs to be cleared.
Similarly in the qux case on != bitint_ext_undef targets, we need to sign
extend the result where it has been zero extended before (at least when passed
in 32-bit/64-bit register).
The problem is that tree-tailcall.cc has:
/* Reject a tailcall if the type conversion might need
additional code. */
if (gimple_assign_cast_p (stmt))
{
if (TYPE_MODE (TREE_TYPE (dest)) != TYPE_MODE (TREE_TYPE (src_var)))
return FAIL;
/* Even if the type modes are the same, if the precision of the
type is smaller than mode's precision,
reduce_to_bit_field_precision would generate additional code. */
if (INTEGRAL_TYPE_P (TREE_TYPE (dest))
&& !type_has_mode_precision_p (TREE_TYPE (dest)))
return FAIL;
}
The type_has_mode_precision_p check (but for dest only) has been added there by
me for PR60971, i.e. for the unsigned char -> bool case.
I'd say we need to punt also for the case where one type is BITINT_TYPE and
another one is not BITINT_TYPE (i.e. BITINT_TYPE_P (TREE_TYPE (dest)) !=
BITINT_TYPE_P (TREE_TYPE (src_var)) because the GIMPLE pass simply has no
information how the bitint vs. normal integer passing differs, and for
BITINT_TYPE_P cases on both sides with the same TYPE_MODE it will depend on
bitint_ext_* - for bitint_ext_undef narrowing conversion or same precision
conversion with different signedness is fine, widening is not. For
bitint_ext_full, widening conversion with same signedness is fine, different
signedness is not fine, narrowing is not fine. And bitint_ext_partial I think
I'm not motivated enough to care, so punt always.
