This is the mail archive of the gcc-bugs@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]

[Bug rtl-optimization/39607] [4.5 Regression] Revision 145309 caused ICE in emit_swap_insn, at reg-stack.c:827


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39607

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |steven at gcc dot gnu.org
         Resolution|FIXED                       |

--- Comment #8 from Steven Bosscher <steven at gcc dot gnu.org> 2012-10-28 11:41:45 UTC ---
Open again since r192440.

The real problem here is this assert:

  if (hard_regno == -1)
    { 
      /* Something failed if the register wasn't on the stack.  If we had
         malformed asms, we zapped the instruction itself, but that didn't
         produce the same pattern of register sets as before.  To prevent
         further failure, adjust REGSTACK to include REG at TOP.  */
      gcc_assert (any_malformed_asm);
      regstack->reg[++regstack->top] = REGNO (reg);
      return;
    }

If IRA uses DF_LIVE, the assert may trigger if there is a use of a stack 
register that is not initialized. The following C test case (derived from
gfortran.dg/pr40587.f) shows the problem:

void
test (int *i, double *r, double *result)
{
  int i2;
  double r2;

  i2 = *i;
  if (i == 0)
    r2 = *r;
  else
    error ();
  *result = r2;
}

r2 is used uninitialized if the path through "error()" is taken. When
using DF_LR, r2 is made live through that path all the way up to the
function entry, but when using DF_LIVE r2 is only live in the trace
from "r2 = *r" to "*result = r2". 

With IRA using DF_LIVE and removing the assert, the result is an fstpl
instruction that triggers an FP-stack underflow.  IMHO that would be
a reasonable behavior for this kind of problem.


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