Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c -O3 -fipa-struct -reorg -fdump-ipa-all -fwhole-program -combine -fipa-type-escape -fno-show-colum n -lm -o ./wo_prof_two_strs.exe (timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c: In function 'm ain': /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 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c: In function 'm ain': /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 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. 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) Excess errors: /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 WARNING: gcc.dg/struct/wo_prof_two_strs.c compilation failed to produce executab le FAIL: gcc.dg/struct/wo_prof_two_strs.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 2" and Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c -O3 -fwhole-prog ram -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all - fno-show-column -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/w_prof_two_strs .x02 (timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c: In function 'ma in': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c:53: internal com piler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c: In function 'ma in': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c:53: internal com piler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. 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 com piler error) UNRESOLVED: gcc.dg/struct/w_prof_two_strs.c execution, -O3 -fwhole-program -c ombine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all For the first, I see the following backtrace: (gdb) p var $2 = (new_var) 0x0 (gdb) bt #0 find_new_var_of_type (orig_var=0x800003fffde810a0, new_type=0x800003fffde7dcc0) at ../../gcc/gcc/ipa-struct-reorg.c:605 #1 0x4000000000d4f140 in gen_cast_stmt (before_cast=0x800003fffde916e0, new_type=0x800003fffde7dcc0, orig_cast_stmt=0x800003fffde79f30, res_p=0x800003fffdff1460) at ../../gcc/gcc/ipa-struct-reorg.c:652 #2 0x4000000000d56564 in create_new_malloc (malloc_stmt=0x800003fffde79f00, new_type=0x800003fffde7dcc0, new_stmts=0x800003fffdff1370, num=0x800003fffde8d0c0) at ../../gcc/gcc/ipa-struct-reorg.c:1747 #3 0x4000000000d582a0 in create_new_alloc_sites (m_data=0x8000000100128410, context=0x800003fffde7b270) at ../../gcc/gcc/ipa-struct-reorg.c:2167 #4 0x4000000000d5bd98 in create_new_alloc_sites_for_func ( node=0x800003fffde41400) at ../../gcc/gcc/ipa-struct-reorg.c:2645 #5 0x4000000000d5f4c4 in do_reorg_for_func (node=0x800003fffde41400) at ../../gcc/gcc/ipa-struct-reorg.c:3191 #6 0x4000000000d61b40 in do_reorg_1 () at ../../gcc/gcc/ipa-struct-reorg.c:3664 #7 0x4000000000d629e4 in do_reorg () at ../../gcc/gcc/ipa-struct-reorg.c:3915 #8 0x4000000000d62b04 in reorg_structs () at ../../gcc/gcc/ipa-struct-reorg.c:3956 #9 0x4000000000d62b58 in reorg_structs_drive () at ../../gcc/gcc/ipa-struct-reorg.c:3967 #10 0x40000000007349c8 in execute_one_pass (pass=0x8000000100048cd8) at ../../gcc/gcc/passes.c:1118 ---Type <return> to continue, or q <return> to quit--- #11 0x4000000000734e30 in execute_ipa_pass_list (pass=0x8000000100048cd8) at ../../gcc/gcc/passes.c:1187 #12 0x4000000000d2ceb0 in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1339 #13 0x4000000000d2d154 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1386 #14 0x40000000001a80e4 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8077 #15 0x4000000000881768 in compile_file () at ../../gcc/gcc/toplev.c:1055 #16 0x40000000008852dc in do_compile () at ../../gcc/gcc/toplev.c:2245 #17 0x40000000008853f8 in toplev_main (argc=22, argv=0x800003fffdff06c0) at ../../gcc/gcc/toplev.c:2277 #18 0x40000000002b86f8 in main (argc=Cannot access memory at address 0x0 ) at ../../gcc/gcc/main.c:35 (gdb) p debug_tree (orig_var) <var_decl 800003fffde810a0 p1.5 type <pointer_type 800003fffde78cc0 type <record_type 800003fffde78900 str_t1 no-force-blk type_0 BLK size <integer_cst 800003fffdec88d0 constant invariant 64> unit size <integer_cst 800003fffdec8900 constant invariant 8> align 32 symtab 0 alias set -1 canonical type 800003fffde786c0 fields <field_decl 800003fffde6d1e0 a> context <translation_unit_decl 800003fffde7d600 D.2666> pointer_to_this <pointer_type 800003fffde78cc0>> public unsigned DI size <integer_cst 800003fffdec88d0 64> unit size <integer_cst 800003fffdec8900 8> align 64 symtab 0 alias set -1 canonical type 800003fffde78d80> used unsigned ignored DI file /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c line 37 col 3 size <integer_cst 800003fffdec88d0 64> unit size <integer_cst 800003fffdec8900 8> align 64 context <function_decl 800003fffde7b270 main> chain <var_decl 800003fffde81140 D.2651>> (gdb) p debug_tree (new_type) <record_type 800003fffde7dcc0 struct.0_sub.0 SF size <integer_cst 800003fffdec87e0 type <integer_type 800003fffded3180 bit_size_type> constant invariant 32> unit size <integer_cst 800003fffdec8450 type <integer_type 800003fffded30c0 long unsigned int> constant invariant 4> align 32 symtab 0 alias set -1 canonical type 800003fffde7dcc0 fields <field_decl 800003fffde6d3c0 d type <real_type 800003fffdee7600 float SF size <integer_cst 800003fffdec87e0 32> unit size <integer_cst 800003fffdec8450 4> align 32 symtab 0 alias set 4 canonical type 800003fffdee7600 precision 32 pointer_to_this <pointer_type 800003fffdee7840>> SF file /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c line 12 col 9 size <integer_cst 800003fffdec87e0 32> unit size <integer_cst 800003fffdec8450 4> align 32 offset_align 128 offset <integer_cst 800003fffdec8480 constant invariant 0> bit offset <integer_cst 800003fffdee50c0 constant invariant 0> context <record_type 800003fffde7dcc0 struct.0_sub.0>> pointer_to_this <pointer_type 800003fffde7de40>> On entry, orig_var was: (gdb) p debug_tree (orig_var) <ssa_name 800003fffde8d1e0 type <pointer_type 800003fffde78cc0 type <record_type 800003fffde78900 str_t1 no-force-blk type_0 BLK size <integer_cst 800003fffdec88d0 constant invariant 64> unit size <integer_cst 800003fffdec8900 constant invariant 8> align 32 symtab 0 alias set -1 canonical type 800003fffde786c0 fields <field_decl 800003fffde6d1e0 a> context <translation_unit_decl 800003fffde7d600 D.2666> pointer_to_this <pointer_type 800003fffde78cc0>> public unsigned DI size <integer_cst 800003fffdec88d0 64> unit size <integer_cst 800003fffdec8900 8> align 64 symtab 0 alias set -1 canonical type 800003fffde78d80> visited var <var_decl 800003fffde810a0 p1.5> def_stmt <gimple_modify_stmt 800003fffde79f30> version 12>
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
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
Created attachment 14810 [details] wo_prof_two_strs.c.000i.cgraph.gz
Created attachment 14811 [details] wo_prof_two_strs.c.017i.visibility.gz
Created attachment 14812 [details] wo_prof_two_strs.c.020i.early_local_cleanups.gz
Created attachment 14813 [details] wo_prof_two_strs.c.046i.inline.gz
Created attachment 14814 [details] wo_prof_two_strs.c.047i.static-var.gz
Created attachment 14815 [details] wo_prof_two_strs.c.048i.pure-const.gz
Created attachment 14816 [details] wo_prof_two_strs.c.049i.type-escape-var.gz
Created attachment 14817 [details] wo_prof_two_strs.c.051i.ipa_struct_reorg.gz
Created attachment 14838 [details] 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
(In reply to comment #11) > Created an attachment (id=14838) [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
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" <gcc-bugzilla@gcc.gnu.org> 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) [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
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
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
I think this is related to PR 34472 and PR 34534
(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
*** Bug 34623 has been marked as a duplicate of this bug. ***
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? With Richard's patch, there are only two fails on hppa64-hp-hpux11.11: 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_two_strs.c scan-ipa-dump ipa_struct_reorg "Number of structures to transform is 2" I've attached the ipa_struct_reorg dumps. I'll rebuild the 32-bit hppa2.0w-hp-hpux11.11 target and try your suggestion if relevant. Dave
Created attachment 14849 [details] wo_prof_two_strs.c.051i.ipa_struct_reorg
Created attachment 14850 [details] w_prof_two_strs.c.051i.ipa_struct_reorg
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.
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
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
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.
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
Created attachment 14864 [details] wo_prof.d
(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
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!-(
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
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;
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
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
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 <stdlib.h> #include <stdio.h> 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
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) call L_malloc$stub movl $400, (%esp) movl %eax, %esi call L_malloc$stub movl $400, (%esp) call L_malloc$stub movl $400, (%esp) call L_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 call L_abort$stub L9: addl $20, %esp xorb %al, %al popl %esi popl %ebp ret .picsymbol_stub L_malloc$stub: .indirect_symbol _malloc call LPC$1 LPC$1: popl %eax movl L1$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 call LPC$2 LPC$2: popl %eax movl L2$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) call L_malloc$stub movl $400, (%esp) call L_malloc$stub movl $400, (%esp) call L_malloc$stub movl $400, (%esp) call L_malloc$stub movl $400, (%esp) call L_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 call L_abort$stub L9: xorl %eax, %eax leave ret .picsymbol_stub L_malloc$stub: .indirect_symbol _malloc call LPC$1 LPC$1: popl %eax movl L1$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 call LPC$2 LPC$2: popl %eax movl L2$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) < call L_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 --- > addl $1, %eax > cmpl $100, %eax 33c33 < cmpl $5, (%eax,%edx,4) --- > cmpl $5, (%esi,%eax,4) 37,38c37,40 < xorl %eax, %eax < leave --- > addl $20, %esp > xorb %al, %al > popl %esi > popl %ebp
(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
(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.
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 leaq 1(%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 leaq 9(%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 .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
(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
> 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 0x0000000000200a70 Crashed Thread: 0 Thread 0 Crashed: 0 a.out 0x0000000100000f40 main + 64 1 a.out 0x0000000100000ed4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000200a70 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000 rdi: 0x00000001002fc095 rsi: 0x0000000000000000 rbp: 0x00007fff5fbfec10 rsp: 0x00007fff5fbfec10 r8: 0x00000001002fe01a r9: 0x0000000001000000 r10: 0x0000000003000001 r11: 0x00007fff8416e474 r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 rip: 0x0000000100000f40 rfl: 0x0000000000010246 cr2: 0x0000000000200a70 Binary Images: 0x100000000 - 0x100000ff7 +a.out ??? (???) /Volumes/MacBook/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out 0x100003000 - 0x1000c9fef +libgfortran.3.dylib ??? (???) <ac0635c6511429acc90b895479c2cbb0> /opt/gcc/gcc4.3w/lib/x86_64/libgfortran.3.dylib 0x10010d000 - 0x100120ff1 +libgcc_s.1.dylib ??? (???) <e9505452e93d052d01993982f18fa20a> /opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib 0x7fff5fc00000 - 0x7fff5fc2e3a3 dyld 95.3 (???) <cd99d065ba4917450dca6958a854c594> /usr/lib/dyld 0x7fff819a9000 - 0x7fff819b5ff1 libgcc_s.1.dylib ??? (???) <6fc905606335f261db4da9529c7e2711> /usr/lib/libgcc_s.1.dylib 0x7fff83fcd000 - 0x7fff83fcffff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x7fff8416c000 - 0x7fff842ebfeb libSystem.B.dylib ??? (???) <a9297f52cb1431e26cd3ffd4b9ca7615> /usr/lib/libSystem.B.dylib 0x7fffffe00000 - 0x7fffffe01780 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 0x0000000000809600 Crashed Thread: 0 Thread 0 Crashed: 0 a.out 0x0000000100000ed0 main + 256 1 a.out 0x0000000100000da4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x000000000080d600 rbx: 0x0000000000000fa0 rcx: 0x0000000100ff80d6 rdx: 0x0000000000000000 rdi: 0x0000000000809600 rsi: 0x00000000000003e8 rbp: 0x00007fff5fbfec10 rsp: 0x00007fff5fbfebf0 r8: 0x00000000034d2346 r9: 0x0000000000000000 r10: 0x0000000100002140 r11: 0x00007fff8416e474 r12: 0x000000010080a600 r13: 0x000000000080c600 r14: 0x0000000000000000 r15: 0x0000000000000000 rip: 0x0000000100000ed0 rfl: 0x0000000000010246 cr2: 0x0000000000809600 Binary Images: 0x100000000 - 0x100000fff +a.out ??? (???) /Volumes/MacBook/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out 0x100003000 - 0x1000c9fef +libgfortran.3.dylib ??? (???) <ac0635c6511429acc90b895479c2cbb0> /opt/gcc/gcc4.3w/lib/x86_64/libgfortran.3.dylib 0x10010d000 - 0x100120ff1 +libgcc_s.1.dylib ??? (???) <e9505452e93d052d01993982f18fa20a> /opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib 0x7fff5fc00000 - 0x7fff5fc2e3a3 dyld 95.3 (???) <cd99d065ba4917450dca6958a854c594> /usr/lib/dyld 0x7fff819a9000 - 0x7fff819b5ff1 libgcc_s.1.dylib ??? (???) <6fc905606335f261db4da9529c7e2711> /usr/lib/libgcc_s.1.dylib 0x7fff83fcd000 - 0x7fff83fcffff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x7fff8416c000 - 0x7fff842ebfeb libSystem.B.dylib ??? (???) <a9297f52cb1431e26cd3ffd4b9ca7615> /usr/lib/libSystem.B.dylib 0x7fffffe00000 - 0x7fffffe01780 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).
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).
(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
>> 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?
(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
> 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.
(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
> 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.
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
(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
> 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
(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
> 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
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 passes 47421 # of unexpected failures 11 # of unexpected successes 1 # of expected failures 163 # of untested testcases 35 # of unsupported tests 477 === gcc Summary === # of expected passes 94966 # of unexpected failures 33 # 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.
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
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"
(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
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
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
(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
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
> 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
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
Created attachment 15069 [details] wo_prof_global_var.s
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
(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
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
(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
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
Fixed.