search for: partigas

...sanitizer test in the dump below complains: FAIL: LLVM :: Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll (3773 of 6811) ******************** TEST 'LLVM :: Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll' FAILED ******************** Script: -- /Users/partigas/Desktop/src/build/Debug+Asserts/bin/opt < /Users/partigas/Desktop/src/llvm/test/Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll -asan -asan-initialization-order -S | /Users/partigas/Desktop/src/build/Debug+Asserts/bin/FileCheck /Users/partigas/Desktop/src/llvm/test/Instrument...

...sanitizer test in the dump below complains: FAIL: LLVM :: Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll (3773 of 6811) ******************** TEST 'LLVM :: Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll' FAILED ******************** Script: -- /Users/partigas/Desktop/src/build/Debug+Asserts/bin/opt < /Users/partigas/Desktop/src/llvm/test/Instrumentation/AddressSanitizer/instrument_initializer_metadata.ll -asan -asan-initialization-order -S | /Users/partigas/Desktop/src/build/Debug+Asserts/bin/FileCheck /Users/partigas/Desktop/src/llvm/test/Instrument...

...a library and the user implements its custom pass, which dump the code (implemented as a FunctionPass, but not as Printer)? You also missed in your changes the declaration of llvm::createGCInfoDeleter() in include/llvm/CodeGen/Passes.h -Dmitry. On Mon, Feb 18, 2013 at 9:34 PM, Pedro Artigas <partigas at apple.com> wrote: > > Hello Yiannis, > > Your patch seems fine. It is option #2 which I am glad to hear solves the > issue. It also removes more lines than it adds, I like patches that fix > issues and have that property! > > Anyhow if you add some testing, as you sug...

...t;echristo at gmail.com> wrote: > > There's a lot of cut and paste in those routines. Can you do something > to unify it a bit? Also, do we have any ports that have support > floating point exceptions? > > -eric > > On Thu, Aug 7, 2014 at 3:07 PM, Pedro Artigas <partigas at apple.com> wrote: >> Hello All, >> >> the patch below adds a target lowering hook to state that the target supports (or not) floating point exception behavior. The patch is small and contains one possible use for the hook (folding potentially exception raising fp operations...

Hello All, the patch below adds a target lowering hook to state that the target supports (or not) floating point exception behavior. The patch is small and contains one possible use for the hook (folding potentially exception raising fp operations). Any comments? Thanks Pedro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: opensource1.txt

...ssembly. It seems to me that finishAssembly is never > called. I used git bisect and I think the commit that is responsible for this is: > d1abec365aa89a8497d9b615ccb4b21c72da9447 is the first bad commit > commit d1abec365aa89a8497d9b615ccb4b21c72da9447 > Author: Pedro Artigas <partigas at apple.com> > Date: Wed Dec 5 17:12:22 2012 +0000 > > - Added calls to doInitialization/doFinalization to immutable passes > - fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies > - fixed machine modul...

Hello All, There is an issue in AddressSanitizer today because it depends on it's doFinalization method be called before the Printer method to output the final code (that is the printer runOnModule call). This assumption seems invalid as the doFinalization method should AFAIK only be used for clean up tasks independent of activities of other passes. When I try to call doFinalization inside

Hello Yiannis, Your patch seems fine. It is option #2 which I am glad to hear solves the issue. It also removes more lines than it adds, I like patches that fix issues and have that property! Anyhow if you add some testing, as you suggest, you should be good to go. Thanks Pedro On Feb 16, 2013, at 6:13 AM, Yiannis Tsiouris <gtsiour at softlab.ntua.gr> wrote: >

Ping for this. On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: > After rebasing my local LLVM repo to ToT, I noticed that the > finishAssembly function is not executed and, thus, the stack map is not > printed at all. > > Is this a known issue or I 'm doing something wrong? > > I used a custom GCMetadataPrinter plugin but I reproduced this using the > builtin

On 02/15/2013 07:13 PM, Pedro Artigas wrote: > I am not an expert on metadata or the CG information but one of the two has to happen: I'm not an expert either but I'll give it a try! :-) > - Simply moving the deleter pass to a different spot > - Changing the doFinalization of another pass (Printer?) to do the deleter pass job (this should work now because the doFinalization order

Hi, After rebasing my local LLVM repo to ToT, I noticed that the finishAssembly function is not executed and, thus, the stack map is not printed at all. Is this a known issue or I 'm doing something wrong? I used a custom GCMetadataPrinter plugin but I reproduced this using the builtin "ocaml" GC plugin and the attached file (actually, any simple ll file that uses

...me that finishAssembly is never called. > > I used git bisect and I think the commit that is responsible for this is: > > > d1abec365aa89a8497d9b615ccb4b21c72da9447 is the first bad commit > > commit d1abec365aa89a8497d9b615ccb4b21c72da9447 > > Author: Pedro Artigas <partigas at apple.com> > > Date: Wed Dec 5 17:12:22 2012 +0000 > > > > - Added calls to doInitialization/doFinalization to immutable passes > > - fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies > > -...

Hello Yiannis, I am not an expert on metadata or the CG information but one of the two has to happen: - Simply moving the deleter pass to a different spot - Changing the doFinalization of another pass (Printer?) to do the deleter pass job (this should work now because the doFinalization order is the reverse of the doInitialization order) Option 1 is a smaller change, option 2 will make the code