similar to: [LLVMdev] __main() function and AliasSet

Oh, I appologize that I should not have asked about __main() ---- it appears in FAQ. But the question remains that why call to __main() can alias stack location? I think the memory location pointed by data_X pointers are not visible to __main(). In comparison, calls to printf() do not have similar effect. On 5/14/06, Nai Xia <nelson.xia at gmail.com> wrote: > > In a code segment of

Hi Chris, I took a haste look at the "Points-to Analysis in Almost Linear Time" by Steens , your PHD thesis and SteensGaard.cpp in LLVM this afternoon. So I think: 1. Actually the basic algorithm described originally by SteensGaard does not provide MOD/REF information for functions. 2. The context insensitive part of Data Structure Analysis (LocalAnalysis) can be deemed as an

On Tuesday 16 May 2006 03:19, Chris Lattner wrote: > On Mon, 15 May 2006, Nai Xia wrote: > > > In other words, if I only use -steens-aa and the data_XXXs are all > > external global variables( and so inComplete ), > > Sounds right! > > > the call to printf will > > make the same effect, which I have tested it. > > > > Am I right ? :) >

On Wed, 17 May 2006, Nai Xia wrote: > Unfortunately, I did not locate the lines in steens-aa for "printf" special case. > In ds-aa, I found the lines below: Right, steens-aa and ds-aa share code for "local analysis", they just stitch it together into an interprocedural analysis in different ways. The code below is used for steens-aa. >

On Mon, 15 May 2006, Nai Xia wrote: > In other words, if I only use -steens-aa and the data_XXXs are all > external global variables( and so inComplete ), Sounds right! > the call to printf will > make the same effect, which I have tested it. > > Am I right ? :) If you've tested it then, yes you're right :). I haven't played with this stuff for a long time,

On 18 Oct 2015, at 23:08, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Supporting only basic block level granularity for "try ranges" may not > be sufficient for Java -- if a basic block has more than one null check > in it then throwing the NullPtrException for the first null check (if > it fails) is semantically different from throwing the

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a

On Fri, Jul 15, 2016 at 2:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > Don't we have the same problems for "exit(0)" > > > > > > This is a noreturn call, so yes, iit has another hidden control > > flow-side-effect of a slightly different kind. GCC models it as an extra >

I won’t be able to attend, but I’d be interested in hearing if any conclusions are reached on several of these topics: > On 16 Oct 2015, at 21:27, Joe Ranieri via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > - Dealing with the explosion of basic blocks that come up with > languages where almost every function call, implicit and explicit, can > raise exceptions. This

On Fri, Jul 15, 2016 at 2:30 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > However, I didn't quite understand your point about may-throw -- how > > is may-throw different from a generic side-effect (volatile store, > > syscall etc.)? All of those can't be hoisted or sunk -- we have to >

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

> On Mar 22, 2016, at 5:57 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Hi all >> >> (No idea if I have the correct audience. Please CC more people as needed). >> >> I have an UBSan

Dear All, I run following code to estimate the blocks using cokriging ( my data set has more than 50,000 data points). All the things run finely but Once I run the predict.gstat function it gave the error message - "memory.c", line 58: can't allocate memory in function m_get(). I run this code on LINUX sever but result is same. Would any one please be able to give a solution for

Hello. I'm writing an LLVM pass that is working on LLVM IR. To my surprise the following LLVM pass code generates optimized code - it does copy propagation on it. Value *vecShuffleOnePtr = Builder.CreateGEP(ptr_B, vecShuffleOne, "VectorGep"); ... packed_gather_params.push_back(vecShuffleOnePtr); CallInst *callGather =

Dear All, I am using wilcox.test to test two samples, data_a and data_b, earch sample has 3 replicates, suppose data_a and data_b are 20*3 matrix. Then I used the following to test the null hypothesis (they are from same distribution.): wilcox.test(x=data_a, y=data_b, alternative="g") I got pvalue = 1.90806170863311e-09. When I switched data_a and data_b by doing the following:

Hi all, I understand how the speculative information flow attack works. I'm trying get my head around the spectre v1 mitigation of LLVM. In the design document here : https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening. <https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening> Example: void leak(int data);void example(int* pointer1,

Hi, Thanks for your email, I understand that the execution stalls until the predicated state is computed, then we mask pointers with all_zeros_mask if there is a mis-prediction. But I understand that as soon as the condition value is available, the processor can check about it's assumptions and revert back. That is, If the branch prediction is correct during speculation, we mask with

Hi, Yeah, now I understand the problem here. Thanks. But I too have another doubt in "Bounds check bypass store" In this example in the Speculative load hardening : unsigned char local_buffer[4];unsigned char *untrusted_data_from_caller = ...;unsigned long untrusted_size_from_caller = ...;if (untrusted_size_from_caller < sizeof(local_buffer)) { // Speculative execution enters here

Hello, I have found a problem with using the glm function with a gamma family. I have a vector of data, assumed to be generated by a gamma distribution. The parameters of this gamma distribution are estimated in two ways (i) using the glm() function, (ii) "by hand", using the optim() function. I find that the -2*likelihood at the maximum found by (i) is substantially larger than that

Hello all, I've been working for the last month or so on a comprehensive mitigation approach to variant #1 of Spectre. There are a bunch of reasons why this is desirable: - Critical software that is unlikely to be easily hand-mitigated (or where the performance tradeoff isn't worth it) will have a compelling option. - It gives us a baseline on performance for hand-mitigation. - Combined