public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
* [Linux-ia64] Re: optimization/3783
@ 2001-08-01 22:02 Steve Ellcey
  0 siblings, 0 replies; 2+ messages in thread
From: Steve Ellcey @ 2001-08-01 22:02 UTC (permalink / raw)
  To: linux-ia64

FYI:  I have spent a little time looking at this bug, I haven't got a
fix but I did create a smaller test program that I am including in this
mail.  Running it on HP-UX IA64 it looks like the optimizer is going
into an infinite loop in canon_rtx because one of the entries (REG 351
in my case) is set to be a plus RTX of REG 351 and CONST 1.  How that
self-referential access got in there, I don't know but it seems to be
the cause of the problem.  Anyway I thought I would just send off what
I know and the smaller test case before going off on some vacation.

Steve Ellcey
sje@cup.hp.com

extern struct buffer_headX *udf_read_taggedX(unsigned short *);
#pragma pack(1)
typedef struct {
        unsigned int extLength;
        unsigned int extLocation;
} extent_adX;
#pragma pack()
struct super_blockX {
        unsigned long s_blocksize;
        unsigned char s_blocksize_bits;
        unsigned char s_dirt;
};
struct buffer_headX {
        struct buffer_head *b_next;
        unsigned long b_blocknr;
        unsigned short b_size;
        unsigned short b_list;
};
static void
udf_load_logicalvolintX(struct super_blockX *sb, extent_adX loc)
{
        struct buffer_headX *bh = ((void *)0);
        unsigned short ident;
        while ((bh = udf_read_taggedX(&ident)) && loc.extLength > 0)
        {
                loc.extLength -= sb->s_blocksize;
                loc.extLocation ++;
        }
}

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr783&database=gcc





^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Linux-ia64] Re: optimization/3783
@ 2001-09-04 20:33 Jessica Han
  0 siblings, 0 replies; 2+ messages in thread
From: Jessica Han @ 2001-09-04 20:33 UTC (permalink / raw)
  To: linux-ia64

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%26pr783%26database=gcc
 It seems this problem occurs only when we have POST_INC addressing mode.
With POST_INC, for rtl "set reg351, reg328 PLUS 1", attempt_auto_inc
(flow.c) will change reg328 into reg351 as an operand of POST_INC, but leave
the "PLUS" as is. Thus the RTL becomes "set reg 351, reg351 PLUS 1" and
causes the infinite recursion in canon_rtx. If I substitute "reg328 PLUS 1"
with POST_INC reg351, the testcase attached in GNAT will pass at compile
time.
   The fix I did is in attempt_auto_inc:
  <       validate_change (incr, &XEXP (y, opnum), q, 1);
  ---
  >       validate_change (incr, &y, inc, 1);
Is this the right thing to do? Thanks.




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-09-04 20:33 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-04 20:33 [Linux-ia64] Re: optimization/3783 Jessica Han
  -- strict thread matches above, loose matches on Subject: below --
2001-08-01 22:02 Steve Ellcey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox