[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171 --- Comment #17 from ncahill_alt at yahoo dot com --- This was the only test that failed for me, the others were debug info in LTO mode. I'm very glad that GCC 6.1.0 works so well and built cleanly like it did. This test was a minor thing because I don't use -O3 at all. I just thought, since it was the only test to fail, it seemed worthwhile mentioning it so that the testsuite would be very clean indeed. Thanks, hopefully I've given enough info for the fix to be obvious. Neil Cahill
[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
--- Comment #16 from ncahill_alt at yahoo dot com ---
(In reply to Richard Biener from comment #15)
> (In reply to ncahill_alt from comment #14)
> > This test is failing for me in GCC 6.1.0 (i386). It complains about having
> > no vectype.
> >
> > Why that is, I don't know. But it doesn't seem to be a problem otherwise,
> > it seems pretty safe to ignore except that it could vectorize the loop but
> > doesn't.
> >
> > I wonder if it would be easier just to have this be UNSUPPORTED on i386.
>
> It should be by means of the { dg-require-effective-target vect_double }
> directive. Does it work if you remove the { dg-options ... } one?
It does, the test still runs but the result is a pass. If I place the
dg-options line below the require-target line, it fails.
[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171 ncahill_alt at yahoo dot com changed: What|Removed |Added CC||ncahill_alt at yahoo dot com --- Comment #14 from ncahill_alt at yahoo dot com --- This test is failing for me in GCC 6.1.0 (i386). It complains about having no vectype. Why that is, I don't know. But it doesn't seem to be a problem otherwise, it seems pretty safe to ignore except that it could vectorize the loop but doesn't. I wonder if it would be easier just to have this be UNSUPPORTED on i386.
[Bug ipa/68035] [5/6 Regression] ipa performance issue when no procedures are present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68035 --- Comment #3 from ncahill_alt at yahoo dot com --- Martin, your patch produces the identical object file in 10.3s versus 24.6s. The profile is also very smooth with none of the functions listed above appearing. Thank you very much, this is now not a problem for users of flite 2.0 (a very good speech engine).
[Bug ipa/68035] New: ipa performance issue when no procedures are present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68035
Bug ID: 68035
Summary: ipa performance issue when no procedures are present
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: ncahill_alt at yahoo dot com
Target Milestone: ---
Created attachment 36552
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36552=edit
source code showing the ipa performance
I have source code showing a possible issue with the IPA code.
Here is a summary of the source code:
static const unsigned short cmu_us_slt_single_param_frame_n[] = {
49599, 18026, 47807, 8034, 31572, 26974, 49436, 23817, 50405, 9699, 41910,
10941, 26670, 21736, 32950, 17162, 35655, 38672, 26306, 14334, 28846, 22876,
22807, 18244, 33990, 21391, 34908, 20997, 31472, 23683, 30802, 22362, 49567,
19033, 34344, 20446, 34123, 25460, 18742, 28898, 36004, 30362, 8420, 14034,
27906, 25618, 22903, 21679, 28720, 27544, 23251, 10290, 22366, 3628, 9385,
13003, 50521, 14289, 23453, 15166, 40948, 19686, 46409, 27702, 47343, 20878,
42959, 30179, 35689, 18748, 33039, 33196, 45794, 22963, 40203, 25433, 35522,
43226, 39469, 31271, 31140, 31707, 40340, 32122, 40396, 28629, 35648, 32788,
15916, 30503, 37380, 28145, 33163, 42595, 38038, 32304, 25717, 37299, 46007,
42212, 38235, 34110, 64844, 1078, 34616, 43377, 18897, 34936, 13503, 23790,
20927, 37384, 60936, 33438, };
const unsigned short * const cmu_us_slt_single_model_vectors[] = {
cmu_us_slt_single_param_frame_0,
cmu_us_slt_single_param_frame_1,
cmu_us_slt_single_param_frame_2,
...
cmu_us_slt_single_param_frame_8872,
};
--
Here is the profile showing the IPA functions:
1371216.4822 cc1
ipa_icf::sem_variable::equals(tree_node*, tree_node*)
8578 10.3110 cc1
ipa_icf::sem_item_optimizer::do_congruence_step_for_index(ipa_icf::congruence_class*,
unsigned int)
6427 7.7254 cc1
ipa_icf::sem_variable::equals(ipa_icf::sem_item*, hash_map<symtab_node*,
ipa_icf::sem_item*, default_hashmap_traits>&)
1891 2.2730 cc1
ipa_icf_gimple::func_checker::compatible_types_p(tree_node*, tree_node*)
803 0.9652 cc1
ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
This may be normal, I don't know, but ~40% for IPA when there are no procedures
seems very wrong. I did build GCC with -fno-inline so that could be a factor.
The code is too large to attach even as an xz. I will attach a shortened
version. I get these results on the shorter code:
1476 11.9689 cc1
ipa_icf::sem_variable::equals(tree_node*, tree_node*)
364 2.9517 cc1
ipa_icf::sem_item_optimizer::do_congruence_step_for_index(ipa_icf::congruence_class*,
unsigned int)
306 2.4813 cc1
ipa_icf::sem_variable::equals(ipa_icf::sem_item*, hash_map<symtab_node*,
ipa_icf::sem_item*, default_hashmap_traits>&)
140 1.1353 cc1
ipa_icf_gimple::func_checker::compatible_types_p(tree_node*, tree_node*)
980.7947 cc1
ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
To build the code:
gunzip bug.c.gz && gcc -m32 -O2 -c bug.c -o bug.o
This is with GCC 5.2.0, 32-bit x86.
Thank you.
Neil.
[Bug tree-optimization/65688] New: xbomb 2.2a segfault, infinite loop at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65688
Bug ID: 65688
Summary: xbomb 2.2a segfault, infinite loop at -O2
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ncahill_alt at yahoo dot com
Created attachment 35247
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35247action=edit
Reduced source with the behaviour
Bug 36124 is similar to this issue, a loop that becomes infinite at -O2.
I think I've found the cause:
### from bug.c ###
struct temp {
Pixel colours[17];
} resources;
for(i=0; i18; i++) {
values.foreground=resources.colours[i];
if (i==15) {
XtVaGetValues(play_area,((char*)XtStrings[52]),
values.background,((void *)0));
}
}
### end ###
### from bug.c.129t.vrp2 ###
Value ranges after VRP:
i_9: [1, 17]
Folding predicate i_9 != 18 to 1
Removing basic block 7
### end ###
bug.c:18:38: warning: iteration 17u invokes undefined behavior
[-Waggressive-loop-optimizations]
values.foreground=resources.colours[i];
I think this warning is not strong enough given that all one gets is a faceless
segfault. It breaks at runtime, should it not be a fatal error? Or if not,
should it not have stronger wording? It seems to suggest one should switch off
the warning.
warning: iteration 17u invokes undefined behaviour, expect it to fail, you
have been warned.
I say this because it isn't clear why the segfault happens at all. The loop
loops 104 times and segfaults in an unrelated subroutine; the obvious thing to
think is that i is getting clobbered.
This is at O1 which works:
movl$1, %ebx
jmp .L2
.L4:
addl$1, %ebx
.L2:
movlresources-4(,%ebx,4), %eax
movl%eax, 8(%esp)
cmpl$16, %ebx
jne .L3
pushl $0
leal16(%esp), %eax
pushl %eax
pushl $XtStrings+52
pushl play_area
callXtVaGetValues
addl$16, %esp
jmp .L4
.L3:
cmpl$17, %ebx
jle .L4
And this is at O2:
movl$1, %ebx
subl$24, %esp
jmp .L2
.L3:
addl$1, %ebx
.L2:
movlresources-4(,%ebx,4), %eax
cmpl$16, %ebx
movl%eax, 8(%esp)
jne .L3
pushl $0
leal16(%esp), %eax
pushl %eax
pushl $XtStrings+52
pushl play_area
callXtVaGetValues
addl$16, %esp
jmp .L3
To reproduce:
gcc -m32 -O2 -S -c bug.c -o bug.S cat bug.S \
grep -v '^[[:space:]]\+\.'
The version: (GCC) 4.9.2, Linux x86.
Thank you.
Neil Cahill.
[Bug lto/61218] New: lto ICE building libcilkrts with 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61218
Bug ID: 61218
Summary: lto ICE building libcilkrts with 4.9.0
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: ncahill_alt at yahoo dot com
Created attachment 32816
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32816action=edit
minimal testcase
I was getting an ICE building gcc-4.9.0 with lto enabled (that is, -flto
-ffat-lto-objects), I traced it to symbol_test.o. I then reduced the
preprocessed output of symbol_test.c, this is what it reduces to:
--- bug.c ---
int main ()
{
_Cilk_spawn foo();
}
--- end bug.c ---
To cause the bug, run make or issue these commands:
gcc -fcilkplus -flto -c bug.c -o bug.o
gcc bug.o
--- output ---
lto1: internal compiler error: in streamer_get_builtin_tree, at
tree-streamer-in.c:1124
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.gentoo.org/ for instructions.
lto-wrapper: /usr/i686-pc-linux-gnu/gcc-bin/4.9.0/gcc returned 1 exit status
/usr/lib/gcc/i686-pc-linux-gnu/4.9.0/../../../../i686-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
--- end output ---
The output of gcc -v is included in gccdashv.txt, and this is on i686 32-bit.
Thank you.
[Bug other/61102] New: ld --plugin causes binutils gold incremental_test to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61102 Bug ID: 61102 Summary: ld --plugin causes binutils gold incremental_test to fail Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ncahill_alt at yahoo dot com This is a heads-up more than anything. I've been trying out gcc 4.9.0 and one of binutils-2.24/gold's testcases fails because --plugin is being emitted to ld. My only guess is that the new slim LTO object files are handled transparently in the sense that one can link with them without supplying the -flto option, and perhaps this requires always emitting --plugin. I haven't tried building gcc's version of gold but I find it more convenient to build it with binutils. So there is some incompatibility between the two packages it seems. This is the command: i686-pc-linux-gnu-gcc -O2 -o incremental_test -Wl,--incremental-full incremental_test_1.o incremental_test_2.o This is gcc 4.9.0 on 32-bit i686. I've filed a bug report on binutils' bugzilla as well, the PR id is 16921. Thank you.
[Bug target/57564] regmove switched operands?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57564 ncahill_alt at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from ncahill_alt at yahoo dot com --- This appears fixed in 4.9.0, I can't reproduce it. Where in 4.8 one had: movl8(%ebx), %eax leal-3(%esi), %ecx movl%eax, 40(%esp) shrl%cl, 40(%esp) andl$7, 40(%esp) movl40(%esp), %eax testl %eax, %eax movl%eax, 44(%esp) Now one has: movl8(%ebx), %edi leal-3(%edx), %ecx shrl%cl, %edi andl$7, %edi testl %edi, %edi movl%edi, %ecx movl%edi, 44(%esp) movl%edi, 40(%esp) So I'm pleased to report that this is now fixed in the release version of gcc 4.9.0. As the original reporter I'll mark this RESOLVED FIXED but if it crops up again I'll reopen it. Thank you very much.
[Bug tree-optimization/57534] [4.8/4.9 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #6 from ncahill_alt at yahoo dot com --- Created attachment 30283 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30283action=edit Smaller testcase
[Bug bootstrap/57291] Failure in build stages 2 and 3 concerning pseudo-op: .balign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57291 ncahill_alt at yahoo dot com changed: What|Removed |Added CC||ncahill_alt at yahoo dot com --- Comment #1 from ncahill_alt at yahoo dot com --- I see from the binutils changelog that .balign was added to the GNU assembler in April 1995, so 18 years ago. Your assembler must be from around that time. I suggest updating binutils to 2.23 or newer if possible. This is a good idea in general and may fix other, yet to be discovered problems. Neil Cahill.
[Bug rtl-optimization/57564] New: regmove switched operands?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57564 Bug ID: 57564 Summary: regmove switched operands? Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ncahill_alt at yahoo dot com Created attachment 30278 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30278action=edit Testcase With x86 GCC 4.8.1 (32-bit), bzip2 built with -O1 decompresses files more quickly than with -O2. I found that -O2 -fno-regmove restores the performance. Looking at the output, I saw the following. I have attached a reduced testcase to generate a similar pattern: movl%eax, 40(%esp) shrl%cl, 40(%esp) andl$7, 40(%esp) movl40(%esp), %eax The command: gcc -S -O2 -pipe -c reduceme.c -o decompress.s Thanks. Neil Cahill.
[Bug target/57564] regmove switched operands?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57564 --- Comment #1 from ncahill_alt at yahoo dot com --- Also present in 4.8.0, not in 4.7.3.
[Bug rtl-optimization/57534] New: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 Bug ID: 57534 Summary: Performance regression versus 4.7.3, 4.8.1 is ~15% slower Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ncahill_alt at yahoo dot com Created attachment 30261 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30261action=edit Reduced source code - timing functions With x86 GCC 4.8.1, slower code is produced (than with 4.7.3) for a particular benchmark I ran, about 15% slower. Whatever is wrong must be happening here: 80486e5: d9 ee fldz 80486e7: d9 c0 fld%st(0) 80486e9: 8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi 80486f0: 8d 04 f5 00 00 00 00lea0x0(,%esi,8),%eax 80486f7: dd 04 f3fldl (%ebx,%esi,8) 80486fa: dc 44 03 08 faddl 0x8(%ebx,%eax,1) 80486fe: dc 44 03 10 faddl 0x10(%ebx,%eax,1) 8048702: dc 44 03 18 faddl 0x18(%ebx,%eax,1) 8048706: de c2 faddp %st,%st(2) 8048708: dd 44 03 20 fldl 0x20(%ebx,%eax,1) 804870c: dc 44 03 28 faddl 0x28(%ebx,%eax,1) 8048710: dc 44 03 30 faddl 0x30(%ebx,%eax,1) 8048714: dc 44 03 38 faddl 0x38(%ebx,%eax,1) 8048718: 8d 46 08lea0x8(%esi),%eax 804871b: 39 c7 cmp%eax,%edi 804871d: de c1 faddp %st,%st(1) 804871f: 7f 0e jg 804872f 8048721: a1 34 91 04 08 mov0x8049134,%eax 8048726: 85 c0 test %eax,%eax 8048728: 74 0e je 8048738 804872a: 83 c5 01add$0x1,%ebp 804872d: 31 c0 xor%eax,%eax 804872f: 89 c6 mov%eax,%esi 8048731: eb bd jmp80486f0 8048733: 90 nop 8048734: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi 8048738: dd 5c 24 10 fstpl 0x10(%esp) 804873c: 83 c6 10add$0x10,%esi 804873f: dd 5c 24 08 fstpl 0x8(%esp) This is the commandline: gcc -O2 reduceme.c timer.o -o cachebench This is from a benchmark (llcbench, GPL software) and uses timers which may be a problem, if I preprocess them, they may not work. I'll attach the main code (reduced) for now, and I'll work on getting the timing code included very soon. I'll also test with 4.8.0 to see whether that version is also affected. Attached is the reduced code minus the timing functions. Uncommenting the commented line in the source code removes the bug. Thanks. Neil.
[Bug rtl-optimization/57534] Performance regression versus 4.7.3, 4.8.1 is ~15% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #1 from ncahill_alt at yahoo dot com --- Here is the 4.7.3 output for comparison: 8048702: 83 ef 08sub$0x8,%edi 8048705: d9 ee fldz 8048707: d9 c0 fld%st(0) 8048709: 8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi 8048710: dd 04 defldl (%esi,%ebx,8) 8048713: 8d 43 08lea0x8(%ebx),%eax 8048716: dc 44 de 08 faddl 0x8(%esi,%ebx,8) 804871a: 39 c7 cmp%eax,%edi 804871c: dc 44 de 10 faddl 0x10(%esi,%ebx,8) 8048720: dc 44 de 18 faddl 0x18(%esi,%ebx,8) 8048724: de c2 faddp %st,%st(2) 8048726: dd 44 de 20 fldl 0x20(%esi,%ebx,8) 804872a: dc 44 de 28 faddl 0x28(%esi,%ebx,8) 804872e: dc 44 de 30 faddl 0x30(%esi,%ebx,8) 8048732: dc 44 de 38 faddl 0x38(%esi,%ebx,8) 8048736: de c1 faddp %st,%st(1) 8048738: 7f 0e jg 8048748 804873a: a1 34 91 04 08 mov0x8049134,%eax 804873f: 85 c0 test %eax,%eax 8048741: 74 0d je 8048750 8048743: 83 c5 01add$0x1,%ebp 8048746: 31 c0 xor%eax,%eax 8048748: 89 c3 mov%eax,%ebx 804874a: eb c4 jmp8048710 804874c: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi 8048750: dd 5c 24 10 fstpl 0x10(%esp) 8048754: 83 c3 10add$0x10,%ebx 8048757: dd 5c 24 20 fstpl 0x20(%esp)
[Bug tree-optimization/57534] [4.8. 4.9 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 ncahill_alt at yahoo dot com changed: What|Removed |Added Attachment #30261|0 |1 is obsolete|| --- Comment #4 from ncahill_alt at yahoo dot com --- Created attachment 30263 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30263action=edit Contained source file demonstrating bug I have tested GCC 4.8.0 (32 bit of course) and the same slowdown is present. The slowdown is greater with -mtune=pentium2 for some reason, but the slowdown with no -mtune specified. I have attached a single file with all the preprocessed source, including the timing functions. Reducing it is difficult because it keeps hitting infinite loops. The command: gcc -O2 wholesource.c -o cachebench With -O1, the bug is not present. Uncommenting the commented line so as to try to remove the timing dependency stops the bug from occurring. The numbers output by the executable are performance numbers, what used to be MB/sec of read performance. Thank you very much. Neil Cahill.
[Bug tree-optimization/57534] [4.8. 4.9 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #5 from ncahill_alt at yahoo dot com --- Jakub Jelinek: Started with SLSR addition, guess you can get the performance back with -fno-tree-slsr. Thanks so much, I'll do that. Neil Cahill.
[Bug other/54671] [4.7/4.8 Regression] gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 --- Comment #3 from ncahill_alt at yahoo dot com 2012-09-24 20:14:04 UTC --- From what I understand, gold's failing test assumes that gcc will make available in general the old functionality, functionality that certain BSD derived systems lacking the .init_array ELF section require(d), but which glibc has not used in 10 years. What can I say, the test is wrong. I will report this to binutils, that the initpri3b test should disclaim or run only when the system-default is a separate .ctors section. Thank you, Jakub, for the quick response and clarification. Neil.
[Bug other/54671] New: gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 Bug #: 54671 Summary: gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncahill_...@yahoo.com Created attachment 28249 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28249 broken output file and generating makefile binutils-2.22/gold has an extra test failure when built with gcc 4.7.2. This is the offending command: gcc -Bgcctestdir/ -Wl,--no-ctors-in-init-array -Wl,-O1,--as-needed -o broken_by_gcc_472 a.o With 4.7.1, the test passes. I have put this in the 'other' category as no compilation seems to be taking place. In the attachment, you'll find output files generated with 4.7.2 and 4.7.1 to compare, hopefully the second is obviously broken. Also there is a Makefile to run the offending command, and preprocessed source for the object file being used. Thank you, hope this is enough to find/fix the error. Neil Cahill.
[Bug other/54671] gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 --- Comment #1 from ncahill_alt at yahoo dot com 2012-09-22 19:00:06 UTC --- gcc -v: Using built-in specs. COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7.2/configure --disable-bootstrap --disable-libada --disable-ld --disable-gold --enable-lto --enable-libssp --enable-cloog-backend=isl --without-cloog --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libgomp --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.2/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran,lto --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ Thread model: posix gcc version 4.7.2 (GCC) Neil.
[Bug c++/53958] New: set_slot_part and canon_value_cmp using 90% of compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53958 Bug #: 53958 Summary: set_slot_part and canon_value_cmp using 90% of compile time Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncahill_...@yahoo.com Created attachment 27786 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27786 Source code showing problem. I've got a situation here where the compile basically stalls, and a profiling sample from a late enough stage shows 92% of time going to set_slot_part and canon_value_cmp (from var-tracking.c). So I guess the assumptions about the size of some data structure are being invalidated. I am unable to give a small testcase, but I've attached the preprocessed code that causes this condition. The flag that seems to give the trouble is -fno-omit-frame-pointer. Without this flag, it completes in reasonable time. This is with gcc 4.7.1, i686-pc-linux-gnu, 32 bit. Commands: cc1plus -v b.c -dumpbase b.c -march=athlon -mtune=pentium2 -auxbase-strip b.o -g2 -O2 -std=gnu++98 -fno-inline -funroll-loops -funswitch-loops -fno-strict-aliasing -fno-omit-frame-pointer gcc -pipe -g2 -fno-omit-frame-pointer -O2 -Werror -fno-strict-aliasing -march=athlon -mtune=pentium2 e -funroll-loops -funswitch-loops -Wall -Wcast-align -Wundef -Wformat-security -Wwrite-strings -Wno-se -Wno-conversion -Wno-narrowing -pthread -pthread -x c++ -std=gnu++98 -Woverloaded-virtual -c b.c -o b.o Thank you. Neil.
[Bug rtl-optimization/53942] New: unable to find a register to spill in class 'CREG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53942
Bug #: 53942
Summary: unable to find a register to spill in class 'CREG'
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com
This command:
gcc -O2 -mtune=pentium2 -fno-inline -x c++ -std=gnu++98 -c a.c -o a.o
gives this output:
### output ###
a.c: In function 'unsigned char _ZL1fP2S_h.isra.0(UINT16, UINT16, UINT16,
unsigned char)':
a.c:25:1: error: unable to find a register to spill in class 'CREG'
a.c:25:1: error: this is the insn:
(insn 11 7 12 2 (parallel [
(set (reg:SI 1 dx [85])
(ashiftrt:SI (reg:SI 1 dx [85])
(reg/v:QI 81 [ i ])))
(clobber (reg:CC 17 flags))
]) a.c:20 409 {*ashrsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
a.c:25: confused by earlier errors, bailing out
### end output ###
when compiling this testcase:
### a.c ###
typedef unsigned short UINT16;
typedef unsigned int UINT32;
typedef struct S_ S;
struct S_ {
UINT16 data[3];
UINT32 x;
UINT32 y;
};
static inline S *get_S() {}
static unsigned char f(S *s, unsigned char i)
{
unsigned char c=0;
unsigned char v;
v = s-data[0];
c|=v;
v=((s-data[1])(1i))?1:0;
c|=v1;
v=((s-data[2])0xff)(1i);
c|=v2;
return c;
}
void g()
{
S *s = get_S();
s-x=f(s,6);
s-y=f(s,7);
}
### end a.c ###
Using -mtune=i686 works. I'm using gcc 4.7.1, i686-pc-linux-gnu, 32-bit.
Thank you.
Neil.
[Bug rtl-optimization/53482] New: -mtune=pentium[pro, 2, 3, 4], insn does not satisfy constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53482
Bug #: 53482
Summary: -mtune=pentium[pro, 2, 3, 4], insn does not satisfy
constraints
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com
This error cropped up today with gcc 4.7.0, but it only occurs with this
combination of flags:
gcc -O2 -fPIC -mtune=pentium[pro,2,3,4] -c source.c -o source.o
There seems to be no error with -O1, without -fPIC, or with other mtune
settings.
Here is the test case. What is interesting is, replacing i = 0 with i = 1
is enough to stop the error occurring.
### source.c ###
unsigned char uc;
void fa()
{
unsigned char i, a;
a = fb();
fc();
uc += a;
for (i = 0; i uc;)
{
fd();
}
}
### error message ###
source.c: In function 'fa':
source.c:14:1: error: insn does not satisfy its constraints:
(insn 58 9 14 2 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (plus:QI (mem/c:QI (reg/f:SI 4 si [68]) [0 uc+0 S1
A8])
(reg:QI 5 di [orig:59 D.1370 ] [59]))
(const_int 0 [0])))
(set (mem/c:QI (reg/f:SI 4 si [68]) [0 uc+0 S1 A8])
(plus:QI (mem/c:QI (reg/f:SI 4 si [68]) [0 uc+0 S1 A8])
(reg:QI 5 di [orig:59 D.1370 ] [59])))
]) source.c:10 199 {*addqi_2}
(nil))
source.c:14:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:767
### gcc -v ###
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7.0/configure --disable-bootstrap --disable-libada
--disable-ld --disable-gold --enable-lto --enable-libssp
--enable-cloog-backend=isl --without-cloog --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --enable-nls --without-included-gettext
--with-system-zlib --disable-werror --enable-secureplt --disable-multilib
--enable-libmudflap --disable-libgomp
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.0/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran,lto
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
Thread model: posix
gcc version 4.7.0 (GCC)
The workaround is to use -mtune=i686 instead.
Thank you.
Neil.
[Bug regression/53442] llvm 2.9 tblgen executable possibly miscompiled with gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53442 --- Comment #5 from ncahill_alt at yahoo dot com 2012-05-22 18:22:09 UTC --- By comparing the linker commands, I've found that replacing crtbegin.o and crtend.o is sufficient to fix the problem. I've built parts of gcc with -flto and I suspect there was a mismatch between those crt.o files and libgcc_s.so possibly, I must be more careful. With a newly built gcc 4.7.0, I'll just see if this builds correctly.
[Bug regression/53442] llvm 2.9 tblgen executable possibly miscompiled with gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53442 ncahill_alt at yahoo dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #6 from ncahill_alt at yahoo dot com 2012-05-22 19:07:50 UTC --- Sorry, false alarm. This now works fine. A simple typing error was the ultimate cause. Please ignore, thank you. Neil.
[Bug regression/53442] New: llvm 2.9 tblgen executable possibly miscompiled with gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53442 Bug #: 53442 Summary: llvm 2.9 tblgen executable possibly miscompiled with gcc 4.7.0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncahill_...@yahoo.com This is a most complex problem, but an executable fails with gcc 4.7.0, giving a segmentation fault. But when linked with gcc 4.5.3, it works. I say linked because the same object files are involved, only the version of gcc for linking changes. It does appear the problem is with the executable itself, but it is so complex that I am unable to generate a test case. My suggestion to anyone trying to reproduce this is to get a source release of llvm-2.9 for 32-bit x86, and if it builds successfully, problem solved. I give the configure command for the package below. This is not a bug yet, but a reported, possible bug occurrence, and it may be that it happens elsewhere. In case this turns out to be something, I wanted it to be noted for now. It occurs with the Release/bin/tblgen executable, which is generated in the build process, and the error occurs after this line of output: Building Intrinsics.gen.tmp from Intrinsics.td. Thank you. Neil. The package was configured the package as follows: configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-shared --with-optimize-option= --enable-optimized --disable-assertions --disable-expensive-checks --enable-targets=host-only --with-llvmgccdir=/dev/null --with-llvmgcc=nope --with-llvmgxx=nope --enable-bindings=none --enable-libffi gcc -v... Using built-in specs. COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7.0/configure --disable-bootstrap --disable-libada --disable-ld --disable-gold --enable-lto --enable-libssp --enable-cloog-backend=isl --without-cloog --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libgomp --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran,lto --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ Thread model: posix gcc version 4.7.0 (GCC)
[Bug regression/53442] llvm 2.9 tblgen executable possibly miscompiled with gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53442 --- Comment #1 from ncahill_alt at yahoo dot com 2012-05-21 19:52:57 UTC --- In case it is of interest, here is the generating command for the tblgen executable. I don't know how to turn this into a test case as it seems to use only pregenerated code. i686-pc-linux-gnu-g++ -I/var/altsrc/buildllvm/include -I/var/altsrc/buildllvm/utils/TableGen -I/var/altsrc/llvm-2.9/include -I/var/altsrc/llvm-2.9/utils/TableGen -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fPIC -Woverloaded-virtual -Wcast-qual -Wl,-R -Wl,'$ORIGIN/../lib' -Wl,-R -Wl,/usr/lib/llvm -L/var/altsrc/buildllvm/Release/lib -L/var/altsrc/buildllvm/Release/lib -Wl,--version-script=/var/altsrc/llvm-2.9/autoconf/ExportMap.map -Wl,-O1,--as-needed -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -o /var/altsrc/buildllvm/Release/bin/tblgen /var/altsrc/buildllvm/utils/TableGen/Release/ARMDecoderEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/AsmMatcherEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/AsmWriterEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/AsmWriterInst.o /var/altsrc/buildllvm/utils/TableGen/Release/CallingConvEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/ClangASTNodesEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/ClangAttrEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/ClangDiagnosticsEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/ClangSACheckersEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/CodeEmitterGen.o /var/altsrc/buildllvm/utils/TableGen/Release/CodeGenDAGPatterns.o /var/altsrc/buildllvm/utils/TableGen/Release/CodeGenInstruction.o /var/altsrc/buildllvm/utils/TableGen/Release/CodeGenTarget.o /var/altsrc/buildllvm/utils/TableGen/Release/DAGISelEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/DAGISelMatcher.o /var/altsrc/buildllvm/utils/TableGen/Release/DAGISelMatcherEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/DAGISelMatcherGen.o /var/altsrc/buildllvm/utils/TableGen/Release/DAGISelMatcherOpt.o /var/altsrc/buildllvm/utils/TableGen/Release/DisassemblerEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/EDEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/FastISelEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/FixedLenDecoderEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/InstrEnumEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/InstrInfoEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/IntrinsicEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/LLVMCConfigurationEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/NeonEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/OptParserEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/Record.o /var/altsrc/buildllvm/utils/TableGen/Release/RegisterInfoEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/StringMatcher.o /var/altsrc/buildllvm/utils/TableGen/Release/SubtargetEmitter.o /var/altsrc/buildllvm/utils/TableGen/Release/TGLexer.o /var/altsrc/buildllvm/utils/TableGen/Release/TGParser.o /var/altsrc/buildllvm/utils/TableGen/Release/TGValueTypes.o /var/altsrc/buildllvm/utils/TableGen/Release/TableGen.o /var/altsrc/buildllvm/utils/TableGen/Release/TableGenBackend.o /var/altsrc/buildllvm/utils/TableGen/Release/X86DisassemblerTables.o /var/altsrc/buildllvm/utils/TableGen/Release/X86RecognizableInstr.o -lLLVMSupport -lpthread -lffi -ldl -lm
[Bug c/53262] New: ICE compiling busybox 1.19.3 with gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53262
Bug #: 53262
Summary: ICE compiling busybox 1.19.3 with gcc 4.7.0
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com
This code produces an internal compiler error with gcc 4.7.0. Build it with
this command: gcc -O2 -o a a.c.
This is gcc built from the original 4.7.0 source, x86 32-bit.
a.c **
typedef unsigned int size_t;
enum {
_ISalnum = 1
};
extern __const unsigned short int **__ctype_b_loc (void) __attribute__
((__nothrow__)) __attribute__ ((__const));
void parse_config_file(char *map, size_t len) {
char *end_3 = map + len - 3;
char *end_7 = map + len - 7;
char *p = map;
char *q;
int off;
for (; p = end_3; p++) {
if (!(((*__ctype_b_loc ())[(int) ((*p))] (unsigned short int) _ISalnum)
|| *p == '_'))continue;
if (p end_7 p[6] == '_') {
if (!memcmp(p, CONFIG, 6)) goto conf7;
}
continue;
conf7: off = 7;
for (q = p; q end_3+3; q++) {}
if (q != p) {
use_config(p, q-p);
}
}
}
* end a.c
a.c: In function 'parse_config_file':
a.c:28:10: internal compiler error: Segmentation fault
Thank you.
Neil Cahill.
[Bug middle-end/53262] ICE compiling busybox 1.19.3 with gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53262 --- Comment #2 from ncahill_alt at yahoo dot com 2012-05-07 17:54:44 UTC --- Unfortunately, this is no longer happening for me. I have made system changes today but no changes to gcc at all. But now the test passes just fine. So there is no longer any problem. If it happens again, I'll be sure to report that. But yeah, it works. It can only really be because of a difference in the layout of the /dev folder. But there is now no problem. Please mark this as presumed working. Thanks. Neil Cahill.
[Bug c++/52929] use of undeclared identifier '__ATOMIC_ACQ_REL'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52929 ncahill_alt at yahoo dot com changed: What|Removed |Added CC||ncahill_alt at yahoo dot ||com --- Comment #1 from ncahill_alt at yahoo dot com 2012-04-10 18:54:51 UTC --- Regarding this, I've found that __ATOMIC_ACQ_REL is new in 4.7.0, it is not used in any 4.6.x. And also my source-built 4.7.0 is lacking a #define for this macro. Neil.
[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 --- Comment #4 from ncahill_alt at yahoo dot com 2012-03-24 10:18:15 UTC --- (In reply to comment #3) --enable-bootstrap \ Can you try without that? I get the same error and the same workaround allows the build to complete.
[Bug libitm/52695] New: libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 Bug #: 52695 Summary: libitm/config/x86/cacheline.h: '__m64' does not name a type Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncahill_...@yahoo.com While building gcc 4.7.0, libitm fails with this error: In file included from ../../../gcc-4.7.0/libitm/libitm_i.h:85:0, from ../../../gcc-4.7.0/libitm/aatree.cc:28: ../../../gcc-4.7.0/libitm/config/x86/cacheline.h:55:3: error: '__m64' does not name a type A possible fix is to add #include x86intrin.h to cacheline.h, which seems to be the desired intent. This was built with gcc 4.6.2, from the gcc-4.7.0.tar.bz2 as released on ftp.gnu.org. The error occured right at the end, after the bootstrap process was successful. Thank you. Neil.
[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 --- Comment #2 from ncahill_alt at yahoo dot com 2012-03-23 22:23:19 UTC --- Sorry, i686-pc-linux-gnu, I think that is the target. This is the configure command: ../gcc-4.7.0/configure \ --enable-bootstrap \ --disable-libada \ --disable-ld \ --disable-gold \ --enable-lto \ --enable-libssp \ \ --prefix=/usr \ --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0 \ --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include \ --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0 \ --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/man \ --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/info \ --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include/g++-v4 \ --host=i686-pc-linux-gnu \ --build=i686-pc-linux-gnu \ --disable-altivec \ --disable-fixed-point \ --without-ppl \ --without-cloog \ --enable-nls \ --without-included-gettext \ --with-system-zlib \ --disable-werror \ --enable-secureplt \ --disable-multilib \ --enable-libmudflap \ --disable-libgomp \ --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.0/python \ --enable-checking=release \ --disable-libgcj \ --enable-languages=c,c++,fortran,lto \ --enable-shared \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-clocale=gnu \ --with-bugurl=http://bugs.gentoo.org/ Thank you.
[Bug c/52640] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #8 from ncahill_alt at yahoo dot com 2012-03-21 17:47:21 UTC --- Created attachment 26945 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26945 gcc -version output with -v added
[Bug c/52640] New: performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640
Bug #: 52640
Summary: performance bottleneck: gcc/tree.c;value_member
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com
Created attachment 26935
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26935
source, output, profiling data indicating problem
It was made known to me that the code provided takes a long time to compile.
Looking into it, the culprit seems to be the value_member function of
gcc/tree.c. Here is that code (preprocessed):
tree value_member (tree elem, tree list)
{
while (list)
{
if (elem == ((list)-list.value))
return list;
list = ((list)-common.chain);
}
return (tree) ((void *)0);
}
A sample of profiling data, from OProfile and using gcc 4.6.2:
samples %image name symbol name
1995543.1814 cc1 value_member
1179 2.5513 cc1 record_reference
1122 2.4279 cc1 insert_aux
With a table of 1 rows, it takes ~40% of the execution time, and with
20 rows, ~90%. The former takes 5 seconds, the later is not finished in 20
minutes.
Provided is a sample source file with output from cc1 and profiling data as
above.
Thank you.
Neil.
[Bug lto/51887] New: wrapped function with LTO - multiple prevailing defs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51887 Bug #: 51887 Summary: wrapped function with LTO - multiple prevailing defs Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncahill_...@yahoo.com Created attachment 26358 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26358 lto build error - multiple prevailing defs This command, gcc -flto -Wl,-wrap,WrapMe -o a a.c b.c, fails for the attached testcase with the following error message: lto1: fatal error: multiple prevailing defs for 'WrapMe' compilation terminated. This works if -flto is removed. Neil.
[Bug lto/51859] New: wrapped symbols (wrap linker option) do not link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51859
Bug #: 51859
Summary: wrapped symbols (wrap linker option) do not link
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com
The following command,
gcc -flto -Wl,-wrap,malloc -o a a.c
produces the following error,
`__wrap_malloc' referenced in section `.text' of
/tmp/ccCKjgAw.ltrans0.ltrans.o: defined in discarded section `.text' of
/tmp/ccREUpxM.o (symbol from plugin)
collect2: ld returned 1 exit status
Here is the test case:
--- a.c ---
void * __wrap_malloc(int bytes)
{
__real_malloc(bytes);
}
int main()
{
int *p = (int *)malloc(4);
*p = 2;
free(p);
return 0;
}
--- end a.c ---
This has the result that xorg-server 1.11.2 does not build with lto enabled.
Thank you.
Neil.
