[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

2008-11-01 Thread danglin at gcc dot gnu dot org


--- 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

2008-02-07 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-02-07 Thread olga at gcc dot gnu dot org


--- 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

2008-02-04 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-02-03 Thread olga at gcc dot gnu dot org


--- 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

2008-01-31 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-31 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-31 Thread alond at il dot ibm dot com


--- 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

2008-01-30 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-29 Thread alond at il dot ibm dot com


--- 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

2008-01-26 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-25 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-25 Thread olga at il dot ibm dot com


--- 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

2008-01-24 Thread danglin at gcc dot gnu dot org


--- 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

2008-01-24 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-24 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-22 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-22 Thread olga at il dot ibm dot com


--- 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

2008-01-22 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-22 Thread olga at il dot ibm dot com


--- 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

2008-01-22 Thread olga at il dot ibm dot com


--- 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

2008-01-21 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-21 Thread olga at il dot ibm dot com


--- 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

2008-01-21 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-21 Thread olga at il dot ibm dot com


--- 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

2008-01-21 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-21 Thread olga at il dot ibm dot com


--- 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

2008-01-21 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-21 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-21 Thread olga at gcc dot gnu dot org


--- 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

2008-01-20 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-20 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-20 Thread olga at gcc dot gnu dot org


--- 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

2008-01-20 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-20 Thread olga at gcc dot gnu dot org


--- 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

2008-01-15 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-15 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-15 Thread olga at gcc dot gnu dot org


--- 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

2008-01-08 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-07 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-07 Thread olga at gcc dot gnu dot org


--- 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

2008-01-02 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-02 Thread dominiq at lps dot ens dot fr


--- 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

2008-01-02 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2008-01-02 Thread rsandifo at nildram dot co dot uk


--- 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

2007-12-31 Thread dominiq at lps dot ens dot fr


--- 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

2007-12-30 Thread pinskia at gcc dot gnu dot org


--- 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

2007-12-30 Thread olga at gcc dot gnu dot org


--- 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

2007-12-29 Thread hjl at lucon dot org


--- 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

2007-12-28 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2007-12-28 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2007-12-28 Thread rsandifo at nildram dot co dot uk


--- 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

2007-12-28 Thread olga at gcc dot gnu dot org


--- 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

2007-12-28 Thread rsandifo at gcc dot gnu dot org


--- 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

2007-12-23 Thread dave at hiauly1 dot hia dot nrc dot ca


--- 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

2007-12-17 Thread olga at gcc dot gnu dot org


--- 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