[Bug target/104253] New: libgcc missing __floatdiif

2022-01-26 Thread murphyp at linux dot vnet.ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

Bug ID: 104253
   Summary: libgcc missing __floatdiif
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
CC: bergner at gcc dot gnu.org, meissner at gcc dot gnu.org
  Target Milestone: ---

When compiling something which uses the __ibm128 type, an instrinsic function
call is generated which is not satisfied at link time. E.g foo.c:

#include 
#include 

int main(int a, char **v)
{
long d = strtol(v[1],0,0);
__ibm128 i = d;
printf("%a
%a\n",__builtin_unpack_ibm128(i,0),__builtin_unpack_ibm128(i,1));
return 0;
}

gcc -O2 foo.c -o foo:
/usr/bin/ld: /tmp/ccuWW1m0.o: in function `main':
foo.c:(.text.startup+0x2c): undefined reference to `__floatdiif'
collect2: error: ld returned 1 exit status

This happens on a ppc64le machine running fedora rawhide, gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64le-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: ppc64le-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release
--enable-targets=powerpcle-linux --disable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.0.1-20220118/obj-ppc64le-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-secureplt
--with-long-double-128 --with-long-double-format=ieee --with-cpu-32=power8
--with-tune-32=power8 --with-cpu-64=power8 --with-tune-64=power8
--build=ppc64le-redhat-linux --with-build-config=bootstrap-lto
--enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220118 (Red Hat 12.0.1-0) (GCC)

[Bug go/98610] New: syscall.TestUnshareUidGidMapping sporadically fails on powerpc64le

2021-01-08 Thread murphyp at linux dot vnet.ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98610

Bug ID: 98610
   Summary: syscall.TestUnshareUidGidMapping sporadically fails on
powerpc64le
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: murphyp at linux dot vnet.ibm.com
CC: cmang at google dot com
  Target Milestone: ---

openat is not always called through the libc variadic wrapper in libgo.  This
results in stack corruption on powerpc64le.

[Bug go/92567] libgo regression in syscall test on ppc64le resulting in timeout due to hang in read

2020-09-14 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92567

--- Comment #2 from Paul E. Murphy  ---
For clarity, the prototype of ptrace from glibc:

extern long int ptrace (enum __ptrace_request __request, ...) __THROW;

[Bug go/92567] libgo regression in syscall test on ppc64le resulting in timeout due to hang in read

2020-09-14 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92567

Paul E. Murphy  changed:

   What|Removed |Added

 CC||murphyp at linux dot 
vnet.ibm.com

--- Comment #1 from Paul E. Murphy  ---
So, this turns out to be an ABI violation of how ptrace() is called, and maybe
a documentation bug.  ptrace is actually implemented as a variadic function in
glibc which takes exactly 4 arguments, and this is not clear from the
documentation.

The golang code does not seem to allocate the parameter save space required
(2.2.2.3 of the ppc64 elfv2-1.4), and the space where golang saves the link
register gets stomped, and the forked process faults waiting for the tracer.

Newer versions of GCC seem to compile ptrace without needing to spill into the
parameter save space, so in many cases this issue is invisible.

[Bug target/94630] General bug for changes needed to switch the powerpc64le-linux long double default

2020-05-06 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630

--- Comment #8 from Paul E. Murphy  ---
The new libm/libc ABI for ieee128 long double on ppc64le is now committed to
glibc which will be available for the 2.32 release (commit
051be01f6b41a1466b07ae4bd7f5894a8ec5fe67).

TS-18661 does not specify any changes to the printf/scanf family of functions
as related to _FloatN types.  It won't always be a drop in replacement.

[Bug target/94200] -mabi=ibmlongdouble and -mlong-double-128 produces error

2020-03-17 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200

--- Comment #2 from Paul E. Murphy  ---
(In reply to Andrew Pinski from comment #1)
> >This was fixed in GCC 8, and does not happen with GCC 7.4.0
> 
> GCC 7.5.0 was the last release of GCC 7.x series.  Can you make sure it
> works with the latest GCC 8.x release?  If so then this will be closed as
> fixed.

This does work with GCC 8.3.1l and any newer versions I have tested.

[Bug c/94200] New: -mabi=ibmlongdouble and -mlong-double-128 produces error

2020-03-16 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200

Bug ID: 94200
   Summary: -mabi=ibmlongdouble and -mlong-double-128 produces
error
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---
Target: powerpc64le

When compiling an empty file with:

`touch foo.c; gcc -mabi=ibmlongdouble -mlong-double-128 foo.c`

produces the following:

gcc: warning: using IBM extended precision long double
cc1: warning: using IBM extended precision long double
cc1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’

Notably, removing the option -mlong-double-128 does not trigger the above.

This was fixed in GCC 8, and does not happen with GCC 7.4.0

[Bug c++/94080] New: -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage

2020-03-06 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080

Bug ID: 94080
   Summary: -mabi=ieeelongdouble and -mfloat128 cause libstc++
header breakage
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---
Target: powerpc64le

When both -mfloat128 and -mabi=ieeelongdouble are used, various libstc++
headers break.  I suspect more headers have similar problems.

I.e "#include ":

cc1plus: warning: Using IEEE extended precision long double [-Wpsabi]
In file included from
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/move.h:55,
 from
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/stl_pair.h:59,
 from
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/utility:70,
 from
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/algorithm:60,
 from foo.c:1:
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/type_traits:346:12:
error: redefinition of ‘struct std::__is_floating_point_helper’
  346 | struct __is_floating_point_helper<__float128>
  |^~
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/type_traits:341:12:
note: previous definition of ‘struct std::__is_floating_point_helper’
  341 | struct __is_floating_point_helper
  |^~~
In file included from
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/cstdlib:77,
 from
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/stl_algo.h:59,
 from
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/algorithm:62,
 from foo.c:1:
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/std_abs.h:103:3:
error: redefinition of ‘constexpr long double std::abs(long double)’
  103 |   abs(__float128 __x)
  |   ^~~
/home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/std_abs.h:79:3:
note: ‘constexpr long double std::abs(long double)’ previously defined here
   79 |   abs(long double __x)
  |   ^~~

[Bug target/92635] New: __builtin_finited{32,64,128} should inline

2019-11-22 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92635

Bug ID: 92635
   Summary: __builtin_finited{32,64,128} should inline
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---
Target: powerpc

Inline ASM is not ideal since dfp classification instructions targets CRs.

e.g for _Decimal128:

inline _Decimal128
___isfinited128 (_Decimal128 x)
{
  int cr0;

  asm ("dtstdcq cr0,%1,0x38\n"
   "mfcr %0, 128\n"
: "=r" (cr0)
: "f" (x)
 : "cr0");

  return (cr0 & 0x2000) ? 1 : 0;
};

[Bug target/92488] New: GCC generates to calls to __dpd_trunctdsd2 with -mhard-dfp

2019-11-12 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

Bug ID: 92488
   Summary: GCC generates to calls to __dpd_trunctdsd2 with
-mhard-dfp
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---

While cleaning up libdfp, I noticed GCC still leans on libgcc to perform
_Decimal128 to _Decimal32 truncation.

This can be inlined with 4-5 instructions depending on ISA using the "round to
prepare for shorter precision" rounding mode supported on all PPC DFP targets:

mffsfp4 /* Save current rounding mode.  */
mtfsfi  7, 7, 1 /* Set round to prepare for shorter.  */
drdpq   fp0,fp2 /* Initial round to _Decimal64.  */
mtfsf   0xff,fp4,1,0 /* Restore previous rounding mode.  */
drspfp1,fp0 /* Round result to _Decimal32.  */

mffs/mtsfi could be substituted for "mffscdrni fp4, 7" on ISA 3.0 and above.

e.g the following trivial example:

_Decimal32
truncd128(_Decimal128 d)
{
  return d;
}

[Bug target/91903] vec_ctf altivec intrinsic can cause ICE on powerpc

2019-09-26 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903

--- Comment #2 from Paul E. Murphy  ---
I tried this out on IBM's new AT13 compiler (GCC 9.2.1):

/opt/at13.0/bin/powerpc64le-linux-gnu-gcc -c test.c 
during RTL pass: expand
test.c: In function ‘test’:
test.c:5:5: internal compiler error: in copy_to_mode_reg, at explow.c:629
5 | ret = vec_ctf(a,b);
  | ^~
0x735d8b copy_to_mode_reg(machine_mode, rtx_def*)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/explow.c:629
0xca0c21 rs6000_expand_binop_builtin
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/config/rs6000/rs6000.c:13787
0xcd0732 rs6000_expand_builtin
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/config/rs6000/rs6000.c:16619
0x64158c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/builtins.c:7236
0x74c180 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:11030
0x755bca store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:5674
0x756bd0 expand_assignment(tree_node*, tree_node*, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:5436
0x660440 expand_call_stmt
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:2722
0x660440 expand_gimple_stmt_1
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:3691
0x660440 expand_gimple_stmt
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:3850
0x6650bf expand_gimple_basic_block
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:5890
0x6676d6 execute
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:6513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/91903] New: vec_ctf altivec intrinsic can cause ICE on powerpc

2019-09-25 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903

Bug ID: 91903
   Summary: vec_ctf altivec intrinsic can cause ICE on powerpc
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---

I was running some tests against the powerpc altivec intrinsics and the
following dubious usage of vec_ctf causes an ICE using "gcc -c test.c":



#include 
vector double test(vector unsigned long a, const int b)
{
vector double ret;
ret = vec_ctf(a,b);
return ret;
}



during RTL pass: expand
test.c: In function ‘test’:
test.c:5:5: internal compiler error: in copy_to_mode_reg, at explow.c:630
 ret = vec_ctf(a,b);
 ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/7/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-objc-gc=auto
--enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux
--disable-multilib --enable-multiarch --disable-werror --with-long-double-128
--enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)


[Bug target/71869] __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.

2016-07-14 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869

--- Comment #1 from Paul E. Murphy  ---
__builtin_isfinite also has a similar issue.

[Bug c/71869] New: __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.

2016-07-13 Thread murphyp at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869

Bug ID: 71869
   Summary: __builtin_isgreater raises an invalid exception on
PPC64 using __float128 inputs.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---

#include 
volatile __float128 qnan = __builtin_nanq("");
int main()
{
feclearexcept(FE_INVALID);
if (__builtin_isgreater(1.0Q, qnan)) puts("isgreater is broken");
if (fetestexcept(FE_INVALID)) puts("invalid wrongly set for quiet
comparison");
return 0;
}

Using a recent gcc-6-branch checkout:
gcc -mfloat128 -mcpu=power8

I assume this also the case for the other __builtin_is{ordering} functions too.

This causes a substantial number of test failures for float128 when shoehorned
into the glibc libm test suite. (Note, this is much hacked up local copy of
glibc to verify the compiler support for float128 is sufficient for glibc).

x86 appears to stick a call to __unordtf2 before attempting to call the
comparison function.  I assume PPC64 should be doing a similar for KFmode.