search for: jyasskin

On OS X 10.5.5 I get an error that ld doesn't support -export-dynamic: dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ ../src/configure --prefix=`pwd`/../install && make VERBOSE=1 ... dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ make VERBOSE=1 for dir in lib/System lib/Support utils lib/VMCore lib tools/llvm-config tools docs; do \ if [ ! -f $dir/Makefile ]; then \ /Users/jyasskin/s...

For those of you who haven't noticed, I'm planning to commit a major change to the Makefile rules tomorrow evening (Tuesday) if there are no complaints about it between now and then. This needs testing on Darwin. I've heard back from Linux on many platforms and even FreeBSD, which is fantastic, but I'm told that lots of LLVMers are running Darwin and I haven't heard a peep

On Dec 16, 2008, at 10:34 AM, Jeffrey Yasskin wrote: > I'm on OSX 10.5, trying to build a svn checkout of llvm-gcc. I've also > checked out llvm. Both are synced to r61075. hi Jeffrey, This patch should have fixed the problem: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071210.html Please update and try again, sorry for the breakage! -Chris

...-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5488) My configure line was: # ../src/configure --prefix=/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install --program-prefix=llvm- --enable-llvm=/Users/jyasskin/src/llvm/trunk/obj/ --with-arch=nocona --with-tune=generic --with-gxx-include-dir=/usr/include/c++/4.0.0 --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9 --enable-languages=c,c...

I'm trying to build the 2.5 prerelease on my MacBook, and I'm getting a bus error in tblgen: $ rm -r * && ../src/configure --prefix=`pwd`/../install && make -j1 VERBOSE=1 ENABLE_OPTIMIZED=0 ... llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td /Users/jyasskin/src/llvm-2.5/obj/Debug/bin/tblgen -I /Users/jyasskin/src/llvm-2.5/src/lib/VMCore -I /Users/jyasskin/src/llvm-2.5/src/include -I /Users/jyasskin/src/llvm-2.5/src/include -I /Users/jyasskin/src/llvm-2.5/src/lib/Target /Users/jyasskin/src/llvm-2.5/src/include/llvm/Intrinsics.td -o /Users/jyasskin/src/...

Thanks for the quick answer! Syncing to r61112 got rid of the ICE, but I still get the following error: make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH" "TARGET_SUBDIR=i686-apple-darwin9" "bindir=/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install/bin" "datadir=/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install/share" "exec_prefix=/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install" "includedir=/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install/include" "da...

> I don't know anything about Solaris, but your paste doesn't actually > contain any errors, just warnings (unless I'm reading "ld: warning: > relocation error:" wrong). It might help to run make without -j until > it fails, and then use `make VERBOSE=1` to print the exact commands > it's running. Sorry. There was so much output I wasn't sure how much

LLVMers, The 2.5 pre-release is available for testing: http://llvm.org/prereleases/2.5/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary (please compile llvm-gcc with fortran if you can). 2) Run make check, send me the testrun.log 3) Run "make

...gt; > > this part of LLVM. > > > > > > It looks like that code segment has been touched by a number of people: > > > > > > 147615 rafael if (JITExceptionHandling) { > > 49924 geoffray uintptr_t ActualSize = 0; > > 91464 jyasskin SavedBufferBegin = BufferBegin; > > 91464 jyasskin SavedBufferEnd = BufferEnd; > > 91464 jyasskin SavedCurBufferPtr = CurBufferPtr; > > 82418 rnk > > 47079 geoffray BufferBegin = CurBufferPtr = > > MemMgr->startExceptionTa...

...d()` (e.g. > `Function::arg_{begin,end}()`). These don't play nice with range-for > loops (we are already seeing this come up in LLD). We probably should > adopt some lightweight "range" class and a naming convention > (`foo_all()`?) that will interact well with range-for. jyasskin, you > have some standards proposals for such a class, maybe you could try > bringing that into tree? The C++ proposal changes rapidly. While it would be great to get usage experience from LLVM in order to inform the C++ proposal, I don't have "what will eventually be in C++" t...

...linker. To avoid that, I'm tentatively using the .a. In configure, behind a --with-oprofile argument, I have: LIBS="$LIBS ${llvm_cv_oppath}/libopagent.a -lbfd -liberty -ldl" This causes llvm-config to print: $ ./Debug/bin/llvm-config --libs --ldflags --cxxflags -L/usr/local/google/jyasskin/llvm/oprof/dbg/Debug/lib -lpthread -lffi -ldl -lm /usr/local/lib/oprofile/libopagent.a -lbfd -liberty -ldl -I/usr/local/google/jyasskin/llvm/oprof/dbg/../src/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fPIC -Woverloaded-virtual -lLLVMXCore -lLLVMSparcAsmPrin...

On Jan 8, 2013, at 4:26 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote: >> Another thing to bring up is that we have a lot of classes which have >> method pairs `foo_begin()` and `foo_end()` (e.g. >> `Function::arg_{begin,end}()`). These don't play nice with range-for >> loops (we are already seeing this come up in...

Good catch! I meant "for iterator" of course. Attached is a corrected patch together with an old patch for clang just to keep them together. Could someone commit these, please? Thanks, Victor 2009/11/4 Jeffrey Yasskin <jyasskin at google.com> > + // Otherwise this is a copy constructor for const_iterator. > > Do you mean "for iterator"? > > Otherwise, looks good to me. If you can commit this, please do. > Otherwise, someone else should as I'm not going to be around tomorrow. > >...

On Fri, Apr 16, 2010 at 9:30 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> I'll forward your next draft back to the stackless folks, unless you >> want to pick up the thread with them. > > Their reply: http://thread.gmane.org/gmane...

On Wed, Jul 21, 2010 at 9:50 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> This (Unknown constant! in bitcode writer when -g is used) is a known >> bug in CloneModule, because it is not cloning MDNodes appropriately. > > What's the link to the bug report? Are you fixing it? PR 7689. Fixed in r109117. - Devang

...vich at googlemail.com> > Good catch! I meant "for iterator" of course. Attached is a corrected patch > together with an old patch for clang just to keep them together. > Could someone commit these, please? > > Thanks, > Victor > > 2009/11/4 Jeffrey Yasskin <jyasskin at google.com> > > + // Otherwise this is a copy constructor for const_iterator. >> >> Do you mean "for iterator"? >> >> Otherwise, looks good to me. If you can commit this, please do. >> Otherwise, someone else should as I'm not going to be aro...

...d-join. This may > or may not technically allowed in C, but it seems generally undesirable, and > it’s extremely undesirable in CL where these kinds of thread joins are a > fundamental of the programming model. > > —Owen > > > On Aug 6, 2013, at 5:36 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote: > > Chandler pointed out another interpretation of C11/6.7.3.1, in which > 'restrict' only addresses aliasing within a single thread. If that's > the right interpretation, then it's a bug in LLVM that it moves > noalias pointers across memor...

mike-m, is there any way to configure doxygen to produce human-readable anchors? They might have avoided the duplication on this thread, since Erick and John could have seen that I was linking to their suggestions. On Fri, May 7, 2010 at 8:47 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Try http://llvm.org/doxygen/classllvm_1_1ConstantExpr.html#a2ea738dfa37ea93c71756be89ba8d92 > or http://llvm.org/doxygen/classllvm_1_1TargetData.html#64c154a7844026e76e18f792ee4ad4b3 > > On Fri, May 7, 2010 at 8:26 PM, Gang.Yao <ttoole9 at gmail.com> wro...

On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > To be clear, Chandler wasn't suggesting any change to the existing > load and store instructions. Instead, we were wondering if people like > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > atomic_exchange and atomic_add instructio...

On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > I'll forward your next draft back to the stackless folks, unless you > want to pick up the thread with them. Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475 Instead of @llvm.getcontextstacktop(%context), they want @llvm.getcurr...