This is the mail archive of the gcc-patches@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: A patch for gcc.c-torture/execute/980505-1.c



  In message <m0yjwcQ-00026AC@ocean.lucon.org>you write:
  > Hi,
  > 
  > This patch seems to fix gcc.c-torture/execute/980505-1.c. But I
  > don't know if it is 100% correct.
  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ---
  > Wed Jun 10 18:53:50 1998  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* cse.c (delete_trivially_dead_insns): Update REG_NOTES when
  > 	delete a insn.
First, it would have helped if you included some information about
exactly what problem you were trying to solve.  You already have this
information since you're working on the bug.  I don't, so I had to
go wandering through the archives to get my original analysis of
this bug.

Please please please please, include analysis with patches since you
already have that information.  Otherwise I waste my time having to
either find an analysis of the problem or recreate it.  I've asked
you to do this many times in the past.  In the future you may find that
I'll ignore your patches if you do not provide the information I need
to properly evaluate them.

Thanks for including the testcase reference though.  From the testcase
I was able to find enough state on the problem to find a relavent
message in the egcs archives.


The problem only occurs with libcalls, so you need not try and fix
reg notes unless you find a deleted insn inside a libcall block.

The existing code tracks when we are in a libcall block, so you should
be able to check those varaibles before trying to fix the notes.

All the searching is unnecessary.  We only need to fix the insn with
the REG_RETVAL note.  So, keep track of what insn had the last
REG_RETVAL note and perform substitutions on that insn only.  Clear
the variable holding the insn with the last REG_RETVAL note anytime
you pass a REG_LIBCALL note.

I'm also not sure you can depend on the insns being single sets; just
in case can you have the code call abort if we deleted an insn within
a libcall that was not a single_set?  That way we'll know if the
situation ever arises instead of silently generating incorrect code.

Thanks,
jeff






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