[Vm-dev] [Pharo-dev] FFICallback crashes windows spur i386 vm
nicolas.cellier.aka.nice at gmail.com
Thu Jan 19 08:29:06 UTC 2017
2017-01-17 22:24 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:
> 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>
>> > 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
>> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> maybe I am missing something but GCC 5.4 was released in Summer 2016 and
>> still supported. Couldn't it be that the better optimizers in GCC expose
>> issue that clang is not capable of exposing (yet?)?
>> just my two cents
> 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
I confirm that the test pass when we compile with gcc thru mvm -d
When such thing happens, most often, this is a sign that we still rely on
some undefined behavior...
I would recommend playing with clang runtime checks to anyone having some
time to invest or finding it fun (ok, it's not everyone).
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...
More information about the Vm-dev