similar to: ABI Breaking Checks

Hi all, An issue that come up from time to time and has cost hours for debug for many of us and users of LLVM is that an assert build isn’t ABI compatible with a release build. The CMake flags that controls this behavior is LLVM_ABI_BREAKING_CHECKS ( LLVM_ABI_BREAKING_CHECKS:STRING Used to decide if LLVM should be built with ABI breaking checks or not. Allowed values are WITH_ASSERTS (default),

I tried building boost 1.45 release with clang 2.9 following instructions on http://blog.llvm.org/2010/05/clang-builds-boost.html but got the following result: $ clang++ --version clang version 2.9 (trunk 123420) Target: x86_64-apple-darwin10 Thread model: posix $ ./bjam toolset=clang Building the Boost C++ Libraries. Performing configuration checks - has_icu builds : no

> On Nov 16, 2016, at 12:05 PM, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > > > > On 11/16/16 11:48 AM, Mehdi Amini via llvm-dev wrote: >> Hi all, >> >> An issue that come up from time to time and has cost hours for debug for >> many of us and users of LLVM is that an assert build isn’t ABI >> compatible with a release build.

>>> 1. The static constructor contortions in place to handle the >>> extremely >>> unlikely case of a static object constructor writing to one of the >>> standard streams. >> >> I also dislike this strongly, but it isn't really related. > > Isn't this the motivation behind "#include <iostreams> is hereby >

On Fri, 17 Aug 2007, David Greene wrote: >> Posix is pretty available, what system doesn't have them? > > Windows, for one. If POSIX is ok, it's better in my mind to just directly Windows has POSIX calls. > use open, write and friends, which is what I do now. Going the cstdio > route should only be done for portability reasons to support non-POSIX > systems. I

On Thursday 16 August 2007 17:59, Chris Lattner wrote: > On Thu, 16 Aug 2007, David Greene wrote: > > Actually, there's another reason not to use unlocked calls. They require > > POSIX compliance. > > Posix is pretty available, what system doesn't have them? Windows, for one. If POSIX is ok, it's better in my mind to just directly use open, write and friends,

On Friday 17 August 2007 17:01, Chris Lattner wrote: > On Fri, 17 Aug 2007, David Greene wrote: > > Ah. Basically operator<< for FILE*. I don't see a lot of benefit to > > redefining operator<< for every type just to avoid ostreams. The > > problem isn't basic_ostream _per_se_. There are two issues we're > > worried about: > > The

On Fri, 17 Aug 2007, David Greene wrote: > Ah. Basically operator<< for FILE*. I don't see a lot of benefit to > redefining operator<< for every type just to avoid ostreams. The > problem isn't basic_ostream _per_se_. There are two issues we're > worried about: The problem is basic_ostream and the design of the whole iostreams library. Use of virtual base

On Sunday 19 August 2007 19:34, Chris Lattner wrote: > How so? It's entirely possible to use FILE*'s without virtual > methods: just don't use iostreams. But you lose some flexibility. It may very well be a valid choice, but it needs to be carefully considered. But see below for more on dynamic vs. static polymorphism. > > What "overhead" are you talking

On Friday 17 August 2007 13:17, Chris Lattner wrote: > On Fri, 17 Aug 2007, David Greene wrote: > >> Posix is pretty available, what system doesn't have them? > > > > Windows, for one. If POSIX is ok, it's better in my mind to just > > directly > > Windows has POSIX calls. Ok, I'll admit I don't know a lot about what's available there.

On Tue, 14 Aug 2007, David Greene wrote: >> Yes, this is one advantage, another is that we wouldn't have to fix the >> same bug in multiple places :) > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > given the current design. Ok, cool. > I'm trying out a few interesting things here based on custom streambufs. > It requires

On Thu, 16 Aug 2007, David Greene wrote: > Actually, there's another reason not to use unlocked calls. They require > POSIX compliance. Posix is pretty available, what system doesn't have them? > To get portability and most of the performance I plan to look at unbuffered > stdio. Buffering is goodness, no? -Chris -- http://nondot.org/sabre/ http://llvm.org/

I'm not sure if I should bother you team with this, apologies in case it's a bother. I'm trying gcc 6.2.1 (from devtoolset-6) with R, everything seems to work just fine, except for mzR. Here is failed build: g++ -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o mzR.so cramp.o ramp_base64.o ramp.o RcppRamp.o RcppRampModule.o rnetCDF.o RcppPwiz.o RcppPwizModule.o RcppIdent.o

Dear R contributors, Considering the following sample C code, that illustrates two possible uses of a Cholesky decomp for inverting a matrix, equally valid at least in theory: SEXP test() { int d = 2; int info = 0; double mat[4] = {2.5, 0.4, 0.4, 1.7}; double id[4] = {1.0, 0.0, 0.0, 1.0}; double lmat[3]; F77_CALL(dpotrf)("L", &d, mat, &d, &info); lmat[0] = mat[0]; lmat[1]

Hi all, Just wondering if anybody knows the answer to this mystery? I upgraded my Dom0 from Xen 3.0.4 + kernel 2.6.16.33-xen to Xen 3.1.0 + kernel 2.6.18-xen. After the upgrade, my domU (WInXP home edition) popped up a message saying that it needed to be re-registered with Microsoft, owing to significant changes in the hardware environment on which it is running. Something about windows

I have been building a package around a sequence of S4 classes which I have coded in separate *.R files in the "./R" subdirectory of the package. The package builds without error, but when I load it in R I get: Error in reconcilePropertiesAndPrototype(name, slots, prototype, superClasses) : Class "xxxx" extends an undefined class ("yyyyyy" I guess R is trying to

Dear R forum, The example below is just an indicative one and I have constructed it. My real life data and conditions are different. I have a data.frame as given below mydat = data.frame(A = c(19, 20, 19, 19, 19, 18, 16, 18, 19, 20), B = c(19, 20, 20, 19, 20, 18, 19, 18, 17, 16)) if (length(mydat$A) > 10) { stop("A has length more than 10") }else if (max(mydat$B) > 18) {

On Wed, 2007-08-15 at 09:32 -0700, Chris Lattner wrote: > On Tue, 14 Aug 2007, David Greene wrote: > >> Yes, this is one advantage, another is that we wouldn't have to fix the > >> same bug in multiple places :) > > > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > > given the current design. > > Ok, cool. >

(cc'ing non-legacy llvm-dev this time; apologies if you get this twice. Please don't reply-all to the first one.) On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org> wrote: > Dear testers, > > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at > r258223. (It took a little longer than I'd planned, sorry about that.) > > There

I''m currently using ruby-postgres (the compiled interface to PostgreSQL), and I''m seeing a huge performance hit with larger :binary fields in ActiveRecord subclasses owing, it appears, to the use of the bytea field type and the fact that using that datatype necessitates an in-memory "unescape" conversion. The best I can tell from looking at the Postgres Active