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]

Re: CSE bug (gcc.c-torture/execute/980605-1.c)



  In message <199807061607.JAA30419@dm.cobaltmicro.com>you write:
  > 
  > Don't fear, Jeff wrote a more complete fix and checked it in last
  > night.  But I believe you are looking at a different bug.
  > 
  > However I want to mention that I think fundamentally the problem
  > exposed with this CSE bug still exists generically, even with Jeff's
  > fix.  I do not believe that everyone in the compiler who rewrites
  > insns within' a libcall block properly update the REG_EQUAL notes at
  > the end.  I could argue that every call to validate_change() should
  > check for this situation, but even then all possible cases won't be
  > handled.
This should only be an issue in cse/cse2 (and thus the passes that
run between cse & cse2.

We know gcse does the wrong thing (and I've got a patch for it from
Joern that I'll be looking at shortly).




  > Jeff, when I showed my version of the patch to a few people I was
  > cautioned that I might have broken the SH target because it does very
  > strange things with libcalls.  Did you check to see if your version of
  > the changes have this effect?  Essentially I believe they make a
  > multiply or some other insn which clobbers a lot of hard registers
  > look like a libcall so that CSE can still occur in their presence.
The sh's port's handling of libcalls is broken.  Interestingly enough
we've got a nice little thread going inside Cygnus on the sh port's
libcall code and how to fix it.

jeff


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