search for: shantonu

No, As it worked fine before. I can't see the #if that goes with +#elif defined(__WIN32__) as you removed -#if TARGET_OS_MAC. Please go over your #if / #endif blocks and trail the #endif with a comment. I am willing to bet there is a problem there. Thanks for your time, Edward. 2009/9/23 Shantonu Sen <ssen at apple.com>: > Sounds like your system compiler doesn't support gcc-style builtin atomics. > Please use a different compiler? > > Shantonu > > Sent from my MacBook > > On Sep 22, 2009, at 7:54 PM, Edward O'Callaghan wrote: > >> Breaks Build...

...anks for your work on the CMake system btw ! I think we need a 'clean' CMake test for the above problem instead of the build just blowing up like that. I guess I will have a look in the morning (its late here) unless you have already committed something by then. Cheers, Edward. 2009/9/23 Shantonu Sen <ssen at apple.com>: > Seems pretty clear cut to me. > > #if defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_INT) && > defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_LONG) > ... > #elif defined(__WIN32__) > ... > #elif defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT) &&...

...-and-swap primitive #endif The problem isn't mismatched #if/#endif. The #error says it all, cmake couldn't detect an appropriate atomic built-in implementation. Please use llvm-gcc or clang to build compiler-rt. Same as how nobody expects to build libgcc with anything other than gcc. Shantonu Sent from my MacBook On Sep 22, 2009, at 8:06 PM, Edward O'Callaghan wrote: > No, As it worked fine before. > > I can't see the #if that goes with +#elif defined(__WIN32__) as you > removed -#if TARGET_OS_MAC. > Please go over your #if / #endif blocks and trail the #endif...

...locksRuntime/runtime.c:689: warning: format '%#lx' expects type 'long unsigned int', but argument 3 has type 'unsigned int' Please check these. Thank you, Edward O'Callaghan. 2009/9/22 Chris Lattner <clattner at apple.com>: > > On Sep 21, 2009, at 9:15 AM, Shantonu Sen wrote: > > [forwarding to llvm-commits, which is where i meant to send it the first > time] > > The source changes seem fine to me, and I don't have an opinion about the > build system changes - I suggest committing them and seeing if anyone > screams :) > Thanks Sha...

Sounds like your system compiler doesn't support gcc-style builtin atomics. Please use a different compiler? Shantonu Sent from my MacBook On Sep 22, 2009, at 7:54 PM, Edward O'Callaghan wrote: > Breaks Builds on Solaris and AuroraUX with: > > bash-3.2$ make > Scanning dependencies of target BlocksRuntime > [ 1%] Building C object BlocksRuntime/CMakeFiles/BlocksRuntime.dir/ > runtime.c.o...

...r that. I've cloned it to Bugzilla as: <http://llvm.org/bugs/show_bug.cgi?id=5034> Implement __builtin_eh_return_data_regno() I can probably make the cmake configure stage fail up front if none of the supported mechanisms are found. I'll look at that. Thanks for the feedback! Shantonu Sent from my MacBook On Sep 22, 2009, at 9:01 PM, Edward O'Callaghan wrote: > Clang does indeed built it with one warning. > > [ 55%] Building C object > lib/CMakeFiles/CompilerRT-Common.dir/gcc_personality_v0.c.o > /export/home/edward/lab/llvm/build/compiler-rt/lib/ > gcc...

doesn't --target=x86_64-apple-darwin imply you don't want multi-libs, and an x86_64-only compiler? Shantonu Sent from my MacBook On Aug 23, 2009, at 11:36 AM, Jack Howarth wrote: > Current llvm-gcc-4.2 for trunk and the 2.6 release > is unable to build the i386 multilib for the > x86_64-apple-darwin target. The attached patch provides > this support. Can we get this into the 2.6 release &g...

...There appears to be a typo for for llvm_cv_no_link_all_option for Darwin, but this never seems to be used anyway. Probably worth fixing in case a new standalone project uses the LLVM makefiles. I regenerated the configure script with the required versions of autotools on Mac OS X on Intel. Shantonu Sen ssen at apple.com Sent from my Mac Pro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080205/f60f23b5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... N...

Shantonu, I just wanted to verify that you used the llvm/autoconf/AutoRegen.sh script to regenerate configure. Is that correct? Thanks, Tanya On Feb 5, 2008, at 10:10 AM, Shantonu Sen wrote: > Some low-priority fixes to the build system.... These can probably > wait after 2.2 > > 1) The...

Current llvm-gcc-4.2 for trunk and the 2.6 release is unable to build the i386 multilib for the x86_64-apple-darwin target. The attached patch provides this support. Can we get this into the 2.6 release and trunk? Jack -------------- next part -------------- Index: gcc/config/i386/t-darwin64 =================================================================== ---

...re changing the existing API contract. Or are you creating an out-of-band bitcode file, in which case the linker would never see it. ld doesn't have bitcode support, it has libLTO support, and libLTO is what processes the bitcode. <http://opensource.apple.com/source/ld64/ld64-95.2.12/> Shantonu Sen ssen at apple.com Sent from my Mac Pro On Dec 4, 2009, at 2:49 PM, John Criswell wrote: > Shantonu Sen wrote: >> Are you building llvm-gcc yourself? If so, what version? >> >> Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode ge...

Hi, Here is an updated version of the patch using address space 257. Zoltan On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen <ssen at apple.com> wrote: > Maybe 257 would be better (or other unused), because of r70197, which gives > special behavior for <256 > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > > On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: > &...

..." behavior, you could tweak the test case as needed, I suppose. But under aggressive optimization, you rapidly approach "must copy" semantics, and then the question is why you don't do that for even the degenerate cases. So again, it turns into an optimization test case. Shantonu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080312/a9121da4/attachment.html>

...sudo ln -s ../../Developer/usr/lib/libLTO.dylib /usr/lib/libLTO.dylib 2) If you still get errors, try installing the libLTO.dylib from your LLVM build into /Developer/usr/lib. Make sure that if you're on a 64-bit machine, you built llvm for x86_64-apple-darwin10 (which should be the default) Shantonu Sen ssen at apple.com Sent from my Mac Pro On Dec 4, 2009, at 1:57 PM, John Criswell wrote: > John Criswell wrote: >> Dear All, >> >> I'm trying to use transparent link-time optimization on Mac OS X. >> >> I've got Xcode 3.2 installed, and I'm tryin...

...3 456 Block_release(copyPrintXAndY); return 0; } $ clang -I$PREFIX/include -fblocks -c foo.c $ clang -L$PREFIX/lib -Wl,-rpath,$PREFIX/lib -o foo foo.o - lBlocksRuntime $ ./foo 123 456 $ I've also tried similar steps on Ubuntu Linux, as well as with llvm- gcc-4.2, which also worked. Shantonu Sen ssen at apple.com Sent from my Mac Pro On Sep 16, 2009, at 8:00 AM, Shantonu Sen wrote: > The Blocks language and implementation specifications are checked into > clang/docs. > > More generally, on Mac OS X, the blocks runtime is linked into the C > library ("libSystem&qu...

Shantonu Sen wrote: > Are you building llvm-gcc yourself? If so, what version? > > Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode generated by newer self-built compilers. > Thanks. A bitcode format mismatch was the problem. I'm not sure if th...

...ocal on ELF; if you need it for other targets, I recommend looking at adapting it. Dan On May 4, 2009, at 2:59 PM, Zoltan Varga wrote: > Hi, > > Here is an updated version of the patch using address space 257. > > Zoltan > > On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen <ssen at apple.com> wrote: > Maybe 257 would be better (or other unused), because of r70197, > which gives special behavior for <256 > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > > On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: >...

...lly portable (it doesn't appear to compiler correctly with llvm-gcc and clang on Linux), and install its headers (doesn't appear to). I can spend some time on this, since I have some familiarity with libdispatch (Apple's APIs that heavily use Blocks for developer convenience). Shantonu Sent from my MacBook On Sep 15, 2009, at 4:42 PM, Edward O'Callaghan wrote: > Good day, > > I been working on the CMake build system (which is nice and portable) > + code clean ups over the whole Compiler-RT software suit. > I recently added Blocks to the CMake build system bu...

...version of the effective type of the object, —anaggregate or union type that includes one of the aforementioned types among its members (including, recursively,amember of a subaggregate or contained union), or —a character type. C89 and C++ have similar language. On Mar 11, 2008, at 10:22 PM, Shantonu Sen wrote: > Does the test case indicate the why it was added? Actually it's testing something else entirely and tripped over this before it got to what it's supposed to be testing:( Just assumed it would work, as it does with gcc's codegen, of course. > More of an implementat...

....2? 4.0 and >=4.2? dnl Verify that GCC is version 3.0 or higher if test "$GCC" = "yes" then AC_COMPILE_IFELSE([[#if !defined(__GNUC__) || __GNUC__ < 3 #error Unsupported GCC version #endif ]], [], [AC_MSG_ERROR([gcc 3.x required, but you have a lower version])]) fi Shantonu Sen ssen at apple.com Sent from my Mac Pro On Mar 20, 2008, at 3:14 PM, Eric Christopher wrote: > > On Mar 20, 2008, at 3:00 PM, Joachim Durchholz wrote: >> Hi all, >> >> I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the >> (broken-for-LLVM) gcc-...