[Bug c/57669] Incorrect floating point values with 32-bit compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57669 Julian Taylor changed: What|Removed |Added CC||jtaylor.debian at gmail dot com --- Comment #1 from Julian Taylor --- looks like expected behavior to me, please read: http://gcc.gnu.org/wiki/x87note you may be able to get consistent results by using -mfpmath=sse e.g. clang will always use amd64 mode even on 32 bit, thus probably the same result.
[Bug c/57491] New: [ia64] internal compiler error: in ia64_split_tmode -O2, quadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57491 Bug ID: 57491 Summary: [ia64] internal compiler error: in ia64_split_tmode -O2, quadmath Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jtaylor.debian at gmail dot com Created attachment 30236 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30236&action=edit preprocessed files when compiling fftw3 3.3.3 with quadmath on ia64 it fails with an internal compiler error: gcc-4.8 -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../kernel -I../../../rdft -I../../../rdft/scalar -D_FORTIFY_SOURCE=2 -g -O2 -Wformat -Werror=format-security -O2 -MT r2cf_8.lo -MD -MP -MF .deps/r2cf_8.Tpo -c r2cf_8.c -fPIC -DPIC -o .libs/r2cf_8.o r2cf_8.c: In function 'r2cf_8': r2cf_8.c:83:1: internal compiler error: in ia64_split_tmode, at config/ia64/ia64.c:1453 } the failure does not occur with -O1 or -O3, only with -O2 reproduceable with the attached .i file with: gcc-4.8 -std=gnu99 -O2 r2cf_8.i -c -fPIC the system is debian unstable with gcc-4.8 (4.8.0-9) which is according to the package changelog SVN 20130529 (r199410) $ gcc-4.8 -v Using built-in specs. COLLECT_GCC=gcc-4.8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/ia64-linux-gnu/4.8/lto-wrapper Target: ia64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.0-9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --disable-libitm --disable-libsanitizer --enable-plugin --with-system-zlib --enable-objc-gc --enable-multiarch --with-system-libunwind --enable-checking=release --build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu Thread model: posix gcc version 4.8.0 (Debian 4.8.0-9)
[Bug other/57219] New: __builtin_isinf_sign source comments more restrictive than documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57219 Bug #: 57219 Summary: __builtin_isinf_sign source comments more restrictive than documentation Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: jtaylor.deb...@gmail.com in glibc bug [0] it is discussed to use __builtin_isinf_sign for C99 isinf. The source code and the patch mail [1] for __builtin_isinf_sign document that it returns -1, 0 or 1 as glibc isinf does. The gcc documentation on the other hand only says it returns the sign of the infinity. To avoid confusion it would be good if the source code comment or the documentation could be matched up to say the exact same thing. Either that the value of the return is undefined (but keeps sign) or that it is strictly define. [0] http://sourceware.org/bugzilla/show_bug.cgi?id=15367 [1] http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01067.html
[Bug c/57004] False warning: comparison is always true due to limited range of data type [-Wtype-limits]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57004 Julian Taylor changed: What|Removed |Added CC||jtaylor.debian at gmail dot ||com --- Comment #2 from Julian Taylor 2013-04-19 12:41:28 UTC --- you need to use -fsigned-char if your program expects signed chars on a machine which defaults to unsigned chars (like ARM).
[Bug lto/56777] New: bad grammar in fwhole-program documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56777 Bug #: 56777 Summary: bad grammar in fwhole-program documentation Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: jtaylor.deb...@gmail.com http://gcc.gnu.org/onlinedocs//gcc/Optimize-Options.html#Optimize-Options -fwhole-program ... In combination with -flto using this option should not be used. it should probably be : In combination with -flto this option should not be used. or This option should not be used in combination with -flto.
[Bug middle-end/56160] unnecessary additions in loop [x86, x86_64]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56160 Julian Taylor changed: What|Removed |Added Version|4.4.1 |4.8.0 --- Comment #4 from Julian Taylor 2013-01-31 17:53:17 UTC --- it is still the case in 4.8 svn r195604 (built on i586 fedora 11) and the versions in between, 4.4 is the oldest I tested.
[Bug c/56160] unnecessary additions in loop [x86, x86_64]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56160 --- Comment #2 from Julian Taylor 2013-01-31 10:47:54 UTC --- these three lines is missing at the top of the attachment #include #include #define UNLIKELY(x) __builtin_expect((x),0)
[Bug c/56160] unnecessary additions in loop [x86, x86_64]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56160 --- Comment #1 from Julian Taylor 2013-01-31 10:43:51 UTC --- Created attachment 29313 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29313 code
[Bug c/56160] New: unnecessary additions in loop [x86, x86_64]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56160 Bug #: 56160 Summary: unnecessary additions in loop [x86, x86_64] Classification: Unclassified Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jtaylor.deb...@gmail.com the attached code which does complex float multiplication using sse3 produces 4 unnecessary integer additions if the NaN fallback function comp_mult is inlined the assembly for the loop generated with -msse3 -O3 -std=c99 in gcc 4.4, 4.6, 4.7 and 4.8 svn 195604 looks like this: 28:0f 28 0e movaps (%esi),%xmm1 2b:f3 0f 12 c1 movsldup %xmm1,%xmm0 2f:8b 55 08 mov0x8(%ebp),%edx 32:0f 28 13 movaps (%ebx),%xmm2 35:f3 0f 16 c9 movshdup %xmm1,%xmm1 39:0f 59 c2 mulps %xmm2,%xmm0 3c:0f c6 d2 b1 shufps $0xb1,%xmm2,%xmm2 40:0f 59 ca mulps %xmm2,%xmm1 43:f2 0f d0 c1 addsubps %xmm1,%xmm0 47:0f 29 04 fa movaps %xmm0,(%edx,%edi,8) 4b:0f c2 c0 04 cmpneqps %xmm0,%xmm0 4f:0f 50 c0 movmskps %xmm0,%eax 52:85 c0test %eax,%eax 54:75 1djne73 // inlined comp_mult 56:83 c7 02 add$0x2,%edi 59:83 c6 10 add$0x10,%esi 5c:83 c3 10 add$0x10,%ebx 5f:83 c1 10 add$0x10,%ecx 62:83 45 e4 10 addl $0x10,-0x1c(%ebp) 66:39 7d 14 cmp%edi,0x14(%ebp) 69:7f bdjg 28 ... the 4 adds for esi ebx ecx and ebp are completely unnecessary and reduce performance by about 20% on my core2duo. on amd64 it also creates to seemingly unnecessary additions but I did not test the performance. a way to coax gcc to emit proper code is to not allow it to inline the fallback it then generates following good assembly with only one integer add: a8:0f 28 0c df movaps (%edi,%ebx,8),%xmm1 ac:f3 0f 12 c1 movsldup %xmm1,%xmm0 b0:8b 45 08 mov0x8(%ebp),%eax b3:0f 28 14 de movaps (%esi,%ebx,8),%xmm2 b7:f3 0f 16 c9 movshdup %xmm1,%xmm1 bb:0f 59 c2 mulps %xmm2,%xmm0 be:0f c6 d2 b1 shufps $0xb1,%xmm2,%xmm2 c2:0f 59 ca mulps %xmm2,%xmm1 c5:f2 0f d0 c1 addsubps %xmm1,%xmm0 c9:0f 29 04 d8 movaps %xmm0,(%eax,%ebx,8) cd:0f c2 c0 04 cmpneqps %xmm0,%xmm0 d1:0f 50 c0 movmskps %xmm0,%eax d4:85 c0test %eax,%eax d6:75 10jnee8 // non-inlined comp_mult d8:83 c3 02 add$0x2,%ebx db:39 5d 14 cmp%ebx,0x14(%ebp) de:7f c8jg a8 ...
[Bug c++/56111] New: {float,double} complex not accepted by g++-4.8 anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
Bug #: 56111
Summary: {float,double} complex not accepted by g++-4.8 anymore
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jtaylor.deb...@gmail.com
the C99 float and double complex is not accepted by g++ 4.8 r195467 anymore in
c++98 or c++11.
Even though its technically not part of c++98 it worked in all gcc versions I
ever used.
Is this change intentional? It will break the compilation of a bunch of
scientific c++ software using C libraries.
$ cat test.c
#include
int testing(float complex a);
int main()
{
float complex a = 1;
return testing(a);
}
$ gcc-4.7 test.c -c
$ gcc-4.8 test.c -c
$ g++-4.7 test.c -c
$ g++-4.8 test.c -c
test.c:2:27: error: expected ',' or '...' before 'a'
int testing(float complex a);
^
test.c: In function 'int main()':
test.c:6:15: error: expected initializer before 'a'
float complex a = 1;
^
test.c:7:16: error: 'a' was not declared in this scope
return testing(a);
^
$ g++-4.8 -std=c++98 test.c -c
test.c:2:27: error: expected ',' or '...' before 'a'
int testing(float complex a);
^
test.c: In function 'int main()':
test.c:6:15: error: expected initializer before 'a'
float complex a = 1;
^
test.c:7:16: error: 'a' was not declared in this scope
return testing(a);
^
$ g++-4.8 --version
g$-4.8 (Debian 4.8-20130123-1) 4.8.0 20130123 (experimental) [trunk revision
195400]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
also reproduced with svn trunk r195467 built on a fedora 11 machine.
using ccomplex and -std=c++11 does not work either.
