[0/2] Repost of patches for solving the build on Fedora 36 problem

  I'm reposting these two patches that allow GCC to build on Fedora 36 just to be
clear which patches I'm talking about.  The issue is that if GCC is configured
with long double using the IEEE 128-bit representation, it currently cannot
build _mulkc3 and _divkc3 in libgcc.

Note, these patches do not solve the underlying problem of mixing _Float128 and
long double types and using built-in functions (i.e. calling a _Float128
built-in function with long double arguments when long double is IEEE 128-bit,
or vice versa calling a long double built-in function with _Float128
arguments).  But they do allow the compiler to build.

Note, it is the morning of February 3rd, and I will be off on vacation from
February 7th through February 14th.

The first patch changes libgcc so that it uses either _Float128 or long double
as the base IEEE 128-bit type, depending on whether long double uses the IBM
double-double representation, or the IEEE 128-bit representation.  And for the
complex type it uses _Complex _Float128 or _Complex long double.  The _mulkc3
and _divkc3 functions are adjusted to use the f128 built-in functions or the
long double built-in functions, based on the long double type.

The second patch improves how the compiler generates the call to _mulkc3 and
_divkc3.  I've discovered as I have tried to fix underlying problem with the
IEEE 128-bit floating point types, it breaks the calls for IEEE 128-bit complex
multiply and divide.  This patch uses a cleaner approach to generate these
calls, and it will work with the current setup, and with the various fixes that
I've attempted to do to fix the underlying problem.
  

On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> I'm reposting these two patches that allow GCC to build on Fedora 36 just to be
> clear which patches I'm talking about.  The issue is that if GCC is configured
> with long double using the IEEE 128-bit representation, it currently cannot
> build _mulkc3 and _divkc3 in libgcc.

It's interesting that we do not see this with openSUSE where I configure with

--with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee
--with-long-double-128

note this is ppc64le, we leave ppc64 and ppc with their default.

> Note, these patches do not solve the underlying problem of mixing _Float128 and
> long double types and using built-in functions (i.e. calling a _Float128
> built-in function with long double arguments when long double is IEEE 128-bit,
> or vice versa calling a long double built-in function with _Float128
> arguments).  But they do allow the compiler to build.
>
> Note, it is the morning of February 3rd, and I will be off on vacation from
> February 7th through February 14th.
>
> The first patch changes libgcc so that it uses either _Float128 or long double
> as the base IEEE 128-bit type, depending on whether long double uses the IBM
> double-double representation, or the IEEE 128-bit representation.  And for the
> complex type it uses _Complex _Float128 or _Complex long double.  The _mulkc3
> and _divkc3 functions are adjusted to use the f128 built-in functions or the
> long double built-in functions, based on the long double type.
>
> The second patch improves how the compiler generates the call to _mulkc3 and
> _divkc3.  I've discovered as I have tried to fix underlying problem with the
> IEEE 128-bit floating point types, it breaks the calls for IEEE 128-bit complex
> multiply and divide.  This patch uses a cleaner approach to generate these
> calls, and it will work with the current setup, and with the various fixes that
> I've attempted to do to fix the underlying problem.
>
> --
> Michael Meissner, IBM
> PO Box 98, Ayer, Massachusetts, USA, 01432
> email: meissner@linux.ibm.com
  

On 2/3/23 1:42 AM, Richard Biener wrote:
> On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> I'm reposting these two patches that allow GCC to build on Fedora 36 just to be
>> clear which patches I'm talking about.  The issue is that if GCC is configured
>> with long double using the IEEE 128-bit representation, it currently cannot
>> build _mulkc3 and _divkc3 in libgcc.
> 
> It's interesting that we do not see this with openSUSE where I configure with
> 
> --with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee
> --with-long-double-128
> 
> note this is ppc64le, we leave ppc64 and ppc with their default.

That's strange, Bill just retested on our ppc64le openSUSE Tumbleweed system
using basically the same configure options and sees the ICE:

/home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c: In function '__mulkc3_sw':
/home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c:97:1: internal compiler error: in fold_stmt, at gimple-range-fold.cc:522

He did not specify --with=cpu= or --with-tune=, which means he got
power8 defaults for both of those.  It's hard for me to believe that
--with-tune=power9 could hide the issue, but we'll try that configuration
too.  Do you have any other configure options that might affect things?

Peter
  

On Mon, Feb 6, 2023 at 7:28 PM Peter Bergner <bergner@linux.ibm.com> wrote:
>
> On 2/3/23 1:42 AM, Richard Biener wrote:
> > On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> I'm reposting these two patches that allow GCC to build on Fedora 36 just to be
> >> clear which patches I'm talking about.  The issue is that if GCC is configured
> >> with long double using the IEEE 128-bit representation, it currently cannot
> >> build _mulkc3 and _divkc3 in libgcc.
> >
> > It's interesting that we do not see this with openSUSE where I configure with
> >
> > --with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee
> > --with-long-double-128
> >
> > note this is ppc64le, we leave ppc64 and ppc with their default.
>
> That's strange, Bill just retested on our ppc64le openSUSE Tumbleweed system
> using basically the same configure options and sees the ICE:
>
> /home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c: In function '__mulkc3_sw':
> /home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c:97:1: internal compiler error: in fold_stmt, at gimple-range-fold.cc:522
>
> He did not specify --with=cpu= or --with-tune=, which means he got
> power8 defaults for both of those.  It's hard for me to believe that
> --with-tune=power9 could hide the issue, but we'll try that configuration
> too.  Do you have any other configure options that might affect things?

The full configure is

../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,jit,m2
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/13
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp
--disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1
--enable-plugin --with-bugurl=https://bugs.opensuse.org/
'--with-pkgversion=SUSE Linux' --with-slibdir=/lib64
--with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-13 --without-system-libunwind --with-cpu=power8
--with-tune=power9 --with-long-double-format=ieee --enable-secureplt
--with-long-double-128 --enable-targets=powerpcle-linux
--disable-multilib --with-build-config=bootstrap-lto-lean
--enable-link-mutex --build=powerpc64le-suse-linux
--host=powerpc64le-suse-linux

and _mulkc3.c is built like

/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5679/obj-powerpc64le-suse-linux/./gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5679/obj-powerpc64le-suse-linux/./gcc/
-B/usr/powerpc64le-suse-linux/bin/ -B/usr/powerpc64le-suse-linux/lib/
-isystem /usr/powerpc64le-suse-linux/include -isystem
/usr/powerpc64le-suse-linux/sys-include   -fno-checking -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection
-Werror=return-type -g -U_FORTIFY_SOURCE -O2  -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=3 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g -U_FORTIFY_SOURCE
-DIN_GCC -fPIC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -fPIC -mlong-double-128 -mno-minimal-toc -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/.
-I../../../libgcc/../gcc -I../../../libgcc/../include
-I../../../libgcc/../libdecnumber/dpd
-I../../../libgcc/../libdecnumber -DHAVE_CC_TLS  -Wno-type-limits
-mvsx -mfloat128 -mno-float128-hardware -mno-gnu-attribute
-I../../../libgcc/soft-fp -I../../../libgcc/config/rs6000
-DFLOAT128_HW_INSNS -DFLOAT128_HW_INSNS_ISA3_1  -o _mulkc3.o -MT
_mulkc3.o -MD -MP -MF _mulkc3.dep  -c
../../../libgcc/config/rs6000/_mulkc3.c -fvisibility=hidden
-DHIDE_EXPORTS

>
> Peter
>
>
  

On Tue, Feb 07, 2023 at 03:22:41PM +0100, Richard Biener via Gcc-patches wrote:
> > He did not specify --with=cpu= or --with-tune=, which means he got
> > power8 defaults for both of those.  It's hard for me to believe that
> > --with-tune=power9 could hide the issue, but we'll try that configuration
> > too.  Do you have any other configure options that might affect things?
> 
> The full configure is
> 
> ../configure --prefix=/usr --infodir=/usr/share/info
> --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
> --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,jit,m2
> --enable-host-shared --enable-checking=release --disable-werror
> --with-gxx-include-dir=/usr/include/c++/13
> --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp
> --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1
> --enable-plugin --with-bugurl=https://bugs.opensuse.org/
> '--with-pkgversion=SUSE Linux' --with-slibdir=/lib64
> --with-system-zlib --enable-libstdcxx-allocator=new
> --disable-libstdcxx-pch --enable-version-specific-runtime-libs
> --with-gcc-major-version-only --enable-linker-build-id
> --enable-linux-futex --enable-gnu-indirect-function
> --program-suffix=-13 --without-system-libunwind --with-cpu=power8
> --with-tune=power9 --with-long-double-format=ieee --enable-secureplt
> --with-long-double-128 --enable-targets=powerpcle-linux
> --disable-multilib --with-build-config=bootstrap-lto-lean
> --enable-link-mutex --build=powerpc64le-suse-linux
> --host=powerpc64le-suse-linux
> 
> and _mulkc3.c is built like

We do not get the ICE in Fedora builds either.  The important thing is
--enable-checking=release
With release checking there is no ICE, with checking there is one.

	Jakub