[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #124 from David dot Monniaux at imag dot fr 2008-11-11 07:46 --- Vincent Lefèvre is right: the issue is quite subtle. (I should mention that Vincent is an expert in computer arithmetics, which I'm not.) As he rightly points, conformance to IEEE-754 should be evaluated for a whole software/hardware system - it is possible to have a IEEE-754 system entirely implemented in software. It seems like the C99 standard prohibits double rounding, and prohibits having values depend on the vagaries of register spilling. Except that this prohibition is explicit only in non-normative sections. "Language lawyers" have sent me justifications that this prohibition is implied by various normative prescriptions of the standard. I think that in any case we should not spend too much energy trying to assign blame (who conforms to the standard) but rather try to find solutions. The short answer is that no compiler, be it gcc, will be modified so that complex sequences of operations are used for floating-point operations in lieu of directly using x87 instructions! At least for two reasons: * x87 is now fading away (its use is deprecated on x86-64, it's not used by default on Intel Macintosh...) * Most people don't want to pay the performance hit. In addition, I think there are more urgent things to fix in gcc's floating-point system, such as support for #pragma STDC FENV ACCESS Now for some additional facts: * It is possible to force the x87 to use reduced precision for the mantissa (with inline asm or even now with gcc options). * This setting does not affect the range of exponents. so you can still have surprises if a very tiny nonzero value is kept in a register then is rounded to zero when spilled to memory. * In some rare cases, you can have "double rounding on underflow": you get a different result by computing on SSE in double precision mode on the one hand, and by computing on x87 in "double precision" then writing to a double variable in memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug tree-optimization/38079] gcc segfaults when using -ftree-vectorizer-verbose=9
--- Comment #1 from David dot Monniaux at imag dot fr 2008-11-11 07:00 --- Created an attachment (id=16649) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16649&action=view) gcc -c -O3 -ftree-vectorizer-verbose=9 set_str.i segfaults This code comes from GNU MP 4.2.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38079
[Bug tree-optimization/38079] New: gcc segfaults when using -ftree-vectorizer-verbose=9
$ gcc -O3 -ftree-vectorizer-verbose=9 -c set_str.i (lots of blah-blah) set_str.c:326: note: get vectype with 4 units of type const unsigned char set_str.c:326: note: vectype: const vector unsigned char set_str.c:326: note: set_str.c: In function __gmpn_set_str: set_str.c:54: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) -- Summary: gcc segfaults when using -ftree-vectorizer-verbose=9 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David dot Monniaux at imag dot fr GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38079
[Bug c++/15795] No way to teach operator new anything about alignment requirements
--- Comment #40 from David dot Monniaux at imag dot fr 2008-11-11 06:24 --- Yes, at least the manual should be updated to reflect this non-obvious behavior. Possible fixes for the programmer: 1) Overload operators new. new[] for a class wrapping the vector datatypes. It works as long as you allocate memory through explicit new, however it fails for buffers allocated by STL's default allocator. 2) Overload the allocators for a wrapper class and select a specific allocator for STL arrays etc. of that class. Haven't tried that yet. 3) Replace the global ::new and ::new[] by something calling memalign instead of malloc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
[Bug c++/38063] New: C++ operator new returns misaligned address
On IA32, operator new returns an address multiple of 8 in all cases, even if
called on a type with strict alignment (16).
typedef double double2 __attribute__ ((vector_size(16)));
int main() {
std::cout << __alignof__(double2) << " " << ((void*) new double2) <<
std::endl;
}
returns:
16 0x8107008
--
Summary: C++ operator new returns misaligned address
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: David dot Monniaux at imag dot fr
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38063
[Bug c++/38012] vectorizer ignores 'restrict'
--- Comment #1 from David dot Monniaux at imag dot fr 2008-11-04 16:06 --- Created an attachment (id=16623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16623&action=view) source code where va and vb are thought to be aliased The compiler should heed that va and vb cannot point to aliased locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38012
[Bug c++/38012] New: vectorizer ignores 'restrict'
The vectorizer ignores the 'restrict' keyword regarding two pointer
destinations, and emits a run-time aliasing text.
--
Summary: vectorizer ignores 'restrict'
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: David dot Monniaux at imag dot fr
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38012
