[Vm-dev] [Pharo-dev] FFICallback crashes windows spur i386 vm

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Jan 17 21:24:55 UTC 2017

2017-01-17 19:49 GMT+01:00 Holger Freyther <holger at freyther.de>:

> > On 17 Jan 2017, at 19:43, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> > Hi Nicolas, Hi Esteban,
> Hi all,
> >
> >     so is it feasible to insist on clang?  The mingw compiler is
> ancient, so my preference is to move to clang.  If so, could someone update
> the HowToBuild to describe the problem with mingw and how to install the
> clang-based toolchain?
> > from cygwin (or cygwin64) shell:
> >
> > $ i686-w64-mingw32-gcc --version
> > i686-w64-mingw32-gcc (GCC) 5.4.0
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is
> NO
> maybe I am missing something but GCC 5.4 was released in Summer 2016 and is
> still supported. Couldn't it be that the better optimizers in GCC expose an
> issue that clang is not capable of exposing (yet?)?
> just my two cents
>         holger

Hi Holger,
maybe... One should compile with -O0 to check if it's really about
optimization and retry if it solves anything.
If yes, then play the game of selecting each individual optimization option.

What I know is that the mingw version of gcc have strange stack management
with bytes reserved below alloca which is causing some complications in our
implemenation of FFI.
Personnally I don't have a clue of the reason behind the difference with
linux gcc, so without further information, I tend to perceive such
differences as a useless and never-ending-source of complications. I'm
speaking for myself, but maybe Eliot has the same feeling.

Not sure that it's a great choice to abandon gcc support, but it's quite
tempting in those circumstances ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170117/c7f92a64/attachment-0001.html>

More information about the Vm-dev mailing list