similar to: [LLVMdev] To APR Or Not To APR. That is the question.

On Sun, Sep 12, 2004 at 04:21:22PM -0700, Reid Spencer wrote: > Downside: > * Makes LLVM dependent on a third party library > * Makes LLVM platform support dependent on > * Error handling in APR is somewhat strange and it could be quite > difficult for us to continue to meet the "throw std::string" > approach we have today. I vote

On Sun, 12 Sep 2004, Reid Spencer wrote: > Our use of APR would be limited to the lib/System library. That is, we > would provide very thin C++ veneers on top of APR's C interface that > match the current lib/System and lib/Support APIs. I think that optionally supporting a an APR interface would not be a bad idea of obscure platforms, but LLVM should not depend on it. I think that

The BGL (Boost Graph Library) defines tie(), which is exactly what the tie() defined in STLExtras.h. The header files of GBL use boost::tie(), and other boost libraries use boost::tie() too. How to resolve the ambiguity for compiler? -- Tzu-Chien Chiu, 3D Graphics Hardware Architect <URL:http://www.csie.nctu.edu.tw/~jwchiu>

On Fri, Dec 26, 2008 at 8:06 PM, Misha Brukman <brukman at gmail.com> wrote: > On Dec 22, 7:34 pm, Talin <viri... at gmail.com> wrote: > > (Forwarding this to llvm-dev) > > > > This patch adds a unit test framework to LLVM, along with a sample unit > test > > for DenseMap. I don't expect this patch to be accepted as-is, this is > mainly > > a

2008/12/27 Mark Kromis <greybird at mac.com> > Just a curiosity question, why push for gtest vs Boost Test or > a different test suite? > I normally use Boost, and their test suite, so I'm more familiar with that. > So I was wondering is one better then the other, or is it just that someone > makes a patch for it? > I looked more into Boost.Test to see what's in

2008/12/27 Mark Kromis <greybird at mac.com> > Is this something your planning as putting in the tree, >> thus require pulling in changes from google (license allowing), or does user >> need to have the libraries/headers pre-installed? >> > > Including it in the tree is the most reasonable thing to do. No point in > inconveniencing the user over tiny libraries

On Dec 27, 2008, at 7:41 PM, Misha Brukman wrote: > 2008/12/27 Mark Kromis <greybird at mac.com> > Just a curiosity question, why push for gtest vs Boost Test or a > different test suite? > I normally use Boost, and their test suite, so I'm more familiar > with that. So I was wondering is one better then the other, or is it > just that someone makes a patch for

I'm re-thinking my penchant for automake. automake is great for many standard applications that just need to get portable makefiles up and running quickly. However, it turns out that LLVM is "different enough" from a standard application that automake might not be the best choice. Here's some of the problems I've run into: 1. There's no way to tell automake to build

Actually, Misha, that won't work. The -C option is used directly in docs/Makefile. So the change will have to go into docs/Makefile. Either that or upgrade install to version 5. Reid. On Thu, 2005-02-17 at 11:33, Misha Brukman wrote: > On Thu, Feb 17, 2005 at 01:21:20PM -0600, Feng Chen wrote: > > llvm[1]: Installing HTML documentation > >

Constant *strcon==ConstantArray::get("Value : %d\n"); Sorry Typo. On Tue, 21 Dec 2004, Misha Brukman wrote: > On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > > I have this call instruction to printf inserted which is causing > > an assertion failure. Any pointers to where I am wrong : > > > > Function

Just a curiosity question, why push for gtest vs Boost Test or a different test suite? I normally use Boost, and their test suite, so I'm more familiar with that. So I was wondering is one better then the other, or is it just that someone makes a patch for it? Regards Mark Kromis On Dec 27, 2008, at 12:26 AM, Keir Mierle wrote: > > > On Fri, Dec 26, 2008 at 8:06 PM, Misha

On Wed, Jun 23, 2004 at 03:50:09PM -0500, Patrick Meredith wrote: > MetaSplit is an anlysis I just finished writing. It doesn't alter > anything, all it does is build a set of "program instructions". For > some reason even though if I run it with any other combination of > passes I've found, anytime I run it with mem2reg I get a seg fault in > dyn_cast!

Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" but there was no output. Maybe this is the probelm, I do have CXX = g++ -mcpu=v9 CC := gcc -mcpu=v9 in the Makefile.config. Do I need to add -m64 as well? Thanks. Shukang On Thu, 7 Oct 2004, Misha Brukman wrote: > Is your compiler configured to define __sparcv9 when it compiles? > The following should tell

2008/12/27 Mark Kromis <greybird at mac.com> > So are you planning on maintaining whatever test system, or just have them > as a pre-requisite. For example are you going to have the gtest > incorporated, or have them install it separately first? I was under the > impression that the user would have to install gtest first. > The current plan is to check in the unittest

On Dec 27, 2008, at 11:01 PM, Misha Brukman wrote: > 2008/12/27 Mark Kromis <greybird at mac.com> >> Is this something your planning as putting in the tree, thus >> require pulling in changes from google (license allowing), or does >> user need to have the libraries/headers pre-installed? >> >> Including it in the tree is the most reasonable thing to do.

I'm working on an update to the patch. The only thing holding me up is trying to come to a final decision as to where all the various pieces should live. Specifically, the Google Test library, and the actual unit tests themselves. On Mon, Dec 29, 2008 at 9:17 AM, Chris Lattner <clattner at apple.com> wrote: > On Dec 27, 2008, at 8:54 PM, Talin wrote: > > Although I haven't

On Fri, 20 Aug 2004 08:52:28 -0700 Reid Spencer <reid at x10sys.com> wrote: > Hi Jeff, > > On Fri, 2004-08-20 at 08:07, Jeff Cohen wrote: > > OK. I've built the front end without any heartaches, but I did > > encountered the following glitches: > > > > The documentation of --with-llvmgccdir is a bit ambiguous. I had to > > try several paths

On Thu, Feb 17, 2005 at 11:39:27AM -0800, Reid Spencer wrote: > Actually, Misha, that won't work. Sorry, Reid, but I think it will, for the following reason: I don't really know what the -c (lowercase) option does, but install says it's ignored anyway, so that's irrelevant for GNU install. We're talking about the -C option (uppercase). > The -C option is used directly

On Wed, 23 Jun 2004, Patrick Meredith wrote: > What's different about code that's been mem2reg'd from straight front end > code, or anything that mem2reg hasn't been run on? PHINODES! Yup, front-ends generally don't produce SSA form. :) > It appears to be crashing when I try to cast a Value* that's really a > BB* (from the PHInode operands) to a User*,

On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > (can't imagine it won't work). We prefer #include <cstdio>, since this is C++ after all. :) -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu