This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Pb with clearing const_tiny_rtx in clear_const_double_mem
- To: rth at redhat dot com
- Subject: Pb with clearing const_tiny_rtx in clear_const_double_mem
- From: Olivier Hainque <hainque at act-europe dot fr>
- Date: Fri, 24 Aug 2001 15:53:03 +0200
- Cc: gcc at gcc dot gnu dot org
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