similar to: [LLVMdev] MC Hammer Test results

Hello everyone At EuroLLVM I presented some testing work we have been doing on improving correctness of the MC Layer for ARM. There seemed to be interest from the community in seeing the results of this test suite. Background ----------- We are using a test suite, called MC Hammer, that compares MC with an ARM in-house implementation of the same functionality. The test space for this suite is

Full_Name: Bill Dunlap Version: 2.5.0 OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 6) Submission from: (NULL) (24.17.60.30) If you read a dcf file with read.dcf(file,fields=c("Field",...)) and the file does not contain the desired field "Field", read.dcf puts a character NA for that entry in its output matrix. If you then call write.dcf, passing it the output of

BIll, Thanks. I am seeing some problems here, for example when all the fields are missing, or all the fields in a row are missing. I've fixes for those, and will commit to R-devel shortly. On Tue, 17 Jul 2007, bill at insightful.com wrote: > Full_Name: Bill Dunlap > Version: 2.5.0 > OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 6) > Submission from: (NULL)

Hello all, I would like to assign some bits in the instructions, based on the order of mnemonics that appear in a special order. I can do it in TableGen itself, but it will not be well maintainable based on the things I want to accomplish. Therefor, I would like to do it in the c++ file which is waaay easier (at least in the concept!!). Imagine I have this in my base class in TableGen:

Oops! I mistook UDT for CDT! I've missed deadline, so... 2011/4/9 Tobias Grosser <grosser at fim.uni-passau.de>: > On 04/08/2011 08:35 PM, Vlad Krylov wrote: >> >> 2011/4/8 ether zhhb<etherzhhb at gmail.com>: >>> >>> Hi, >>> >>> 2011/4/8 Vlad Krylov<krvladislav at gmail.com>: >>>> >>>> Hi.

On 04/08/2011 08:35 PM, Vlad Krylov wrote: > 2011/4/8 ether zhhb<etherzhhb at gmail.com>: >> Hi, >> >> 2011/4/8 Vlad Krylov<krvladislav at gmail.com>: >>> Hi. >>> >>> I see that to detect scops firstly we search for regions in CFG ( by >>> RegionInfo ) and then select regions that answer some requirements ( >>> in

Hi, 2011/4/8 Vlad Krylov <krvladislav at gmail.com>: > Hi. > > I see that to detect scops firstly we search for regions in CFG ( by > RegionInfo ) and then select regions that answer some requirements ( > in ScopDetection ). Because only affine expressions in conditions and > bounds are permissible, we trying to get scalar expressions into > affine form by

2011/4/8 ether zhhb <etherzhhb at gmail.com>: > Hi, > > 2011/4/8 Vlad Krylov <krvladislav at gmail.com>: >> Hi. >> >> I see that to detect scops firstly we search for regions in CFG ( by >> RegionInfo ) and then select regions that answer some requirements ( >> in ScopDetection ). Because only affine expressions in conditions and >> bounds

How to feed pocc by jscop files which are made with -polly-export-jscop? 2011/4/8 ether zhhb <etherzhhb at gmail.com>: > Hi, > > 2011/4/8 Vlad Krylov <krvladislav at gmail.com>: >> Hi. >> >> I see that to detect scops firstly we search for regions in CFG ( by >> RegionInfo ) and then select regions that answer some requirements ( >> in

Dear R-Help, I am trying to perform forward selection on the following coxph model: >my.bpfs <- Surv(bcox$pfsdays, bcox$pfscensor) > b.cox <- coxph(my.bpfs ~ Cbase + Abase + Cbave + CbSD + KPS + gender + as.factor(eor) + Age)>stepAIC(b.cox, scope=list(upper =~ Cbase + Abase + Cbave + CbSD + KPS + gender + as.factor(eor) + Age, lower=~1), direction= c("forward")) However

On Aug 11, 2011, at 1:32 AM, James Molloy wrote: > Hi, > > I’m looking at the new ARM disassembler, and performing testing to see if there are any obvious bugs I can fix. Overall it looks really nice – I’ve only found one obvious bug that I’m packaging up a patch for now. Glad you're liking it! I haven't really done comprehensive testing yet—it passes all the decoding tests

Hello, on the problems cross-building compiler-rt: Tried to follow https://llvm.org/docs/HowToCrossCompileBuiltinsOnArm.html which lead to this cmake: cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF

Hi, I'm looking at the new ARM disassembler, and performing testing to see if there are any obvious bugs I can fix. Overall it looks really nice - I've only found one obvious bug that I'm packaging up a patch for now. Currently it does not provide information as to whether a particular bitpattern was UNPREDICTABLE or not. For example, an invalid bitpattern may return correct

Hey everyone. My mind has been boggled by an issue I ran into a few hours ago. I am completely lost as to why the following code behaves the way it does and would appreciate any hints from you guys. It would already be super-helpful if others could post their output for the following so that I can figure out whether this is weirdness specific to my setup or a global phenomenon. So far,

Hello again! Tried out the small Hello World Setup, worked as intended: root at christian-forschung-virtual-machine:/home/progs# clang -v --target=arm-linux-gnueabihf hello.c -o hello -fuse-ld=lld clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a152c7a4b7ba8f4cb9532ead9a38a7121db43d50) (https://git.llvm.org/git/llvm.git/ 1959ce6f3e01241919968ac1911fd45660239d23) Target:

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

Hi. I see that to detect scops firstly we search for regions in CFG ( by RegionInfo ) and then select regions that answer some requirements ( in ScopDetection ). Because only affine expressions in conditions and bounds are permissible, we trying to get scalar expressions into affine form by AffineSCEVIterator. At present there plugs for scev types Truncate, ZeroExtend, SignExtend, UDivExpr,

Hello Lang, thanks for the suggestion :) it's very interesting. I'll take a read to the email you've pointed out there to understand how it works. Btw, does this mean that only your allocator is able to handle or support this type of constraint? As a follow up to my previous email, the following code is a real example of what i was explaining, Lang this example is exactly why i need

On 22 January 2016 at 12:20, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> 1) I realise this is a somewhat silly question, but is this still >> acceptable "undefined behaviour"? > > Yes, it is. I always thought these out-of-range instructions did produce an "undef" rather than allowing fully-general undefined behaviour (otherwise we

Hello Christian, I've put some comments inline, On Sun, 3 Feb 2019 at 13:11, Christian Richter <christian.richter at hsu-hh.de> wrote: > > Hello again, > > so after I successfully build the compiler-rt for armv6 I tried to > actually use it in compiling a small helloworld for a baremetal arm > (consisting of barehelloCLANG.c and a small io.h + io.c) , but the >