[Bug c++/35159] New: g++ inoperable with no error message

[Bug c++/35159] New: g++ inoperable with no error message

[nightstrike at gmail dot com]

To summarize, c++ doesn't work in a native build for x86_64-pc-mingw32. We have
found that not all of c++ is broken, and I've been narrowing it down further.
The problem manifests itself as a segfault and ICE that is only visible when
you use the -E switch -- otherwise, the failure is silent. This in and of
itself I think is a bug, and we should report it to gcc. 

The segfault can be triggered by #including a c++ header like iostream or
cmath. Further digging reveals that it's not all of the headers. I found that
for instance cassert works fine. I've been able to narrow down cmath's failure
due to including <ext/type_traits.h>, and this might be the failure point for
everything.

I think I've found a reduced test case... 

#include <bits/c++config.h> 
#include <bits/cpp_type_traits.h> 
template<bool, typename> 
struct __enable_if 
{ }; 

template<typename _Tp> 
struct __enable_if<true, _Tp> 
{ typedef _Tp __type; }; 

int main() {return 0; } 



That code is taken from the ext/type_traits.h header. It doesn't give any error
(and no segfault in the -E output), but it won't compile. If you get rid of the
second template, it will compile and link to create an executable. This is, I
think, getting much closer to the heart of the problem. I think we should post
on gcc soon for this.


-- 
           Summary: g++ inoperable with no error message
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nightstrike at gmail dot com
  GCC host triplet: x86_64-pc-mingw32
GCC target triplet: x86_64-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159

[Bug c++/35159] g++ inoperable with no error message

[nightstrike at gmail dot com]

-- 

nightstrike at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159

[Bug c++/35159] g++ inoperable with no error message

[rguenth at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[nightstrike at gmail dot com]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[mmitchel at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[jakub at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[ubizjak at gmail dot com]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[rguenth at gcc dot gnu dot 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 anyway).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159

[Bug c++/35159] g++ inoperable with no error message

[ubizjak at gmail dot com]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[nightstrike at gmail dot com]

------- 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

[Bug c++/35159] g++ inoperable with no error message

[nightstrike at gmail dot com]

------- 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

[Bug c++/35159] g++ and gfortran inoperable with no error message

[nightstrike at gmail dot com]

------- 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

[ktietz at gcc dot gnu dot org]

------- 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

[Bug c++/35159] g++ and gfortran inoperable with no error message

[nightstrike at gmail dot com]

------- 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

[Bug c++/35159] g++ and gfortran inoperable with no error message

[jvdelisle at gcc dot gnu dot org]

------- 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

[nightstrike at gmail dot com]

------- 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

[nightstrike at gmail dot com]

------- 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

[jvdelisle at gcc dot gnu dot org]

------- 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

[nightstrike at gmail dot com]

------- 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

[pepalogik at seznam dot cz]

------- 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

[nightstrike at gmail dot com]

------- 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

[ktietz at gcc dot gnu dot org]

------- 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

[ktietz at gcc dot gnu dot org]

------- 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