Smalltalk › Squeak › Squeak VM

status of compilation with LLVM 3.0 with Xcode

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Nicolas Cellier

status of compilation with LLVM 3.0 with Xcode

I now compile and run a modified squeak.cog.spur 32bits VM 3264 with Xcode 4.2, OSX 10.6.8 and LLVM 3.0.
I can run all the tests in the image.
I have a bit more errors than VM 3254 published by Eliot, notably due to elementsForwardIdentityTo: failed.
This is caused when trying to restore an ImageSegment.
Presumably triggered because two globals DummyUIManager and MVCUIManager are instances of ImageSegmentRootStub.
I really don't know why they are... When I run the image with official VM, they are not.

I saw that many of the Xcode projects still try to force usage of gcc 4.2 and I had to change them.

What is the status of LLVM compilation currently?

Nicolas Cellier

Re: status of compilation with LLVM 3.0 with Xcode

As a follow up, the image segment problem was caused by a bug of mine.

I have duplicated code for byte swapping objects from image segment with/without swapping the largeInt (for handling native order 32bits digits).

But of course, the format changed for Spur and I forgot to update the method...

After correcting, my own imageSegment are still not OK.

Hard to catch up with run-away development speed of Eliot :)

Though I can run all the other tests in a 32bits trunk Spur built with XCode4.2/LLVM clang 3.0, DeploymentSymbol version without regression.

And can I run all tests with cog V3.

Nice :)

2015-03-15 0:40 GMT+01:00 Nicolas Cellier <[hidden email]>:

I now compile and run a modified squeak.cog.spur 32bits VM 3264 with Xcode 4.2, OSX 10.6.8 and LLVM 3.0.
I can run all the tests in the image.
I have a bit more errors than VM 3254 published by Eliot, notably due to elementsForwardIdentityTo: failed.
This is caused when trying to restore an ImageSegment.
Presumably triggered because two globals DummyUIManager and MVCUIManager are instances of ImageSegmentRootStub.
I really don't know why they are... When I run the image with official VM, they are not.

I saw that many of the Xcode projects still try to force usage of gcc 4.2 and I had to change them.
What is the status of LLVM compilation currently?

ccrraaiigg

re: status of compilation with LLVM 3.0 with Xcode

> Hard to catch up with run-away development speed of Eliot :)
>
> Though I can run all the other tests in a 32bits trunk Spur built with
> XCode4.2/LLVM clang 3.0, DeploymentSymbol version without regression.
> And can I run all tests with cog V3.
>
> Nice :)

Cool!

-C

--
Craig Latta
netjam.org
March 2015:
+ 1 510 480 5860 (SMS ok)
+31 20 893 2796 (no SMS)
afterward:
+31 6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)

EstebanLM

Re: status of compilation with LLVM 3.0 with Xcode

In reply to this post by Nicolas Cellier

I compile always with llvm (Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn))
No issues so far (but I needed to add a couple of compilation flags).

Esteban

> On 15 Mar 2015, at 00:40, Nicolas Cellier <[hidden email]> wrote:
>
> I now compile and run a modified squeak.cog.spur 32bits VM 3264 with Xcode 4.2, OSX 10.6.8 and LLVM 3.0.
> I can run all the tests in the image.
> I have a bit more errors than VM 3254 published by Eliot, notably due to elementsForwardIdentityTo: failed.
> This is caused when trying to restore an ImageSegment.
> Presumably triggered because two globals DummyUIManager and MVCUIManager are instances of ImageSegmentRootStub.
> I really don't know why they are... When I run the image with official VM, they are not.
>
> I saw that many of the Xcode projects still try to force usage of gcc 4.2 and I had to change them.
> What is the status of LLVM compilation currently?

Nicolas Cellier

Re: status of compilation with LLVM 3.0 with Xcode

Thanks for the information Esteban.

I added no flags - just played with settings the warnings on or off to concentrate on specific errors...

An example extracted from LOGD produced by Eliot's mvm:

/Developer/usr/bin/clang -x c -arch i386 -fmessage-length=0 -fdiagnostics-print-source-range-info -fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -Wno-trigraphs -fpascal-strings -O3 -mdynamic-no-pic -Wno-return-type -Wparentheses -Wswitch -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wuninitialized -Wno-shorten-64-to-32 -DNDEBUG=1 -DCOGMTVM=0 -DDEBUGVM=0 -DUSE_GLOBAL_STRUCT=0 "-DTZ=\"CET\"" -DNO_ISNAN -DTARGET_API_MAC_CARBON -DSQUEAK_BUILTIN_PLUGIN -DHAVE_SYS_TIME_H -isysroot /Developer/SDKs/MacOSX10.6.sdk -fasm-blocks -mmacosx-version-min=10.6 -gdwarf-2 -Wno-sign-conversion -I/Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/build/CoreVM.build/DeploymentSymbols/Squeak.build/Squeak.hmap -I/Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/build/DeploymentSymbols/include -I/Developer/SDKs/MacOSX10.6.sdk/Developer/Headers/FlatCarbon -I/Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur -I/Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/build/CoreVM.build/DeploymentSymbols/Squeak.build/DerivedSources/i386 -I/Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/build/CoreVM.build/DeploymentSymbols/Squeak.build/DerivedSources -F/Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/build/DeploymentSymbols -MMD -MT dependencies -MF /Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/build/CoreVM.build/DeploymentSymbols/Squeak.build/Objects-normal/i386/sqMacMIDI.d -c "/Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/../../platforms/Mac OS/plugins/MIDIPlugin/sqMacMIDI.c" -o /Users/nicolas/Smalltalk/Squeak/vm_cog/build.macos32x86/squeak.cog.spur/build/CoreVM.build/DeploymentSymbols/Squeak.build/Objects-normal/i386/sqMacMIDI.o

2015-03-18 9:05 GMT+01:00 Esteban Lorenzano <[hidden email]>:

I compile always with llvm (Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn))
No issues so far (but I needed to add a couple of compilation flags).

Esteban

> On 15 Mar 2015, at 00:40, Nicolas Cellier <[hidden email]> wrote:
>
> I now compile and run a modified squeak.cog.spur 32bits VM 3264 with Xcode 4.2, OSX 10.6.8 and LLVM 3.0.
> I can run all the tests in the image.
> I have a bit more errors than VM 3254 published by Eliot, notably due to elementsForwardIdentityTo: failed.
> This is caused when trying to restore an ImageSegment.
> Presumably triggered because two globals DummyUIManager and MVCUIManager are instances of ImageSegmentRootStub.
> I really don't know why they are... When I run the image with official VM, they are not.
>
> I saw that many of the Xcode projects still try to force usage of gcc 4.2 and I had to change them.
> What is the status of LLVM compilation currently?