* Re: Problem in 'reload_cse_regno_equal_p'
@ 1998-04-29 15:21 Michael_Collison
0 siblings, 0 replies; 3+ messages in thread
From: Michael_Collison @ 1998-04-29 15:21 UTC (permalink / raw)
To: Joern Rennecke; +Cc: egcs, gcc2
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
Looks like you are correct. The problem 'smells' like a memory leak
somewhere. I stepped into 'reload_cse_regs' and watched 'reg_values' being
initialized to zero. Everything is fine after this loop. However a couple
of line later when the 'reload_obstack' gets allocated a specific entry in
'reg_values' (item 42 specifically) is non-zero.
Any ideas on where to start looking for this problem?
Mike
Joern Rennecke <amylaar@cygnus.co.uk> on 04/28/98 05:09:42 PM
To: Michael Collison/Iris
cc: egcs@cygnus.com, gcc2@cygnus.com
Subject: Re: Problem in 'reload_cse_regno_equal_p'
> It seems that the code for the 'for' loop is incorrect. Why is 'x' being
> set
> equal to 'XEXP(x,1)' everytime thru the loop? The code seems to be
assuming
> that it will hit a null pointer and things will be okay with the check at
> the next line. Is it okay for the code to assume this?
Yes, it is. Look at the comment in front of the reg_values declaration.
There should only be EXPR_LISTs of values. So the real question is,
where and why has the raw SYMBOL_REF been added?
[-- Attachment #2: att1.eml --]
[-- Type: message/rfc822, Size: 1772 bytes --]
Received: from capricorn.iris.com ([9.95.75.20]) by arista.iris.com (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id 852565F4.0074BA67; Tue, 28 Apr 1998 17:14:58 -0400
Received: from pasanda.cygnus.co.uk ([194.130.39.3])
by capricorn.iris.com (Lotus Domino Build 158)
with SMTP id 1998042817133122:1431 ;
Tue, 28 Apr 1998 17:13:31 -0400
Received: (qmail 4734 invoked by alias); 28 Apr 1998 21:10:32 -0000
Received: (qmail 4722 invoked from network); 28 Apr 1998 21:10:32 -0000
Received: from phal.cygnus.co.uk (amylaar@194.130.39.5)
by dns.cygnus.co.uk with SMTP; 28 Apr 1998 21:10:32 -0000
Received: (from amylaar@localhost)
by phal.cygnus.co.uk (8.8.8/8.8.8) id WAA14618;
Tue, 28 Apr 1998 22:09:42 +0100
From: Joern Rennecke <amylaar@cygnus.co.uk>
Message-Id: <199804282109.WAA14618@phal.cygnus.co.uk>
Subject: Re: Problem in 'reload_cse_regno_equal_p'
In-Reply-To: <852565F4.005648AF.00@arista.iris.com> from "Michael_Collison@iris.com" at "Apr 28, 98 12:11:08 pm"
To: Michael_Collison@iris.com
Date: Tue, 28 Apr 1998 22:09:42 +0100 (BST)
Cc: egcs@cygnus.com, gcc2@cygnus.com
X-Mailer: ELM [version 2.4ME+ PL37 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> It seems that the code for the 'for' loop is incorrect. Why is 'x' being
> set
> equal to 'XEXP(x,1)' everytime thru the loop? The code seems to be assuming
> that it will hit a null pointer and things will be okay with the check at
> the next line. Is it okay for the code to assume this?
Yes, it is. Look at the comment in front of the reg_values declaration.
There should only be EXPR_LISTs of values. So the real question is,
where and why has the raw SYMBOL_REF been added?
UmVjZWl2ZWQ6IGZyb20gY2Fwcmljb3JuLmlyaXMuY29tIChbOS45NS43NS4y
MF0pIGJ5IGFyaXN0YS5pcmlzLmNvbSAoTG90dXMgU01UUCBNVEEgdjQuNi4x
ICAoNTY5LjIgMi02LTE5OTgpKSB3aXRoIFNNVFAgaWQgODUyNTY1RjQuMDA3
NEJBNjc7IFR1ZSwgMjggQXByIDE5OTggMTc6MTQ6NTggLTA0MDANClJlY2Vp
dmVkOiBmcm9tIHBhc2FuZGEuY3lnbnVzLmNvLnVrIChbMTk0LjEzMC4zOS4z
XSkNCiAgICAgICAgICBieSBjYXByaWNvcm4uaXJpcy5jb20gKExvdHVzIERv
bWlubyBCdWlsZCAxNTgpDQogICAgICAgICAgd2l0aCBTTVRQIGlkIDE5OTgw
NDI4MTcxMzMxMjI6MTQzMSA7DQogICAgICAgICAgVHVlLCAyOCBBcHIgMTk5
OCAxNzoxMzozMSAtMDQwMCANClJlY2VpdmVkOiAocW1haWwgNDczNCBpbnZv
a2VkIGJ5IGFsaWFzKTsgMjggQXByIDE5OTggMjE6MTA6MzIgLTAwMDANClJl
Y2VpdmVkOiAocW1haWwgNDcyMiBpbnZva2VkIGZyb20gbmV0d29yayk7IDI4
IEFwciAxOTk4IDIxOjEwOjMyIC0wMDAwDQpSZWNlaXZlZDogZnJvbSBwaGFs
LmN5Z251cy5jby51ayAoYW15bGFhckAxOTQuMTMwLjM5LjUpDQogIGJ5IGRu
cy5jeWdudXMuY28udWsgd2l0aCBTTVRQOyAyOCBBcHIgMTk5OCAyMToxMDoz
MiAtMDAwMA0KUmVjZWl2ZWQ6IChmcm9tIGFteWxhYXJAbG9jYWxob3N0KQ0K
CWJ5IHBoYWwuY3lnbnVzLmNvLnVrICg4LjguOC84LjguOCkgaWQgV0FBMTQ2
MTg7DQoJVHVlLCAyOCBBcHIgMTk5OCAyMjowOTo0MiArMDEwMA0KRnJvbTog
Sm9lcm4gUmVubmVja2UgPGFteWxhYXJAY3lnbnVzLmNvLnVrPg0KTWVzc2Fn
ZS1JZDogPDE5OTgwNDI4MjEwOS5XQUExNDYxOEBwaGFsLmN5Z251cy5jby51
az4NClN1YmplY3Q6IFJlOiBQcm9ibGVtIGluICdyZWxvYWRfY3NlX3JlZ25v
X2VxdWFsX3AnDQpJbi1SZXBseS1UbzogPDg1MjU2NUY0LjAwNTY0OEFGLjAw
QGFyaXN0YS5pcmlzLmNvbT4gZnJvbSAiTWljaGFlbF9Db2xsaXNvbkBpcmlz
LmNvbSIgYXQgIkFwciAyOCwgOTggMTI6MTE6MDggcG0iDQpUbzogTWljaGFl
bF9Db2xsaXNvbkBpcmlzLmNvbQ0KRGF0ZTogVHVlLCAyOCBBcHIgMTk5OCAy
MjowOTo0MiArMDEwMCAoQlNUKQ0KQ2M6IGVnY3NAY3lnbnVzLmNvbSwgZ2Nj
MkBjeWdudXMuY29tDQpYLU1haWxlcjogRUxNIFt2ZXJzaW9uIDIuNE1FKyBQ
TDM3ICgyNSldDQpNSU1FLVZlcnNpb246IDEuMA0KQ29udGVudC1UeXBlOiB0
ZXh0L3BsYWluOyBjaGFyc2V0PVVTLUFTQ0lJDQpDb250ZW50LVRyYW5zZmVy
LUVuY29kaW5nOiA3Yml0DQoNCj4gSXQgc2VlbXMgdGhhdCB0aGUgY29kZSBm
b3IgdGhlICdmb3InIGxvb3AgaXMgaW5jb3JyZWN0LiBXaHkgaXMgJ3gnIGJl
aW5nDQo+IHNldA0KPiBlcXVhbCB0byAnWEVYUCh4LDEpJyBldmVyeXRpbWUg
dGhydSB0aGUgbG9vcD8gVGhlIGNvZGUgc2VlbXMgdG8gYmUgYXNzdW1pbmcN
Cj4gdGhhdCBpdCB3aWxsIGhpdCBhIG51bGwgcG9pbnRlciBhbmQgdGhpbmdz
IHdpbGwgYmUgb2theSB3aXRoIHRoZSBjaGVjayBhdA0KPiB0aGUgbmV4dCBs
aW5lLiBJcyBpdCBva2F5IGZvciB0aGUgY29kZSB0byBhc3N1bWUgdGhpcz8N
Cg0KWWVzLCBpdCBpcy4gIExvb2sgYXQgdGhlIGNvbW1lbnQgaW4gZnJvbnQg
b2YgdGhlIHJlZ192YWx1ZXMgZGVjbGFyYXRpb24uDQpUaGVyZSBzaG91bGQg
b25seSBiZSBFWFBSX0xJU1RzIG9mIHZhbHVlcy4gIFNvIHRoZSByZWFsIHF1
ZXN0aW9uIGlzLA0Kd2hlcmUgYW5kIHdoeSBoYXMgdGhlIHJhdyBTWU1CT0xf
UkVGIGJlZW4gYWRkZWQ/DQo=
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problem in 'reload_cse_regno_equal_p'
1998-04-28 11:00 Michael_Collison
@ 1998-04-28 14:10 ` Joern Rennecke
0 siblings, 0 replies; 3+ messages in thread
From: Joern Rennecke @ 1998-04-28 14:10 UTC (permalink / raw)
To: Michael_Collison; +Cc: egcs, gcc2
> It seems that the code for the 'for' loop is incorrect. Why is 'x' being
> set
> equal to 'XEXP(x,1)' everytime thru the loop? The code seems to be assuming
> that it will hit a null pointer and things will be okay with the check at
> the next line. Is it okay for the code to assume this?
Yes, it is. Look at the comment in front of the reg_values declaration.
There should only be EXPR_LISTs of values. So the real question is,
where and why has the raw SYMBOL_REF been added?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Problem in 'reload_cse_regno_equal_p'
@ 1998-04-28 11:00 Michael_Collison
1998-04-28 14:10 ` Joern Rennecke
0 siblings, 1 reply; 3+ messages in thread
From: Michael_Collison @ 1998-04-28 11:00 UTC (permalink / raw)
To: egcs; +Cc: gcc2
I have built both gcc-2.8.1 and egc-1.0.2 for the target 'dsp16xx' a DSP
processor.
When I compile with optimization I get an access violation in the function
'reload_cse_regno_equal_p' which is shown below.
static int
reload_cse_regno_equal_p (regno, val, mode)
int regno;
rtx val;
enum machine_mode mode;
{
rtx x;
if (val == 0)
return 0;
for (x = reg_values[regno]; x; x = XEXP (x, 1))
if (XEXP (x, 0) != 0
&& rtx_equal_p (XEXP (x, 0), val)
&& (GET_CODE (val) != CONST_INT
|| mode == GET_MODE (x)
|| (GET_MODE_SIZE (mode) < GET_MODE_SIZE (GET_MODE (x))
/* On a big endian machine if the value spans more than
one register then this register holds the high part of
it and we can't use it.
??? We should also compare with the high part of the
value. */
&& !(WORDS_BIG_ENDIAN
&& HARD_REGNO_NREGS (regno, GET_MODE (x)) > 1)
&& TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode),
GET_MODE_BITSIZE (GET_MODE (x))))))
return 1;
return 0;
}
The stack trace from gdb is shown below:
(gdb) where
#0 reload_cse_regno_equal_p (regno=42, val=0x1cb5e0, mode=QImode)
at ../reload1.c:8056
#1 0x139d98 in reload_cse_simplify_operands (insn=0x1b3e58)
at ../reload1.c:8326
#2 0x138cb8 in reload_cse_regs (first=0x1b3b70) at ../reload1.c:7960
#3 0x4ddd8 in rest_of_compilation (decl=0x1cc2d0) at ../toplev.c:3501
#4 0x39aac in finish_function (nested=0) at ../c-decl.c:7100
#5 0x27c2c in yyparse () at c-parse.y:319
#6 0x4bdf8 in compile_file (name=0xeffff441 "f_play2.i") at
../toplev.c:2484
#7 0x4f2fc in main (argc=3, argv=0xeffff2cc, envp=0xeffff2dc)
at ../toplev.c:4353
(gdb)
The insn in function 'reload_cse_simplify_operands' is:
insn 8 6 10 (set (reg:QI 9 r0)
(symbol_ref:QI ("bg_flags"))) 48 {match_movqi2} (nil)
(expr_list:REG_EQUAL (symbol_ref:QI ("bg_flags"))
(nil)))
In function 'reload_cse_regno_equal_p' the variable 'x' is initialized to
x = reg_values[42] = (set (reg:QI 9 r0)
(symbol_ref:QI ("bg_flags")))
Now the second time through the loop 'x' = (symbol_ref:QI ("bg_flags"))
The third time thru the loop 'x' is assigned a bad pointer (because
SYMBOL_REF's only have
one parameter, operand 0). Now XEXP(x,0) is non null (but a bad pointer)
and a memory exception occurs.
It seems that the code for the 'for' loop is incorrect. Why is 'x' being
set
equal to 'XEXP(x,1)' everytime thru the loop? The code seems to be assuming
that it will hit a null pointer and things will be okay with the check at
the next line. Is it okay for the code to assume this?
Michael Collison
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1998-04-29 15:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-04-29 15:21 Problem in 'reload_cse_regno_equal_p' Michael_Collison
-- strict thread matches above, loose matches on Subject: below --
1998-04-28 11:00 Michael_Collison
1998-04-28 14:10 ` Joern Rennecke
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).