--- 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 #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=gcc&view=rev&rev=149374
Log:
PR target/38900
* config/i386/i386.h (CONDITIONAL_RE
--- 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=gcc&view=rev&rev=149373
Log:
PR target/38900
* config/i386/i386.h (CONDITIONAL_RE
--- 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 b
--- 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 #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 #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 #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 t
--- 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 tha
--- 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 maintain
--- 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 @@
>
--
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 #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 it,
--- 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 occur
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- 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 #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);
}
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- 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 changed
19 matches
Mail list logo
