This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/6233: simple loop miscompilation
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Richard Henderson <rth at redhat dot com>, gcc-gnats at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 10 Apr 2002 09:30:14 +0930
- Subject: Re: optimization/6233: simple loop miscompilation
- References: <20020409042706.21456.qmail@bubble.local> <20020409112735.GM1042@bubble.sa.bigpond.net.au> <20020409094157.A8596@redhat.com>
On Tue, Apr 09, 2002 at 09:41:57AM -0700, Richard Henderson wrote:
> On Tue, Apr 09, 2002 at 08:57:35PM +0930, Alan Modra wrote:
> > * alias.c (nonlocal_referenced_p): Make global.
> > * tree.h (nonlocal_referenced_p): Declare.
> > * loop.c (prescan_loop): Set has_nonconst_call for pure functions.
>
> This is almost certainly wrong. It sounds more like either
> we've mis-categorized the function to begin with
No, initial rtl looks OK (to my untrained eye)
(call_insn 21 9 22 (call_placeholder 16 10 0 0 (call_insn/u 16 0 18 (set (reg:SI 0 eax)
(call (mem:QI (symbol_ref:SI ("is_end_of_statement")) [0 S1 A8])
(const_int 0 [0x0]))) -1 (nil)
(insn_list:REG_LIBCALL 18 (expr_list:REG_EH_REGION (const_int -1 [0xffffffff])
(nil)))
(expr_list (use (mem:BLK (scratch) [0 A8]))
(nil)))) -1 (nil)
(nil)
(nil))
>, or loop is
> failing to note the USE of memory in CALL_INSN_FUNCTION_USAGE.
Yes, that's what I was using nonlocal_referenced_p to find.
Sledgehammer to crack a nut? Should I instead specifically search
for the use_mem_scratch?
--
Alan Modra
IBM OzLabs - Linux Technology Centre