Re: GCC 4.1.2 RC1
Hi, On Tuesday 30 January 2007 04:06:36 Mark Mitchell wrote: > GCC 4.1.2 RC1 is now on ftp://gcc.gnu.org and its mirrors. The > canonical location is: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070128 > > As with all prereleases, the issue of most concern to me is packaging. > Therefore, please test the actual pre-release tarballs, rather than > sources from SVN. Beyond packaging problems, I'm most concerned about > regression from previous 4.1.x releases, since the primary purpose of > 4.1.2 is to provide an upgrade path from previous 4.1.x releases, > incorporating the bug fixes since 4.1.1. > > If you do encounter problems, please file a Bugzilla PR, and add me to > the CC: list for the issue. Please do not send me reports without first > filing a PR, as I am unable to keep track of all the issues if they are > not in the database. > > We'll do either the final GCC 4.1.2 release (if all goes well), or RC2 > (if it doesn't) in about a week. Builds fine in the T2 SDE *) for i686: == 10:36:01 =[5]=> Building base/gcc [4.1.2-20070128 7.0-trunk]. -> Compiler Cache Hits while pkg build: 27.78% (794 hits, 2064 misses) == 01/30/07 12:11:16 =[5]=> Finished building package gcc. Target: i686-t2-linux-gnu Configured with: ../configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib --datadir=/usr/share --includedir=/usr/include --infodir=/usr/info --mandir=/usr/man --sysconfdir=/etc --localstatedir=/var --disable-debug --build=i686-t2-linux-gnu --host=i686-t2-linux-gnu --enable-__cxa_atexit --disable-checking --disable-bootstrap --disable-multilib --with-gnu-as --with-gnu-ld --enable-threads=posix --enable-libgcj --enable-languages=c,c++,objc,java,fortran --enable-shared Thread model: posix gcc version 4.1.2 20070129 (prerelease) Yours, *) T2 System Development Environment - http://www.t2-project.org -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
gcc-4.0.0-prerelease: -O0 build time higher than -O1?
Hi all, I'm just doing the first benchmarking with the 4.0.0 pre release (20050319) and just noticed that -O0 build time is not always the fastest. (In contrast to what the changes suggest: "When compiling without optimizations (-O0), the C++ frontend is much faster than in any previous versions of GCC. ..." - Or is it just that previous versions have already been way slower ...) One of the tests is Richard Guenther's tramp3d and the -O0 build time is _significantly_ higher than with -O1: (user + system) CXX used: g++ (4.0.0) -O0 -march=i386 tramp3d-v3 Building ... 63.85 + 2.02 Running ... 76.71 + 0.11 CXX used: g++ (4.0.0) -O1 -march=i386 tramp3d-v3 Building ... 49.62 + 0.98 Running ... 12.82 + 0.11 CXX used: g++ (4.0.0) -O2 -march=i386 tramp3d-v3 Building ... 66.33 + 1.05 Running ... 13.55 + 0.12 Most probably due to -O1 eliminates much more of the template stuff and needs to generate far less code? Currently my athlon is busy crunching all the optimization permutations I want to get numbers for - and then 3.4.3 results are build up for comparision ... I hope to have a full set available tomorrow ... Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45
gcc 4.0 miscompilation on sparc(32) with ultrasparc optmization
Hi all, this is just a tiny note, that gcc-4.0 does produce miscompiled binaries on sparc(32)-linux with -mcpu=ultrasparc. Some binaries work, however many such as bash, curl or gzip segfault. I know this is not a reduced testcase, just a note. I try to invest some time over the weekend to debug this and hopefully produce a reduced testcase. So far this only happens with v9 or above optmiizations. v8 optimized binaries pass checking. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45
Re: gcc 4.0 miscompilation on sparc(32) with ultrasparc optmization
Hi, Steven Bosscher wrote: this is just a tiny note, that gcc-4.0 does produce miscompiled binaries on sparc(32)-linux with -mcpu=ultrasparc. Some binaries work, however many such as bash, curl or gzip segfault. I know this is not a reduced testcase, just a note. I try to invest some time over the weekend to debug this and hopefully produce a reduced testcase. So far this only happens with v9 or above optmiizations. v8 optimized binaries pass checking. Try the top of the gcc 4.0 branch first. There is a known bug in an optimization pass that may cause wrong code to be produced by GCC 4.0 as released (see http://gcc.gnu.org/PR21173). You may be just seeing yet another incarnation of this problem. Thanks for the prompt answer. I bootsrapped the 4_0 branch's CVS HEAD (which took quite some hours on the old UltraSPARC) and during the first tests I have not yet encountered the random segfaults anymore. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45
[BENCHMARK] comparing GCC 3.4 and 4.0 on an AMD Athlon-XP 2500+
Hi all, I have some preleminary benchmark results comparing 3.4(.3) with 4.0.0, including some optimization option permuations. http://exactcode.de/rene/hidden/gcc-article/2005-gcc-4.0/stat2-rt.png http://exactcode.de/rene/hidden/gcc-article/2005-gcc-4.0/stat2-bt.png rt = runtime bt = buildtime -lu == -funroll-loops -uaat == -funit-at-a-time -vect == -ftree-vectorize -oft == -fomit-frame-pointer -x == -funroll-loops -fpeel-loops -fpeel-loops -funswitch-loops -ftree-vectorize -ftracer -fomit-frame-pointer -x-uaat == -x + -uaat A short summary: 4.0 seems to be very good at modern C++ code, especially involving a lot of templates. The -Os switch's generated code speed degenerated by magnitudes for C++ code (look at Botan and tramp3d). 4.0 seems to have problems catching up at C code where 3.4(.3) was previously yielding good results - e.g openssl, libmad and gnupg seem to be a challenge for GCC. Of course all hand written assembly was disabled in those benchmarks, to review what GCC is able to genereate out of the generic C code ... Feedback welcome - yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45
GCC 4.1 and R_PPC64_ADDR32 out of range
Hi, not such an high priority, but testing the latest gcc 4.1.0 in "whole system builds" I stumble over: jackd: error while loading shared libraries: /usr/lib64/libjack.so.0: R_PPC64_ADDR32 4056b70 for symbol `' out of range There only R_PPC64_ADDR32 in .text+0*. Any idea or proposal how to hunt this? Sincerely yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rebe.name +49 (0)30 / 255 897 45
Re: GCC 4.1 and R_PPC64_ADDR32 out of range
Hi, On Tuesday 25 April 2006 14:21, Andrew Haley wrote: > Rene Rebe writes: > > Hi, > > > > not such an high priority, but testing the latest gcc 4.1.0 in > > "whole system builds" I stumble over: > > > > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0: > > R_PPC64_ADDR32 4056b70 for symbol `' out of range > > > > There only R_PPC64_ADDR32 in .text+0*. > > > > Any idea or proposal how to hunt this? > > just a guess, but perhaps libjack isn't compiled -fPIC? Nope, it is. -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rebe.name +49 (0)30 / 255 897 45
Re: GCC 4.1 and R_PPC64_ADDR32 out of range
On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> Rene Rebe writes:
> > Hi,
> >
> > not such an high priority, but testing the latest gcc 4.1.0 in
> > "whole system builds" I stumble over:
> >
> > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> > R_PPC64_ADDR32 4056b70 for symbol `' out of range
> >
> > There only R_PPC64_ADDR32 in .text+0*.
> >
> > Any idea or proposal how to hunt this?
>
> just a guess, but perhaps libjack isn't compiled -fPIC?
I further narrowed it stripping down the preprocessed sources. The
culprit appears to be a function pointer passed as reference to a thread
creation function:.
client.c:1696:
#else
if (jack_client_create_thread (client,
&client->thread,
client->engine->client_priority,
client->engine->real_time,
jack_client_thread, client)) {
return -1;
}
#endif
When the jack_client_thread is replaced with NULL the shared object can be
loaded, with jack_client_thread it yields the:
R_PPC64_ADDR32 402e240 for symbol `' out of range
The functions are declared as:
void *
jack_client_thread (void *arg)
and
int jack_client_create_thread (jack_client_t* client,
pthread_t *thread,
int priority,
int realtime,
void *(*start_routine)(void*),
void *arg);
Any idea?
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://exactcode.de | http://t2-project.org | http://rebe.name
+49 (0)30 / 255 897 45
Re: How to use gcc4 to compile FreeBSD6.0 ?
On Thursday 29 June 2006 08:30, Beyond.Luo wrote: > Hi, all >When I compile FreeBSD6.0 using gcc4.1 instead of gcc3, lots of > errors are reported. > I knowes that gcc4.1 checks syntax more strictly, then how can I do now? > any command-line options? Fix the code? -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rebe.name +49 (0)30 / 255 897 45
Re: Does SIMD optimization of GCC 3.4.6 work?
Hi, On Wednesday 05 July 2006 19:57, Mike Stump wrote: > On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote: > > The codec is at http://www.sourceforge.net/projects/openavs/. > > Currently, it requires a 3Ghz or better CPU to get a resonable > > framerate. I would like the codec to be useful even on 586 > > ( 1Ghz or > > so ). Any ideas? > > Recode slower parts in assembler or punt to video card. Aside the general com.lang.c boilderplate (...) usually it is already a gain to rewrite inefficent algorithms with something more clever and to use gcc SIMD vector extensions. Then of course assembly is the (often) last step ,-) Yours, -- René Rebe - ExactCODE - Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
Re: Does SIMD optimization of GCC 3.4.6 work?
Hi, On Wednesday 05 July 2006 20:26, Dave Korn wrote: > I believe Lionel's real problem is likely to be that he was hoping that > turning on the "-mmx -sse -sse2 -3dnow" options would auto-vectorise his code > for him. > > Lionel, (IIUIC) those options just /enable/ the use of the various SIMD > features; they don't adjust your code to use those features if it doesn't do > so already, so apart from a fairly small speed-up on some floating point > operations that can be done more efficiently in the mmx unit, you shouldn't > have been expecting to see much difference in the first place. When you put it this way one should point him to "-ftree-vectorize" of GCC 4.0 and 4.1 ... Yours, -- René Rebe - ExactCODE - Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
[PATCH] fix PowerPC < 7 w/ Altivec not to default to power7
This might not be the best timing -short before a major release-, however, Sam just commented on the bug I filled years ago [1], so here we go: Glibc uses .machine to determine assembler optimizations to use. However, since reworking the rs6000 .machine output selection in commit e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, G5 as well as Cell, and even power4 w/ -maltivec currently resulted in power7. Mask _ALTIVEC away as the .machine selection already did for GFX and GPOPT. powerpc64-t2-linux-gnu-gcc test.c -S -o - -mcpu=G5 .file "test.c" .machine power7 .abiversion 2 .section".text" .ident "GCC: (GNU) 10.2.0" .section.note.GNU-stack,"",@progbits We ship this in T2/Linux [2] since 2020 and it is tested on G5, Cell and Power8. Signed-of-by: René Rebe [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 [2] https://t2sde.org --- gcc-11.1.0-RC-20210423/gcc/config/rs6000/rs6000.cc.vanilla 2021-04-25 22:57:16.964223106 +0200 +++ gcc-11.1.0-RC-20210423/gcc/config/rs6000/rs6000.cc 2021-04-25 22:57:27.193223841 +0200 @@ -5765,7 +5765,7 @@ HOST_WIDE_INT flags = rs6000_isa_flags; /* Disable the flags that should never influence the .machine selection. */ - flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT | OPTION_MASK_ISEL); + flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT | OPTION_MASK_ALTIVEC | OPTION_MASK_ISEL); if ((flags & (ISA_3_1_MASKS_SERVER & ~ISA_3_0_MASKS_SERVER)) != 0) return "power10"; -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin https://exactcode.com | https://t2sde.org | https://rene.rebe.de
