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]

Pb with clearing const_tiny_rtx in clear_const_double_mem



Hello,

The CVS log for revision 1.185 of varasm.c reads :

        (clear_const_double_mem): Clear const_tiny_rtx too.

This is related to :

  http://gcc.gnu.org/ml/gcc-patches/2001-07/msg02061.html

which says :

 [...] If these rtxes are in use in an outer function, then we'll assign new
 memories to them in reload.

It unfortunately appears that we can get in trouble before having the chance
to do that in some cases, as illustrated by the following test case :

     void foo (void)
     {
       float f1 = 1.0;

       void bar (void)
	 {
	 }

       float f2 = 1.0;
       float f3 = 2.0;
     }

Using trunk sources (2001.08.23) on pa32-hpux, the compiler enters an infinite
loop because of CONST_DOUBLE_CHAIN (const_double_chain) == const_double_chain
at some point.

AFAICS, the basic scenario is :

- 1.0, as CONST1_RTX(SFmode), gets into the const_double_chain via 
  force_const_mem while processing f1 for foo

- The processing of bar within foo leads to clear_const_double_mem(),
  which clears the MEM attached to CONST1_RTX(SFmode), via rest_of_compilation,

- 1.0, as CONST1_RTX(SFmode), gets again into the const_double_chain while
  processing f2 for foo because the attached MEM has been cleared, though
  the node is still chained actually,

- Walking the chain for the processing of f3 runs infinitely.

I'm unsure what the best approach to fix is.  An advice would be greatly
appreciated then :)

Avoiding to clear the const_tiny_rtxes in a nested context works fine for this
case but might not be the right thing to do in general. I'm unclear as to what
the initial problem was.

Thanks in advance for your help,

Kind Regards,

Olivier



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