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
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
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;
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
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 a
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
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
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
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
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
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
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":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869
--- Comment #1 from Paul E. Murphy ---
__builtin_isfinite also has a similar issue.
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(
14 matches
Mail list logo
