On Apr 17, 2012, at 9:22 PM, Mark Pizzolato - Info Comm wrote: > Hi Craig, > > On Tuesday, April 17, 2012, at 5:25 PM, Craig A. Berry wrote: >> On Apr 17, 2012, at 11:06 AM, Mark Pizzolato - Info Comm wrote: >>> My OSX test environment is using the XCode which came with Snow >> Leopard (or was available when Snow Leopard released). I don't recall the >> version and I'm not sure how to determine this detail. >> >> If you open XCode and look in the about box, that will tell you. It should >> also >> be in a version.plist file somewhere. > > I am NOT a MAC user, so what I get to work I manage by stumbling around until > my head bangs into something. My OSX test environment is running in a > VirtualBox VM on my windows desktop.
The following commands may be useful. There is probably some better way but this is what I found quickly: % defaults read /Applications/Xcode.app/Contents/version CFBundleShortVersionString 4.3.2 or with older versions of XCode, prepend /Developer : % defaults read /Developer/Applications/Xcode.app/Contents/version CFBundleShortVersionString 3.1.4 > My llvm-gcc -v returns: > gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6) Very similar to mine: gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) >>> The attached makefile has been adjusted so that for OSX >> LTO_EXCLUDE_VERSIONS contains the current GCC_VERSION if gcc -v >> doesn't contain "--enable-lto" as you suggested. I believe that setting this >> will do the right thing on my XCode environment and your XCode and native >> gcc environments AND the native gcc built without --enable-lto. Can you test >> and confirm this? >> >> I'm going to do that. The new makefile works, thanks. With GCC=llvm-gcc in the environment, it successfully builds a working vax executable, though without optimizations. Without GCC in the environment, it successfully picks up the LTO-capable, true blue, built from source with ./configure --enable-lto GCC and builds with the intended optimizations. >> I have gotten a successful compile by doing: >> >> % make NO_LTO=1 CFLAGS_O=-O4 vax > Unfortunately this produced a binary 25% larger and 17% slower than without the -O4: VUPS SIMH version, Compiler _____ ___________________________ 14.0 v3.8-1, gcc (4.0?) 18.5 v3.8-2-rc2-190, llvm-gcc 4.2.1, NO_LTO=1 22.5 v3.8-2-rc2-190, gcc v4.7.0 15.4 v3.8-2-rc2-190, llvm-gcc 4.2.1, NO_LTO=1 CFLAGS_O=-O4 > How it runs will be interesting. > > -O4 compiles for me as well, but I'm not sure what it really did. > > Since I'm running my tests inside a VM on relatively slow hardware, > performance testing isn't very useful, but the simple DCL loop might > illustrate something when comparing compile options... > > I'll test the speed tomorrow. If this llvm thing can be made to do beneficial optimizations, I haven't seen it yet. There may be linker invocations involved, or maybe one has to use clang rather than the gcc-compatible front end. Hmm. Putting GCC=clang in the environment gets a successful compile, though with lots of warnings. However, starting the simulator hangs after "Eth: opened OS device en0" which it didn't do with other compilers, so there would be more work to support that compiler or it may not like something about the libpcap library. ________________________________________ Craig A. Berry mailto:[email protected] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
