* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
@ 2008-02-11 7:40 ` nightstrike at gmail dot com
2008-02-11 14:52 ` rguenth at gcc dot gnu dot org
` (24 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-02-11 7:40 UTC (permalink / raw)
To: gcc-bugs
--
nightstrike at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
2008-02-11 7:40 ` [Bug c++/35159] " nightstrike at gmail dot com
@ 2008-02-11 14:52 ` rguenth at gcc dot gnu dot org
2008-02-11 14:57 ` ktietz at gcc dot gnu dot org
` (23 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-11 14:52 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
2008-02-11 7:40 ` [Bug c++/35159] " nightstrike at gmail dot com
2008-02-11 14:52 ` rguenth at gcc dot gnu dot org
@ 2008-02-11 14:57 ` ktietz at gcc dot gnu dot org
2008-02-14 1:54 ` nightstrike at gmail dot com
` (22 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-02-11 14:57 UTC (permalink / raw)
To: gcc-bugs
------- 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
----------------------------------------------------------------------------
Version|unknown |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (2 preceding siblings ...)
2008-02-11 14:57 ` ktietz at gcc dot gnu dot org
@ 2008-02-14 1:54 ` nightstrike at gmail dot com
2008-02-14 7:00 ` mmitchel at gcc dot gnu dot org
` (21 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-02-14 1:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (3 preceding siblings ...)
2008-02-14 1:54 ` nightstrike at gmail dot com
@ 2008-02-14 7:00 ` mmitchel at gcc dot gnu dot org
2008-02-14 8:16 ` jakub at gcc dot gnu dot org
` (20 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2008-02-14 7:00 UTC (permalink / raw)
To: gcc-bugs
------- 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 for the new release.
So, I've marked this P1 -- but we can get it down to P4 by checking that we're
not claiming support for this target, if we can't fix the defect.
--
mmitchel at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (4 preceding siblings ...)
2008-02-14 7:00 ` mmitchel at gcc dot gnu dot org
@ 2008-02-14 8:16 ` jakub at gcc dot gnu dot org
2008-02-14 9:08 ` ktietz at gcc dot gnu dot org
` (19 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: jakub at gcc dot gnu dot org @ 2008-02-14 8:16 UTC (permalink / raw)
To: gcc-bugs
------- 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 using a cross
compiler.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (5 preceding siblings ...)
2008-02-14 8:16 ` jakub at gcc dot gnu dot org
@ 2008-02-14 9:08 ` ktietz at gcc dot gnu dot org
2008-02-14 9:19 ` ubizjak at gmail dot com
` (18 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-02-14 9:08 UTC (permalink / raw)
To: gcc-bugs
------- 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-round for this, is to disable stack probing. So I assume the reason
is to be searched in optimization or in the builtin function itself.
AFAICS the implementation in the i386.md file seems to be ok.
Cheers, Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (6 preceding siblings ...)
2008-02-14 9:08 ` ktietz at gcc dot gnu dot org
@ 2008-02-14 9:19 ` ubizjak at gmail dot com
2008-02-14 9:27 ` ktietz at gcc dot gnu dot org
` (17 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: ubizjak at gmail dot com @ 2008-02-14 9:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (7 preceding siblings ...)
2008-02-14 9:19 ` ubizjak at gmail dot com
@ 2008-02-14 9:27 ` ktietz at gcc dot gnu dot org
2008-02-14 9:33 ` rguenth at gcc dot gnu dot org
` (16 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-02-14 9:27 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (8 preceding siblings ...)
2008-02-14 9:27 ` ktietz at gcc dot gnu dot org
@ 2008-02-14 9:33 ` rguenth at gcc dot gnu dot org
2008-02-14 9:39 ` ubizjak at gmail dot com
` (15 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-14 9:33 UTC (permalink / raw)
To: gcc-bugs
------- 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 anyway).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (9 preceding siblings ...)
2008-02-14 9:33 ` rguenth at gcc dot gnu dot org
@ 2008-02-14 9:39 ` ubizjak at gmail dot com
2008-02-14 10:04 ` ktietz at gcc dot gnu dot org
` (14 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: ubizjak at gmail dot com @ 2008-02-14 9:39 UTC (permalink / raw)
To: gcc-bugs
------- 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/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (10 preceding siblings ...)
2008-02-14 9:39 ` ubizjak at gmail dot com
@ 2008-02-14 10:04 ` ktietz at gcc dot gnu dot org
2008-02-14 14:28 ` nightstrike at gmail dot com
` (13 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-02-14 10:04 UTC (permalink / raw)
To: gcc-bugs
------- 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 am currently
rebuild and test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (11 preceding siblings ...)
2008-02-14 10:04 ` ktietz at gcc dot gnu dot org
@ 2008-02-14 14:28 ` nightstrike at gmail dot com
2008-02-14 14:29 ` nightstrike at gmail dot com
` (12 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-02-14 14:28 UTC (permalink / raw)
To: gcc-bugs
------- 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 -0000, jakub at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- 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 using a cross
> compiler.
One of the issues is that there isn't any error output from g++. In
fact, that's probably the most disturbing part -- g++ will die
silently, giving zero output, zero errors, zero anything. Under some
situations, you might be able to get an ICE when you use -E, but it
says that the ICE occurred in "<built-in>:0", which isn't too helpful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (12 preceding siblings ...)
2008-02-14 14:28 ` nightstrike at gmail dot com
@ 2008-02-14 14:29 ` nightstrike at gmail dot com
2008-02-16 17:23 ` [Bug c++/35159] g++ and gfortran " nightstrike at gmail dot com
` (11 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-02-14 14:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (13 preceding siblings ...)
2008-02-14 14:29 ` nightstrike at gmail dot com
@ 2008-02-16 17:23 ` nightstrike at gmail dot com
2008-02-16 19:51 ` ktietz at gcc dot gnu dot org
` (10 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-02-16 17:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from nightstrike at gmail dot com 2008-02-16 17:22 -------
edited title to reflect gfortran failure, as well.
--
nightstrike at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|g++ inoperable with no error|g++ and gfortran inoperable
|message |with no error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (14 preceding siblings ...)
2008-02-16 17:23 ` [Bug c++/35159] g++ and gfortran " nightstrike at gmail dot com
@ 2008-02-16 19:51 ` ktietz at gcc dot gnu dot org
2008-03-06 3:01 ` nightstrike at gmail dot com
` (9 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-02-16 19:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from ktietz at gcc dot gnu dot org 2008-02-16 19:50 -------
(In reply to comment #10)
> (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?
As far as I saw there is a bug in ix86_expand_prologue, but it hasn't to do
something with this problem.
The code expansion for inlined static methods, seems to be broken. If I write
small test programs using alloca (and so indirect ___chkstk) every thing works
fine and the assembly is proven correct. But if the methods getting more
complex like in cp/pt.c the code gets broken. If I use the target by disabling
the stack probing most problems are gone, but still there seems to be a stack
corruption in c++ and fortan compiler. These compilers make more use of stack
allocation method alloca.
For the stack probing I am certain, that if the a linux x86_64 would enable it,
things get here broken, too. But there seems to be a issue with inline
expansion in general.
So for this bug may it the best to disable for now the stack probing at all.
Cheers, Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (15 preceding siblings ...)
2008-02-16 19:51 ` ktietz at gcc dot gnu dot org
@ 2008-03-06 3:01 ` nightstrike at gmail dot com
2008-03-06 4:51 ` jvdelisle at gcc dot gnu dot org
` (8 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-03-06 3:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from nightstrike at gmail dot com 2008-03-06 03:00 -------
Created an attachment (id=15267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15267&action=view)
Preprocssed source for the testcase mentioned
I took the code that I mentioned in the first post in this bug and I compiled
it with "g++ --save-temps". This is the result. It outputed this to stderr:
<built-in>:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (16 preceding siblings ...)
2008-03-06 3:01 ` nightstrike at gmail dot com
@ 2008-03-06 4:51 ` jvdelisle at gcc dot gnu dot org
2008-03-06 5:10 ` nightstrike at gmail dot com
` (7 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2008-03-06 4:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-03-06 04:50 -------
What is the Fortran test case that makes this is a gfortran issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (17 preceding siblings ...)
2008-03-06 4:51 ` jvdelisle at gcc dot gnu dot org
@ 2008-03-06 5:10 ` nightstrike at gmail dot com
2008-03-06 16:09 ` nightstrike at gmail dot com
` (6 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-03-06 5:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from nightstrike at gmail dot com 2008-03-06 05:09 -------
(In reply to comment #17)
> What is the Fortran test case that makes this is a gfortran issue?
PROGRAM HelloWorld
WRITE(*,*) "Hello World!"
END PROGRAM
I haven't tested that again with the latest changes that Joesph Myers has put
into gcc, so I'll do it again as soon as I rebuild. But yeah, hello world
doesn't work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (18 preceding siblings ...)
2008-03-06 5:10 ` nightstrike at gmail dot com
@ 2008-03-06 16:09 ` nightstrike at gmail dot com
2008-03-08 6:06 ` jvdelisle at gcc dot gnu dot org
` (5 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-03-06 16:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from nightstrike at gmail dot com 2008-03-06 16:08 -------
Ok, compiling the aforementioned "Hello, world!" program using "gfortran
--save-temps hello.f90" results in f951.exe maxing out the CPU forever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (19 preceding siblings ...)
2008-03-06 16:09 ` nightstrike at gmail dot com
@ 2008-03-08 6:06 ` jvdelisle at gcc dot gnu dot org
2008-05-13 13:24 ` nightstrike at gmail dot com
` (4 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2008-03-08 6:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-03-08 06:06 -------
This looks like bad stuff. See my separate note to see if I can get to a point
of reproducing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (20 preceding siblings ...)
2008-03-08 6:06 ` jvdelisle at gcc dot gnu dot org
@ 2008-05-13 13:24 ` nightstrike at gmail dot com
2008-09-21 15:03 ` pepalogik at seznam dot cz
` (3 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-05-13 13:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from nightstrike at gmail dot com 2008-05-13 13:23 -------
ping.. Is there anyone that can help us with this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (21 preceding siblings ...)
2008-05-13 13:24 ` nightstrike at gmail dot com
@ 2008-09-21 15:03 ` pepalogik at seznam dot cz
2008-09-21 17:08 ` nightstrike at gmail dot com
` (2 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: pepalogik at seznam dot cz @ 2008-09-21 15:03 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from pepalogik at seznam dot cz 2008-09-21 15:02 -------
I'm probably not the one who'll find the core of the bug but I'd like to
mention two simple facts:
1: mingw-w64-bin_i686-mingw_20080707 WORKS
2: mingw-w64-bin_x86_64-mingw_20080724 DOESN'T WORK
(Vista64 SP1)
I don't use it currently so I haven't tried new versions.
Btw. I think it's GCC v. 4.4.0 (experimental) instead of 4.3.0.
--
pepalogik at seznam dot cz changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pepalogik at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (22 preceding siblings ...)
2008-09-21 15:03 ` pepalogik at seznam dot cz
@ 2008-09-21 17:08 ` nightstrike at gmail dot com
2008-10-20 11:25 ` ktietz at gcc dot gnu dot org
2009-06-24 10:28 ` ktietz at gcc dot gnu dot org
25 siblings, 0 replies; 27+ messages in thread
From: nightstrike at gmail dot com @ 2008-09-21 17:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from nightstrike at gmail dot com 2008-09-21 17:06 -------
(In reply to comment #22)
> I'm probably not the one who'll find the core of the bug but I'd like to
> mention two simple facts:
Thanks for your feedback!
> 1: mingw-w64-bin_i686-mingw_20080707 WORKS
> 2: mingw-w64-bin_x86_64-mingw_20080724 DOESN'T WORK
> (Vista64 SP1)
>
> I don't use it currently so I haven't tried new versions.
This is because the first one is a cross compiler, while the second is a native
compiler. It just happens that you can run a cross compiler on the native
system, since Win64 supports running Win32 code.
> Btw. I think it's GCC v. 4.4.0 (experimental) instead of 4.3.0.
The problem originated in version 4.3.0, and has stayed ever since.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (23 preceding siblings ...)
2008-09-21 17:08 ` nightstrike at gmail dot com
@ 2008-10-20 11:25 ` ktietz at gcc dot gnu dot org
2009-06-24 10:28 ` ktietz at gcc dot gnu dot org
25 siblings, 0 replies; 27+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-10-20 11:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from ktietz at gcc dot gnu dot org 2008-10-20 11:24 -------
This bug is reasoned by some problems in ira. IIUC, mingw 32-bit has the same
issue here.
This bug can be worked around by disable ira optimization via -fno-ira.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug c++/35159] g++ and gfortran inoperable with no error message
2008-02-11 7:38 [Bug c++/35159] New: g++ inoperable with no error message nightstrike at gmail dot com
` (24 preceding siblings ...)
2008-10-20 11:25 ` ktietz at gcc dot gnu dot org
@ 2009-06-24 10:28 ` ktietz at gcc dot gnu dot org
25 siblings, 0 replies; 27+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-06-24 10:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from ktietz at gcc dot gnu dot org 2009-06-24 10:28 -------
This bug was fixed for 4.4 version. The real issue here was the changes happend
to ira and specifying one register via the constrains "=a" or "+a". Both
variant don't work anymore. By expanding the stack_allocator methods (for
32-bit and 64-bit) by one input and one output contrain, it solves the issue.
--
ktietz at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
^ permalink raw reply [flat|nested] 27+ messages in thread