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: RFA: final.c:final_scan_insn: Delete notes when reinserting test insns. +testcase.


> Date: Sun, 11 Jun 2000 13:36:04 -0600
> From: Jeffrey A Law <law@cygnus.com>

>   In message <200006102111.XAA09484@ignucius.axis.se>you write:
>   > Bug appears as:
>   > foo.ii:320: Internal compiler error in `final_scan_insn', at
>   > foo.ii:320: final.c:2203
>   > foo.ii:320: Please submit a full bug report.
>   > (etc.)
>   > 
>   > Not for any target in CVS for the testcase below, though.
>   > 
>   > Some targets have cc0-user insns that return NULL as output template
>   > when cc0 flags are not to taste, like when the overflow bit is unusable.
>   > This is supposed to cause the pseudo-deleted cc0-setter test insn to be
>   > "reinserted".  This is implemented by final_scan_insn returning the
>   > cc0-setter as the return value (presumably the next insn) when the
>   > cc0-user insn has a NULL template.
>   > 
>   > Unfortunately the code overlooked that the cc0-setter can be on the other
>   > side of a block note.  I'm not sure if that happens for valid reasons, but
>   > it happens.  (If it's not valid, then this patch should be transmogrified
>   > into a sanity check.)  The cautiously guarded block_depth variable got out
>   > of sync, with a later abort.  A *.27.dbr (last generated dump)
>   > snippet showing the straddled (double) block-end:
> This is wrong.
> 
> On a cc0 machine, the setter & user must be adjacent -- nothing can come
> between the setter & user.  You need to find out why you've got notes and
> other stuff between the setter & user.

It seems your statement is wrong.

Notes (but nothing else) are allowed in between the cc0 setter
and user insns.  Source and manual agree.  From md.texi, node
Jump Patterns:

 For machines that use @code{(cc0)}, the set
 and use of the condition code must be adjacent (separated only by
 @code{note} insns) allowing flags in @code{cc_status} to be used.

And in combine.c (like can_combine_p) and elsewhere (like
next_cc0_user) search for HAVE_cc0; next_nonnote_insn is used
to check adjacency of cc0 setter and user.

BTW, the fatal notes appear in combine.  (There were only notes,
no "other stuff".)  It seems to be valid that they are placed as
they are; the block notes are the result of inlining, and the
instructions nearby have opportunity for combination over the
border.  Some of those set cc0, others use cc0.

The same combine opportunities do not arise for v850 for that
test-case, and no other target has the HAVE_cc0 &&
may-return-NULL-for-output-pattern characteristics.

brgds, H-P

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