[Bug c/64687] New: powerpc: GCC 5.0 (trunk@219851) build failure for powerpc with hardware decimal floating point disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64687
Bug ID: 64687
Summary: powerpc: GCC 5.0 (trunk@219851) build failure for
powerpc with hardware decimal floating point disabled
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: azanella at linux dot vnet.ibm.com
Created attachment 34499
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34499action=edit
Testcase to trigger the issue
GCC 5.0 (trunk@219851) trigger the following issue when building a C file with
Decimal types for powerpc64 with hardware decimal floating point disabled
(-DSHARED -O3 -fpic -ggdb3 -mno-hard-dfp):
../libdfp-git/sysdeps/dpd/decode.c: In function ‘__decoded32’:
../libdfp-git/sysdeps/dpd/decode.c:77:1: error: insn does not satisfy its
constraints:
}
^
(insn 278 13 279 2 (set (mem/c:SD (plus:DI (reg/f:DI 1 1)
(const_int -16 [0xfff0])) [18 %sfp+48 S4 A32])
(reg:SD 33 1)) ../libdfp-git/sysdeps/dpd/decode.c:40 492
{movsd_hardfloat}
(nil))
../libdfp-git/sysdeps/dpd/decode.c:77:1: internal compiler error: in
extract_constrain_insn, at recog.c:2246
0x105f6b13 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-git/gcc/rtl-error.c:110
0x105f6b6b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-git/gcc/rtl-error.c:121
0x105bf81b extract_constrain_insn(rtx_insn*)
../../gcc-git/gcc/recog.c:2246
0x1059c8d7 reload_cse_simplify_operands
../../gcc-git/gcc/postreload.c:430
0x1059dd33 reload_cse_simplify
../../gcc-git/gcc/postreload.c:207
0x1059dd33 reload_cse_regs_1
../../gcc-git/gcc/postreload.c:246
0x1059f9d7 reload_cse_regs
../../gcc-git/gcc/postreload.c:94
0x1059f9d7 execute
../../gcc-git/gcc/postreload.c:2367
Temporary files in attachments (decode.i and decode.s), to reproduce just
issue:
$ gcc decode.i -c -DSHARED -O3 -fpic -ggdb3 -mno-hard-dfp
[Bug target/64687] powerpc: GCC 5.0 (trunk@219851) build failure for powerpc with hardware decimal floating point disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64687 --- Comment #3 from Adhemerval Zanella azanella at linux dot vnet.ibm.com --- Yes, my GCC build have -mcpu=power7 -mtune=power8 option as configure option.
[Bug target/57363] IBM long double: adding NaN and number raises inexact exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363 --- Comment #2 from Adhemerval Zanella azanella at linux dot vnet.ibm.com --- You are correct and I meant in my first comment QNaN for the NaN work. And I believe the patch is still correct: for IBM long double SNaN will be represented by first double being the NaN (the second double is ignored) and the first sum (z = a + c) will trigger exception if any.
[Bug target/57363] New: IBM long double: adding NaN and number raises inexact exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363
Bug ID: 57363
Summary: IBM long double: adding NaN and number raises inexact
exception
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: azanella at linux dot vnet.ibm.com
For IBM long double, adding a normal number to a NaN raises an inexact
exception. Adding any number to NaN should not raise any exception. The
following testcase triggers the issue (the testcase is meant to run a gnu
compatible libc):
--
$ cat gcc_testcase.c
#include math.h
#include fenv.h
#include stdio.h
double
sum (double x, long double y)
{
return x + y;
}
int main ()
{
feenableexcept (FE_INEXACT);
double x = __builtin_nan ();
long double y = 1.1L;
printf (%e\n, sum (x, y));
return 0;
}
$ gcc -O3 -m64 -fno-inline gcc_testcase.c -o gcc_testcase -lm
$ ./gcc_testcase
Floating point exception (core dumped)
--
The issue is in __gcc_qadd implementation at
libgcc/config/rs6000/ibm-ldouble.c,
if the number if non finite, there is not check if it a NaN before actually
summing all the components. A possible solution would be to add an extra test
and return the first sum if the number if not infinity:
Index: libgcc/config/rs6000/ibm-ldouble.c
===
--- libgcc/config/rs6000/ibm-ldouble.c (revision 199159)
+++ libgcc/config/rs6000/ibm-ldouble.c (working copy)
@@ -104,6 +104,8 @@
if (nonfinite (z))
{
+ if (z != inf())
+ return z;
z = cc + aa + c + a;
if (nonfinite (z))
return z;
[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54393 --- Comment #2 from Adhemerval Zanella azanella at linux dot vnet.ibm.com 2012-08-28 18:44:44 UTC --- Created attachment 28094 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28094 __gnu_ext::__vstring getline optimization
[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54393 --- Comment #3 from Adhemerval Zanella azanella at linux dot vnet.ibm.com 2012-08-28 18:49:42 UTC --- The default algorithm used on both std::string and __gnu_cxx::__vstring appends data char by char. However, std::string also provides an template specialization for both char and wchar_t (defined in src/istream.cc) which appends the data from the stream using larger buffer (which is calculated by finding the delimiter). Based on that and following how std::string provides its template specialization, I'm proposing a fix for the performance issue. This was made against gcc-4.6 (I still working a patch for trunk) and I only update the baseline_symbols for PPC64 (since it a still RFC patch).
