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).