[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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=15267action=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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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
