[Bug middle-end/107703] New: Some integral to __bf16 conversions and __bf16 to integral conversions are implemented incorrectly

[Bug middle-end/107703] New: Some integral to __bf16 conversions and __bf16 to integral conversions are implemented incorrectly

[jakub at gcc dot gnu.org]

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

            Bug ID: 107703
           Summary: Some integral to __bf16 conversions and __bf16 to
                    integral conversions are implemented incorrectly
           Product: gcc
           Version: 13.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: ---

__bf16 f1 (long long x) { return x; }
__bf16 f2 (unsigned long long x) { return x; }
__bf16 f3 (int x) { return x; }
__bf16 f4 (unsigned int x) { return x; }
__bf16 f5 (short x) { return x; }
__bf16 f6 (unsigned short x) { return x; }
__bf16 f7 (signed char x) { return x; }
__bf16 f8 (unsigned char x) { return x; }
__bf16 f9 (__int128 x) { return x; }
__bf16 f10 (unsigned __int128 x) { return x; }
long long f11 (__bf16 x) { return x; }
unsigned long long f12 (__bf16 x) { return x; }
__int128 f13 (__bf16 x) { return x; }
unsigned __int128 f14 (__bf16 x) { return x; }
We implement f1 as DI->XF->BF conversion which is valid I think, because
XFmode can represent all the 63 bits exactly, for f3 SI->DF->BF too,
f5/f7 as {H,Q}I->SF->BF looks ok too.
But for f9/f10 we emit __floattibf/__floatuntibf which aren't implemented in
libgcc and I think they have to.
11 is done as BF->SF->DI which looks good, BF->SF is value preserving
conversion.
But for f12/f13 we emit __fixbfti/__fixunsbfti which again aren't implemented
and I think we need them because __BFLT16_MAX__ is (2^8 − 1) * 2^−7 * 2^127.

[Bug target/107703] TImode to __bf16 conversions and __bf16 to TImode conversions aren't implemented in libgcc

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
aarch64 isn't affected (yet), the __bf16 arithmetics support patch has just
been posted but not reviewed.  So, on arm and aarch64 __bf16 is a store only
type one can't convert to/from nor use in unary/binary operations.

[Bug target/107703] TImode to __bf16 conversions and __bf16 to TImode conversions aren't implemented in libgcc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:246127ab238bac6aa71a9b4ee1f6fabf776b5ccb

commit r13-6598-g246127ab238bac6aa71a9b4ee1f6fabf776b5ccb
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 10 20:39:54 2023 +0100

    libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf [PR107703]

    While DI <-> BF conversions can be handled (and are) through
    DI <-> XF <-> BF and for narrower integral modes even sometimes
    through DF or SF, because XFmode has 64-bit mantissa and so all
    the DImode values are exactly representable in XFmode.
    That is not the case for TImode, and while e.g. the HF -> TI
    conversions are IMHO useless in libgcc, because HFmode has
    -65504.0f16, 65504.0f16 range, all the integers will be already
    representable in SImode (or even HImode for unsigned) and so
    I think HF -> DI -> TI conversions are faster and valid,
    BFmode has roughly the same range as SFmode and so we absolutely need
    the TI -> BF conversions to avoid double rounding.

    As for BF -> TI conversions, they can be either also implemented
    in libgcc, or they can be implemented (as done in this commit)
    as BF -> SF -> TI conversions with the same code generation used
    elsewhere, just doing the 16-bit left shift of the bits - I think
    we don't need to handle sNaNs during the BF -> SF part because
    SF -> TI (which is already a libcall too) will handle that too.

    The BF -> SF -> TI path avoids wasting
        32: 0000000000015e10   321 FUNC    GLOBAL DEFAULT   13
__fixbfti@@GCC_13.0.0
        89: 0000000000015f60   299 FUNC    GLOBAL DEFAULT   13
__fixunsbfti@@GCC_13.0.0

    2023-03-10  Jakub Jelinek  <jakub@redhat.com>

            PR target/107703
            * optabs.cc (expand_fix): For conversions from BFmode to integral,
            use shifts to convert it to SFmode first and then convert SFmode
            to integral.

            * soft-fp/floattibf.c: New file.
            * soft-fp/floatuntibf.c: New file.
            * config/i386/libgcc-glibc.ver: Export __float{,un}tibf @
GCC_13.0.0.
            * config/i386/64/t-softfp (softfp_extras): Add floattibf and
            floatuntibf.
            (CFLAGS-floattibf.c, CFLAGS-floatunstibf.c): Add -msse2.

[Bug target/107703] TImode to __bf16 conversions and __bf16 to TImode conversions aren't implemented in libgcc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:c227508d06a63f9b8fede3fd88813accb447060e

commit r13-6599-gc227508d06a63f9b8fede3fd88813accb447060e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 10 20:43:58 2023 +0100

    c++ testsuite: Add test for PR107703

    This is on top of the
    https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
    and
    https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html
    patches (to be precise, the latter isn't essential for it), I've
    realized that for the PR107703 bugfix in the first patch I haven't
    added some test coverage that the extended floating vs. integral
    or vice versa conversions work correctly.

    This new testcase adds such checks.  And when writing it I've
    found that in ext-floating.h header in the testsuite I forgot back
    in November to remove #undef __STDCPP_BFLOAT16_T__ which was left
    there because the bfloat16 support wasn't in yet.

    The new testcase (and all older ext-floating*.C tests too) passes
    on vanilla trunk without the ext-floating.h change (x86_64-linux
    -m32/-m64) and with the PR107703 fix also with the ext-floating.h
    change.

    2023-03-10  Jakub Jelinek  <jakub@redhat.com>

            PR target/107703
            * g++.dg/cpp23/ext-floating.h (__STDCPP_BFLOAT16_T__): Don't
undefine
            it.
            (std::bfloat16_t): Use decltype (0.0bf16) like libstdc++, rather
than
            __bf16.
            * g++.dg/cpp23/ext-floating14.C: New test.

[Bug target/107703] TImode to __bf16 conversions and __bf16 to TImode conversions aren't implemented in libgcc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.