[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #69 from danglin at gcc dot gnu dot org 2008-11-01 20:15 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-07 15:33 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > I looked into assembly you send and see the following difference: > for original malloc there is additional instruction > > stwm %r4,64(%r30) > > before malloc call, while for first artificial malloc (field a, I suppose) > there is similar instruction > > stw %r3,-60(%r30) > > but for the second artificial malloc there isn't. ("Copy" instructions are to > carry results of the malloc). > > As I am not familiar with hp assembler, can you please explain what is the > meaning of this instruction? Probably my suspicion is wrong. The above two instructions are part of the prologue for main. Both instructions are stores. In non leaf functions, the prologue always creates a frame. In the 32-bit runtime, this is always a multiple of 64 bytes. Depending on the details of the prologue, the creation of a new frame may be combined with a register store. The above stwm instruction saves register r4 at the stack pointer address contained in r30 (conventionally the stack pointer register) and then 64 is added to r30. The stw insn saves r3 at the stack pointer address minus 60. r3 and r4 are both caller saves registers, so they have to be saved in the frame when used and restored in the epilogue. Prologue and epilogue handling occurs in every function with a frame, so it is extremely well tested. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #67 from olga at gcc dot gnu dot org 2008-02-07 10:26 --- (In reply to comment #66) > I looked wo_prof_global_var.c. The test passes with the above options. > The floating point convert operations look similar to those with > -fipa-struct-reorg. However, there's just one malloc call and the > values allocated for b are all zero. I see your point. Indeed, struct-reorg generates two additional mallocs, one additional for each structure field, so that original malloc is not used any more. (I hoped compiler optimizes it out, but it does not happen.) Your investigation implies that original malloc was initialized to zero, while mallocs generated by this optimization are not, that cause the failure. I looked into assembly you send and see the following difference: for original malloc there is additional instruction stwm %r4,64(%r30) before malloc call, while for first artificial malloc (field a, I suppose) there is similar instruction stw %r3,-60(%r30) but for the second artificial malloc there isn't. ("Copy" instructions are to carry results of the malloc). As I am not familiar with hp assembler, can you please explain what is the meaning of this instruction? Probably my suspicion is wrong. Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #66 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-05 02:42 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > If so, there is still question why the tests do not fail without struct-reorg. > Or they fail? Can you please check it with -O3 -fipa-type-escape > -fwhole-program -combine. I looked wo_prof_global_var.c. The test passes with the above options. The floating point convert operations look similar to those with -fipa-struct-reorg. However, there's just one malloc call and the values allocated for b are all zero. I should note that these tests have never failed on hppa-unknown-linux-gnu and the generated assembler code should be very similar to that under hpux (i.e., the fails are due to the difference in behavior of malloc). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #65 from olga at gcc dot gnu dot org 2008-02-03 14:48 --- (In reply to comment #64) Oh, it's just what I suspected! Please look at the PR 34534 comment #4. If so, there is still question why the tests do not fail without struct-reorg. Or they fail? Can you please check it with -O3 -fipa-type-escape -fwhole-program -combine. Thank you a lot, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #64 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31 22:18 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > Then, in the second loop, we load p[968].a and convert it to a float > value of 3. We do a floating-point compare of this value with > p[968].b + 1.0 = 3.0049336, and the compare fails. Test passes if the comparison is changed. For example, if (p[i].a != (int) (p[i].b + 1)) Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #62 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31 22:00 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 On Thu, 31 Jan 2008, alond at il dot ibm dot com wrote: > > > --- Comment #61 from alond at il dot ibm dot com 2008-01-31 18:07 --- > > Done. Still have same fails on hppa2.0w-hp-hpux11.11. > > Dave, > can you please perform an initial debugging? I have attached a somewhat annotated assembler output for the wo_prof_global_var.c test. The test aborts in the second loop at i = 968. In the first loop, malloc gives us p[968].b == 0x400050d4 or 2.00493336. We add 1.0, convert it a fixed value of 3, and save it in p[968].a. Then, in the second loop, we load p[968].a and convert it to a float value of 3. We do a floating-point compare of this value with p[968].b + 1.0 = 3.0049336, and the compare fails. > If you can also check the sizeof: HOST_WIDE_INT, int, unsigned HOST_WIDE_INT. These should all be 4 on hppa2.0w-hp-hpux11.11. They should be 8 on hppa64-hp-hpux11.11. Don't think the problem is here. Dave --- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31 22:00 --- Created an attachment (id=15069) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15069&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #61 from alond at il dot ibm dot com 2008-01-31 18:07 --- > Done. Still have same fails on hppa2.0w-hp-hpux11.11. Dave, can you please perform an initial debugging? I think it will make it easier to loacte the bug if we had some debugging information, like where is the failure etc. If you can also check the sizeof: HOST_WIDE_INT, int, unsigned HOST_WIDE_INT. Thank you for the cooperation, Alon -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #60 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-30 19:44 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > > On hppa2.0w-hp-hpux11.11, we are down to: > Dave, > > Can you please try this patch: Done. Still have same fails on hppa2.0w-hp-hpux11.11. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #59 from alond at il dot ibm dot com 2008-01-29 10:01 --- (In reply to comment #58) > On hppa2.0w-hp-hpux11.11, we are down to: Dave, Can you please try this patch: Index: ipa-struct-reorg.c === --- ipa-struct-reorg.c (revision 131933) +++ ipa-struct-reorg.c (working copy) @@ -614,7 +614,7 @@ gen_size (tree num, tree type, tree *res) { tree struct_size = TYPE_SIZE_UNIT (type); - HOST_WIDE_INT struct_size_int = TREE_INT_CST_LOW (struct_size); + HOST_WIDE_INT struct_size_int = int_cst_value (struct_size); tree new_stmt; *res = create_tmp_var (TREE_TYPE (num), NULL); @@ -1787,7 +1787,7 @@ return NULL_TREE; struct_size = TYPE_SIZE_UNIT (str_decl); - struct_size_int = TREE_INT_CST_LOW (struct_size); + struct_size_int = int_cst_value (struct_size); gcc_assert (struct_size); Alon -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #58 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-26 22:23 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > can you please check now? I committed patches from comment #11. On hppa2.0w-hp-hpux11.11, we are down to: FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c execution test FAIL: gcc.dg/struct/w_prof_global_var.c execution,-O3 -fwhole-program -combi ne -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_local_var.c execution,-O3 -fwhole-program -combin e -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all I should say the tests don't fail on hppa-unknown-linux. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #57 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-25 18:54 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > can you please check now? I committed patches from comment #11. Yes. However, I still have the feeling the tests are failing because malloc is allocating some non-zero data. This introduces fixed to float conversion and rounding mode issues. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #56 from olga at il dot ibm dot com 2008-01-25 08:10 --- (In reply to comment #55) > With revision 131802, we are down to the followning fails: can you please check now? I committed patches from comment #11. Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #55 from danglin at gcc dot gnu dot org 2008-01-24 23:39 --- With revision 131802, we are down to the followning fails: FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_two_strs.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 2" FAIL: gcc.dg/struct/w_prof_global_var.c execution,-O3 -fwhole-program -combi ne -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_local_var.c execution,-O3 -fwhole-program -combin e -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_two_strs.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 2" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #54 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-24 16:26 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > On i686-apple-darwin9 the patch from > http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01081.html (now commited in > trunk) solves all the failures in gcc.dg/struct/*, both in 32 and 64 bit > modes. Unfortunately, it didn't resolve the problems on hppa. With no patches, this is the current state on hppa2.0w-hp-hpux11.11. FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_two_strs.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_two_strs.c (test for excess errors) WARNING: gcc.dg/struct/wo_prof_two_strs.c compilation failed to produce executable FAIL: gcc.dg/struct/wo_prof_two_strs.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 2" FAIL: gcc.dg/struct/w_prof_global_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_local_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_two_strs.c compilation, -O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all (internal compiler error) The ICE is here: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c:56: internal co mpiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #53 from dominiq at lps dot ens dot fr 2008-01-24 12:58 --- On i686-apple-darwin9 the patch from http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01081.html (now commited in trunk) solves all the failures in gcc.dg/struct/*, both in 32 and 64 bit modes. I have even an XPASS: XPASS: gcc.dg/struct/wo_prof_malloc_size_var.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 1" I got these results with and WITHOUT the patches in comments #11 and #31 (with == both of them) and the two builds give the same summary: === gcc Summary for unix/-m64 === # of expected passes47421 # of unexpected failures11 # of unexpected successes 1 # of expected failures 163 # of untested testcases 35 # of unsupported tests 477 === gcc Summary === # of expected passes94966 # of unexpected failures33 # of unexpected successes 3 # of expected failures 326 # of unresolved testcases 1 # of untested testcases 70 # of unsupported tests 843 /opt/gcc/i686-darwin/gcc/xgcc version 4.3.0 20080124 (experimental) (GCC) So the patches in comments #11 and #31 may fix some other issues, but do nor seem necessary to fix this PR (and PR34472), at least on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #52 from dominiq at lps dot ens dot fr 2008-01-22 23:25 --- > You mean does not, right? Yes indeed! sorry for skipping the negation. The assembly follows. Comparing it to the assembly for wo_prof_mult_field_peeling_db.c in comment #35, the striking difference is that the latter (working) call L_malloc$stub, while the former call _malloc. I have very little knowledge about the $stub and friends suffices, but if I remember correctly what I have read, the Darwin libraries have both symbols, but one should use the "decorated" one(s). Also the stuff following ".picsymbol_stub" in the working assembly is missing in the non working assembly. .text .align 4,0x90 .globl _main _main: LFB5: pushq %rbp LCFI0: movl$1600, %edi movq%rsp, %rbp LCFI1: call_malloc movl$400, %edi call_malloc movl$400, %edi call_malloc movl$400, %edi call_malloc movl$400, %edi call_malloc xorl%edx, %edx cltq .align 4,0x90 L2: movl$5, (%rax,%rdx,4) addq$1, %rdx cmpq$100, %rdx jne L2 xorb%dl, %dl jmp L4 .align 4,0x90 L3: addq$1, %rdx cmpq$100, %rdx je L9 L4: cmpl$5, (%rax,%rdx,4) je L3 call_abort L9: xorl%eax, %eax leave ret LFE5: .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long 0x0 .byte 0x1 .ascii "zR\0" .byte 0x1 .byte 0x78 .byte 0x10 .byte 0x1 .byte 0x10 .byte 0xc .byte 0x7 .byte 0x8 .byte 0x90 .byte 0x1 .align 3 LECIE1: .globl _main.eh _main.eh: LSFDE1: .set L$set$1,LEFDE1-LASFDE1 .long L$set$1 LASFDE1: .long LASFDE1-EH_frame1 .quad LFB5-. .set L$set$2,LFE5-LFB5 .quad L$set$2 .byte 0x0 .byte 0x4 .set L$set$3,LCFI0-LFB5 .long L$set$3 .byte 0xe .byte 0x10 .byte 0x86 .byte 0x2 .byte 0x4 .set L$set$4,LCFI1-LCFI0 .long L$set$4 .byte 0xd .byte 0x6 .align 3 LEFDE1: .subsections_via_symbols -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #51 from olga at il dot ibm dot com 2008-01-22 22:58 --- (In reply to comment #50) > > I wonder what it will be if we use -fno-unroll-loops in compilation > It does change the segfault: You mean does not, right? Can you please send me its assembly (with -fno-unroll-loops) to compare with assembly of wo_prof_mult_fields_peeling_db.c? They must be really close. Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #50 from dominiq at lps dot ens dot fr 2008-01-22 22:47 --- > I wonder what it will be if we use -fno-unroll-loops in compilation It does change the segfault: [ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O3 -fno-unroll-loops -fipa-struct-reorg -fipa-type-escape -fwhole-program -combine -m64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/wo_prof_mult_field_peeling.c [ibook-dhum] f90/bug% a.out Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #49 from olga at il dot ibm dot com 2008-01-22 21:55 --- (In reply to comment #48) sorry, with -O3 -fipa-struct-reorg -fipa-type-escape -fwhole-program -combine wo_prof_mult_fields_peeling.c -fno-unroll-loops Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #48 from olga at il dot ibm dot com 2008-01-22 20:21 --- Looking closely on the assembly files you generated, I see that in the version that fails there is a loop unrolling. On my linux x86_64 machine the assembly generated for 64 bits has no loop unrolling effects, also as the assembly files from your 32 bits. I wonder what it will be if we use -fno-unroll-loops in compilation, i.e. compiler with -O3 -fipa-struct-reorg -fipa-type-escape -fwhole-program -combine wo_prof_mult_fields_peeling.c and run it. Olga -- olga at il dot ibm dot com changed: What|Removed |Added CC||alond at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #47 from dominiq at lps dot ens dot fr 2008-01-21 20:55 --- > If you run the executable generated by: > -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate > w_prof_global_var.c -m64 > > is it fail or not? It does not fail: [ibook-dhum] bug/depend% /opt/gcc/gcc4.3w/bin/gcc -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate -m64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/w_prof_global_var.c [ibook-dhum] bug/depend% a.out [ibook-dhum] bug/depend% /opt/gcc/gcc4.3w/bin/gcc -O3 -fipa-type-escape -fwhole-program -combine -fprofile-use -m64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/w_prof_global_var.c [ibook-dhum] bug/depend% a.out So it seems that the failures come from the combination "-fipa-struct-reorg -fipa-type-escape -m64". If one option is missing in the triplet the test succeeds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #46 from olga at il dot ibm dot com 2008-01-21 20:42 --- (In reply to comment #45) > > Sorry pursuing this issue, but let me completely understand it: when you run > > *with* profiling, there are two compilations and two executions. If you > > compile > > first with: > > > > -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate > > w_prof_global_var.c > > > > and run the generated executable, is it fail or not? > Sorry for beeing unclear. If I have done the compilation in 32 bit mode (the > default in my config), the generated executable run fine. Then I can use the > generated info to compile with -fprofile-use in 64 bit mode (-m64). gcc does > not complain about this dirty trick (I have no idea if it is supposed to work) > and produces an executable that fails to run. I do not know whether it's legal or not to use information collected by 32bits profiling for optimizations in 64bits, most likely it's not. But it's not what importent here. If you run the executable generated by: -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate w_prof_global_var.c -m64 is it fail or not? Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #45 from dominiq at lps dot ens dot fr 2008-01-21 20:26 --- > Sorry pursuing this issue, but let me completely understand it: when you run > *with* profiling, there are two compilations and two executions. If you > compile > first with: > > -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate > w_prof_global_var.c > > and run the generated executable, is it fail or not? Sorry for beeing unclear. If I have done the compilation in 32 bit mode (the default in my config), the generated executable run fine. Then I can use the generated info to compile with -fprofile-use in 64 bit mode (-m64). gcc does not complain about this dirty trick (I have no idea if it is supposed to work) and produces an executable that fails to run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #44 from olga at il dot ibm dot com 2008-01-21 20:16 --- (In reply to comment #43) > >> They failed with -fprofile-generate (BTW they fail without -fprofile-*). > without! sorry > > If I understand you correctly, the executable of w_prof_global_var.c, > > compiled > > with -O3 -fipa-type-escape -fwhole-program -combine -fdump-ipa-all, fails on > > your system? > No, w_prof_global_var.c and friends pass without '-fipa-type-escape', but they > fail with > -O3 -fipa-struct-reorg -fwhole-program -combine -fipa-type-escape -m64 > due to a segfault (note that I don't know if '-fipa-struct-reorg > -fwhole-program -combine' makes sense without '-fipa-type-escape'). AFAICT > '-fdump-ipa-all' does not change the outcome: pass without > '-fipa-type-escape', > fail otherwise. The -fipa-type-escape flag activates the analysis pass, that does not optimize the code itself. The -fipa-struct-reorg relies on this analysis, and does nothing when it is not activated. Therefore the tests pass without ipa-type-escape. Sorry pursuing this issue, but let me completely understand it: when you run *with* profiling, there are two compilations and two executions. If you compile first with: -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate w_prof_global_var.c and run the generated executable, is it fail or not? > Could this problem be related to PR34621? I do not know. It can be checked by reverting the patch mentioned in comment #5 of this PR. Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #43 from dominiq at lps dot ens dot fr 2008-01-21 19:09 --- >> They failed with -fprofile-generate (BTW they fail without -fprofile-*). without! sorry > If I understand you correctly, the executable of w_prof_global_var.c, compiled > with -O3 -fipa-type-escape -fwhole-program -combine -fdump-ipa-all, fails on > your system? No, w_prof_global_var.c and friends pass without '-fipa-type-escape', but they fail with -O3 -fipa-struct-reorg -fwhole-program -combine -fipa-type-escape -m64 due to a segfault (note that I don't know if '-fipa-struct-reorg -fwhole-program -combine' makes sense without '-fipa-type-escape'). AFAICT '-fdump-ipa-all' does not change the outcome: pass without '-fipa-type-escape', fail otherwise. Could this problem be related to PR34621? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #42 from olga at il dot ibm dot com 2008-01-21 18:33 --- (In reply to comment #41) > Sorry I missed the second question: > > The other question is whether the failing tests that should run *with* > > profiling, like w_prof_gloval_var.c and w_prof_local_var.c, fail after > > compilation with -fprofile-generate or after second compilation with > > -fprofile-use. > They failed with -fprofile-generate (BTW they fail without -fprofile-*). If I understand you correctly, the executable of w_prof_global_var.c, compiled with -O3 -fipa-type-escape -fwhole-program -combine -fdump-ipa-all, fails on your system? Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #41 from dominiq at lps dot ens dot fr 2008-01-21 14:54 --- Sorry I missed the second question: > The other question is whether the failing tests that should run *with* > profiling, like w_prof_gloval_var.c and w_prof_local_var.c, fail after > compilation with -fprofile-generate or after second compilation with > -fprofile-use. They failed with -fprofile-generate (BTW they fail without -fprofile-*). What I said in comment #38, is that I profiled the test(s) in 32 bit mode then compiled with -profile-use -m64 (I do not expect that to be right, but gcc did not complain about that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #40 from dominiq at lps dot ens dot fr 2008-01-21 14:09 --- > Why are you running wo_prof_mult_field_peeling.c with profiling? My best guess is because I have reused some previous command line(s) with it (from gcc.dg/struct/w_prof_global_array.c for instance) without thinking about it. Anyway, I have run all the tests in gcc.dg/struct failing with -m64 with -O3 -fipa-struct-reorg -fwhole-program -combine -fipa-type-escape -m64 and they all crash with "Segmentation fault". The backtrace for gcc.dg/struct/wo_prof_mult_field_peeling.c is: Process: a.out [41283] Path:a.out Identifier: a.out Version: ??? (???) Code Type: X86-64 (Native) Parent Process: tcsh [11101] Date/Time: 2008-01-21 15:03:26.935 +0100 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00200a70 Crashed Thread: 0 Thread 0 Crashed: 0 a.out 0x00010f40 main + 64 1 a.out 0x00010ed4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00200a70 rbx: 0x rcx: 0x rdx: 0x rdi: 0x0001002fc095 rsi: 0x rbp: 0x7fff5fbfec10 rsp: 0x7fff5fbfec10 r8: 0x0001002fe01a r9: 0x0100 r10: 0x0301 r11: 0x7fff8416e474 r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x00010f40 rfl: 0x00010246 cr2: 0x00200a70 Binary Images: 0x1 -0x10ff7 +a.out ??? (???) /Volumes/MacBook/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out 0x13000 -0x1000c9fef +libgfortran.3.dylib ??? (???) /opt/gcc/gcc4.3w/lib/x86_64/libgfortran.3.dylib 0x10010d000 -0x100120ff1 +libgcc_s.1.dylib ??? (???) /opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib 0x7fff5fc0 - 0x7fff5fc2e3a3 dyld 95.3 (???) /usr/lib/dyld 0x7fff819a9000 - 0x7fff819b5ff1 libgcc_s.1.dylib ??? (???) <6fc905606335f261db4da9529c7e2711> /usr/lib/libgcc_s.1.dylib 0x7fff83fcd000 - 0x7fff83fc libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x7fff8416c000 - 0x7fff842ebfeb libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0x7fe0 - 0x7fe01780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib for gcc.dg/struct/wo_prof_two_strs.c Process: a.out [41292] Path:a.out Identifier: a.out Version: ??? (???) Code Type: X86-64 (Native) Parent Process: tcsh [11101] Date/Time: 2008-01-21 15:04:45.522 +0100 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00809600 Crashed Thread: 0 Thread 0 Crashed: 0 a.out 0x00010ed0 main + 256 1 a.out 0x00010da4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0080d600 rbx: 0x0fa0 rcx: 0x000100ff80d6 rdx: 0x rdi: 0x00809600 rsi: 0x03e8 rbp: 0x7fff5fbfec10 rsp: 0x7fff5fbfebf0 r8: 0x034d2346 r9: 0x r10: 0x00012140 r11: 0x7fff8416e474 r12: 0x00010080a600 r13: 0x0080c600 r14: 0x r15: 0x rip: 0x00010ed0 rfl: 0x00010246 cr2: 0x00809600 Binary Images: 0x1 -0x10fff +a.out ??? (???) /Volumes/MacBook/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out 0x13000 -0x1000c9fef +libgfortran.3.dylib ??? (???) /opt/gcc/gcc4.3w/lib/x86_64/libgfortran.3.dylib 0x10010d000 -0x100120ff1 +libgcc_s.1.dylib ??? (???) /opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib 0x7fff5fc0 - 0x7fff5fc2e3a3 dyld 95.3 (???) /usr/lib/dyld 0x7fff819a9000 - 0x7fff819b5ff1 libgcc_s.1.dylib ??? (???) <6fc905606335f261db4da9529c7e2711> /usr/lib/libgcc_s.1.dylib 0x7fff83fcd000 - 0x7fff83fc libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x7fff8416c000 - 0x7fff842ebfeb libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0x7fe0 - 0x7fe01780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib and so on (I can give similar ones for the other cases). Note that if I remove '-fipa-type-escape' the segfaults disappear (with unpatched rev. 131689). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #39 from olga at gcc dot gnu dot org 2008-01-21 13:33 --- (In reply to comment #38) > With patch form comments #11 and #31, the executable for > gcc.dg/struct/wo_prof_mult_field_peeling.c segfault with -m64. I have used the > 32 bit mode for -fprofile-generate, run the executable, and use -m64 for > -fprofile-use. wo_prof_mult_field_peeling_db.c is the code from comment #34. Yes... The assembly for wo_prof_mult_field_peeling.c looks "unrolled". But I have number of question to you. Why are you running wo_prof_mult_field_peeling.c with profiling? At least, it was not intended to be executed this way. If it is, then it is a bug in struct-reorg.exp. The other question is whether the failing tests that should run *with* profiling, like w_prof_gloval_var.c and w_prof_local_var.c, fail after compilation with -fprofile-generate or after second compilation with -fprofile-use. Thanks a lot for debugging, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #38 from dominiq at lps dot ens dot fr 2008-01-20 20:47 --- With patch form comments #11 and #31, the executable for gcc.dg/struct/wo_prof_mult_field_peeling.c segfault with -m64. I have used the 32 bit mode for -fprofile-generate, run the executable, and use -m64 for -fprofile-use. wo_prof_mult_field_peeling_db.c is the code from comment #34. The assembly follows with the options I have used: [ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -m64 -O3 -fdump-ipa-all -fwhole-program -combine -fipa-type-escape wo_prof_mult_field_peeling_db.c [ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling_db.s .text .align 4,0x90 .globl _main _main: LFB6: pushq %rbp LCFI0: movl$400, %edi movq%rsp, %rbp LCFI1: pushq %rbx LCFI2: subq$8, %rsp LCFI3: call_malloc movl$400, %edi movq%rax, %rbx call_malloc movl$400, %edi call_malloc movl$400, %edi call_malloc xorl%eax, %eax .align 4,0x90 L2: movl$5, (%rbx,%rax,4) addq$1, %rax cmpq$100, %rax jne L2 xorb%al, %al jmp L4 .align 4,0x90 L3: addq$1, %rax cmpq$100, %rax je L9 L4: cmpl$5, (%rbx,%rax,4) je L3 call_abort L9: addq$8, %rsp xorb%al, %al popq%rbx leave ret LFE6: .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long 0x0 .byte 0x1 .ascii "zR\0" .byte 0x1 .byte 0x78 .byte 0x10 .byte 0x1 .byte 0x10 .byte 0xc .byte 0x7 .byte 0x8 .byte 0x90 .byte 0x1 .align 3 LECIE1: .globl _main.eh _main.eh: LSFDE1: .set L$set$1,LEFDE1-LASFDE1 .long L$set$1 LASFDE1: .long LASFDE1-EH_frame1 .quad LFB6-. .set L$set$2,LFE6-LFB6 .quad L$set$2 .byte 0x0 .byte 0x4 .set L$set$3,LCFI0-LFB6 .long L$set$3 .byte 0xe .byte 0x10 .byte 0x86 .byte 0x2 .byte 0x4 .set L$set$4,LCFI1-LCFI0 .long L$set$4 .byte 0xd .byte 0x6 .byte 0x4 .set L$set$5,LCFI3-LCFI1 .long L$set$5 .byte 0x83 .byte 0x3 .align 3 LEFDE1: .subsections_via_symbols [ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -m64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/wo_prof_mult_field_peeling.c -O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all [ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling.s .section __TEXT,__text,regular,pure_instructions .align 4 .globl _main _main: LFB5: pushq %rbp LCFI0: movl$1600, %edi movq%rsp, %rbp LCFI1: call_malloc movl$400, %edi call_malloc movl$400, %edi call_malloc movl$400, %edi call_malloc movl$400, %edi call_malloc xorl%edx, %edx cltq .align 4 L2: movl$5, (%rax,%rdx,4) movl$5, 4(%rax,%rdx,4) movl$5, 8(%rax,%rdx,4) movl$5, 12(%rax,%rdx,4) movl$5, 16(%rax,%rdx,4) movl$5, 20(%rax,%rdx,4) movl$5, 24(%rax,%rdx,4) movl$5, 28(%rax,%rdx,4) movl$5, 32(%rax,%rdx,4) movl$5, 36(%rax,%rdx,4) addq$10, %rdx cmpq$100, %rdx jne L2 xorb%dl, %dl .align 4 L4: cmpl$5, (%rax,%rdx,4) jne L35 leaq1(%rdx), %rcx cmpl$5, (%rax,%rcx,4) jne L35 cmpl$5, 8(%rax,%rdx,4) jne L35 cmpl$5, 12(%rax,%rdx,4) jne L35 cmpl$5, 16(%rax,%rdx,4) jne L35 cmpl$5, 20(%rax,%rdx,4) jne L35 cmpl$5, 24(%rax,%rdx,4) jne L35 cmpl$5, 28(%rax,%rdx,4) jne L35 cmpl$5, 32(%rax,%rdx,4) jne L35 cmpl$5, 36(%rax,%rdx,4) jne L35 leaq9(%rcx), %rdx cmpq$100, %rdx jne L4 xorl%eax, %eax leave ret L35: call_abort LFE5: .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long 0x0 .byte 0x1 .ascii "zR\0" .byte 0x1 .byte 0x78 .byte 0x10 .byte 0x1 .byte 0x10 .byte 0xc
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #37 from dominiq at lps dot ens dot fr 2008-01-20 18:09 --- (In reply to comment #36) > ... And, if I understand correctly the comment #32, with 64 bits mode it does > fails with wo_prof_mult_fields_peeling.c. Please fix me if I am wrong. Yes, you are right. I did not look carefully enough to my display. What's happen is that the executable with -profile-generate segfault. I am not sure to be in a position to reapply the patches in the coming hours. I'll do my best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #36 from olga at gcc dot gnu dot org 2008-01-20 17:03 --- (In reply to comment #35) > Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and > 64 bit modes on i686-apple-darwin9, so I am not sure that what follows will > help. Sorry, I meant compiling with two patches: from comment #11 and from comment #31. And, if I understand correctly the comment #32, with 64 bits mode it does fails with wo_prof_mult_fields_peeling.c. Please fix me if I am wrong. Thank you a lot, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #35 from dominiq at lps dot ens dot fr 2008-01-20 15:16 --- Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and 64 bit modes on i686-apple-darwin9, so I am not sure that what follows will help. For the code in comment #34 the assembly code is: [ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -O3 -fdump-ipa-all -fwhole-program -combine -fipa-type-escape wo_prof_mult_field_peeling_db.c [ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling_db.s .text .align 4,0x90 .globl _main _main: pushl %ebp movl%esp, %ebp pushl %esi subl$20, %esp movl$400, (%esp) callL_malloc$stub movl$400, (%esp) movl%eax, %esi callL_malloc$stub movl$400, (%esp) callL_malloc$stub movl$400, (%esp) callL_malloc$stub xorl%eax, %eax .align 4,0x90 L2: movl$5, (%esi,%eax,4) addl$1, %eax cmpl$100, %eax jne L2 xorb%al, %al jmp L4 .align 4,0x90 L3: addl$1, %eax cmpl$100, %eax je L9 L4: cmpl$5, (%esi,%eax,4) je L3 callL_abort$stub L9: addl$20, %esp xorb%al, %al popl%esi popl%ebp ret .picsymbol_stub L_malloc$stub: .indirect_symbol _malloc callLPC$1 LPC$1: popl%eax movlL1$lz-LPC$1(%eax),%edx jmp *%edx L_malloc$stub_binder: lea L1$lz-LPC$1(%eax),%eax pushl %eax jmp dyld_stub_binding_helper .lazy_symbol_pointer L1$lz: .indirect_symbol _malloc .long L_malloc$stub_binder .picsymbol_stub L_abort$stub: .indirect_symbol _abort callLPC$2 LPC$2: popl%eax movlL2$lz-LPC$2(%eax),%edx jmp *%edx L_abort$stub_binder: lea L2$lz-LPC$2(%eax),%eax pushl %eax jmp dyld_stub_binding_helper .lazy_symbol_pointer L2$lz: .indirect_symbol _abort .long L_abort$stub_binder .subsections_via_symbols [ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -O3 -fdump-ipa-all -fwhole-program -combine -fipa-type-escape -fipa-struct-reorg /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/wo_prof_mult_field_peeling.c [ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling.s .text .align 4,0x90 .globl _main _main: pushl %ebp movl%esp, %ebp subl$24, %esp movl$1600, (%esp) callL_malloc$stub movl$400, (%esp) callL_malloc$stub movl$400, (%esp) callL_malloc$stub movl$400, (%esp) callL_malloc$stub movl$400, (%esp) callL_malloc$stub xorl%edx, %edx .align 4,0x90 L2: movl$5, (%eax,%edx,4) addl$1, %edx cmpl$100, %edx jne L2 xorb%dl, %dl jmp L4 .align 4,0x90 L3: addl$1, %edx cmpl$100, %edx je L9 L4: cmpl$5, (%eax,%edx,4) je L3 callL_abort$stub L9: xorl%eax, %eax leave ret .picsymbol_stub L_malloc$stub: .indirect_symbol _malloc callLPC$1 LPC$1: popl%eax movlL1$lz-LPC$1(%eax),%edx jmp *%edx L_malloc$stub_binder: lea L1$lz-LPC$1(%eax),%eax pushl %eax jmp dyld_stub_binding_helper .lazy_symbol_pointer L1$lz: .indirect_symbol _malloc .long L_malloc$stub_binder .picsymbol_stub L_abort$stub: .indirect_symbol _abort callLPC$2 LPC$2: popl%eax movlL2$lz-LPC$2(%eax),%edx jmp *%edx L_abort$stub_binder: lea L2$lz-LPC$2(%eax),%eax pushl %eax jmp dyld_stub_binding_helper .lazy_symbol_pointer L2$lz: .indirect_symbol _abort .long L_abort$stub_binder .subsections_via_symbols [ibook-dhum] bug/tmp_dir% diff wo_prof_mult_field_peeling.s wo_prof_mult_field_peeling_db.s 7,9c7,8 < subl$24, %esp < movl$1600, (%esp) < callL_malloc$stub --- > pushl %esi > subl$20, %esp 12a12 > movl%eax, %esi 18c18 < xorl%edx, %edx --- > xorl%eax, %eax 21,23c21,23 < movl$5, (%eax,%edx,4) < addl$1, %edx < cmpl$100, %edx --- > movl$5, (%esi,%eax,4) > addl$1, %eax > cmpl$100, %eax 25c25 < xorb%dl, %dl --- > xorb%al, %al 29,30c29,30 < addl$1, %edx < cmpl$100, %edx --
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #34 from olga at gcc dot gnu dot org 2008-01-20 13:28 --- Dave, Dominique, As I have no such execution failures on any one of machines, would you please help me debugging the execution failures? I am actually need the place where it fails and assembly files. The most convenient file is wo_prof_mult_fields_peeling.c . Can you please produce an assembly for it? For this file I also generated the artificial result of struct-reorg optimization (below), to be compiled without -fipa-struct-reorg, but with all other flags (-O3 -fdump-ipa-all -fwhole-program -combine -fipa-type-escape). The idea is to compare two assembly files, from original wo_prof_mult_fields_peeling.c and from faked one: #include #include typedef struct { int a; }str_t0; typedef struct { float b; }str_t1; typedef struct { int c; }str_t2; typedef struct { float d; }str_t3; #define N 100 int main () { int i; str_t0 *p0 = malloc (N * sizeof (str_t0)); str_t1 *p1 = malloc (N * sizeof (str_t1)); str_t0 *p2 = malloc (N * sizeof (str_t2)); str_t0 *p3 = malloc (N * sizeof (str_t3)); for (i = 0; i < N; i++) p0[i].a = 5; for (i = 0; i < N; i++) if (p0[i].a != 5) abort (); return 0; } Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #33 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-16 02:33 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > I gave it another push. The following is a patch solving inconsistency of the > data structures in struct reorg, and releasing comparison with 0. Please try > it This is the result on hppa2.0w-hp-hpux11.11: FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c execution test XPASS: gcc.dg/struct/wo_prof_malloc_size_var.c scan-ipa-dump ipa_struct_reorg "N umber of structures to transform is 1" FAIL: gcc.dg/struct/w_prof_global_var.c execution,-O3 -fwhole-program -combi ne -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_local_var.c execution,-O3 -fwhole-program -combin e -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #32 from dominiq at lps dot ens dot fr 2008-01-15 20:03 --- With the patches in comments #11 and 31, the error disappears in 32 bit mode on Intel Darwin9 (as with #11 alone), now appears in 64 bit mode with the other errors already reported: FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c execution test < new with patch #31 FAIL: gcc.dg/struct/wo_prof_mult_field_peeling.c execution test FAIL: gcc.dg/struct/wo_prof_two_strs.c execution test FAIL: gcc.dg/struct/w_prof_global_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_local_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_two_strs.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #31 from olga at gcc dot gnu dot org 2008-01-15 14:11 --- I gave it another push. The following is a patch solving inconsistency of the data structures in struct reorg, and releasing comparison with 0. Please try it together with the Richard's patch. It should give extra XPASS. If it's ok for you, I submit it for gcc-patches. Thank you, Olga Index: ipa-struct-reorg.c === --- ipa-struct-reorg.c (revision 130927) +++ ipa-struct-reorg.c (working copy) @@ -187,7 +187,7 @@ typedef const struct func_alloc_sites *const_fallocs_t; /* All allocation sites in the program. */ -htab_t alloc_sites; +htab_t alloc_sites = NULL; /* New global variables. Generated once for whole program. */ htab_t new_global_vars; @@ -1246,12 +1248,14 @@ s0 = (str0 != length) ? true : false; s1 = (str1 != length) ? true : false; - gcc_assert ((!s0 && s1) || (!s1 && s0)); + gcc_assert (s0 || s1); + /* For now we allow only comparison with 0 or NULL. */ + gcc_assert (integer_zerop (arg0) || integer_zerop (arg1)); - str = s0 ? VEC_index (structure, structures, str0): -VEC_index (structure, structures, str1); - arg = s0 ? arg0 : arg1; - pos = s0 ? 0 : 1; + str = integer_zerop (arg0) ? VEC_index (structure, structures, str1): +VEC_index (structure, structures, str0); + arg = integer_zerop (arg0) ? arg1 : arg0; + pos = integer_zerop (arg0) ? 1 : 0; for (i = 0; VEC_iterate (tree, str->new_types, i, type); i++) { @@ -2339,6 +2343,41 @@ htab_traverse (accs, dump_acc, NULL); } +/* This function is a callback for alloc_sites hashtable + traversal. SLOT is a pointer to fallocs_t. This function + removes all allocations of the structure defined by DATA. */ + +static int +remove_str_allocs_in_func (void **slot, void *data) +{ + fallocs_t fallocs = *(fallocs_t *) slot; + unsigned i = 0; + alloc_site_t *call; + + while (VEC_iterate (alloc_site_t, fallocs->allocs, i, call)) +{ + if (call->str == (d_str) data) + VEC_ordered_remove (alloc_site_t, fallocs->allocs, i); + else + i++; +} + + return 1; +} + +/* This function remove all entries corresponding to the STR structure + from alloc_sites hashtable. */ + +static void +remove_str_allocs (d_str str) +{ + if (!str) +return; + + if (alloc_sites) +htab_traverse (alloc_sites, remove_str_allocs_in_func, str); +} + /* This function removes the structure with index I from structures vector. */ static void @@ -2349,7 +2388,11 @@ if (i >= VEC_length (structure, structures)) return; - str = VEC_index (structure, structures, i); + str = VEC_index (structure, structures, i); + + /* Before removing the structure str, we have to remove its + allocations from alloc_sites hashtable. */ + remove_str_allocs (str); free_data_struct (str); VEC_ordered_remove (structure, structures, i); } @@ -2383,8 +2426,12 @@ s0 = (str0 != length) ? true : false; s1 = (str1 != length) ? true : false; + + if (!s0 && !s1) +return false; - if (!((!s0 && s1) || (!s1 && s0))) + /* For now we allow only comparison with 0 or NULL. */ + if (!integer_zerop (arg0) && !integer_zerop (arg1)) return false; return true; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-08 15:51 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > Subject: Re: wo_prof_two_strs.c:56: internal compiler > error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > > > Would you please try the Alon's patch for PR 34701. > > I did but the reported failures are still there. Too bad!-( Same on hppa2.0w-hp-hpux11.11. It doesn't help with the malloc related fails. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #29 from dominiq at lps dot ens dot fr 2008-01-07 20:04 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > Would you please try the Alon's patch for PR 34701. I did but the reported failures are still there. Too bad!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #28 from olga at gcc dot gnu dot org 2008-01-07 13:38 --- (In reply to comment #27) Would you please try the Alon's patch for PR 34701. I am not sure but maybe it's related. Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-03 01:44 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 With the attached change and Richard's patch from comment #11, I'm down to the same two fails on hppa2.0w-hp-hpux11.11 as reported for hppa64-hp-hpux11.11 in comment #19. Dave --- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-03 01:44 --- Created an attachment (id=14864) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14864&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #25 from dominiq at lps dot ens dot fr 2008-01-02 17:07 --- On Intel Darwin9 the patch from PR34472 has the same effect than the patch in comment #11, i.e., the behavior reported in comment #22. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-02 15:11 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > Would you please see the comment #4 for PR 34534, and try it on your machine? The wo_prof_global_var.c test doesn't abort on hppa2.0w-hp-hpux11.11 if a) -fipa-struct-reorg is not used, or b) "float" is changed to "int" in the struct, or c) "a" and "b" are switched in the struct, or d) calloc is used instead of malloc. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #23 from rsandifo at nildram dot co dot uk 2008-01-02 13:19 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 Olga, is it OK if I submit the patch from comment #11? Or would you prefer to go with the patch from PR34472? richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #22 from dominiq at lps dot ens dot fr 2007-12-31 19:43 --- The patch in comment #11 fixes the failure of gcc.dg/struct/wo_prof_malloc_size_var.c on i686-apple-darwin9 32 bit mode, but I have still the failures reported in comment #6 of PR34534 in 64 bit mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-12-30 14:54 --- *** Bug 34623 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #17 from olga at gcc dot gnu dot org 2007-12-30 12:19 --- (In reply to comment #16) > I think this is related to PR 34472 and PR 34534 true. Would you please see the comment #4 for PR 34534, and try it on your machine? Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #16 from hjl at lucon dot org 2007-12-29 16:20 --- I think this is related to PR 34472 and PR 34534 -- hjl at lucon dot org changed: What|Removed |Added BugsThisDependsOn||34472, 34534 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-29 01:24 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > > But isn't my patch more efficient? I don't see why you need to > > build a separate list like that. > > I'm testing your patch on hppa2.0w-hp-hpux11.11. With this patch, I still have the following fails on hppa2.0w-hp-hpux11.11: FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_two_strs.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 2" FAIL: gcc.dg/struct/w_prof_global_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_local_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_two_strs.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 2" Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-28 19:54 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > But isn't my patch more efficient? I don't see why you need to > build a separate list like that. I'm testing your patch on hppa2.0w-hp-hpux11.11. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #13 from rsandifo at nildram dot co dot uk 2007-12-28 19:38 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 "olga at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > --- Comment #12 from olga at gcc dot gnu dot org 2007-12-28 19:28 --- > (In reply to comment #11) >> Created an attachment (id=14838) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14838&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14838&action=view) [edit] >> Patch for double free and iteration bug >> I'm seeing a struct-reorg.exp ICE on MIPS too, although in >> wo_prof_malloc_size_var.i instead of wo_prof_two_strs.c. >> ISTR seeing the same ICE you did, but now I just get a >> segmentation fault. >> As far as the segfault goes, the problem is that we free >> a htab from inside a htab_traverse of it. I also noticed >> that a couple of "remove this structure?" loops were skipping >> the structure that replaces a removed one. >> Could you try this patch and see if it is the same problem, >> or whether it's something different? > > Indeed, would you please try the patch that solved PR34472? Gah, I'd tried several searches to find an existing PR for this! But isn't my patch more efficient? I don't see why you need to build a separate list like that. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #12 from olga at gcc dot gnu dot org 2007-12-28 19:28 --- (In reply to comment #11) > Created an attachment (id=14838) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14838&action=view) [edit] > Patch for double free and iteration bug > I'm seeing a struct-reorg.exp ICE on MIPS too, although in > wo_prof_malloc_size_var.i instead of wo_prof_two_strs.c. > ISTR seeing the same ICE you did, but now I just get a > segmentation fault. > As far as the segfault goes, the problem is that we free > a htab from inside a htab_traverse of it. I also noticed > that a couple of "remove this structure?" loops were skipping > the structure that replaces a removed one. > Could you try this patch and see if it is the same problem, > or whether it's something different? Indeed, would you please try the patch that solved PR34472? Thanks, Olga > Thanks, > Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-12-28 14:57 --- Created an attachment (id=14838) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14838&action=view) Patch for double free and iteration bug I'm seeing a struct-reorg.exp ICE on MIPS too, although in wo_prof_malloc_size_var.i instead of wo_prof_two_strs.c. ISTR seeing the same ICE you did, but now I just get a segmentation fault. As far as the segfault goes, the problem is that we free a htab from inside a htab_traverse of it. I also noticed that a couple of "remove this structure?" loops were skipping the structure that replaces a removed one. Could you try this patch and see if it is the same problem, or whether it's something different? Thanks, Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 Hi Olga, On Mon, 17 Dec 2007, olga at gcc dot gnu dot org wrote: > I actually need the dump files > wo_prof_two_strs.c.* generated in your build directory. I've attached the dump files. Dave --- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14810) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14810&action=view) --- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14811) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14811&action=view) --- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14812) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14812&action=view) --- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14813) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14813&action=view) --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14814) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14814&action=view) --- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14815) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14815&action=view) --- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14816) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14816&action=view) --- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-24 02:08 --- Created an attachment (id=14817) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14817&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #1 from olga at gcc dot gnu dot org 2007-12-17 15:15 --- Thank you a lot for debugging! As I have not hpux system, and cannot reproduce this dug on x86 or ppc machine, would you please help me to debug it? In gcc/gcc/ipa-struct-reorg.c file, please comment out line 3915 that says: do_reorg_1 (); Also please remove the following line from the wo_prof_two_strs.c test: /* { dg-final { cleanup-ipa-dump "*" } } */ compile gcc, and run struct-reorg.exp tests. I actually need the dump files wo_prof_two_strs.c.* generated in your build directory. thank you for cooperation, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483