This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] combine: RTX changes depending on presence of DEBUG_INSN
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Mikael Pettersson <mikpe at it dot uu dot se>
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 27 May 2010 20:48:12 +0200
- Subject: Re: [PATCH] combine: RTX changes depending on presence of DEBUG_INSN
- References: <20100527173330.GA9663@bart> <19454.48205.648850.113895@pilspetsen.it.uu.se>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, May 27, 2010 at 08:39:09PM +0200, Mikael Pettersson wrote:
> Andreas Krebbel writes:
> > in combine.c (propagate_for_debug) we currently have code which might
> > change the rtx depending on the presence of a DEBUG_INSN. This
> > currently causes a bootstrap comparison failure on S/390.
> >
> > ...
> > if (DEBUG_INSN_P (insn))
> > {
> > if (first_p)
> > {
> > src = make_compound_operation (src, SET);
> > first_p = false;
> > }
> > ...
> >
> > We should either not do it at all or always do it (e.g. in
> > try_combine). The attached patch simply removes the 'if (first_p)'
> > block and fixes the comparison failure.
>
> This block was introduced in r159600, which is known to have broken
> bootstrap on sparc64 and arm by causing stage 2/3 comparison failures.
> See PR44255.
>
> Other parts of r159600 have been proven innocent, and your patch reverts
> the last part which (by exclusion) has to be the cause of the breakage.
>
> Should stage 2 and 3 differ wrt DEBUG_INSNs?
DEBUG_INSNs don't (well, should not) affect code generation and they don't
correspond to any generated code, they solely affect debug info generation.
Stage 2 is built with -g0, stage 3 is built with -g, so only the latter has
DEBUG_INSNs and the bootstrap comparison is done on stripped objects,
so it also checks that -g/-g0 doesn't effect code generation (like
-fcompare-debug option does).
The above should just result in a different expression to be substituted in
DEBUG_INSNs, so it shouldn't affect generated code.
So, please either provide preprocessed testcase that fails with
-fcompare-debug in a cross compiler (as I've asked for in the PR), so that I
can debug this myself, or try to find out why and how it affects generated
code.
In the AUTO_INC_DEC case I think there is a bug, that if (first_p) should
not just update src, but also update p.to, but that still doesn't explain
why there are -fcompare-debug differences.
Jakub