gcc-4.3-20071221 compilation problems
I've been trying to compile gcc-4.3-20071221 on a sunblade 1000, running Solaris 10 (SunOS faile 5.10 Generic_127111-05 sun4u sparc SUNW,Sun-Blade-1000), and have been running into memory issues. I keep getting the error message that my system is running out of virtual memory (virtual memory exhausted: Not enough space). I have 4GB of swap and 4GB of RAM, so I shouldn't be having this problem. The error I'm getting is shown below: /source/gcc/gcc-4.3-20071221/host-sparc-sun-solaris2.10/prev-gcc/xgcc -B/source/gcc/gcc-4.3-20071221/host-sparc-sun-solaris2.10/prev-gcc/ -B/usr/local/sparc-sun-solaris2.10/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/usr/local/include/ -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include ../.././gcc/c-decl.c -o c-decl.o virtual memory exhausted: Not enough space make[3]: *** [c-decl.o] Error 1 make[3]: Leaving directory `/source/gcc/gcc-4.3-20071221/host-sparc-sun-solaris2.10/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/source/gcc/gcc-4.3-20071221' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/source/gcc/gcc-4.3-20071221' make: *** [all] Error 2 The output of top shows (when the compilation isn't in progress): last pid: 17852; load avg: 0.61, 1.25, 1.41; up 2+00:03:27 06:13:41 143 processes: 141 sleeping, 1 zombie, 1 on cpu CPU states: 84.2% idle, 10.4% user, 5.4% kernel, 0.0% iowait, 0.0% swap Memory: 4096M phys mem, 2835M free mem, 4097M total swap, 4097M free swap Richard Paynter [EMAIL PROTECTED]
Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı: > Hi all, > > I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day > and I see 3 tests fail : > > math/test-float > math/test-ildoubl > math/test-ifloat > > The erorrs are all similar : > > Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i > Result: > is: 0.e+00 0x0.p+0 > should be: 1.57079637050628662109e+00 0x1.921fb600p+0 > difference: 1.57079637050628662109e+00 0x1.921fb600p+0 > ulp : 13176795. > max.ulp : 0. All these failures are gone when glibc is compiled with -O2 instead of -O3 but there are still 4 regressions : math/test-ildoubl Usual math problem : testing long double (inline functions) Failure: Test: expm1 (1) == M_El - 1.0 Result: is: 1.71828182845904523532e+00 0xd.bf0a8b1457695350p-3 should be: 1.71828182845904523543e+00 0xd.bf0a8b1457695360p-3 difference: 1.08420217248550443401e-19 0x8.p-66 ulp : 1. max.ulp : 0. Maximal error of `expm1' is : 1 ulp accepted: 0 ulp libio/tst-fopenloc2 libio/tst-fopenloc These two seems to be a new gcc regression, they crash when compiled with gcc trunk. elf/check-localplt These seems to be less harmful, shows memalign is missing from expected output. Any ideas appreciated. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
gcc-4.3-20071228 is now available
Snapshot gcc-4.3-20071228 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071228/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 131213 You'll find: gcc-4.3-20071228.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20071228.tar.bz2 C front end and core compiler gcc-ada-4.3-20071228.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20071228.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20071228.tar.bz2 C++ front end and runtime gcc-java-4.3-20071228.tar.bz2 Java front end and runtime gcc-objc-4.3-20071228.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20071228.tar.bz2The GCC testsuite Diffs from 4.3-20071221 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Friday 28 December 2007 16:20:52 tarihinde Ismail Dönmez şunları yazmıştı: > libio/tst-fopenloc2 > libio/tst-fopenloc > > These two seems to be a new gcc regression, they crash when compiled with > gcc trunk. Ok I identified that commit 130788 [0] broke these testcases , the same commit seems to be the cause for PR34465 . [0] http://gcc.gnu.org/viewcvs?view=rev&revision=130788 Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
censored naked SSE reciprocals, -mrecip
Merry xmas,
i lately had some use for -mrecip but it turned out to come with all
sorts of strings attached and apparently no opt-out. Briefly, barring
inline asm, i can't get gcc to emit those ops without a NR fixup.
# cat src/pr-recip.c
#include
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
__m128 foo(__m128 a) { return _mm_sqrt_ps(a); }
__m128 bar(__m128 a) { return _mm_rsqrt_ps(a); }
__m128 baz(__m128 a) { return _mm_rcp_ps(a); }
v4sf_t nope1(v4sf_t a) { return __builtin_ia32_sqrtps(a); }
v4sf_t nope2(v4sf_t a) { return __builtin_ia32_rsqrtps(a); }
v4sf_t allright(v4sf_t a) { return __builtin_ia32_rcpps(a); }
int main() { return 0; }
# /usr/local/gcc-4.3-20071221/bin/gcc -march=native -ffast-math
-mrecip -O2 src/pr-recip.c
... and as can be witnessed in the attached asm dump foo, bar, nope1,
nope2 get mangled (at least on x86-64 linux).
While i can somehow understand the logic behind the automatic
transformation of _mm_sqrt_ps - it can be argued that's what the user
has asked for - there's no obvious way to opt out. But then i really
don't understand why gcc feels the urge to tinker when i specifically
ask for a rsqrt.
To add insult to injury -mrecip, unlike fast-math, doesn't set any
macro so kludging around is a cat / mouse game.
Questions:
a) is that really by design?
b) what's the official way to dodge fixups when -mrecip is active?
c) any chance for -mrecip to set __FAST_MATH_NONE_SHALL_PASS__ or something?
dump.asm
Description: Binary data
