www.digitalmars.com         C & C++   DMDScript  

D.gnu - gdc 0.20 svn branch on mingw/gcc4.0.3 (win32) segfaults

reply Downs <mathis.beer tu-ilmenau.de> writes:
Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
the resulting gdc.exe is incapable of compiling even the most basic test 
files; it crashes on configure with a sigsegv in actest.d:0.
Somewhat related question; is it possible to compile gcc so that it does 
not catch segment violations internally? This "feature" makes it 
impossible for me to get stack traces of the crash in gdb (no stackdumps 
are produced either).
Alternatively, any idea what I could do to narrow the problem area down?
Thanks for ideas; greetings.
Dec 04 2006
next sibling parent Downs <mathis.beer tu-ilmenau.de> writes:
Downs wrote:
 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
 the resulting gdc.exe is incapable of compiling even the most basic test 
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does 
 not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no stackdumps 
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.

Oh, btw; my configure flags were --enable-languages=c,d --prefix=/MinGW/gdc --enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared --disable-bootstrap. CFLAGS was -O0 -pipe, CXXFLAGS dito, LDFLAGS set to empty, DFLAGS not set.
Dec 04 2006
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Downs escribiˇ:
 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
 the resulting gdc.exe is incapable of compiling even the most basic test 
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does 
 not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no stackdumps 
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.

The ChangeLog right now says "More 0.176 merges", so I would consider the compiler unstable. -- Carlos Santander Bernal
Dec 04 2006
parent reply Downs <mathis.beer tu-ilmenau.de> writes:
Carlos Santander wrote:
 Downs escribiˇ:
 Attempting to build the current rev48 gdc 0.20 branch on 
 mingw/gcc4.0.3; the resulting gdc.exe is incapable of compiling even 
 the most basic test files; it crashes on configure with a sigsegv in 
 actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it 
 does not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no 
 stackdumps are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.

The ChangeLog right now says "More 0.176 merges", so I would consider the compiler unstable.

I was under the assumption code had to be somewhat stable-y to be checked into svn. Good point though; I hadn't considered that. Still, the current version of the compiler fails on a _trivial_ example; so I still think I was justified in pointing it out (especially considering the problem seems to be exclusive to win32 (somebody is using rev48 under macos without problems (I think)) and, there not being that many gdcwin users, it could well have gone unnoticed (on that note, does anybody know if the gdc maintainer does test builds on win32?)) Greetings
Dec 04 2006
next sibling parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Downs wrote:

 does anybody know if the gdc maintainer does test builds on win32?

I believe that David Friedman makes GDC binaries for MinGW and Cygwin, at least there were for the GDC 0.19 release so it might be for 0.20 ? --anders
Dec 04 2006
parent Downs <mathis.beer tu-ilmenau.de> writes:
Anders F Bj÷rklund wrote:
 Downs wrote:
 
 does anybody know if the gdc maintainer does test builds on win32?

I believe that David Friedman makes GDC binaries for MinGW and Cygwin, at least there were for the GDC 0.19 release so it might be for 0.20 ? --anders

Okay, good to know. Thanks :)
Dec 04 2006
prev sibling parent reply David Friedman <dvdfrdmn users.ess-eff.net> writes:
Downs wrote:
 Carlos Santander wrote:
 
 Downs escribiˇ:

 Attempting to build the current rev48 gdc 0.20 branch on 
 mingw/gcc4.0.3; the resulting gdc.exe is incapable of compiling even 
 the most basic test files; it crashes on configure with a sigsegv in 
 actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it 
 does not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no 
 stackdumps are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.

The ChangeLog right now says "More 0.176 merges", so I would consider the compiler unstable.

I was under the assumption code had to be somewhat stable-y to be checked into svn. Good point though; I hadn't considered that. Still, the current version of the compiler fails on a _trivial_ example; so I still think I was justified in pointing it out (especially considering the problem seems to be exclusive to win32 (somebody is using rev48 under macos without problems (I think)) and, there not being that many gdcwin users, it could well have gone unnoticed (on that note, does anybody know if the gdc maintainer does test builds on win32?)) Greetings

The trunk will be stable, but don't expect the same of a "-dev" branch. One thing I'm trying to do is put the raw merge of new DMD version in a separate commit from any further modifications to the DMD code that are needed to get it working with GDC. The code is no even going to compile after some of those merges. That said, I want to keep the dev code fairly stable. I usually only build for my current development platofrm (currently GCC 4.0.3 on MacOS Intel) unless there have been changes that I think might cause problems. When I start to put a release together, I will run regression tests on all of the other targets. So... I was not aware of this problem. Thanks for pointing it out. I realize people are building out of the dev branch because there has not been a release for so long... I will try to get this fixed soon. David
Dec 04 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  I 
 realize people are building out of the dev branch because there has not 
 been a release for so long... I will try to get this fixed soon.

I am eagerly awaiting a stable release of GDC that is caught up to DMD 0.176. As far as I can tell, this will allow Pyd to compile on Linux, which will allow me to declare an actual release of the library. My hope is that this will then attract some of the Python crowd to D. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Dec 05 2006
parent reply Dave <Dave_member pathlink.com> writes:
Kirk McDonald wrote:
 David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  I 
 realize people are building out of the dev branch because there has 
 not been a release for so long... I will try to get this fixed soon.

I am eagerly awaiting a stable release of GDC that is caught up to DMD 0.176. As far as I can tell, this will allow Pyd to compile on Linux, which will allow me to declare an actual release of the library. My hope is that this will then attract some of the Python crowd to D.

Just curious - will DMD 0.176 not work for this, or do you just prefer GDC for that platform? Thanks.
Dec 05 2006
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Dave wrote:
 Kirk McDonald wrote:
 David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  
 I realize people are building out of the dev branch because there has 
 not been a release for so long... I will try to get this fixed soon.

I am eagerly awaiting a stable release of GDC that is caught up to DMD 0.176. As far as I can tell, this will allow Pyd to compile on Linux, which will allow me to declare an actual release of the library. My hope is that this will then attract some of the Python crowd to D.

Just curious - will DMD 0.176 not work for this, or do you just prefer GDC for that platform?

I think it's because to use Pyd you need to compile as a shared library, which DMD doesn't support on Linux. Couldn't find an explicit statement about this on the site, though.
Dec 05 2006
prev sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Dave wrote:
 Kirk McDonald wrote:
 David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  
 I realize people are building out of the dev branch because there has 
 not been a release for so long... I will try to get this fixed soon.

I am eagerly awaiting a stable release of GDC that is caught up to DMD 0.176. As far as I can tell, this will allow Pyd to compile on Linux, which will allow me to declare an actual release of the library. My hope is that this will then attract some of the Python crowd to D.

Just curious - will DMD 0.176 not work for this, or do you just prefer GDC for that platform? Thanks.

The last time I checked, DMD could not compile working .so files on Linux. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Dec 05 2006
prev sibling next sibling parent David Friedman <dvdfrdmn users.ess-eff.net> writes:
Downs wrote:
 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
 the resulting gdc.exe is incapable of compiling even the most basic test 
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does 
 not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no stackdumps 
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.

This problem has been fixed in subversion rev.50. MinGW uses msvcrt which does not have a C99-compatible printf. Thus, all of the new '%z..' and '%j...' formats are ignored. Something like printf("%zu %s", 42, "M$") crashes. Re: gdb. It should catch segfaults. Were you debugging gdc.exe? The actual compiler is cc1d.exe. David
Dec 06 2006
prev sibling parent reply Mathieu Chouinard <mchoui e-c.qc.ca> writes:
Downs wrote:

 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3;
 the resulting gdc.exe is incapable of compiling even the most basic test
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does
 not catch segment violations internally? This "feature" makes it
 impossible for me to get stack traces of the crash in gdb (no stackdumps
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.

Mathieu -- Tip of the day: The Windows 95 CD-ROM makes an excellent skeet shoot target.
Dec 06 2006
parent reply David Friedman <dvdfrdmn users.ess-eff.net> writes:
Mathieu Chouinard wrote:
 Downs wrote:
 
 
Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3;
the resulting gdc.exe is incapable of compiling even the most basic test
files; it crashes on configure with a sigsegv in actest.d:0.
Somewhat related question; is it possible to compile gcc so that it does
not catch segment violations internally? This "feature" makes it
impossible for me to get stack traces of the crash in gdb (no stackdumps
are produced either).
Alternatively, any idea what I could do to narrow the problem area down?
Thanks for ideas; greetings.

Will this developement branch have any support for gcc 4.1.x? Mathieu

No, my goal for the next release is just fix critical bugs and to get the DMD 0.176 merge stable. David
Dec 06 2006
parent Mathieu Chouinard <mchoui e-c.qc.ca> writes:
David Friedman wrote:

 Mathieu Chouinard wrote:
 Downs wrote:
 
 
Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3;
the resulting gdc.exe is incapable of compiling even the most basic test
files; it crashes on configure with a sigsegv in actest.d:0.
Somewhat related question; is it possible to compile gcc so that it does
not catch segment violations internally? This "feature" makes it
impossible for me to get stack traces of the crash in gdb (no stackdumps
are produced either).
Alternatively, any idea what I could do to narrow the problem area down?
Thanks for ideas; greetings.

Will this developement branch have any support for gcc 4.1.x? Mathieu

No, my goal for the next release is just fix critical bugs and to get the DMD 0.176 merge stable. David

Mathieu -- One possible reason that things aren't going according to plan is that there never was a plan in the first place.
Dec 06 2006