This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ICE in bitmap routines with LRA and inline assembly language


Hi,

It appears that the current program point was not incremented when an early 
clobber pseudo register was marked as dead.

The patch below solves the problem for both testcases. I'll post the patch 
along with a testcase to gcc-patches mailing list after running 
the regression on, at least, x86_64-linux-gnu. 

Regards,
Robert

diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
index f34517d..f9a0b45 100644
--- a/gcc/lra-lives.c
+++ b/gcc/lra-lives.c
@@ -680,9 +680,9 @@ process_bb_lives (basic_block bb, int &curr_point)
       /* Mark early clobber outputs dead.  */
       for (reg = curr_id->regs; reg != NULL; reg = reg->next)
 	if (reg->type == OP_OUT && reg->early_clobber && ! reg->subreg_p)
-	  need_curr_point_incr = mark_regno_dead (reg->regno,
-						  reg->biggest_mode,
-						  curr_point);
+	  need_curr_point_incr |= mark_regno_dead (reg->regno,
+			 			   reg->biggest_mode,
+						   curr_point);
 
       for (reg = curr_static_id->hard_regs; reg != NULL; reg = reg->next)
 	if (reg->type == OP_OUT && reg->early_clobber && ! reg->subreg_p)



> -----Original Message-----
> From: Steve Ellcey
> Sent: 05 September 2014 22:49
> To: Vladimir Makarov
> Cc: Robert Suchanek
> Subject: Re: ICE in bitmap routines with LRA and inline assembly language
> 
> On Thu, 2014-09-04 at 20:32 -0400, Vladimir Makarov wrote:
> > On 2014-09-04, 2:04 PM, Steve Ellcey wrote:
> > >
> > > I was wondering if anyone has seen this bug involving LRA and inline
> > > assembly code.  On MIPS, I am getting the attached ICE.  Somehow
> > > the 'first' pointer in the live_reload_and_inheritance_pseudos bitmap
> > > structure is either getting clobbered or is not being correctly
> > > initialized to begin with.  I am not sure which yet.
> > >
> > >
> >
> > Sorry, I am on vacation now.  I'll investigate this next week.
> 
> Here is some more information I found while investigating this problem,
> maybe it will help when you get back.
> 
> I see the bug with -O1, but not with -O0 and if I add
> '-fno-forward-propagate -fno-if-conversion' to -O1, then I can also
> make the ICE go away.
> 
> I also have a second (similar) test case:
> 
> int foo(const unsigned char* a, const unsigned char* b) {
>    int count;
>    int tmp;
>    __asm__ volatile("mult $zero, $zero\n\t"
>                     "mflo %[count]\n\t" : [tmp]"=&r"(tmp),
> [count]"=&r"(count) :
>  [a]"r"(a), [b]"r"(b) : "memory", "hi" , "lo");
>    return count;
> }
> 
> The interesting thing I noticed is that 'tmp' is not used in the inline
> assembly code (because I cut the test case down).  But if I remove 'tmp'
> from the output list completely, the test case compiles.  Likewise,
> if I leave it in but put 'count' in front of 'tmp' in the output list
> then the test case also compiles.
> 
> So I think something, maybe forward propagation, maybe if-conversion,
> maybe LRA, is not looping through all the elements in the output list
> of an inline assembly language instruction when calculating register
> uses or dependencies or clobbers.
> 
> Steve Ellcey
> sellcey@mips.com
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]