--- Comment #13 from nightstrike at gmail dot com 2008-02-14 14:29 ---
Addendum - this applies to gfortran, as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #12 from nightstrike at gmail dot com 2008-02-14 14:27 ---
Subject: Re: g++ inoperable with no error message
On 14 Feb 2008 08:15:35 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #5 from jakub at gcc dot gnu dot org 2008-02-14 08:15 -
--- Comment #11 from ktietz at gcc dot gnu dot org 2008-02-14 10:03 ---
May I find a point, where things aren't treated for 64-bit correctly for
Windows. In i386.c ix86_expand_prologue() there are stack pointer manipulation
operations using 4 byte offset for both targets (32 and 64). I a
--- Comment #10 from ubizjak at gmail dot com 2008-02-14 09:38 ---
(In reply to comment #8)
> I tested this already and it didn't solved the problem. But may +a is more
> correct.
Perhaps setting RTX_FRAME_RELATED_P is needed? Or gen_blockage() at some point?
--
http://gcc.gnu.org/
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-14 09:32 ---
x86_64-mingw is neither a primary nor a secondary target, also this PR is not
a regression as this target is new. So this clearly should not be P1 (though
technically it doesn't matter as this PR isn't a regression
--- Comment #8 from ktietz at gcc dot gnu dot org 2008-02-14 09:26 ---
I tested this already and it didn't solved the problem. But may +a is more
correct.
Cheers, Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #7 from ubizjak at gmail dot com 2008-02-14 09:19 ---
Just a shoot-in-the-dark question... does allocate_stack_worker_64 needs +a, as
is the case in allocate_stack_worker_32 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-02-14 09:07 ---
Hello,
I tracked the problems down. Stack probing in builtin_alloca is the reason for
this. As I found, in some cases the input %rax argument isn't got set at all or
got clobbered before call to __chkstk.
The work-a-
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-14 08:15 ---
It would be helpful if you could post the actual errors that are reported for
the ICE, perhaps backtrace and other details. Guess most of the people don't
have access to this target and I doubt it can be reproduced us
--- Comment #4 from mmitchel at gcc dot gnu dot org 2008-02-14 06:59
---
It's true that having the new target not work well is embarrassing, but it's
not a regression of any kind. However, if we don't fix this, then we certainly
shouldn't brag about support for this target in the NEWS
--- Comment #3 from nightstrike at gmail dot com 2008-02-14 01:53 ---
Can we have this fixed before 4.3.0? x86_64-pc-mingw32 is a new target for
this release, and it shouldn't be delivered completely broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #2 from ktietz at gcc dot gnu dot org 2008-02-11 14:57 ---
It is 4.3.0. I modified the bug report for that.
Cheers, Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-11 14:51 ---
which gcc version?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--
nightstrike at gmail dot com changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
14 matches
Mail list logo
