GCC 5 Status Report (2015-01-19), Trunk in Stage 4
Status == The trunk is now in "Stage 4" which means it is open for regression and documentation fixes only, like if it were a release branch. Please concentrate on getting P1 bugs fixed and provide help in confirming and analyzing UNCONFIRMED bugs. For non-primary, non-secondary targets important bugs are not flagged with high priority - instead target maintainers have to ensure themselves that the GCC 5 release will be in proper shape for them (same applies to non-C/C++ frontends and runtime). Please also make sure to mark bugs as regressions if appropriate, always filling out the known-to-work and known-to-fail fields. Quality Data Priority # Change from last report --- --- P1 32- 7 P2 97- 1 P3 32- 16 --- --- Total 161- 24 Previous Report === https://gcc.gnu.org/ml/gcc/2015-01/msg00032.html
Re: organization of optimization options in manual
On 01/17/15 07:34, Gary Funck wrote: On 01/14/15 23:15:59, Jeff Law wrote: Sounds good. I think just starting with the list & creating the buckets with the list. Then post here and we'll iterate and try to nail that down before you start moving everything in the .texi file. Something to consider, if the optimization options are re-worked: Arrange the -O options such that -O1 can be described by a distinct set of specific optimizations enabled (or disabled) in addition to -O0, and -O2 would be described as a composite of specific optimizations applied to -O1 and so on. (This might require the addition of new optimization options.) For -O1 to -O2 and -O2 to -O3, that makes sense. However, -O0 to -O1 isn't something we can do this for right now as there are still many things that -O1 turns on that are not flag controlled. Whether or not to make all those bits individually controllable is a subject of debate. Personally, I think we have too many options, so my inclination would not be to make all those bits individually controllable. Others may have different opinions. jeff
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On 19 January 2015 at 09:17, Richard Biener wrote: > > Status > == > > The trunk is now in "Stage 4" which means it is open for regression > and documentation fixes only, like if it were a release branch. > > Please concentrate on getting P1 bugs fixed and provide help in > confirming and analyzing UNCONFIRMED bugs. For non-primary, > non-secondary targets important bugs are not flagged with high > priority - instead target maintainers have to ensure themselves > that the GCC 5 release will be in proper shape for them (same > applies to non-C/C++ frontends and runtime). > > Please also make sure to mark bugs as regressions if appropriate, > always filling out the known-to-work and known-to-fail fields. > > > Quality Data > > > Priority # Change from last report > --- --- > P1 32- 7 > P2 97- 1 > P3 32- 16 > --- --- > Total 161- 24 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2015-01/msg00032.html I would like to commit these two patches which complete the C++11 library implementation: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01648.html And this one to complete C++14 library implementation: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01704.html This one is tiny, and only affects the header, which is, as the name suggests, experimental: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01684.html OK? (After that I will stop changing things and fix the regressions!)
colors in `-fsanitize=bounds' and UBSAN_OPTIONS
I compile and run my program inside Emacs (M-x compile) with gcc 5.0.0 20150112 using `-fsanitize=bounds'. Although this Emacs buffer is technically a tty, but it is `dumb' and does not handle colors properly. The gcc info concerning `-fsanitize=address' hints that there is a parameter ASAN_OPTIONS and the referenced wiki of address-sanitizer says that this environment variable can be used to disable the colors. Unfortunately and very confusingly, this hint does not help with `-fsanitize=bounds', since it uses UBSAN_OPTIONS instead. I guess the gcc info should be updated to mention UBSAN_OPTIONS. It would be nice to port the terminal color capability detection code from gcc to sanitizer, since gcc itself colorizes the error messages properly: by default the colors are on in `xterm', and off in `dumb'. -- Regards, ASK
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On Mon, Jan 19, 2015 at 12:32 PM, Jonathan Wakely wrote: > I would like to commit these two patches which complete the C++11 > library implementation: I would definitely be in favor. > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html Just a nit. Why wouldn't you check the value of the variable after the assignment in the test case?
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On 19 January 2015 at 18:05, Ulrich Drepper wrote: >> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html > > Just a nit. Why wouldn't you check the value of the variable after > the assignment in the test case? Umm, just because I'm dumb? :-) I'll make that change to my local branch, thanks.
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On Mon, Jan 19, 2015 at 05:32:39PM +, Jonathan Wakely wrote: > I would like to commit these two patches which complete the C++11 > library implementation: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01648.html > > And this one to complete C++14 library implementation: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01704.html > > This one is tiny, and only affects the header, > which is, as the name suggests, experimental: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01684.html > > OK? I think this is worth making an exception for it. So ok from me, but please give Richard and/or Joseph a chance to chime in if they disagree. Jakub
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On Mon, Jan 19, 2015 at 1:17 AM, Richard Biener wrote: > > Status > == > > The trunk is now in "Stage 4" which means it is open for regression > and documentation fixes only, like if it were a release branch. > > Please concentrate on getting P1 bugs fixed and provide help in > confirming and analyzing UNCONFIRMED bugs. For non-primary, > non-secondary targets important bugs are not flagged with high > priority - instead target maintainers have to ensure themselves > that the GCC 5 release will be in proper shape for them (same > applies to non-C/C++ frontends and runtime). > > Please also make sure to mark bugs as regressions if appropriate, > always filling out the known-to-work and known-to-fail fields. > > > Quality Data > > > Priority # Change from last report > --- --- > P1 32- 7 > P2 97- 1 > P3 32- 16 > --- --- > Total 161- 24 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2015-01/msg00032.html Can we make an exception for https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00956.html It was originally submitted in November, 2013: https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01515.html -- H.J.
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On Mon, 19 Jan 2015, Jakub Jelinek wrote: > On Mon, Jan 19, 2015 at 05:32:39PM +, Jonathan Wakely wrote: > > I would like to commit these two patches which complete the C++11 > > library implementation: > > > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01648.html > > > > And this one to complete C++14 library implementation: > > > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01704.html > > > > This one is tiny, and only affects the header, > > which is, as the name suggests, experimental: > > > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01684.html > > > > OK? > > I think this is worth making an exception for it. > So ok from me, but please give Richard and/or Joseph a chance to chime in if > they disagree. OK with me as well. -- Joseph S. Myers jos...@codesourcery.com
[ping] Re: proper name of i386/x86-64/etc targets
On 01/01/2015 05:30 PM, Sandra Loosemore wrote: I've noticed that the GCC user documentation is quite inconsistent about the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a section for "i386 and x86-64 Options", but in other places the manual uses x86, X86, i?86, i[34567]86, x86_64 (underscore instead of a dash), etc. I'd be happy to work on a patch to bring the manual to using a common naming convention, but what should it be? Wikipedia seems to use "x86" (lowercase) to refer to the entire family of architectures (including the original 16-bit variants), "IA-32" for the 32-bit architecture (I believe that is Intel's official name), and "x86-64" (with a dash instead of underscore) for the 64-bit architecture. But of course the target maintainers should have the final say on what names to use. Ping? Any thoughts? -Sandra
Problem with extremely large procedures and 64-bit code
Hi, I have a strange problem with extremely large procedures when generating 64-bit code I am using gcc 4.9.2 on RHEL6.3 on a 64-thread 4-socket Xeon E7 4820 with 256GB of memory. No avx extensions, using sse option when building the compiler. This particular code is serial. I made measurements with 32- and 64- bit both debug -g and optimize -O3 for two different examples (this is a circuit simulator and each example is a different circuit that uses different transistors). Example A is the one the effect is more acute. I listed at the bottom of the e-mail the 3 procedures that consume 90% of the execution time: a) As a counter-example, the factor code listed is heavily optimized hand-written 300-lines of C++ code that behaves as expected: 64-bit optimize is way faster than any other, up to 15x faster than 32-bit debug (btw great job in the compiler, it is really shining here). b) evalTran has 18000 lines of auto-generated code and behaves very counter-intuitively 64-bit optimize code is 3x slower than 32-bit optimize code. c) evalTranRhs has 5000 lines even worse: 64-bit is 4x slower than 32-bit. Notice that all the data structures in 32-bit code and 64-bit code are identical and most variables are identical - in fact all integers used are 64-bit, and most operations are floating-point ops. Initially I thought the 64-bit code was a lot bigger than 32-bit code and the cache was overwhelmed. In fact the difference in code sizes is not even 10% (at least debug - notice I calculated the size of each procedure in bytes) so my trash-the I-cache conjecture seems to be wrong. The overall execution time is causing us a lot of problems - 64-bit optimize takes 16seconds, even more than 32-bit debug 10seconds and 32-bit optimize 4.8 seconds. Considering we only care about 64-bit optimize we got a big problem here. Example B is not so bad, and in fact 64-bit code is slightly faster than 32-bit code, would be nice if went even faster, but if I got A to behave like that I'd be pretty happy already. I tried to look at the wide array of optimizing options for the code, it is is a dizzying task and I could not get any kind of intuition besides the -O3 ... Would you have any suggestions for the proper flags for those ridiculously large auto-generated codes that might be able to alleviate this 32-bit vs 64-bit problem? Would you think that the fact this code is in a dynamic linked library (-fPIC) plays a role? Thanks very much for your help, Ricardo All times are wall clock in micro-seconds - the main was checked against the reported UNIX time and is exact. example A == evalTran has 18000 lines of C code (two for loops around 99% of the code) evalTranRhs has 5000 lines of C code (two for loops around 99% of the code) 32 bit debug -g -m32 -fPIC -Wall -Winvalid-pch -msse2 %time elapsed(us) #calls per call(us)timer name @DN@ - --- -- -- 2.503 254536833530 numerical TRAN factor 56.01 5695065 8335683 evalTranbytes=231791 35.41 3600646 13924 258 evalTranRhs bytes=57501 10010168242 1 10168242main @DT@ 32 bit optimize -O3 -m32 -fPIC -Wall -Winvalid-pch -msse2 %time elapsed(us) #calls per call(us) timer name @DN@ - --- -- -- 0.710 34442 83354 numerical TRAN factor 43.06 2087757 8335250 evalTran 43.49 2108786 13925 151 evalTranRhs 1004848520 1 4848520 main @DT@ 64 bit debug -g -fPIC -Wall -Winvalid-pch -msse2 %time elapsed(us) #calls per call(us) timer name @DN@ - --- -- -- 0.973 205144833524 numerical TRAN factor 46.43 9785920 83351174 evalTran bytes=252741 49.72 1047 13924 752 evalTranRhs bytes=58442 10021077659 1 21077659main @DT@ 64 bit optimize -O3 -fPIC -Wall -Winvalid-pch -msse2 %time elapsed(us) #calls per call(us)timer name @DN@ - --- -- -- 0.147 23819 83352 numerical TRAN factor 39.26 6360254 8335763 evalTran 57.28 9279087 13924 666 evalTranRhs 10016198762 1 16198762main @DT@ example B = evalTran has 1 lines of C code (two for loops around 99% of the code) evalTranRhs has 2500 lines of C code (two for loops around 99% of the code) 32-bit debug -g -fPIC -Wall -Winvalid-pch -msse2 %time elapsed(us) #calls per call(us)timer name @DN@ - --- -- -- 6.55 98982646612 21 numerical T
Re: [ping] Re: proper name of i386/x86-64/etc targets
On Tue, Jan 20, 2015 at 3:26 AM, Sandra Loosemore wrote: >> I've noticed that the GCC user documentation is quite inconsistent about >> the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a >> section for "i386 and x86-64 Options", but in other places the manual >> uses x86, X86, i?86, i[34567]86, x86_64 (underscore instead of a dash), >> etc. >> >> I'd be happy to work on a patch to bring the manual to using a common >> naming convention, but what should it be? Wikipedia seems to use "x86" >> (lowercase) to refer to the entire family of architectures (including >> the original 16-bit variants), "IA-32" for the 32-bit architecture (I >> believe that is Intel's official name), and "x86-64" (with a dash >> instead of underscore) for the 64-bit architecture. But of course the >> target maintainers should have the final say on what names to use. > > > Ping? Any thoughts? Let's ask Intel people ... Uros.
