[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #12 from zadeck at naturalbridge dot com  2008-05-09 12:29 
---
Patch committed.


-- 

zadeck at naturalbridge dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #11 from zadeck at naturalbridge dot com  2008-05-09 12:25 
---
Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
 ICEs with 135041 -> 135057

zadeck at naturalbridge dot com wrote:
> --- Comment #10 from zadeck at naturalbridge dot com  2008-05-09 11:58 
> ---
> Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
>  ICEs with 135041 -> 135057
>
> bonzini at gnu dot org wrote:
>   
>> --- Comment #9 from bonzini at gnu dot org  2008-05-09 11:32 ---
>> You know I'm still not sure if I can review patches outside df* (i.e. files
>> that do what flow.c did, but are not dataflow related), but if you think I
>> can... then patch is ok. :-)
>>
>>
>>   
>> 
> I had talked to david last time you raised this issue and he indicated 
> that he thought it was fine.
> If someone objects, the patch can be reversed. 
>
> Thanks
>
> Kenny
>
>
>   
commit as 135113.

2008-05-08  Kenneth Zadeck  <[EMAIL PROTECTED]>

PR middle-end/36117
* dce.c (deletable_insn_p): Do not delete calls if
df_in_progress.
(delete_unmarked_insns): When deleting a call, call
delete_unreachable_blocks.
* rtl.texi (RTL_CONST_CALL_P, RTL_PURE_CALL_P,
RTL_CONST_OR_PURE_CALL_P, RTL_LOOPING_CONST_OR_PURE_CALL_P): Fixed
doc.

Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 135089)
+++ doc/rtl.texi(working copy)
@@ -559,13 +559,36 @@ In either case GCC assumes these address
 perhaps with the help of base registers.
 Stored in the @code{unchanging} field and printed as @samp{/u}.

[EMAIL PROTECTED] CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] RTL_CONST_CALL_P
 @cindex @code{call_insn} and @samp{/u}
 @cindex @code{unchanging}, in @code{call_insn}
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P (@var{x})
-In a @code{call_insn}, @code{note}, or an @code{expr_list} for notes,
-indicates that the insn represents a call to a const or pure function.
-Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+const function.  Stored in the @code{unchanging} field and printed as
[EMAIL PROTECTED]/u}.
+
[EMAIL PROTECTED] RTL_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/i}
[EMAIL PROTECTED] @code{return_val}, in @code{call_insn}
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+pure function.  Stored in the @code{return_val} field and printed as
[EMAIL PROTECTED]/i}.
+
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/u} or @samp{/i}
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn}, true if @code{RTL_CONST_CALL_P} or
[EMAIL PROTECTED] is true.
+
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/c}
[EMAIL PROTECTED] @code{call}, in @code{call_insn}
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a possibly
+infinite looping call to a const or pure function.  Stored in the
[EMAIL PROTECTED] field and printed as @samp{/c}.  Only true if one of
[EMAIL PROTECTED] or @code{RTL_PURE_CALL_P} is true.

 @findex INSN_ANNULLED_BRANCH_P
 @cindex @code{jump_insn} and @samp{/u}
@@ -869,6 +892,9 @@ These are the fields to which the above 
 @item call
 In a @code{mem}, 1 means that the memory reference will not trap.

+In a @code{call}, 1 means that this pure or const call may possibly
+infinite loop.
+
 In an RTL dump, this flag is represented as @samp{/c}.

 @findex frame_related
@@ -938,6 +964,8 @@ known not to be a member of a structure,

 In @code{symbol_ref} expressions, 1 means the referenced symbol is weak.

+In @code{call} expressions, 1 means the call is pure.
+
 In an RTL dump, this flag is represented as @samp{/i}.

 @findex jump
@@ -967,8 +995,8 @@ instruction, 1 means an annulling branch
 In a @code{symbol_ref} expression, 1 means that this symbol addresses
 something in the per-function constant pool.

-In a @code{call_insn}, @code{note}, or an @code{expr_list} of notes,
-1 means that this instruction is a call to a const or pure function.
+In a @code{call_insn} 1 means that this instruction is a call to a const
+function.

 In an RTL dump, this flag is represented as @samp{/u}.

Index: dce.c
===
--- dce.c   (revision 135089)
+++ dce.c   (working copy)
@@ -99,11 +99,16 @@ deletable_insn_p (rtx insn, bool fast)
   rtx body, x;
   int i;

-  /* We can delete dead const or pure calls as long as they do not
- infinite loop and are not sibling calls.  The problem with
- sibling calls is that it is hard to see the result.  */
-  if (CALL_P (insn) 
+  if (CALL_P (insn)
+  /* We cannot delete calls inside of the recursive dce because
+this may cause basic

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #10 from zadeck at naturalbridge dot com  2008-05-09 11:58 
---
Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
 ICEs with 135041 -> 135057

bonzini at gnu dot org wrote:
> --- Comment #9 from bonzini at gnu dot org  2008-05-09 11:32 ---
> You know I'm still not sure if I can review patches outside df* (i.e. files
> that do what flow.c did, but are not dataflow related), but if you think I
> can... then patch is ok. :-)
>
>
>   
I had talked to david last time you raised this issue and he indicated 
that he thought it was fine.
If someone objects, the patch can be reversed. 

Thanks

Kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[bonzini at gnu dot org]

--- Comment #9 from bonzini at gnu dot org  2008-05-09 11:32 ---
You know I'm still not sure if I can review patches outside df* (i.e. files
that do what flow.c did, but are not dataflow related), but if you think I
can... then patch is ok. :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #8 from zadeck at naturalbridge dot com  2008-05-09 11:20 
---
Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
 ICEs with 135041 -> 135057

hp at gcc dot gnu dot org wrote:
> --- Comment #7 from hp at gcc dot gnu dot org  2008-05-09 10:16 ---
> (In reply to comment #5)
>
>   
>> I am testing this patch on x86.  But hp needs to test it on the cris 
>> before i will ask for approval.
>> 
>
> The patch works with no regressions; tested against 135097 for cris-elf and
> crisv32-elf.  Thanks again.
>
>
>   
Bonzini,

Would you review this patch?  I know i am missing the bug number on the 
changelog.

kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-05-09 10:16 ---
(In reply to comment #5)

> I am testing this patch on x86.  But hp needs to test it on the cris 
> before i will ask for approval.

The patch works with no regressions; tested against 135097 for cris-elf and
crisv32-elf.  Thanks again.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[hp at bitrange dot com]

--- Comment #6 from hp at bitrange dot com  2008-05-09 03:49 ---
Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
 ICEs with 135041 -> 135057

On Thu, 8 May 2008, zadeck at naturalbridge dot com wrote:
> I am testing this patch on x86.  But hp needs to test it on the cris
> before i will ask for approval.

For the record, anyone can test this target using
 and
.
Anyway, I'm doing it; I just made a baseline run.

The patch was malformed; applying it gave:
patching file doc/rtl.texi
patching file dce.c
Hunk #1 succeeded at 99 with fuzz 2.
Hunk #3 FAILED at 388.
1 out of 3 hunks FAILED -- saving rejects to file dce.c.rej

Apparently TABs had been expanded or something.  I applied the
rejected part manually and I'm testing the patch in the
attachment, which I hope is the same as what you have.

(I suggest attaching patches to the PR's by uploading them or
sending them as attachments; not cutnpasting into the web form
or whatever happened.  I sure hope the same doesn't happen to
this one!)

Thanks for your quick action!

brgds, H-PIndex: doc/rtl.texi
===
--- doc/rtl.texi(revision 135097)
+++ doc/rtl.texi(working copy)
@@ -559,14 +559,37 @@
 perhaps with the help of base registers.
 Stored in the @code{unchanging} field and printed as @samp{/u}.

[EMAIL PROTECTED] CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] RTL_CONST_CALL_P
 @cindex @code{call_insn} and @samp{/u}
 @cindex @code{unchanging}, in @code{call_insn}
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P (@var{x})
-In a @code{call_insn}, @code{note}, or an @code{expr_list} for notes,
-indicates that the insn represents a call to a const or pure function.
-Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+const function.  Stored in the @code{unchanging} field and printed as
[EMAIL PROTECTED]/u}.

[EMAIL PROTECTED] RTL_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/i}
[EMAIL PROTECTED] @code{return_val}, in @code{call_insn}
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+pure function.  Stored in the @code{return_val} field and printed as
[EMAIL PROTECTED]/i}.
+
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/u} or @samp{/i}
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn}, true if @code{RTL_CONST_CALL_P} or
[EMAIL PROTECTED] is true.
+
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/c}
[EMAIL PROTECTED] @code{call}, in @code{call_insn}
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a possibly
+infinite looping call to a const or pure function.  Stored in the
[EMAIL PROTECTED] field and printed as @samp{/c}.  Only true if one of
[EMAIL PROTECTED] or @code{RTL_PURE_CALL_P} is true.
+
 @findex INSN_ANNULLED_BRANCH_P
 @cindex @code{jump_insn} and @samp{/u}
 @cindex @code{call_insn} and @samp{/u}
@@ -869,6 +892,9 @@
 @item call
 In a @code{mem}, 1 means that the memory reference will not trap.

+In a @code{call}, 1 means that this pure or const call may possibly
+infinite loop.
+
 In an RTL dump, this flag is represented as @samp{/c}.

 @findex frame_related
@@ -938,6 +964,8 @@

 In @code{symbol_ref} expressions, 1 means the referenced symbol is weak.

+In @code{call} expressions, 1 means the call is pure.
+
 In an RTL dump, this flag is represented as @samp{/i}.

 @findex jump
@@ -967,8 +995,8 @@
 In a @code{symbol_ref} expression, 1 means that this symbol addresses
 something in the per-function constant pool.

-In a @code{call_insn}, @code{note}, or an @code{expr_list} of notes,
-1 means that this instruction is a call to a const or pure function.
+In a @code{call_insn} 1 means that this instruction is a call to a const
+function.

 In an RTL dump, this flag is represented as @samp{/u}.

Index: dce.c
===
--- dce.c   (revision 135097)
+++ dce.c   (working copy)
@@ -99,11 +99,16 @@
   rtx body, x;
   int i;

-  /* We can delete dead const or pure calls as long as they do not
- infinite loop and are not sibling calls.  The problem with
- sibling calls is that it is hard to see the result.  */
-  if (CALL_P (insn) 
+  if (CALL_P (insn)
+  /* We cannot delete calls inside of the recursive dce because
+this may cause basic blocks to be deleted and this messes up
+the rest of the stack of optimization passes.  */
+  && (!df_in_progress)
+  /* We cannot delete pure or const sibling calls because it is
+hard to see the result.  */
   && (!SIBLING_CALL_P (insn))
+  /* We can delete dead const or pure calls as lon

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #5 from zadeck at naturalbridge dot com  2008-05-08 23:04 
---
Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
 ICEs with 135041 -> 135057

steven at gcc dot gnu dot org wrote:
> --- Comment #4 from steven at gcc dot gnu dot org  2008-05-08 22:27 
> ---
> So I was looking at an older revision of dce.c.  There is this new check 
> before
> the !NONJUMP_INSN_P check now:
>
>   /* We can delete dead const or pure calls as long as they do not
>  infinite loop and are not sibling calls.  The problem with
>  sibling calls is that it is hard to see the result.  */
>   if (CALL_P (insn) 
>   && (!SIBLING_CALL_P (insn))
>   && (RTL_CONST_OR_PURE_CALL_P (insn)
>   && !RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)))
> return true;
>
> CALL_P is obviously true for this insn, and so is !SIBLING_CALL_P (there is no
> call_insn/j).  The "/u" flag means that RTL_CONST_OR_PURE_CALL_P is true for
> the insn.  The "/c" flag is clear, so RTL_LOOPING_CONST_OR_PURE_CALL_P is
> false.
>
> I don't know where RTL_CONST_OR_PURE_CALL_P is set.  But that's where I would
> look.
>
> [ I see that RTL_LOOPING_CONST_OR_PURE_CALL_P is not documented.  Kenny, can
> you please take care of that (and probably other necessary document updates
> following your patch)? ]
>
>
>   
The real problem is that this call was being deleted (and I believe that 
it should have been because it is const.) and this caused some blocks to 
become orphaned. 

In particular, the bug was that when this call was deleted, it also 
caused the exception edge out of that block to be deleted.   That caused 
some other blocks to be orphaned and that caused an assertion check.   
What this patch does is only allow pure and const calls to be deleted 
when dce is run as a stand alone pass because it is not possible to 
properly update the blocks from the call  to fast dce that happens as a 
side effect of running the lr problem. 

However, such calls (and there will be a lot more of them once more 
libcall code gets removed) are deleted by the use-def based dce that is 
run right before combine. 

I am testing this patch on x86.  But hp needs to test it on the cris 
before i will ask for approval.

kenny

2008-05-08  Kenneth Zadeck  <[EMAIL PROTECTED]>

* dce.c (deletable_insn_p): Do not delete calls if
df_in_progress.
(delete_unmarked_insns): When deleting a call, call
delete_unreachable_blocks.
* rtl.texi (RTL_CONST_CALL_P, RTL_PURE_CALL_P,
RTL_CONST_OR_PURE_CALL_P, RTL_LOOPING_CONST_OR_PURE_CALL_P): Fixed
doc.



Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 135089)
+++ doc/rtl.texi(working copy)
@@ -559,13 +559,36 @@ In either case GCC assumes these address
 perhaps with the help of base registers.
 Stored in the @code{unchanging} field and printed as @samp{/u}.

[EMAIL PROTECTED] CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] RTL_CONST_CALL_P
 @cindex @code{call_insn} and @samp{/u}
 @cindex @code{unchanging}, in @code{call_insn}
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P (@var{x})
-In a @code{call_insn}, @code{note}, or an @code{expr_list} for notes,
-indicates that the insn represents a call to a const or pure function.
-Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+const function.  Stored in the @code{unchanging} field and printed as
[EMAIL PROTECTED]/u}.
+
[EMAIL PROTECTED] RTL_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/i}
[EMAIL PROTECTED] @code{return_val}, in @code{call_insn}
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+pure function.  Stored in the @code{return_val} field and printed as
[EMAIL PROTECTED]/i}.
+
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/u} or @samp{/i}
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn}, true if @code{RTL_CONST_CALL_P} or
[EMAIL PROTECTED] is true.
+
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/c}
[EMAIL PROTECTED] @code{call}, in @code{call_insn}
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a possibly
+infinite looping call to a const or pure function.  Stored in the
[EMAIL PROTECTED] field and printed as @samp{/c}.  Only true if one of
[EMAIL PROTECTED] or @code{RTL_PURE_CALL_P} is true.

 @findex INSN_ANNULLED_BRANCH_P
 @cindex @code{jump_insn} and @samp{/u}
@@ -869,6 +892,9 @@ These are the fields to which the above 
 @item call
 In a @code{mem}, 1 means that the memory reference will not trap.

+In a @code{call}, 1 means that this pure or const call may possibly
+infinite loop.
+
 In an RTL dump, this flag is represented as @samp{/c}.

 @findex fra

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2008-05-08 22:27 ---
So I was looking at an older revision of dce.c.  There is this new check before
the !NONJUMP_INSN_P check now:

  /* We can delete dead const or pure calls as long as they do not
 infinite loop and are not sibling calls.  The problem with
 sibling calls is that it is hard to see the result.  */
  if (CALL_P (insn) 
  && (!SIBLING_CALL_P (insn))
  && (RTL_CONST_OR_PURE_CALL_P (insn)
  && !RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)))
return true;

CALL_P is obviously true for this insn, and so is !SIBLING_CALL_P (there is no
call_insn/j).  The "/u" flag means that RTL_CONST_OR_PURE_CALL_P is true for
the insn.  The "/c" flag is clear, so RTL_LOOPING_CONST_OR_PURE_CALL_P is
false.

I don't know where RTL_CONST_OR_PURE_CALL_P is set.  But that's where I would
look.

[ I see that RTL_LOOPING_CONST_OR_PURE_CALL_P is not documented.  Kenny, can
you please take care of that (and probably other necessary document updates
following your patch)? ]


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2008-05-08 22:16 ---
> I would have thought that since this can generate an exception and it is 
> a call insn that it would have been declared as a non deleteable insn by 
> dce.c:deleteable_insn_p.

deletable_insn_p() *will* declare this insn as non-deletable.  The insn is not
a NONJUMP_INSN_P so the very first check in deletable_insn_p() will already
make it return false.

So the problem is somewhere else.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-05-08 22:07 ---
(In reply to comment #1)
> In particular, i assume that the dce code is getting confused because it 
> does not see the call inside the parallel.
> 
> i do not know if this is a bug in the cris port or if there are other 
> cases that need to be added to dce.   This is for the rtl trained 
> professionals to determine.

This is a valid insn and the parallel-construct is certainly valid and not some
"burying". If some part of gcc doesn't look inside a parallel, then there¨s the
bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #1 from zadeck at naturalbridge dot com  2008-05-08 16:46 
---
Subject: Re:  [4.4 Regression] g++.dg/tree-ssa/pr19637.C
 ICEs with 135041 -> 135057

Here is the bug.   I do not know if this is just an illegal insn 
generated by a bad port or if we are missing something in the dce code.

the dce code is deleting insn 12:

(call_insn/u 12 11 47 2 
/home/zadeck/gcc36177/gcc/testsuite/g++.dg/opt/pr23714.C:11 (parallel [
(set (reg:SF 10 r10)
(call (mem:QI (reg/f:SI 31) [0 S1 A8])
(const_int 0 [0x0])))
(clobber (reg:SI 16 srp))
]) 224 {*expanded_call_value_non_v32} (expr_list:REG_EH_REGION 
(const_int 1 [0x1])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:SF 11 r11))
(expr_list:REG_DEP_TRUE (use (reg:SF 10 r10))
(nil

I would have thought that since this can generate an exception and it is 
a call insn that it would have been declared as a non deleteable insn by 
dce.c:deleteable_insn_p.  It is also clearly a jump insn even though we 
do not see it as such since it is buried in a parallel.

In particular, i assume that the dce code is getting confused because it 
does not see the call inside the parallel.

i do not know if this is a bug in the cris port or if there are other 
cases that need to be added to dce.   This is for the rtl trained 
professionals to determine.

kenny 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177