[Bug c++/33127] New: private isn't private
Compilation of following code fails with error:
a.cpp: In constructor `c::c()':
a.cpp:14: error: reference to `i' is ambiguous
a.cpp:8: error: candidates are: int b::i
a.cpp:3: error: int a::i
a.cpp:14: error: `i' was not declared in this scope
class a{
private:
int i;
};
class b{
public:
int i;
};
class c: public a,public b{
public:
c(){
i=0;
};
};
int main(){
c o;
};
a::i isn't accessible in constructor of c.
Reference to i can't be ambiguous.
--
Summary: private isn't private
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wbrana at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33127
[Bug tree-optimization/21485] [4.2 Regression] codegen regression due to PRE increasing register pressure (missing load PRE really)
--- Comment #27 from wbrana at gmail dot com 2008-09-28 18:00 --- gcc 4.3.2, -march=core2 instead of -march=nocona BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 1516.3 : 38.89 : 12.77 STRING SORT : 381.24 : 170.35 : 26.37 BITFIELD: 6.0164e+08 : 103.20 : 21.56 FP EMULATION: 332 : 159.31 : 36.76 FOURIER : 32687 : 37.17 : 20.88 ASSIGNMENT : 57.93 : 220.44 : 57.18 IDEA:9380 : 143.46 : 42.60 HUFFMAN : 3276.1 : 90.85 : 29.01 NEURAL NET : 72.251 : 116.07 : 48.82 LU DECOMPOSITION: 2641.5 : 136.84 : 98.81 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 117.698 FLOATING-POINT INDEX: 83.889 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz 3200MHz L2 Cache: 4096 KB OS : Linux 2.6.26.5 C compiler : gcc-4.3.2 libc: MEMORY INDEX: 31.912 INTEGER INDEX : 27.598 FLOATING-POINT INDEX: 46.528 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug tree-optimization/37732] New: [4.2/4.3/4.4 Regression] 40% slower numeric sort
: 85.548 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz 3200MHz L2 Cache: 4096 KB OS : Linux 2.6.26.5 C compiler : gcc-4.3.2 libc: libc-2.8.so MEMORY INDEX: 31.716 INTEGER INDEX : 27.199 FLOATING-POINT INDEX: 47.448 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 1580.2 : 40.52 : 13.31 STRING SORT : 359.88 : 160.80 : 24.89 BITFIELD: 5.9462e+08 : 102.00 : 21.30 FP EMULATION: 291.28 : 139.77 : 32.25 FOURIER : 32567 : 37.04 : 20.80 ASSIGNMENT : 57.097 : 217.26 : 56.35 IDEA: 7876.8 : 120.47 : 35.77 HUFFMAN : 3433.1 : 95.20 : 30.40 NEURAL NET : 72.091 : 115.81 : 48.71 LU DECOMPOSITION: 2664.4 : 138.03 : 99.67 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 112.739 FLOATING-POINT INDEX: 83.966 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz 3200MHz L2 Cache: 4096 KB OS : Linux 2.6.26.5 C compiler : gcc-4.2.4 libc: libc-2.8.so MEMORY INDEX: 31.032 INTEGER INDEX : 26.138 FLOATING-POINT INDEX: 46.571 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. -- Summary: [4.2/4.3/4.4 Regression] 40% slower numeric sort Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wbrana at gmail dot com GCC build triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37732
[Bug tree-optimization/37732] [4.2/4.3/4.4 Regression] 40% slower numeric sort
--- Comment #2 from wbrana at gmail dot com 2008-10-03 22:47 --- (In reply to comment #1) > Dup of PR21485? > PR21485 is ignored by reporter and doesn't have updated summary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37732
[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #33 from wbrana at gmail dot com 2008-10-04 09:22 --- results with -fno-tree-pre 1749 - 4.4.0 20080926 (experimental) 1701 - 4.3.2 2476 - 4.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug bootstrap/56182] [4.6 Regression] gcc/config/i386/t-linux64:29: recipe commences before first target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56182 wbrana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from wbrana 2013-02-04 18:50:24 UTC --- It seems Gentoo build is modifying t-linux64. Change in GCC broke Gentoo build.
[Bug c/56458] New: support for crash on invalid array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56458
Bug #: 56458
Summary: support for crash on invalid array access
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wbr...@gmail.com
GCC could support command-line flag for at least C and C++, which would enable
checking of array access, which would increase security.
If wrong access is detected, process should crash, but following code returns
two zeros.
#include
using namespace std;
int array[5];
inline void crash() {
int* v = 0;
*v = 0;
}
int read1(int i) {
return array[i];
}
int write1(int i) {
return array[i] = 0;
}
int main(int i, char* argv[]) {
cout << read1(i + 100) << endl;
cout << write1(i + 100) << endl;
return 0;
}
[Bug tree-optimization/56522] New: [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 Bug #: 56522 Summary: [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz 196263 ASSIGNMENT : 57.274 : 217.94 : 56.53 196260 ASSIGNMENT : 62.83 : 239.08 : 62.01 4.6 branch ASSIGNMENT : 64.311 : 244.72 : 63.47 196263: 2013-02-25 Richard Biener PR tree-optimization/56175 * tree-ssa-forwprop.c (hoist_conversion_for_bitop_p): New predicate, split out from ... (simplify_bitwise_binary): ... here. Also guard the conversion of (type) X op CST to (type) (X op ((type-x) CST)) with it. * gcc.dg/tree-ssa/forwprop-24.c: New testcase. -O3 -g0 -march=corei7 -fomit-frame-pointer -funroll-loops -ffast-math -fno-PIE -fno-exceptions -fno-stack-protector -static CPU Sandy Bridge
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #4 from wbrana 2013-03-07 18:35:10 UTC --- compiled 196260 again using same way and nbench is now slow, which is strange. When I compile nbench using gcc compiled from snapshot ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130224/ there is different result from nbench compiled using gcc from GIT using revision 196245 http://gcc.gnu.org/ml/gcc/2013-02/msg00273.html nbench compiled using gcc snapshot is fast nbench compiled using gcc revision is slow file nbench1.c.164t.optimized is same with both gcc builds, but executable has different size despite of using same CFLAGS nbench compiled using gcc revision has 1366219 bytes nbench compiled using gcc snapshot has 1205879 bytes
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #5 from wbrana 2013-03-08 14:17:52 UTC --- weird results in comment 4 were caused by unexpected Gentoo patches and/or broken GIT I made own build which doesn't contain any Gentoo patches and still can reproduce 9% slow down caused by 196263 When I run reduced test there is only 1% slow down. Reduced test case has similar difference on my PC as in comment 2. I'm using -m64.
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #6 from wbrana 2013-03-08 14:22:03 UTC --- Created attachment 29622 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29622 assign.c with main function
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #7 from wbrana 2013-03-08 14:23:35 UTC --- Created attachment 29623 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29623 assign.c.164t.optimized.diff
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #8 from wbrana 2013-03-08 14:24:38 UTC --- Created attachment 29624 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29624 nbench1.c.164t.optimized.diff
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #10 from wbrana 2013-03-08 17:27:49 UTC --- I found strange thing - result depends on linker there is slow down with "GNU ld (GNU Binutils) 2.23.1" there is improvement with "GNU gold (GNU Binutils 2.23.1) 1.11"
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #11 from wbrana 2013-03-08 17:36:10 UTC --- GNU ld (GNU Binutils) 2.23.1 192263 - slow 192260 - fast GNU gold (GNU Binutils 2.23.1) 1.11 192263 - fast 192260 - slow It is possible that result also depends on CPU model (core count, cache size, etc.)
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #12 from wbrana 2013-03-08 17:41:09 UTC --- (In reply to comment #11) > GNU ld (GNU Binutils) 2.23.1 > 192263 - slow > 192260 - fast I meant 196260 and 196263
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #13 from wbrana 2013-03-08 17:57:32 UTC --- There is almost no difference with reduced test case. Assignment in nbench can be tested with: ./nbench -cCOM.DAT where file COM.DAT has content: ALLSTATS=F DONUMSORT=F DOSTRINGSORT=F DOBITFIELD=F DOEMF=F DOFOUR=F DOASSIGN=T DOIDEA=F DOHUFF=F DONNET=F DOLU=F Which CPU have you tested?
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #15 from wbrana 2013-03-12 14:28:43 UTC --- I can see different results with different linkers - see above. Your CPU is Nehalem quad core, but my CPU is Sandy Bridge dual core, which have less L1/L2/L3 cache.
[Bug tree-optimization/56522] [4.8/4.9 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 wbrana changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #17 from wbrana 2013-03-20 11:37:05 UTC --- I can switch to gold linker since 4.8
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #5 from wbrana 2013-04-13 16:43:10 UTC --- branch 4.9 without lto 101462 bytes with -flto -fwhole-program 157243 bytes - linker bfd 155488 bytes - linker gold other CFLAGS = -O3 -g0 -march=corei7 -fomit-frame-pointer -funroll-loops -ffast-math -fno-PIE -fno-exceptions -fno-stack-protector
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #6 from wbrana 2013-04-13 17:01:27 UTC --- executable is smaller with lto when I add -fno-inline-functions 95928 vs 93880
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #7 from wbrana 2013-04-13 17:34:23 UTC --- -fno-inline-functions makes same tests 12% or 6% slower with lto/gold NUMERIC SORT: 1689.2 : 43.32 : 14.23 NUMERIC SORT: 1483.2 : 38.04 : 12.49 IDEA:9932 : 151.91 : 45.10 IDEA:9360 : 143.16 : 42.50
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #8 from wbrana 2013-04-13 17:59:47 UTC --- lto/gold -finline-limit=43 99960 bytes NUMERIC SORT: 1471.2 : 37.73 : 12.39 -finline-limit=44 149136 bytes NUMERIC SORT: 1705.2 : 43.73 : 14.36
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Summary|-fPIE -pie shouldn't|-fvisibility=hidden |disable -fvisibility=hidden |shouldn't be disabled with ||-fPIE -pie --- Comment #6 from wbrana 2012-08-10 12:31:08 UTC --- updated
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182
--- Comment #8 from wbrana 2012-08-10 13:40:29 UTC ---
int func() {
return random();
}
int main(){
return func();
}
$ gcc-4.7.2 -O2 1.c -o 1
$ nm -CD ./1
w __gmon_start__
U __libc_start_main
U random
$ gcc-4.7.2 -O2 -fPIE -pie 1.c -o 1
$ nm -CD ./1
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
00201040 B __bss_start
w __cxa_finalize
w __gmon_start__
08a0 T __libc_csu_fini
08b0 T __libc_csu_init
U __libc_start_main
00201040 D _edata
00201048 B _end
0760 T main
U random
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 --- Comment #10 from wbrana 2012-08-10 13:49:19 UTC --- How can I tell linker to not export symbols?
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 --- Comment #12 from wbrana 2012-08-10 17:27:02 UTC --- Created attachment 27986 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27986 bash compiled with -fPIE -pie -fvisibility=hidden
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 --- Comment #13 from wbrana 2012-08-10 17:29:15 UTC --- Created attachment 27987 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27987 bash compiled with -fPIE -pie
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #14 from wbrana 2012-08-10 17:39:27 UTC --- -fvisibility=hidden is really disabled. Attached output from bash without -fvisibility=hidden has 57 kB, but with -fvisibility=hidden only 11 kB. Which compiler/linker flag except -fvisibility=hidden will make 11 kB output from bash? How exactly should I use linker version script to hide symbols in bash executable or any other software?
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #16 from wbrana 2012-08-10 18:17:02 UTC --- -fvisibility=hidden exactly does what I need. Why it isn't enabled by default with -fPIE -pie?
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 --- Comment #18 from wbrana 2012-08-11 07:01:18 UTC --- I can use it, but other people don't have to know about this bug.
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 --- Comment #20 from wbrana 2012-08-11 07:39:37 UTC --- Why -fvisibility=hidden is enabled by default without -fPIE, but disabled with -fPIE?
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #21 from wbrana 2012-08-11 07:51:34 UTC --- People who don't want -fvisibility=hidden should use -fvisibility=normal and -fvisibility=hidden should be enabled by default.
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 --- Comment #23 from wbrana 2012-08-11 15:17:04 UTC --- Why lot of program's makefiles have to be changed? If this change breaks some program, developers of that program will fix it. You don't have to. New versions of GCC always break many programs see https://bugs.gentoo.org/show_bug.cgi?id=390247 This change will just another one of many changes.
[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #24 from wbrana 2012-08-11 15:37:47 UTC --- I compiled many programs with -fPIE -pie -fvisibility=hidden and almost all work fine. Very few broken ones could be easily fixed by adding -fvisibility=normal.
[Bug tree-optimization/21485] [4.6/4.7/4.8 Regression] missed load PRE, PRE makes i?86 suck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 --- Comment #52 from wbrana 2012-08-12 12:30:21 UTC --- This bug celebrated 7th anniversary this year. Congratulations!
[Bug tree-optimization/21485] [4.6/4.7/4.8 Regression] missed load PRE, PRE makes i?86 suck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 --- Comment #53 from wbrana 2012-08-13 08:26:13 UTC --- It seems it was improved. 4.8 20120806 NUMERIC SORT: 1543.7 : 39.59 : 13.00 4.8 20120813 NUMERIC SORT: 2007.8 : 51.49 : 16.91
[Bug target/54246] New: Bytemark FOURIER 54% slower in X32 chroot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54246 Bug #: 54246 Summary: Bytemark FOURIER 54% slower in X32 chroot Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz compiled on 64-bit system with glibc 2.14.1 and run in X32 chroot FOURIER : 36275 : 41.26 : 23.17 compiled in X32 chroot with glibc 2.16 and run in X32 chroot FOURIER : 16574 : 18.85 : 10.59 both were compiled with same CFLAGS -static -m64 -ggdb -Wall -O3 -funroll-loops -g0 -march=core2 -mfpmath=sse -fomit-frame-pointer -ffast-math -mssse3 -fno-PIE -fno-exceptions -fno-stack-protector
[Bug tree-optimization/54271] New: [4.7/4.8 Regression] libgcrypt CRC24RFC2440 30% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54271 Bug #: 54271 Summary: [4.7/4.8 Regression] libgcrypt CRC24RFC2440 30% slower Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2 tests/benchmark --cipher-repetitions 100 --hash-repetitions 100 md crc24rfc2440 gcc 4.6 20120804 CRC24RFC2440 1660 1690 3420 1900 1670 10340ms gcc 4.7 20120812 CRC24RFC2440 2520 2550 4230 2760 2520 14580ms gcc 4.8 20120813 CRC24RFC2440 2550 2590 4220 2790 2550 14700ms -O3 -pipe -march=core2 -mtune=core2 -fomit-frame-pointer -funroll-loops --param max-unrolled-insns=64
[Bug target/54246] Bytemark FOURIER 54% slower with glibc 2.16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54246 wbrana changed: What|Removed |Added Summary|Bytemark FOURIER 54% slower |Bytemark FOURIER 54% slower |in X32 chroot |with glibc 2.16 --- Comment #2 from wbrana 2012-08-19 08:20:06 UTC --- It isn't related to X32, but glibc 2.16. Bug submitted: http://sourceware.org/bugzilla/show_bug.cgi?id=14496
[Bug bootstrap/54329] New: gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 Bug #: 54329 Summary: gcc/reginfo.o differs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com gcc 4.8 0adffe7816495b961a1bab85eaaf7bcea85ed2a8 gcc/reginfo.o differs gcc/ira.o differs make[2]: *** [compare] Error 1
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 --- Comment #1 from wbrana 2012-08-20 11:20:33 UTC --- Created attachment 28055 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28055 build log
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 --- Comment #3 from wbrana 2012-08-20 12:04:05 UTC --- configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --with-arch=core2 --with-tune=core2 --disable-plugin --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre999 9/python --enable-checking=release --disable-libgcj --disable-build-with-cxx --disable-build-poststage1-with-cxx --disable-libquadmath --enable-languages=c --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.8.0_pre CFLAGS="-O2 -O3 -pipe -march=core2 -mtune=core2 -fomit-frame-pointer -funroll-loops --param max-unrolled-insns=64" CXXFLAGS="-O2 -O3 -pipe -march=core2 -mtune=core2 -fomit-frame-pointer -funroll-loops --param max-unrolled-insns=64"
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 wbrana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from wbrana 2012-08-27 08:27:45 UTC --- it seems to be fixed
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2 --- Comment #12 from wbrana 2012-08-27 08:42:38 UTC --- 4.8 has improved 20120813 FP EMULATION: 229.84 : 110.29 : 25.45 20120827 FP EMULATION: 281.4 : 135.03 : 31.16
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 wbrana changed: What|Removed |Added Attachment #28055|0 |1 is obsolete|| --- Comment #5 from wbrana 2012-09-10 07:45:10 UTC --- Created attachment 28158 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28158 build log new failure gcc/cfgcleanup.o differs
[Bug bootstrap/54329] gcc/cfgcleanup.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 wbrana changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Summary|gcc/reginfo.o differs |gcc/cfgcleanup.o differs --- Comment #6 from wbrana 2012-09-10 07:47:09 UTC --- see comment 5
[Bug bootstrap/54329] [4.8 Regression] gcc/cfgcleanup.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 --- Comment #7 from wbrana 2012-09-24 11:48:51 UTC --- still broken
[Bug tree-optimization/54143] [4.8 Regression] Bytemark ASSIGNMENT 8% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54143 wbrana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from wbrana 2012-09-27 08:52:44 UTC --- It seems to be fixed.
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #15 from wbrana 2012-10-04 14:25:29 UTC --- I can reliably reproduce bug on Core 2. Reverting 175752 reliably fixes bug.
[Bug tree-optimization/54977] New: example3 not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54977
Bug #: 54977
Summary: example3 not vectorized
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wbr...@gmail.com
I tried to compile example3 from
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
typedef int aint __attribute__ ((__aligned__(16)));
void foo (int n, aint * __restrict__ p, aint * __restrict q) {
/* feature: support for (aligned) pointer accesses. */
while (n--){
*p++ = *q++;
}
}
with g++ -O3 -ftree-vectorizer-verbose=2 -fPIC -shared 1.cpp -o 1.so
Analyzing loop at 1.cpp:5
5: not vectorized: no vectype for stmt: D.2238_9 = *q_21;
scalar_type: aint
1.cpp:2: note: vectorized 0 loops in function.
[Bug java/53817] New: The import antlr cannot be resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53817 Bug #: 53817 Summary: The import antlr cannot be resolved Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com Created attachment 27723 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27723 log build of stringtemplate with command CLASSPATH=/usr/local/lib/libantlr.so gcj-4.7.1 -v -O3 -fPIC -shared -o test.so `find src -type f -name '*.java'` fails with error src/org/antlr/stringtemplate/language/StringTemplateToken.java:30: error: The import antlr cannot be resolved import antlr.CommonToken; see log
[Bug java/53819] New: org/antlr/runtime/ANTLRFileStream.java:0:0: internal compiler error: in java_mark_decl_local, at java/decl.c:1912
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53819 Bug #: 53819 Summary: org/antlr/runtime/ANTLRFileStream.java:0:0: internal compiler error: in java_mark_decl_local, at java/decl.c:1912 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com Created attachment 27725 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27725 log gcj-4.7.1 -O3 -fPIC -shared -o test.so junit.jar antlr-3.1.3.jar antlr-runtime-3.1.3.jar stringtemplate-3.2.jar
[Bug java/53817] The import antlr cannot be resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53817 --- Comment #2 from wbrana 2012-06-30 21:11:24 UTC --- It seems jar files have to be in CLASSPATH instead of so files.
[Bug java/53817] The import antlr cannot be resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53817 wbrana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from wbrana 2012-06-30 21:44:26 UTC --- WORKSFORME
[Bug java/53819] org/antlr/runtime/ANTLRFileStream.java:0:0: internal compiler error: in java_mark_decl_local, at java/decl.c:1912
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53819 wbrana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #1 from wbrana 2012-06-30 22:55:31 UTC --- compilation of antlr 3.4 was successful
[Bug c++/53910] New: use -std=c++11 by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53910 Bug #: 53910 Summary: use -std=c++11 by default Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com g++ could use -std=c++11 by default
[Bug other/53928] New: use tar.xz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53928 Bug #: 53928 Summary: use tar.xz Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com xz has better compression than bz2 59740 kBgcc-4.7.1.tar.xz 80708 kBgcc-4.7.1.tar.bz2
[Bug other/53961] New: internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961 Bug #: 53961 Summary: internal compiler error: in memory_address_length, at config/i386/i386.c:23341 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com see https://bugs.gentoo.org/show_bug.cgi?id=426572
[Bug other/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961 --- Comment #2 from wbrana 2012-07-14 15:14:18 UTC --- Created attachment 27788 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27788 source code /usr/bin/gcc: file format elf32-x86-64 gcc -m64 -O2 -c ./host_ppc_isel.i -o test.o In file included from priv/host_ppc_isel.c:37:0: ../VEX/pub/libvex_basictypes.h: In function 'Ptr_to_ULong': ../VEX/pub/libvex_basictypes.h:195:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../VEX/pub/libvex_basictypes.h: In function 'ULong_to_Ptr': ../VEX/pub/libvex_basictypes.h:200:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] priv/host_ppc_isel.c: In function 'iselInt64Expr': priv/host_ppc_isel.c:2834:1: internal compiler error: in memory_address_length, at config/i386/i386.c:23341
[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961 --- Comment #4 from wbrana 2012-07-14 19:22:16 UTC --- Are you using X32 GCC binary?
[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961 --- Comment #6 from wbrana 2012-07-14 20:17:23 UTC --- if gcc is compiled as X32 /usr/bin/gcc: file format elf32-x86-64 and command gcc -m64 -O2 -c ./host_ppc_isel.i -o test.o
[Bug pch/48004] doesn't work with randomize_va_space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48004 wbrana changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from wbrana 2012-07-19 18:57:26 UTC --- I have tested GCC 4.5.4 and 4.7.1. It seems to be fixed.
[Bug pch/54042] New: always create and use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54042 Bug #: 54042 Summary: always create and use Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: pch AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com GCC supports pch, but majority of software don't use them GCC could automatically generate and use them to speed up compilation
[Bug pch/54050] New: chaining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54050 Bug #: 54050 Summary: chaining Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: pch AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com GCC could support chaining of pch, which is supported by clang: http://clang.llvm.org/docs/PCHInternals.html Precompiled headers can be chained. When you create a PCH while including an existing PCH, Clang can create the new PCH by referencing the original file and only writing the new data to the new file. For example, you could create a PCH out of all the headers that are very commonly used throughout your project, and then create a PCH for every single source file in the project that includes the code that is specific to that file, so that recompiling the file itself is very fast, without duplicating the data from the common headers for every file.
[Bug c++/54054] New: merged compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54054
Bug #: 54054
Summary: merged compilation
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wbr...@gmail.com
Using command
g++-4.7.1 -O3 -march=core2 -v -o test func.cpp main.cpp
GCC compiles files separately with
cc1plus func.cpp
cc1plus main.cpp
GCC could merge these files and compile only file merged.cpp
---func.cpp-
#include "func.h"
#include
long int func() {
return random();
}
---main.cpp
#include "func.h"
#include
int main() {
return func();
}
-merged.cpp---
#include "func.h"
#include
long int func() {
return random();
}
int main() {
return func();
}
[Bug middle-end/54066] New: wrong-code at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54066
Bug #: 54066
Summary: wrong-code at -O0
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wbr...@gmail.com
GCC 4.6.3
1
GCC 4.7.1
2
#include
using namespace std;
struct c {
char* Achit;
c() {
Achit = new char[1];
}
unsigned char uint8() {
unsigned char lires = 1;
Achit += 1;
return lires;
};
};
int main() {
c* Lf = new c();
char* Lc1 = Lf->Achit;
Lf->Achit += Lf->uint8();
cout << Lf->Achit - Lc1 << endl;
}
[Bug tree-optimization/54077] New: Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 Bug #: 54077 Summary: Bytemark FP EMULATION 44% slower than with clang Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz clang FP EMULATION: 405.92 : 194.78 : 44.95 gcc FP EMULATION: 227.32 : 109.08 : 25.17 CFLAGS = -s -Wall -O3 -g0 -march=core2 -fomit-frame-pointer -funroll-loops -ffast-math -mssse3 -fno-PIE -fno-exceptions -fno-stack-protector
[Bug tree-optimization/54077] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #1 from wbrana 2012-07-24 09:39:37 UTC --- Created attachment 27863 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27863 AddSubInternalFPF.clang.txt
[Bug tree-optimization/54077] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #2 from wbrana 2012-07-24 09:41:21 UTC --- Created attachment 27864 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27864 AddSubInternalFPF.gcc.txt
[Bug tree-optimization/54077] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #3 from wbrana 2012-07-24 09:42:27 UTC --- Created attachment 27865 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27865 DivideInternalFPF.clang.txt
[Bug tree-optimization/54077] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #4 from wbrana 2012-07-24 09:43:38 UTC --- Created attachment 27866 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27866 DivideInternalFPF.gcc.txt
[Bug lto/54078] New: Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 Bug #: 54078 Summary: Bytemark 46% bigger binary with -flto Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com without -flto 106856 bytes with -flto 156312 bytes http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz CFLAGS = -s -Wall -O3 -g0 -march=core2 -fomit-frame-pointer -funroll-loops -ffast-math -mssse3 -fno-PIE -fno-exceptions -fno-stack-protector
[Bug tree-optimization/54081] New: Bytemark ASSIGNMENT 10% slower with g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54081 Bug #: 54081 Summary: Bytemark ASSIGNMENT 10% slower with g++ Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com Bytemark is 10% slower if compiled with g++ than with gcc gcc ASSIGNMENT : 63.36 : 241.10 : 62.53 g++ ASSIGNMENT : 57.411 : 218.46 : 56.66 CFLAGS = -s -Wall -O3 -g0 -march=core2 -fomit-frame-pointer -funroll-loops -ffast-math -mssse3 -fno-PIE -fno-exceptions -fno-stack-protector http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #2 from wbrana 2012-07-24 13:38:03 UTC --- 156312 bytes with -s -Wall -O3 -g0 -march=core2 -fomit-frame-pointer -funroll-loops -ffast-math -mssse3 -fno-PIE -fno-exceptions -fno-stack-protector -flto -fwhole-program?
[Bug lto/54108] New: 35% bigger binary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54108 Bug #: 54108 Summary: 35% bigger binary Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://sourceforge.net/projects/qemplayer/files/source%20code/qemplayer-12.6.tar.xz/download with -flto 478896 bytes without -flto 354896 bytes compiler flags can be changed in file SConstruct
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #4 from wbrana 2012-07-28 06:54:06 UTC --- one of tests is faster
[Bug lto/54118] New: ICE in lto_output_varpool_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54118 Bug #: 54118 Summary: ICE in lto_output_varpool_node Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com g++.dg/cpp0x/variadic-init.C fails with lto1: internal compiler error: in lto_output_varpool_node, at lto-cgraph.c:595 if -flto is used Compiler version: 4.7.2 20120728 (prerelease) (Gentoo Hardened 4.7.2 p1.0, pie-0.5.3) Platform: x86_64-pc-linux-gnu configure flags: --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --disable-nls --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-esp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python --enable-checking=release --disable-libgcj --disable-libquadmath --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.7.2 p1.0, pie-0.5.3'
[Bug tree-optimization/54077] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #6 from wbrana 2012-07-31 10:11:48 UTC --- clang FP EMULATION: 405.92 : 194.78 : 44.95 4.4.7 FP EMULATION: 337.44 : 161.92 : 37.36 4.5.4 FP EMULATION: 320.08 : 153.59 : 35.44 4.6.3 FP EMULATION: 320.68 : 153.88 : 35.51 4.7.1 FP EMULATION: 227.32 : 109.08 : 25.17
[Bug tree-optimization/54143] New: [4.8 Regression] Bytemark ASSIGNMENT 8% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54143 Bug #: 54143 Summary: [4.8 Regression] Bytemark ASSIGNMENT 8% slower Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz 4.8 20120422 ASSIGNMENT : 63.924 : 243.24 : 63.09 4.8 20120429 ASSIGNMENT : 58.793 : 223.72 : 58.03 4.8 20120729 ASSIGNMENT : 58.969 : 224.39 : 58.20 CFLAGS = -ggdb -Wall -O3 -finline-functions -g0 -march=core2 -fomit-frame-pointer -funroll-loops -ffast-math -mssse3 -fno-PIE -fno-exceptions -fno-stack-protector
[Bug tree-optimization/54143] [4.8 Regression] Bytemark ASSIGNMENT 8% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54143 --- Comment #1 from wbrana 2012-07-31 17:48:57 UTC --- Created attachment 27908 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27908 20120422
[Bug tree-optimization/54143] [4.8 Regression] Bytemark ASSIGNMENT 8% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54143 --- Comment #2 from wbrana 2012-07-31 17:50:20 UTC --- Created attachment 27909 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27909 20120429
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #7 from wbrana 2012-07-31 22:45:25 UTC --- 4.7 20110626 FP EMULATION: 318.44 : 152.80 : 35.26 4.7 20110703 FP EMULATION: 228.08 : 109.44 : 25.25
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #8 from wbrana 2012-08-01 10:59:46 UTC --- If I didn't make mistake it seems big slow down is caused by revision 175752 Date: Fri Jul 1 10:00:25 2011 + 2011-07-01 Kai Tietz * tree-ssa-forwprop.c (simplify_bitwise_binary): Fix typo. 2011-07-01 Kai Tietz * gcc.dg/tree-ssa/bitwise-sink.c: New test. 175751 FP EMULATION: 318.76 : 152.96 : 35.29 175752 FP EMULATION: 227.68 : 109.25 : 25.21
[Bug testsuite/54152] New: add Bytemark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54152 Bug #: 54152 Summary: add Bytemark Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz Bytemark could be added to tests to search for performance regressions. Its code has less than 400 kB.
[Bug tree-optimization/54153] New: [4.8 Regression] Bytemark IDEA 6% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54153 Bug #: 54153 Summary: [4.8 Regression] Bytemark IDEA 6% slower Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz 4.7.1 IDEA:9492 : 145.18 : 43.10 4.8 20120408 IDEA:9444 : 144.44 : 42.89 4.8 20120415 IDEA:8916 : 136.37 : 40.49 4.8 20120729 IDEA:8928 : 136.55 : 40.54
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #10 from wbrana 2012-08-01 22:35:29 UTC --- Reversion of 175752 on latest 4.7 branch improved FP EMU by 41%, but made ASSIGNMENT worse by 8%. with 175752 NUMERIC SORT: 1562.9 : 40.08 : 13.16 STRING SORT : 730.08 : 326.22 : 50.49 BITFIELD: 5.956e+08 : 102.17 : 21.34 FP EMULATION: 232.96 : 111.79 : 25.79 FOURIER : 36191 : 41.16 : 23.12 ASSIGNMENT : 63.469 : 241.51 : 62.64 IDEA:9512 : 145.48 : 43.20 HUFFMAN : 3475.8 : 96.38 : 30.78 NEURAL NET : 80.296 : 128.99 : 54.26 LU DECOMPOSITION: 2696.9 : 139.71 : 100.89 without 175752 NUMERIC SORT: 1526.9 : 39.16 : 12.86 STRING SORT : 724.96 : 323.93 : 50.14 BITFIELD: 5.962e+08 : 102.27 : 21.36 FP EMULATION: 328.32 : 157.54 : 36.35 FOURIER : 36275 : 41.26 : 23.17 ASSIGNMENT : 58.37 : 222.11 : 57.61 IDEA:9480 : 144.99 : 43.05 HUFFMAN : 3453.1 : 95.75 : 30.58 NEURAL NET : 79.128 : 127.11 : 53.47 LU DECOMPOSITION: 2733.4 : 141.60 : 102.25
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 --- Comment #11 from wbrana 2012-08-05 10:56:58 UTC --- I found something strange. There is much smaller slow down in ASSIGNMENT without 175752 with Gentoo Hardened patches gcc version 4.7.2 20120804 (prerelease) (Gentoo Hardened 4.7.2 p1.2, pie-0.5.3) ASSIGNMENT : 62.95 : 239.53 : 62.13 latest gcc 4.7 branch ASSIGNMENT : 58.29 : 221.80 : 57.53
[Bug c/54179] please split insn-emit.c !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 wbrana changed: What|Removed |Added CC||wbrana at gmail dot com --- Comment #2 from wbrana 2012-08-05 11:22:24 UTC --- Your PC is broken. C only build with 3 stages takes about 18 minutes with -j2 on my PC. Compilation of small count of big files is faster than big count of small files.
[Bug c/54179] please split insn-emit.c !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #5 from wbrana 2012-08-05 12:00:50 UTC --- (In reply to comment #3) > And what type of super-computer is that ? outdated, almost 5 years old: Core 2 Quad 3.2 GHz, 4 GB RAM
[Bug c/54179] please split insn-emit.c !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #8 from wbrana 2012-08-05 12:27:52 UTC --- 2 GB RAM isn't enough. It isn't good idea to use x86_64 with 2 GB RAM.
[Bug c/54179] please split insn-emit.c !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #12 from wbrana 2012-08-05 13:31:28 UTC --- embedded systems compiler doesn't mean you can run gcc on embedded system, but you can cross compile for embedded system. Average user doesn't build or use compiler. It is only done by developers which have modern PC which means 8 GB RAM.
[Bug c/54179] please split insn-emit.c !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #18 from wbrana 2012-08-05 14:11:37 UTC --- (In reply to comment #17) > Sorry, but this is just rubbish. You didn't confute my statements.
[Bug other/54182] New: enable -fvisibility=hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 Bug #: 54182 Summary: enable -fvisibility=hidden Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com -fvisibility=hidden could be enabled by default if -fPIC isn't used
[Bug lto/54187] New: liblto_plugin.so broken with -fvisibility=hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54187 Bug #: 54187 Summary: liblto_plugin.so broken with -fvisibility=hidden Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com liblto_plugin.so is broken if BOOT_CFLAGS includes -fvisibility=hidden build system should add -fvisibility=normal for building liblto_plugin.so to fix it
[Bug other/54182] enable -fvisibility=hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #2 from wbrana 2012-08-06 08:52:14 UTC --- I don't mean only flags used for building gcc, but -fvisibility=hidden should be enabled if -O1/2/3/s is used and if -fPIC isn't used. How plugins have to disabled? It shouldn't be needed.
[Bug lto/54187] liblto_plugin.so broken with -fvisibility=hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54187 --- Comment #2 from wbrana 2012-08-06 08:57:43 UTC --- Executables are smaller and loads faster with -fvisibility=hidden. Since which version -fvisibility=hidden is enabled by default? 4.7.2 pre doesn't use -fvisibility=hidden by default.
[Bug lto/54187] liblto_plugin.so broken with -fvisibility=hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54187 wbrana changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | --- Comment #3 from wbrana 2012-08-06 09:29:09 UTC --- I was wrong 4.7.2 pre is using -fvisibility=hidden by default, but cc1 isn't built with -fvisibility=hidden. Why it isn't possible to have cc1 built with -fvisibility=hidden and liblto_plugin.so built without -fvisibility=hidden?
[Bug other/54182] enable -fvisibility=hidden with -fPIE -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|enable -fvisibility=hidden |enable -fvisibility=hidden ||with -fPIE -pie --- Comment #4 from wbrana 2012-08-06 16:47:23 UTC --- -fPIE -pie shouldn't disable -fvisibility=hidden
[Bug other/54182] -fPIE -pie shouldn't disable -fvisibility=hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Keywords|build | Summary|enable -fvisibility=hidden |-fPIE -pie shouldn't |with -fPIE -pie |disable -fvisibility=hidden --- Comment #5 from wbrana 2012-08-07 12:34:36 UTC --- updated
