similar to: [ThreadSanitizer] Get deadlocks working

Hi all, As per the instructions here <http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access>, I contacted Chris Lattner to obtain commit access but haven't received a response (either positive or negative). What's the expected turnaround time for this (I contacted him five days ago)? In case he's currently unavailable, is there someone else I could contact? Thanks,

>You could, in the LTO pipeline, reinsert GlobalsAA after the SLPVectorizer (not saying you should). I didn't realise that adding GlobalsAA* after* SLPVectorizer could help. Thanks for this tip. >There is something fishy. Do you have a test case that reproduce with llvm-lto? I'm currently looking at a proprietary benchmark. I'll try to extract out a simple test case and send it.

that would be an escaping global, and as far as I know is handled separately in GlobalsAA (AnalyzeUsesOfPointer checks if a global is used as operand to a function) On December 4, 2015 11:47:20 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote: >It is if one of the operands is or can alias a global ? >On Fri, 4 Dec 2015 at 18:16, Vaivaswatha Nagaraj <vn at

Hi James, Thank you for the response. I understand the concern about malloc/free hooks. Could we detect that a program has setup malloc hooks (assuming we're in a whole program compilation) and make assumptions (such as onlyAccessesArgMem()) when the program hasn't setup malloc hooks? Using a command line flag could be one option too. I'm currently working on a program where having

> On Dec 4, 2015, at 10:33 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Vaivaswatha Nagaraj" <vn at compilertree.com> >> To: "James Molloy" <james at jamesmolloy.co.uk>, "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM Dev" <llvm-dev at

Hi Mehdi, Thank you for the response. I'm actually on an LTO setup and was referring to PassManagerBuilder::addLTOOptimizationPasses. Here, GlobalsAA is scheduled to run well ahead of SLPVectorizer. However since GlobalsAA is a module pass, it runs once and a bunch of passes, including SLPVectorizer is run for each function. When one of them invalidates the analysis, rest of the functions do

On Thu, Jun 21, 2012 at 2:29 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Thu, Jun 21, 2012 at 1:23 PM, Kostya Serebryany <kcc at google.com> wrote: > >> On Thu, Jun 21, 2012 at 12:52 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> On Thu, Jun 21, 2012 at 1:42 AM, Kostya Serebryany <kcc at google.com>wrote: >>>

>there would be two disjoint global states In some sense yes, but technically not disjoint. Functions marked with this attribute should still be able to access the globals within the program under compilation, if its not marked with ReadNone. >If malloc and free can both use global variables (there is no notion of library in the compiler) Inaccessible state here refers to any global that is

Hi James, Thanks for the help. From the log, I could infer that SLP vectorizer is not preserving alias analysis, preventing GVN from getting the info. Although the first function to get compiled has GlobalsAA available during GVN, rest of them do not as SLP vectorizer run on that function invalidates GlobalsAA which is a module pass. Is there a way to force re-computation of a particular

>What if you had bitcode versions of your C library Then the definitions for these functions would be available. Would we still set function attributes to these functions in FunctionAttrs.cpp if their definitions were available? >This also seems a bit tailored to malloc/free, and can't work for user-defined allocation functions I don't think so. For example, printf would have the

>what is a non-public state that no-one but you can access? (I’d call that private). malloc and free could both use global variables that are defined in libc, but are inaccessible to the program under compilation. >if you’re attribute is saying they have some internal state, then malloc() cannot access the state of free() and vice versa. Which is why it would be preferable to call it

On Thu, Jun 21, 2012 at 1:23 PM, Kostya Serebryany <kcc at google.com> wrote: > On Thu, Jun 21, 2012 at 12:52 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Thu, Jun 21, 2012 at 1:42 AM, Kostya Serebryany <kcc at google.com>wrote: >> >>> Can we alter the build system so that when building a run-time library >>> it modifies all

On Thu, Jun 21, 2012 at 1:30 PM, Chandler Carruth <chandlerc at google.com>wrote: > Can we alter the build system so that when building a run-time library it >>>>> modifies all .cpp files like this: >>>>> namespace FOO { >>>>> <file body> >>>>> } >>>>> This will give us essentially the same thing,

>but is there or is there not accessible, visible state, Wouldn't ReadNone and/or ReadOnly cover that? If ReadNone is set, it means it doesn't access any of the visible (accessible) states. - Vaivaswatha On Fri, Dec 4, 2015 at 3:17 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I don't think the attribute as is is strong enough to do what you

FWIW see also http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043301.html As far as I understand DFSan functionality isn't required for libFuzzer to work, so it should be safe to disable DFSan support on Mac. On Wed, Jul 8, 2015 at 7:45 AM, Kostya Serebryany <kcc at google.com> wrote: > +pcc , glider > > On Mon, Jul 6, 2015 at 12:59 PM, Juan Ceasar <juan.d.ceasar at

writing into operands is not the same as writing to globals right? I added printf in the same category since we were discussing writing to globals. On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote: >Hi, > >I just want to reiterate: printf and friends do *not* fall into this >category as they can write to their operands (unless you parse

On Thu, Jun 21, 2012 at 1:34 PM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Thu, Jun 21, 2012 at 1:30 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> Can we alter the build system so that when building a run-time library >>>>>> it modifies all .cpp files like this: >>>>>> namespace FOO { >>>>>>

On Thu, Jun 21, 2012 at 1:04 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Thu, Jun 21, 2012 at 11:52 AM, Chandler Carruth <chandlerc at google.com>wrote: >> >> Hi, >>> >>> Yes, stlport was a pain to deploy and maintain + it calls normal >>> operator new/delete (there is no way to put them into a separate namespace). >>>

(resurrecting the thread, as much is discussed here already) Formulating Kostya's suggestion: What do you think of compiling LLVM sources into ASan/TSan runtime by just taking the library sources, providing custom compiler (target) flags *and* a flag "-Dllvm=__sanitizer_llvm"? Yeah, it's hacky and applicable to LLVM libs, but OTOH we don't plan to use smth else for now (in

Reviving the discussion. The cool cmake-build of compiler-rt is not completely functional, but allows sanitizer runtimes to reuse LLVM code with almost no dirty hacks. Suppose I want to run call functions from LLVM libs (currently: LLVMDebugInfo, LLVMSupport) from sanitizer runtime. 1) I can simply include LLVM headers in sanitizer runtime, and it compiles and builds static asan runtime