This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: More CFG branch merge lossage
- From: Jan Hubicka <jh at suse dot cz>
- To: Richard dot Earnshaw at buzzard dot freeserve dot co dot uk
- Cc: Jan Hubicka <jh at suse dot cz>, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, rth at cygnus dot com
- Date: Sat, 9 Mar 2002 23:31:30 +0100
- Subject: Re: More CFG branch merge lossage
- References: <200203091615.g29GF5O21515@buzzard.buzzard.freeserve.co.uk>
>
> Jan,
>
> Until reload is completed, the two asignement expressions are handled as
> if_then_else expressions. After reload these are split into conditional
> execution insns. The new feature seems to be that the false arms of both
> expressions are being merged and that this is sufficient to confuse the
> conditional-life tracking that we perform.
There appears to be verify_flow-info crashes even on platforms w/o conditional
execution so I guess I've managed to do something wrong there. As I am
on the way till monday, I can't investigate the problems in detail, I would
propose the attached patch to avoid liveness updating after crossjumping
until I can test it on more platforms.
It is probably good idea to first stabilize the libjava isses and investigate
the crossjumping then.
Is it possible to check whether it avoids the problem?
If the patch gets approved, would be possible to install it?
Sat Mar 9 23:29:55 CET 2002 Jan Hubicka <jH@suse.cz>
* toplev.c (rest_of_compilation): Do cleanup_cfg after crossjumping.
Index: toplev.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/toplev.c,v
retrieving revision 1.588
diff -c -3 -p -r1.588 toplev.c
*** toplev.c 2002/03/08 20:32:15 1.588
--- toplev.c 2002/03/09 22:27:14
*************** rest_of_compilation (decl)
*** 3270,3277 ****
if (optimize)
{
life_analysis (insns, rtl_dump_file, PROP_FINAL);
- cleanup_cfg (CLEANUP_EXPENSIVE | CLEANUP_CROSSJUMP | CLEANUP_UPDATE_LIFE);
/* This is kind of a heuristic. We need to run combine_stack_adjustments
even for machines with possibly nonzero RETURN_POPS_ARGS
--- 3290,3297 ----
if (optimize)
{
+ cleanup_cfg (CLEANUP_EXPENSIVE | CLEANUP_CROSSJUMP);
life_analysis (insns, rtl_dump_file, PROP_FINAL);
/* This is kind of a heuristic. We need to run combine_stack_adjustments
even for machines with possibly nonzero RETURN_POPS_ARGS