[Bug libgcc/114907] New: Missing __extendhfbf2 in libgcc

[Bug libgcc/114907] New: Missing __extendhfbf2 in libgcc

[hjl.tools at gmail dot com]

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

            Bug ID: 114907
           Summary: Missing __extendhfbf2 in libgcc
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: crazylht at gmail dot com
  Target Milestone: ---
            Target: x86-64

From https://sourceware.org/bugzilla/show_bug.cgi?id=31685

$ cat x.cc
#include <stdlib.h>
#include <cstdint>
#include <array>
#include <iostream>

#define SIZE 8

typedef _Float16 T;
//typedef volatile float T;

void fp16tobf16(_Float16 * f) {
        __bf16 * b = reinterpret_cast<__bf16*>(f);
        for(int i=0; i<SIZE; i++){
            T temp = f[i];
            b[i] = (__bf16) temp;
        }
}

int main(){

    std::array<_Float16, SIZE> a{};
    std::fill(a.begin(), a.end(), (_Float16) 1.7653432432424324);
    fp16tobf16(a.data());

    __bf16 * b = reinterpret_cast<__bf16*>(a.data());

    std::cout << "\n";
    for(int i=0; i<SIZE; i++)
        std::cout << ((double) b[i]) << "\n";

    return 0;
}
$ g++ -O0 -std=c++23 x.cc
/usr/local/bin/ld: /tmp/ccWrIm0Z.o: in function `fp16tobf16(_Float16*)':
x.cc:(.text+0x4d): undefined reference to `__extendhfbf2'
collect2: error: ld returned 1 exit status
$

[Bug libgcc/114907] Missing __extendhfbf2 in libgcc

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
There is __trunchfbf2.  Why does GCC generate __extendhfbf2?

[Bug libgcc/114907] Missing __extendhfbf2 in libgcc

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-05-01
             Status|UNCONFIRMED                 |NEW

[Bug libgcc/114907] Missing __extendhfbf2 in libgcc

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
[hjl@gnu-cfl-3 pr114907]$ cat foo.c
__bf16
foo (_Float16 x)
{
  return x;
}
[hjl@gnu-cfl-3 pr114907]$ make CC=gcc
gcc -O2 -S foo.c
[hjl@gnu-cfl-3 pr114907]$ cat foo.s
        .file   "foo.c"
        .text
        .p2align 4
        .globl  foo
        .type   foo, @function
foo:
.LFB0:
        .cfi_startproc
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        call    __extendhfbf2
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        ret
        .cfi_endproc
.LFE0:
        .size   foo, .-foo
        .globl  __extendhfbf2
        .ident  "GCC: (GNU) 14.0.1 20240411 (Red Hat 14.0.1-0)"
        .section        .note.GNU-stack,"",@progbits
[hjl@gnu-cfl-3 pr114907]$

[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Missing __extendhfbf2 in    |__trunchfbf2 should be
                   |libgcc                      |renamed to __extendhfbf2

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
convert_mode_scalar has

     if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
        /* Conversion between decimal float and binary float, same size.  */
        tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;

Since for HF->BF, DECIMAL_FLOAT_MODE_P (from_mode) is false, tab is sext_optab
and __trunchfbf2 should be renamed to __extendhfbf2.

[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #3)
> convert_mode_scalar has
> 
>      if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
>         /* Conversion between decimal float and binary float, same size.  */
>         tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
> 
> Since for HF->BF, DECIMAL_FLOAT_MODE_P (from_mode) is false, tab is
> sext_optab
> and __trunchfbf2 should be renamed to __extendhfbf2.

Since BFmode range is bigger than HFmode, __trunchfbf2 should be used.

[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #4)
> (In reply to H.J. Lu from comment #3)
> > convert_mode_scalar has
> > 
> >      if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
> >         /* Conversion between decimal float and binary float, same size.  */
> >         tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
> > 
> > Since for HF->BF, DECIMAL_FLOAT_MODE_P (from_mode) is false, tab is
> > sext_optab
> > and __trunchfbf2 should be renamed to __extendhfbf2.
> 
> Since BFmode range is bigger than HFmode, __trunchfbf2 should be used.

Opp, __extendhfbf2 is correct.

[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Neither of the modes is a subset or superset of the other, so truncate vs.
extend makes no sense.  The choice was arbitrary.

[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2

[liuhongt at gcc dot gnu.org]

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

Hongtao Liu <liuhongt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liuhongt at gcc dot gnu.org

--- Comment #7 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> Neither of the modes is a subset or superset of the other, so truncate vs.
> extend makes no sense.  The choice was arbitrary.

It sounds to me we need to define an alias of
strong_alias (__trunchfbf2, __extendhfbf2)

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 58108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58108&action=edit
gcc15-pr114907.patch

In retrospect, it has been a mistake to export __trunchfbf2 rather than
__extendhfbf2, but we've done that already.
Given that it is an arbitrary name choice (both are wrong), I think it is
better to change what gcc emits rather than what functions libgcc exports,
because we can backport what gcc emits but can't the libgcc changes.

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC 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:28ee13db2e9d995bd3728c4ff3a3545e24b39cd2

commit r15-303-g28ee13db2e9d995bd3728c4ff3a3545e24b39cd2
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 7 21:30:21 2024 +0200

    expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

    The HF and BF modes have the same size/precision and neither is
    a subset nor superset of the other.
    So, using either __extendhfbf2 or __trunchfbf2 is weird.
    The expansion apparently emits __extendhfbf2, but on the libgcc side
    we apparently have __trunchfbf2 implemented.

    I think it is easier to switch to using what is available rather than
    adding new entrypoints to libgcc, even alias, because this is backportable.

    2024-05-07  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/114907
            * expr.cc (convert_mode_scalar): Use trunc_optab rather than
            sext_optab for HF->BF conversions.
            * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

            * gcc.dg/pr114907.c: New test.

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r14-10181-gf43f346f19889a15a171a10c6ae1b1fe0a5bc038
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 7 21:30:21 2024 +0200

    expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

    The HF and BF modes have the same size/precision and neither is
    a subset nor superset of the other.
    So, using either __extendhfbf2 or __trunchfbf2 is weird.
    The expansion apparently emits __extendhfbf2, but on the libgcc side
    we apparently have __trunchfbf2 implemented.

    I think it is easier to switch to using what is available rather than
    adding new entrypoints to libgcc, even alias, because this is backportable.

    2024-05-07  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/114907
            * expr.cc (convert_mode_scalar): Use trunc_optab rather than
            sext_optab for HF->BF conversions.
            * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

            * gcc.dg/pr114907.c: New test.

    (cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed for 14.2+ for now.

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r13-8734-gcad27df08915ead8db3c7d512cfcc1866e7ece69
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 7 21:30:21 2024 +0200

    expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

    The HF and BF modes have the same size/precision and neither is
    a subset nor superset of the other.
    So, using either __extendhfbf2 or __trunchfbf2 is weird.
    The expansion apparently emits __extendhfbf2, but on the libgcc side
    we apparently have __trunchfbf2 implemented.

    I think it is easier to switch to using what is available rather than
    adding new entrypoints to libgcc, even alias, because this is backportable.

    2024-05-07  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/114907
            * expr.cc (convert_mode_scalar): Use trunc_optab rather than
            sext_optab for HF->BF conversions.
            * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

            * gcc.dg/pr114907.c: New test.

    (cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed also for 13.3.