public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/3783
@ 2001-09-04 13:36 Jessica Han
0 siblings, 0 replies; 2+ messages in thread
From: Jessica Han @ 2001-09-04 13:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/3783; it has been noted by GNATS.
From: "Jessica Han" <jessica@cup.hp.com>
To: <wilson@redhat.com>, <gcc-gnats@gcc.gnu.org>,
<gcc-prs@gcc.gnu.org>, <linux-ia64@linuxia64.org>,
<davidm@hpl.hp.com>, <davidm@hpl.hp.com>, <gcc-bugs@gcc.gnu.org>,
<nobody@gcc.gnu.org>
Cc:
Subject: Re: optimization/3783
Date: Tue, 4 Sep 2001 13:33:04 -0700
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%26pr=3783%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
* Re: optimization/3783
@ 2001-08-01 15:06 Steve Ellcey
0 siblings, 0 replies; 2+ messages in thread
From: Steve Ellcey @ 2001-08-01 15:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/3783; it has been noted by GNATS.
From: Steve Ellcey <sje@cup.hp.com>
To: wilson@redhat.com, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
linux-ia64@linuxia64.org, davidm@hpl.hp.com, davidm@hpl.hp.com,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:
Subject: Re: optimization/3783
Date: Wed, 01 Aug 2001 15:02:40 -0700
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&pr=3783&database=gcc
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-09-04 13:36 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-04 13:36 optimization/3783 Jessica Han
-- strict thread matches above, loose matches on Subject: below --
2001-08-01 15:06 optimization/3783 Steve Ellcey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).