Re: [buildrobot] gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was not declared in this scope
Hi, thanks for cathing this.
I certainly missed that OPTION_BIONIC is not defined for linux targets
that do not include config/linux.h in their tm.h.
This patch fixed build for powerpc64le-linux and mn10300-linux.
linux_libc, LIBC_GLIBC, LIBC_BIONIC should be defined for all targets.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 56e6fd4..6bb18f8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-08-20 Alexander Ivchenko
+
+ * config/linux-android.c (linux_android_libc_has_function): Fix
+ checks for libc.
+
2013-08-20 Zhouyi Zhou
* tree-ssa-ccp.c (get_default_value): Remove redundant condition
diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
index 4a4b48d..e9d9e9a 100644
--- a/gcc/config/linux-android.c
+++ b/gcc/config/linux-android.c
@@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
bool
linux_android_libc_has_function (enum function_class fn_class)
{
- if (OPTION_GLIBC)
+ if (linux_libc == LIBC_GLIBC)
return true;
- if (OPTION_BIONIC)
+ if (linux_libc == LIBC_BIONIC)
if (fn_class == function_c94
|| fn_class == function_c99_misc
|| fn_class == function_sincos)
is it OK?
thanks,
Alexander
2013/8/19 Jan-Benedict Glaw :
> Hi!
>
> My build robot[1] catched this error[2] while cross-building for
> powerpc64le-linux:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/.
> -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include
> -I../../../../gcc/gcc/../libdecnumber
> -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
> -I../../../../gcc/gcc/../libbacktrace-I. -I. -I../../../../gcc/gcc
> -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include
> -I../../../../gcc/gcc/../libcpp/include
> -I../../../../gcc/gcc/../libdecnumber
> -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
> -I../../../../gcc/gcc/../libbacktrace \
> ../../../../gcc/gcc/config/linux-android.c
> ../../../../gcc/gcc/config/linux-android.c: In function ‘bool
> linux_android_libc_has_function(function_class)’:
> ../../../../gcc/gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was
> not declared in this scope
>if (OPTION_BIONIC)
>^
> make[2]: *** [linux-android.o] Error 1
>
> Probably introduced with r201838
> (http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=201838). I
> guess it's just a forgotten chunk.
>
> MfG, JBG
> [1] http://toolchain.lug-owl.de/buildbot/
> [2] http://toolchain.lug-owl.de/buildbot/#job8903
>
> --
> Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
> Signature of: http://perl.plover.com/Questions.html
> the second :
Re: Build problem msg: xgcc: error trying to exec 'cc1': execvp: No such file or directory
Florian,
Thank you for your willingness to help me.
I see
the message 3 times during a build which appears to succeed... I run a
script that checks status codes and it runs a "make install" command.
Thanks
for the hint with gcc-help. I sent my request to this list because this
build process has been running successfully for some time.
Here's
the uname -a output Linux xxx 3.6.11-4.fc16.x86_64 #1 SMP Tue Jan 8
20:57:42 UTC 2013 x86_64 GNU/Linux. This system is a Fedora 16 x86_64
system.
Regards and THANKS again for your help,
George...
#1:
3517 g++ -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros
-Wno-ov 3517 erlength-strings -fno-common -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -o cpp gcc.o ggc-none.o \
3518 c-family/cppspec.o driver-i386.o libcommon-target.a \
3519 libcommon.a ../libcpp/libcpp.a
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
3520 /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -dumpspecs > tmp-specs
3521 mv tmp-specs specs
3522 g++ -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-ov 3522 erlength-strings -fno-common
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o xg++ \
3523 gcc.o ggc-none.o g++spec.o driver-i386.o libcommon-target.a \
3524 libcommon.a ../libcpp/libcpp.a
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
3525 : > tmp-libgcc.mvars
3526 echo GCC_CFLAGS = '-g -O2 -DIN_GCC -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include ' >> tmp-libgcc.mvars
3527 echo INHIBIT_LIBC_CFLAGS = '' >> tmp-libgcc.mvars
3528 echo TARGET_SYSTEM_ROOT = '' >> tmp-libgcc.mvars
3529 mv tmp-libgcc.mvars libgcc.mvars
3530 echo | /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -E -dM - | \
3531 sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p'
\
3532 -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
3533 sort -u > tmp-macro_list
3534 xgcc: error trying to exec 'cc1': execvp: No such file or directory
3535 /bin/bash ../../gcc/gcc/../move-if-change tmp-macro_list macro_list
3536 echo timestamp > s-macro_list
3537 if /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -print-sysroot-headers-suffix
> /dev/null 2>&1; then \
3538 set -e; for ml in
`/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -print-multi-lib`; do \
3539 multi_dir=`echo ${ml} | sed -e 's/;.*$//'`; \
3540 flags=`echo ${ml} | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`;
\
3541 sfx=`/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ ${flags}
-print-sysroot-headers-suffix`; \
3542 if [ "${multi_dir}" = "." ]; \
3543 then multi_dir=""; \
3544 else \
3545 multi_dir=/${multi_dir}; \
3546 fi; \
3547 echo "${sfx};${multi_dir}"; \
3548 done; \
3549 else \
3550 echo ";"; \
3551 fi > tmp-fixinc_list
3552 /bin/bash ../../gcc/gcc/../move-if-change tmp-fixinc_list fixinc_list
#2
11739 gcc.o ggc-none.o gfortranspec.o driver-i386.o libcommon-target.a
\
11740 libcommon.a ../libcpp/libcpp.a
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
11741
/tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/xg++
-B/tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/tools/gcc/obj-i686-pc-linux-gnu/prev-x86_64-unkno
11741
wn-linux-gnu/libstdc++-v3/src/.libs
-B/tools/gcc/obj-i686-pc-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/tools/gcc/obj-i686-pc-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3
11741 /include/x86_64-unknown-linux-gnu
-I/tools/gcc/obj-i686-pc-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/tools/gcc/gcc/libstdc++-v3/libsupc++
-L/tools/gcc/obj-i686-pc-linux-gnu/prev-x86_64-
11741
unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tools/gcc/obj-i686-pc-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous
11741 -unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common -DHAVE_CONFIG_H -I. -I
11741 . -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/u
Re: Propose moving vectorization from -O3 to -O2.
Xinliang David Li wrote: >On Mon, Aug 19, 2013 at 11:53 AM, Richard Biener > wrote: >> Xinliang David Li wrote: >>>+cc auto-vectorizer maintainers. >>> >>>David >>> >>>On Mon, Aug 19, 2013 at 10:37 AM, Cong Hou wrote: Nowadays, SIMD instructions play more and more important roles in >our daily computations. AVX and AVX2 have extended 128-bit registers to 256-bit ones, and the newly announced AVX-512 further doubles the size. The benefit we can get from vectorization will be larger and larger. This is also a common practice in other compilers: 1) Intel's ICC turns on vectorizer at O2 by default and it has been the case for many years; 2) Most recently, LLVM turns it on for both O2 and Os. Here we propose moving vectorization from -O3 to -O2 in GCC. Three main concerns about this change are: 1. Does vectorization greatly increase the generated code size? 2. How much performance can be improved? 3. Does vectorization increase compile time >significantly? I have fixed GCC bootstrap failure with vectorizer turned on (http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00497.html). To >>>evaluate the size and performance impact, experiments on SPEC06 and internal benchmarks are done. Based on the data, I have tuned the parameters for vectorizer which reduces the code bloat without sacrificing the performance gain. There are some performance regressions in SPEC06, and the root cause has been analyzed and understood. I will file >bugs tracking them independently. The experiments failed on three benchmarks (please refer to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993). The experiment result is attached here as two pdf files. Below are our summaries >of the result: 1) We noticed that vectorization could increase the generated code size, so we tried to suppress this problem by doing some tunings, which include setting a higher loop bound so that loops with small iterations won't be vectorized, and disabling loop versioning. The average size increase is decreased from 9.84% to 7.08% after our tunings (13.93% to 10.75% for Fortran benchmarks, and 3.55% to >1.44% for C/C++ benchmarks). The code size increase for Fortran >benchmarks can be significant (from 18.72% to 34.15%), but the performance >gain is also huge. Hence we think this size increase is reasonable. For C/C++ benchmarks, the size increase is very small (below 3% except 447.dealII). 2) Vectorization improves the performance for most benchmarks by around 2.5%-3% on average, and much more for Fortran benchmarks. On Sandybridge machines, the improvement can be more if using -march=corei7 (3.27% on average) and -march=corei7-avx (4.81% on average) (Please see the attachment for details). We also noticed >>>that some performance degrades exist, and after investigation, we found some are caused by the defects of GCC's vectorization (e.g. GCC's >SLP could not vectorize a group of accesses if the number of group >cannot be divided by VF http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49955, and any data dependence between statements can prevent >>>vectorization), which can be resolved in the future. 3) As last, we found that introducing vectorization almost does not affect the build time. GCC bootstrap time increase is negligible. As a reference, Richard Biener is also proposing to move >>>vectorization to O2 by improving the cost model (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00904.html). >> >> And my conclusion is that we are not ready for this. The compile >time cost does not outweigh the benefit. > >Can you elaborate on your reasoning ? I have done measurements with spec 2006 and selective turning on parts of the vectorizer at O2. vectorizing has both a compile-time (around 10%) and code-size (up to 15%) impact. at full feature set vectorization regresses runtime of quite a number of benchmarks significantly. At reduced feature set - basically trying to vectorize only obvious profitable cases - these regressions can be avoided but progressions only remain on two spec fp cases. As most user applications fall into the spec int category a 10% compile-time and 15% code-size regression for no gain is no good. Richard. >thanks, > >David > > >> >> Richard. >> Vectorization has great performance potential -- the more people >use it, the likely it will be further improved -- turning it on at O2 >is the way to go ... Thank you! Cong Hou >> >>
Recent libstdc++-v3 regressions (PCHs related?!?)
Hi, sorry it the issue is by now well known but... I see many libstdc++-v3 regressions on at least x86_64-linux. When running the libstdc++-v3 testsuite (which uses PCHs) one gets tons of new fails like the below. That's annoying, a lot of confusing noise. Thanks! Paolo. PS: CC-ing two "random" ;) people lately very active. /// FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors) Excess errors: /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:567:2: internal compiler error: Segmentation fault 0xb2521f crash_signal /scratch/Gcc/svn-dirs/trunk/gcc/toplev.c:335 0xa747a7 gcc::pass_manager::gt_ggc_mx() /scratch/Gcc/svn-dirs/trunk/gcc/passes.c:201 0x9652b5 ggc_mark_root_tab /scratch/Gcc/svn-dirs/trunk/gcc/ggc-common.c:133 0x965600 ggc_mark_roots() /scratch/Gcc/svn-dirs/trunk/gcc/ggc-common.c:152 0x7c1f44 ggc_collect() /scratch/Gcc/svn-dirs/trunk/gcc/ggc-page.c:2077 0x836995 cgraph_finalize_function(tree_node*, bool) /scratch/Gcc/svn-dirs/trunk/gcc/cgraphunit.c:456 0x6e882f expand_or_defer_fn(tree_node*) /scratch/Gcc/svn-dirs/trunk/gcc/cp/semantics.c:3941 0x719104 maybe_clone_body(tree_node*) /scratch/Gcc/svn-dirs/trunk/gcc/cp/optimize.c:428 0x6e848f expand_or_defer_fn_1(tree_node*) /scratch/Gcc/svn-dirs/trunk/gcc/cp/semantics.c:3866 0x6e8808 expand_or_defer_fn(tree_node*) /scratch/Gcc/svn-dirs/trunk/gcc/cp/semantics.c:3936 0x5ce0ed instantiate_decl(tree_node*, int, bool) /scratch/Gcc/svn-dirs/trunk/gcc/cp/pt.c:19269 0x6096df instantiate_pending_templates(int) /scratch/Gcc/svn-dirs/trunk/gcc/cp/pt.c:19356 0x646b2a cp_write_global_declarations() /scratch/Gcc/svn-dirs/trunk/gcc/cp/decl2.c:4064 Thanks! Paolo.
Re: Recent libstdc++-v3 regressions (PCHs related?!?)
Hi Paolo, > sorry it the issue is by now well known but... I see many libstdc++-v3 > regressions on at least x86_64-linux. When running the libstdc++-v3 > testsuite (which uses PCHs) one gets tons of new fails like the > below. That's annoying, a lot of confusing noise. same on i386-pc-solaris2.10 and sparc-sun-solaris2.11 as of r201870. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Toolchain Build Robot
On Mon, 19 Aug 2013, Jan-Benedict Glaw wrote: > Ok? > > Index: htdocs/testing/index.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/testing/index.html,v > retrieving revision 1.29 > diff -u -p -r1.29 index.html > --- htdocs/testing/index.html 18 Aug 2013 10:54:32 - 1.29 > +++ htdocs/testing/index.html 19 Aug 2013 11:43:47 - > @@ -34,6 +34,10 @@ the test suite directories. >send their test results to the >http://gcc.gnu.org/ml/gcc-testresults/";>gcc-testresults >mailing list. > + > + Jan-Benedict Glaw is runing a > + http://toolchain.lug-owl.de/buildbot/";>build robot that > + tries to build various cross-target (stage1 only) on some > machines. > Yes, thanks! Gerald
Re: Toolchain Build Robot
On Mon, 19 Aug 2013, Jan-Benedict Glaw wrote: > ...and this on top of that: > > Ok? That one, too. :-) Gerald
Re: Recent libstdc++-v3 regressions (PCHs related?!?)
On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote: > Hi, > > sorry it the issue is by now well known but... I see many libstdc++-v3 > regressions on at least x86_64-linux. When running the libstdc++-v3 > testsuite (which uses PCHs) one gets tons of new fails like the below. > That's annoying, a lot of confusing noise. > > Thanks! > Paolo. > > PS: CC-ing two "random" ;) people lately very active. Sorry about this - looking at the backtrace this could well be due to me, specifically r201865, which moved the gcc::pass_manager and all the passes into the GC heap (so that we can then move GC-owned per-pass state into the pass instances). This would require pch files to be regenerated, but presumably the test suite does this, right? I did rerun the bootstrap and regression tests before committing (based on clean builds with and without the patches), but presumably something unexpected is happening. I'm investigating now. (FWIW, if we have to back out r201865, I believe we also have to back out r201864). > /// > > FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors) > Excess errors: > /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:567:2: > > internal compiler error: Segmentation fault > 0xb2521f crash_signal > /scratch/Gcc/svn-dirs/trunk/gcc/toplev.c:335 > 0xa747a7 gcc::pass_manager::gt_ggc_mx() > /scratch/Gcc/svn-dirs/trunk/gcc/passes.c:201 > 0x9652b5 ggc_mark_root_tab > /scratch/Gcc/svn-dirs/trunk/gcc/ggc-common.c:133 > 0x965600 ggc_mark_roots() > /scratch/Gcc/svn-dirs/trunk/gcc/ggc-common.c:152 > 0x7c1f44 ggc_collect() > /scratch/Gcc/svn-dirs/trunk/gcc/ggc-page.c:2077 > 0x836995 cgraph_finalize_function(tree_node*, bool) > /scratch/Gcc/svn-dirs/trunk/gcc/cgraphunit.c:456 > 0x6e882f expand_or_defer_fn(tree_node*) > /scratch/Gcc/svn-dirs/trunk/gcc/cp/semantics.c:3941 > 0x719104 maybe_clone_body(tree_node*) > /scratch/Gcc/svn-dirs/trunk/gcc/cp/optimize.c:428 > 0x6e848f expand_or_defer_fn_1(tree_node*) > /scratch/Gcc/svn-dirs/trunk/gcc/cp/semantics.c:3866 > 0x6e8808 expand_or_defer_fn(tree_node*) > /scratch/Gcc/svn-dirs/trunk/gcc/cp/semantics.c:3936 > 0x5ce0ed instantiate_decl(tree_node*, int, bool) > /scratch/Gcc/svn-dirs/trunk/gcc/cp/pt.c:19269 > 0x6096df instantiate_pending_templates(int) > /scratch/Gcc/svn-dirs/trunk/gcc/cp/pt.c:19356 > 0x646b2a cp_write_global_declarations() > /scratch/Gcc/svn-dirs/trunk/gcc/cp/decl2.c:4064 > > Thanks! > Paolo. > >
Re: Recent libstdc++-v3 regressions (PCHs related?!?)
Hi, On 08/20/2013 04:41 PM, David Malcolm wrote: On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote: Hi, sorry it the issue is by now well known but... I see many libstdc++-v3 regressions on at least x86_64-linux. When running the libstdc++-v3 testsuite (which uses PCHs) one gets tons of new fails like the below. That's annoying, a lot of confusing noise. Thanks! Paolo. PS: CC-ing two "random" ;) people lately very active. Sorry about this - looking at the backtrace this could well be due to me, specifically r201865, which moved the gcc::pass_manager and all the passes into the GC heap (so that we can then move GC-owned per-pass state into the pass instances). I can confirm that r201864 isn't affected. Thanks for looking into this! Paolo.
Re: Recent libstdc++-v3 regressions (PCHs related?!?)
On Tue, 2013-08-20 at 10:41 -0400, David Malcolm wrote: > On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote: > > Hi, > > > > sorry it the issue is by now well known but... I see many libstdc++-v3 > > regressions on at least x86_64-linux. When running the libstdc++-v3 > > testsuite (which uses PCHs) one gets tons of new fails like the below. > > That's annoying, a lot of confusing noise. > > > > Thanks! > > Paolo. > > > > PS: CC-ing two "random" ;) people lately very active. > > Sorry about this - looking at the backtrace this could well be due to > me, specifically r201865, which moved the gcc::pass_manager and all the > passes into the GC heap (so that we can then move GC-owned per-pass > state into the pass instances). This would require pch files to be > regenerated, but presumably the test suite does this, right? > > I did rerun the bootstrap and regression tests before committing (based > on clean builds with and without the patches), but presumably something > unexpected is happening. > > I'm investigating now. I've been erroneously running the test suite as: make check but looking at http://gcc.gnu.org/contribute.html#testing I now realise that I should be running: make -k check and that it's only been running the gcc tests, stopping when they don't all pass - the "-k" flag is needed: $ find test/*/build -name "*.sum" test/control/build/gcc/testsuite/gcc/gcc.sum test/control/build/gcc/testsuite/g++/g++.sum test/control/build/gcc/testsuite/gfortran/gfortran.sum test/control/build/gcc/testsuite/objc/objc.sum test/experiment/build/gcc/testsuite/gcc/gcc.sum test/experiment/build/gcc/testsuite/g++/g++.sum test/experiment/build/gcc/testsuite/gfortran/gfortran.sum test/experiment/build/gcc/testsuite/objc/objc.sum Sorry about this. I've updated my scripts to fix this, and am rerunning (I hope) the full set of test suites now. It's probably worth updating that page to spell out that -k is necessary. > (FWIW, if we have to back out r201865, I believe we also have to back > out r201864). Given that I don't yet have a fix and that my testing has been incomplete, I've gone ahead and backed out both changes as r201887. Sorry again. Dave
Re: i386 __atomic_compare_exchange_n not found
On 08/09/2013 12:59 PM, Joe Buck wrote: On Fri, Aug 09, 2013 at 11:23:51AM -0500, Joel Sherrill wrote: On 8/9/2013 11:05 AM, Deng Hengyi wrote: Hi Joel, I have done a test, it seems that '-march=i386' does not provide "__atomic_compare_exchange_n" libs. And '-march=i486' or '-march=pentium' can find the '__atomic_compare_exchange_n' function. Look in the source for that methods on x86 and see what instruction it used. If it only got added in i486, then we have to figure out something for i386. If it was an oversight and the instruction is on an i386, we fix the code. The i386 architecture lacks atomic compare instructions, to the point where libstdc++ can't be built with that architecture (correct and efficient atomic operations are vital important for libstdc++, andon i386 it can't be done). The worry is that if you add "atomic" operations that don't lock for the i386 architecture, you've screwed anyone who decides to build their application for i386 hoping for maximum portability, but winds up with locks that don't lock. You could perhaps handle that for RTEMS by providing these functions in a library, but users need to understand this issue, because improper locks are tough to debug. libatomic provides a library implementations for all __atomic operations. If the hardware doesn't have atomic operations, it will utilize a lock to implement those routines. At least thats the way its suppose to work :-) I have no idea if its configured to build by default on 386 targets or not... I presume it is. Andrew
Re: Propose moving vectorization from -O3 to -O2.
On Tue, Aug 20, 2013 at 3:59 AM, Richard Biener wrote: > Xinliang David Li wrote: >>On Mon, Aug 19, 2013 at 11:53 AM, Richard Biener >> wrote: >>> Xinliang David Li wrote: +cc auto-vectorizer maintainers. David On Mon, Aug 19, 2013 at 10:37 AM, Cong Hou wrote: > Nowadays, SIMD instructions play more and more important roles in >>our > daily computations. AVX and AVX2 have extended 128-bit registers to > 256-bit ones, and the newly announced AVX-512 further doubles the > size. The benefit we can get from vectorization will be larger and > larger. This is also a common practice in other compilers: > > 1) Intel's ICC turns on vectorizer at O2 by default and it has been > the case for many years; > > 2) Most recently, LLVM turns it on for both O2 and Os. > > > Here we propose moving vectorization from -O3 to -O2 in GCC. Three > main concerns about this change are: 1. Does vectorization greatly > increase the generated code size? 2. How much performance can be > improved? 3. Does vectorization increase compile time >>significantly? > > > I have fixed GCC bootstrap failure with vectorizer turned on > (http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00497.html). To evaluate > the size and performance impact, experiments on SPEC06 and internal > benchmarks are done. Based on the data, I have tuned the parameters > for vectorizer which reduces the code bloat without sacrificing the > performance gain. There are some performance regressions in SPEC06, > and the root cause has been analyzed and understood. I will file >>bugs > tracking them independently. The experiments failed on three > benchmarks (please refer to > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993). The experiment > result is attached here as two pdf files. Below are our summaries >>of > the result: > > > 1) We noticed that vectorization could increase the generated code > size, so we tried to suppress this problem by doing some tunings, > which include setting a higher loop bound so that loops with small > iterations won't be vectorized, and disabling loop versioning. The > average size increase is decreased from 9.84% to 7.08% after our > tunings (13.93% to 10.75% for Fortran benchmarks, and 3.55% to >>1.44% > for C/C++ benchmarks). The code size increase for Fortran >>benchmarks > can be significant (from 18.72% to 34.15%), but the performance >>gain > is also huge. Hence we think this size increase is reasonable. For > C/C++ benchmarks, the size increase is very small (below 3% except > 447.dealII). > > > 2) Vectorization improves the performance for most benchmarks by > around 2.5%-3% on average, and much more for Fortran benchmarks. On > Sandybridge machines, the improvement can be more if using > -march=corei7 (3.27% on average) and -march=corei7-avx (4.81% on > average) (Please see the attachment for details). We also noticed that > some performance degrades exist, and after investigation, we found > some are caused by the defects of GCC's vectorization (e.g. GCC's >>SLP > could not vectorize a group of accesses if the number of group >>cannot > be divided by VF http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49955, > and any data dependence between statements can prevent vectorization), > which can be resolved in the future. > > > 3) As last, we found that introducing vectorization almost does not > affect the build time. GCC bootstrap time increase is negligible. > > > As a reference, Richard Biener is also proposing to move vectorization > to O2 by improving the cost model > (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00904.html). >>> >>> And my conclusion is that we are not ready for this. The compile >>time cost does not outweigh the benefit. >> >>Can you elaborate on your reasoning ? > > I have done measurements with spec 2006 and selective turning on parts of the > vectorizer at O2. vectorizing has both a compile-time (around 10%) and > code-size (up to 15%) impact. Cong only did some compile time measurement with GCC bootstrap -- and the impact is very small. He can confirm the compile time impact with his tuning. >From Cong's data, benchmarks with large size increase also comes with huge performance improvement: o catatusADM -- size increases 18.7%, performance improves 37.5% o leslie3d -- size increases 34.15%, performance improves 29.4% .. etc. CPU savings here are much larger than the cost due to small ram increases in text. For applications that really care about size, Os should be used anyway. For the compile time increase, do you see similar pattern -- i.e., large compile time increase --> large performance improvement? On the other hand, 10% compile time increase due to one pass sounds excessive -- there might be some lo
Re: Steven Bosscher appointed RTL optimizers reviewer
On Sun, Aug 11, 2013 at 10:04 PM, Gerald Pfeifer wrote: > It's my pleasure to announce the appointment of Steven Bosscher > as RTL optimizers reviewer. > > Congratulations and Happy Hacking, Steven! > > Gerald > > PS: Please update MAINTAINERS accordingly. Thanks! I've updated MAINTAINERS in r201889. Ciao! Steven
Re: Steven Bosscher appointed RTL optimizers reviewer
congrats! David On Tue, Aug 20, 2013 at 12:24 PM, Steven Bosscher wrote: > On Sun, Aug 11, 2013 at 10:04 PM, Gerald Pfeifer wrote: >> It's my pleasure to announce the appointment of Steven Bosscher >> as RTL optimizers reviewer. >> >> Congratulations and Happy Hacking, Steven! >> >> Gerald >> >> PS: Please update MAINTAINERS accordingly. > > > Thanks! I've updated MAINTAINERS in r201889. > > Ciao! > Steven
Re: Recent libstdc++-v3 regressions (PCHs related?!?)
On Tue, 2013-08-20 at 17:02 +0200, Paolo Carlini wrote: > Hi, > > On 08/20/2013 04:41 PM, David Malcolm wrote: > > On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote: > >> Hi, > >> > >> sorry it the issue is by now well known but... I see many libstdc++-v3 > >> regressions on at least x86_64-linux. When running the libstdc++-v3 > >> testsuite (which uses PCHs) one gets tons of new fails like the below. > >> That's annoying, a lot of confusing noise. > >> > >> Thanks! > >> Paolo. > >> > >> PS: CC-ing two "random" ;) people lately very active. > > Sorry about this - looking at the backtrace this could well be due to > > me, specifically r201865, which moved the gcc::pass_manager and all the > > passes into the GC heap (so that we can then move GC-owned per-pass > > state into the pass instances). > I can confirm that r201864 isn't affected. Thanks for looking into this! Thanks. It tool me a while to reproduce the failure - perhaps on my test box, GC is happening much less than on yours? On a test run I only saw 6 failures due to this (my test machine appears to have 3.6 GB of RAM) Is there a good way to encourage the testsuite to GC more? (I know about setting --param ggc-min-expand=0 --param ggc-min-heapsize=0 on an individual invocation, but is there a standard way of doing this? Or do I need to run the whole thing in a cgroup or somesuch, and constrain the available RAM?) The bug (or, at least the first one I see) is that the pass_manager's "passes_by_id" array is being allocated using XRESIZEVEC (xrealloc, hence malloc/realloc under the covers), but given that all this is meant to interact with GC, it needs to be persistable to PCH [1]. Now that I see it, I'm wondering how it managed to work in my prior testing. Presumably the array always happened to be allocated at the same location between the process that created the pch file and the processes that read it. Is there a good way to perturb memory so that accidentally mixing a malloc allocation with a GC allocation is more reliably fatal, to shake out this kind of bug? i.e. to make malloc place its results at locations that vary from process to process? (perhaps in libiberty?) Perhaps also valgrind can catch this kind of thing? Thanks Dave [1] I wish I could just have GC and not have to deal with PCH; oh well.
Re: Recent libstdc++-v3 regressions (PCHs related?!?)
On Tue, 2013-08-20 at 21:26 -0400, David Malcolm wrote: > On Tue, 2013-08-20 at 17:02 +0200, Paolo Carlini wrote: > > Hi, > > > > On 08/20/2013 04:41 PM, David Malcolm wrote: > > > On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote: > > >> Hi, > > >> > > >> sorry it the issue is by now well known but... I see many libstdc++-v3 > > >> regressions on at least x86_64-linux. When running the libstdc++-v3 > > >> testsuite (which uses PCHs) one gets tons of new fails like the below. > > >> That's annoying, a lot of confusing noise. > > >> > > >> Thanks! > > >> Paolo. > > >> > > >> PS: CC-ing two "random" ;) people lately very active. > > > Sorry about this - looking at the backtrace this could well be due to > > > me, specifically r201865, which moved the gcc::pass_manager and all the > > > passes into the GC heap (so that we can then move GC-owned per-pass > > > state into the pass instances). > > I can confirm that r201864 isn't affected. Thanks for looking into this! > > Thanks. > > It tool me a while to reproduce the failure - perhaps on my test box, GC > is happening much less than on yours? On a test run I only saw 6 > failures due to this (my test machine appears to have 3.6 GB of RAM) > > Is there a good way to encourage the testsuite to GC more? (I know about > setting --param ggc-min-expand=0 --param ggc-min-heapsize=0 on an > individual invocation, but is there a standard way of doing this? Or do > I need to run the whole thing in a cgroup or somesuch, and constrain the > available RAM?) > > The bug (or, at least the first one I see) is that the pass_manager's > "passes_by_id" array is being allocated using XRESIZEVEC (xrealloc, > hence malloc/realloc under the covers), but given that all this is meant > to interact with GC, it needs to be persistable to PCH [1]. Now that I > see it, I'm wondering how it managed to work in my prior testing. > Presumably the array always happened to be allocated at the same > location between the process that created the pch file and the processes > that read it. ...and also the code wasn't visiting the array itself during pch traversal, just the elements within it. Fixing this will likely make the other problem show up immediately. > Is there a good way to perturb memory so that accidentally mixing a > malloc allocation with a GC allocation is more reliably fatal, to shake > out this kind of bug? i.e. to make malloc place its results at > locations that vary from process to process? (perhaps in libiberty?) > Perhaps also valgrind can catch this kind of thing? > > Thanks > Dave > > [1] I wish I could just have GC and not have to deal with PCH; oh well. >
Re: Steven Bosscher appointed RTL optimizers reviewer
> On Tue, Aug 20, 2013 at 12:24 PM, Steven Bosscher > wrote: >> On Sun, Aug 11, 2013 at 10:04 PM, Gerald Pfeifer wrote: >>> It's my pleasure to announce the appointment of Steven Bosscher >>> as RTL optimizers reviewer. >>> >>> Congratulations and Happy Hacking, Steven! >>> >>> Gerald >>> >>> PS: Please update MAINTAINERS accordingly. >> >> >> Thanks! I've updated MAINTAINERS in r201889. >> >> Ciao! >> Steven Congrats! I knew you deserve this position. Many of your comments on mailing list did help me a lot to improve my implementation for GCC contribution. :) By the way, would you like to post a patch about MAINTAINERS file changes on gcc-patches? ^^ Best regards, jasonwucj
