similar to: [LLVMdev] Prevent clang from replacing code with library calls

Hi Jim, I have tried "-fno-builtin" but it didn't help. Thanks, David On Tue, Aug 5, 2014 at 12:12 AM, Jim Grosbach <grosbach at apple.com> wrote: > Hi David, > > "-fno-builtin” is probably what you want. > > -Jim > > On Aug 4, 2014, at 2:19 AM, David Sela <sela.david at gmail.com> wrote: > > Clang optimizes code by replacing some parts

Hi, I downloaded the latest NDK (r10) and compiled with the following cmd: *arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0* It still produces assembly with a call to "memcpy". Maybe the -*fno-builtin *is broken also in the latest release. Do you have some other idea that can help here? Thanks, David On Tue, Aug 5, 2014 at 11:00 AM, Jim Grosbach <grosbach at

> On Aug 7, 2014, at 4:12 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > >> I downloaded the latest NDK (r10) and compiled with the following cmd: >> arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0 >> It still produces assembly with a call to "memcpy". Maybe the -fno-builtin >> is broken also in the latest release. >

Greetings, I am working on a logistic regression model in R and I am struggling with the code, as it is a relatively new program for me. In searching Google for 'logistic regression diagnostics' I came Elizabeth Brown's Lecture 14 from her Winter 2004 Biostatistics 515 course (http://courses.washington.edu/b515/l14.pdf) . I found most of the code to be very helpful, but I am

I am writing a program in which I would like to take in a formula, change the response (Y) variable into something else, and then pass the formula, with the new Y variable to another function. That is, I am starting with formula <- Y~X1+X2+X3 and I'd like to do something like Y <- formula$Y newY <- f(Y) lm(newY~X1+X2+X3) So far, it seems that my

John Ackermann N8UR via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes: > I am monitoring via the SNMP driver an APC SmartUPS that has split > phase (2L + neutral) 240V input and 120/120 volt outputs. The data > for the voltages is not what I'm expecting, and I am wondering how I > should interpret it. Wow, that sounds kind of industrial. Model? Is the

Hi Anton, Thanks for the answer. The link you provided doesn't answer the question. It lists the ways to overcome the linking error if the inline was not successful. The only condition that is found there to make the compiler not inline is "when compiling without optimization". I asked the question in the forum because I think that this info is not documented and most chances that

Hi, I want to have some functions in my code inline so I use the *inline * keyword: *inline void foo() {}* On some functions the compiler inlines the function but it fails to do so on other functions and thus I get a linkage error: *error: undefined reference to 'foo'* What are the conditions that make the compiler refuse inline? Thanks, David p.s. I know that there are ways to pass

Hello, I am still progressing with very high compression and I have corrected a processing, so now very high compression (-l10 to -l13 quality settings) has really better precision and so better quality. I have also released a first draft of a new -l14 very high compression quality setting. More at: http://nhwcodec.blogspot.com/ Just a remark, the entropy coding schemes start to be less

Hi, the attached example works with bfd-ld and with gold, but not with lld: $ cat rodatareloc.s ... .align 16 leaq .JTab(%rip), %r10 jmp *(%r10, %rdx, 8) ... .section .rodata .JTab: .quad .L00, .L01, .L02, .L03, .L04, .L05, .L06, .L07 .quad .L08, .L09, .L10, .L11, .L12, .L13, .L14, .L15, .L16 $ gcc -o rodatareloc.s.o -c rodatareloc.s $ lld -o rodatareloc.so -shared

I am trying to estimate models with subsets using the NLME package. However, I am getting an error in the case below (among others): > subset <- c(rep(TRUE, 107), FALSE) > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1, subset=subset) Error in xj[i] : invalid subscript type 'closure' > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1,

I am having the same problem as one Rebecca Sela(see bellow). On 21/12/2007 12:07 AM, Rebecca Sela wrote: >* I am trying to optimize a likelihood function using NLMINB. After running without a problem for quite a few iterations (enough that my intermediate output extends further than I can scroll back), it tries a vector of parameter values NaN. This has happened with multiple Monte Carlo

Hi, I tried compiling llvm-gcc front end by giving the configure commands : $ ../llvm-gcc4-2.0.source/configure --enable-checking --enable-languages=c --target=arm-none-linux But I am getting the following kind of assembeler errors when I do "make $BUILDOPTIONS" /tmp/ccYAgFFY.s: Assembler messages: /tmp/ccYAgFFY.s:36: Error: junk at end of line, first unrecognized character is

Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly

Dear list members, I ran into the problem that neither clang 3.4 nor current trunk versions of clang ar not usable for Objective-C on ARM. This is described in the bug report http://llvm.org/bugs/show_bug.cgi?id=18622 clang 3.3 didn't have that problem, but I also need the exception handling for ARM that is only available in recent builds, as I learned. I would like to get in touch with

I am creating an R package. I ran R CMD check on the package, and everything passed until it tried to run the examples. Then, the result was: * checking examples ... ERROR Running examples in REEMtree-Ex.R failed. The error most likely occurred in: > ### * AutoCorrelationLRtest > > flush(stderr()); flush(stdout()) > > ### Name: AutoCorrelationLRtest > ### Title: Test for

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

Sounds pretty normal from what I see. It appears that this is *NOT* a true 240v UPS, but rather one that provides two legs of 120v output from two legs of 120 input, and what is seen as "L2" is actually neutral, and the line names are reporting incorrectly. With that in mind, each leg in should be 120v, as well as the outputs, which is exactly what you are seeing.(The fact tht L1 to L3

I thought the ARM EHABI added a twist to this because it created some upward dependency from the unwinder to libc++abi. Other than that, I don’t have any strong feeling where it lives. -Nick On Jan 30, 2015, at 12:33 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 20:17, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> There is a valid

On 15 March 2014 17:06, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > I would like to know what do you mean by "commoning them up"? Hi Logan, That'd be reducing ARM directives in favour of CFI, but as I said (and you too), GNU compatibility will probably be an issue for a very long time. > For the space issue, I personally don't think this is a big issue.