--- Comment #16 from rth at gcc dot gnu dot org 2009-07-08 16:41 ---
Subject: Bug 38900
Author: rth
Date: Wed Jul 8 16:41:23 2009
New Revision: 149373
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149373
Log:
PR target/38900
* config/i386/i386.h
--- Comment #17 from rth at gcc dot gnu dot org 2009-07-08 16:59 ---
Subject: Bug 38900
Author: rth
Date: Wed Jul 8 16:59:15 2009
New Revision: 149374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149374
Log:
PR target/38900
* config/i386/i386.h
--- Comment #18 from rth at gcc dot gnu dot org 2009-07-08 17:03 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-07-06 10:33 ---
(In reply to comment #5)
Perhaps there are two bugs, not one, as my more elaborate testcases show.
Though they are seemingly equivalent, one triggers the bug, while another
don't.
Ok, is the same issue
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-07-06 11:54 ---
Ok, I think I found the issue. The following patch solved the ICE here. The ebx
register wasn't allowed for sibcall_1 in i386.md, but for fastcall it can be
used for sibcalling.
I have to do a regression test for
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot
|dot org
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2009-07-06 12:49
---
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 149152)
+++ config/i386/i386.md (working copy)
@@ -15536,7 +15536,7 @@
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-07-06 13:17 ---
(In reply to comment #8)
This cannot be correct in the general case as %ebx is call-saved, you cannot
clobber it through a function call. A solution could be to disparage the 'c'
alternative, but a x86 maintainer
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-07-06 15:31
---
Well, why? For save or called saved registers the functions epilogue/prologue
takes care. The reason why gcc tries to choose ebx for call address register
here, is exactly this reason, as it can be sure that
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-07-06 16:12 ---
(In reply to comment #10)
Well, why? For save or called saved registers the functions
epilogue/prologue
takes care. The reason why gcc tries to choose ebx for call address register
here, is exactly this
--- Comment #12 from ktietz at gcc dot gnu dot org 2009-07-06 16:13 ---
And this is pretty wrong :}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
--- Comment #13 from ktietz at gcc dot gnu dot org 2009-07-06 16:41 ---
By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that c
is last element, produced code is ok and no ICE I've seen. The ebx issue is
pretty wrong here.
Index: gcc/gcc/config/i386/i386.md
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-07-06 16:43
---
By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that c
is last element, produced code is ok and no ICE I've seen.
Disparaging it (s,!c,d,a) would be even more robust I think.
--
--- Comment #15 from ktietz at gcc dot gnu dot org 2009-07-06 17:02 ---
(In reply to comment #14)
By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that
c
is last element, produced code is ok and no ICE I've seen.
Disparaging it (s,!c,d,a) would be even
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2009-06-26
14:57 ---
Perhaps there are two bugs, not one, as my more elaborate testcases show.
Though they are seemingly equivalent, one triggers the bug, while another
don't.
--
--- Comment #4 from ivmai at mail dot ru 2009-06-25 10:31 ---
Bug confirmed in mingw-w64 gcc v4.5.0 (32-bit target).
Bug also observed in MinGW gcc v3.4.5 and v4.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-13 20:04
---
Simpler testcase, confirmed on native i386-pc-mingw32 (trunk, SVN rev. 147441):
$ cat a.c
void __attribute__((dllimport,fastcall)) h(int);
void f()
{
h(2);
h(1);
}
$ gcc -S -O1 a.c -foptimize-sibling-calls
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-01-17
23:19 ---
bug.c:
void __attribute__((dllimport,fastcall)) h(int);
void f(int i)
{
static void (__attribute__((fastcall)) *g)(int) = h;
g(i);
g(i);
}
--
d dot g dot gorbachev at gmail dot com
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-01-17
23:20 ---
ok.c:
void __attribute__((dllimport,fastcall)) h(int);
void f(int i)
{
static void (__attribute__((fastcall)) *g)(int);
g = h;
g(i);
g(i);
}
--
19 matches
Mail list logo
