public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/52731] New: internal compiler error: in ia64_st_address_bypass_p, at config/ia64/ia64.c:9357
@ 2012-03-26 20:12 awl at passagen dot se
2013-11-19 13:15 ` [Bug target/52731] " kirill.yukhin at intel dot com
0 siblings, 1 reply; 2+ messages in thread
From: awl at passagen dot se @ 2012-03-26 20:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52731
Bug #: 52731
Summary: internal compiler error: in ia64_st_address_bypass_p,
at config/ia64/ia64.c:9357
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: awl@passagen.se
Created attachment 27004
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27004
Preprocessed test case
Internal compiler error in GCC 4.7.0 on IA64. Fault exists also in older
versions of GCC.
Target: ia64-unknown-linux-gnu
Configured with: /home/user/build/gcc-4.7.0/configure
--prefix=/home/user/software --with-gmp=/home/user/software
--with-mpfr=/home/user/software --with-mpc=/home/user/software
--with-system-libunwind --enable-languages=c,c++
$ gcc -c -O2 ia64_8451.cc
ia64_8451.cc: In function 'void fun(long unsigned int)':
ia64_8451.cc:16:1: internal compiler error: in ia64_st_address_bypass_p, at
config/ia64/ia64.c:9357
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ cat ia64_8451.cc
char* area;
long int area_size;
char* base;
void fun(unsigned long int addr)
{
unsigned long int size32 = (addr + 4096 - 1) & ~(4096 - 1);
unsigned long int size = size32 * sizeof(unsigned int);
if (size > 0) {
size = (size + 16384 -1) & ~(16384 - 1);
}
area_size = size;
area = base + size;
}
$
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug target/52731] internal compiler error: in ia64_st_address_bypass_p, at config/ia64/ia64.c:9357
2012-03-26 20:12 [Bug target/52731] New: internal compiler error: in ia64_st_address_bypass_p, at config/ia64/ia64.c:9357 awl at passagen dot se
@ 2013-11-19 13:15 ` kirill.yukhin at intel dot com
0 siblings, 0 replies; 2+ messages in thread
From: kirill.yukhin at intel dot com @ 2013-11-19 13:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52731
--- Comment #1 from Yukhin Kirill <kirill.yukhin at intel dot com> ---
Reproduced on recent trunk.
It seems that we have in ia64.c:
int
ia64_st_address_bypass_p (rtx producer, rtx consumer)
{
rtx dest, reg, mem;
gcc_assert (producer && consumer);
dest = ia64_single_set (producer);
gcc_assert (dest);
...
The problem is that we have as `producer':
(insn 18 17 4 2 (cond_exec (eq (reg:BI 262 p6 [351])
(const_int 0 [0]))
(parallel [
(set (reg:DI 16 r16 [orig:346 D.1446 ] [346])
(reg/v:DI 112 r32 [orig:340 size ] [340]))
(set (reg/v:DI 112 r32 [orig:340 size ] [340])
(reg/v:DI 112 r32 [orig:340 size ] [340]))
])) 1188 {*p epilogue_deallocate_stack}
(nil))
ia64_single_set can handle cond_exec (this is actually its purpose).
But it (after going into cond_exec) calls rtlanal.c's `single_set_2',
which returns non zero if we have only one *live* set expr after
the insn. It returns 0 otherwise (this case), which in turn triggers
assert in `ia64_st_address_bypass_p'.
I think, we could fix `ia64_st_address_bypass_p' not to use
`ia64_single_set', but iterate through all set exprs in producer.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-11-19 13:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-26 20:12 [Bug target/52731] New: internal compiler error: in ia64_st_address_bypass_p, at config/ia64/ia64.c:9357 awl at passagen dot se
2013-11-19 13:15 ` [Bug target/52731] " kirill.yukhin at intel dot com
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).