search for: unannotated

...be required to implement the definition in the current standard. I expect that P0190R0 will be discussed at the upcoming C++ Standards Committee meeting taking place the week of February 29th. Points of discussion are likely to include: o May memory_order_consume dependency ordering be used in unannotated code? I believe that this must be the case, especially given that this is our experience base. P0190R0 therefore recommends this approach. o If memory_order_consume dependency ordering can be used in unannotated code, must implementations support annotation? I believe that annotation support...

...inition in the current standard. > > I expect that P0190R0 will be discussed at the upcoming C++ Standards > Committee meeting taking place the week of February 29th. Points of > discussion are likely to include: > > o May memory_order_consume dependency ordering be used in > unannotated code? I believe that this must be the case, > especially given that this is our experience base. P0190R0 > therefore recommends this approach. > > o If memory_order_consume dependency ordering can be used in > unannotated code, must implementations support annotation? > I believe...

...> > > I expect that P0190R0 will be discussed at the upcoming C++ Standards > > Committee meeting taking place the week of February 29th. Points of > > discussion are likely to include: > > > > o May memory_order_consume dependency ordering be used in > > unannotated code? I believe that this must be the case, > > especially given that this is our experience base. P0190R0 > > therefore recommends this approach. > > > > o If memory_order_consume dependency ordering can be used in > > unannotated code, must implementations suppor...

...ld be required, > and how many bugs you found, when running this over LLVM and Clang? > Two months ago it was like this: I compiled llvm and clang with the recently added -Wimplicit-fallthrough diagnostic > and analyzed the results. For those who are curious: there are about 400 > 'unannotated fall-through' warnings in total, about 290 fall-through > locations are annotated in comments, about 30 locations fall-through to an > empty block (case 1: ....<no break> case 2: break;), 7 locations have > assert(false) not followed by break; >From the remaining ~70 locatio...

...ow many bugs you found, when running this over LLVM and Clang? >> > Two months ago it was like this: > > I compiled llvm and clang with the recently added -Wimplicit-fallthrough diagnostic >> and analyzed the results. For those who are curious: there are about 400 >> 'unannotated fall-through' warnings in total, about 290 fall-through >> locations are annotated in comments, about 30 locations fall-through to an >> empty block (case 1: ....<no break> case 2: break;), 7 locations have >> assert(false) not followed by break; > > From the rema...

...we use a decent metadata engine or > none at all. The point isn't whether it's a good idea to discard FP precision data (or vectorization data, or debug data), but rather whether IR transformations are allowed to treat a meta-data annotated instruction as having the same semantics as an unannotated instruction. If transformation passes which aren't metadata aware aren't allowed to reason about an annotated instruction, there's no point to metadata in the first place: we can just introduce new intrinsics/instructions, or change the definition of an existing instruction/intrinsic....

...this over LLVM and >>> Clang? >>> >> Two months ago it was like this: >> >> I compiled llvm and clang with the recently added -Wimplicit-fallthrough diagnostic >>> and analyzed the results. For those who are curious: there are about 400 >>> 'unannotated fall-through' warnings in total, about 290 fall-through >>> locations are annotated in comments, about 30 locations fall-through to an >>> empty block (case 1: ....<no break> case 2: break;), 7 locations have >>> assert(false) not followed by break; >> &g...

> The point isn't whether it's a good idea to discard FP precision data > (or vectorization data, or debug data), but rather whether IR > transformations are allowed to treat a meta-data annotated instruction > as having the same semantics as an unannotated instruction.  If > transformation passes which aren't metadata aware aren't allowed to > reason about an annotated instruction, there's no point to metadata in > the first place: we can just introduce new intrinsics/instructions, or > change the definition of an existing ins...

...that P0190R0 will be discussed at the upcoming C++ Standards > > > Committee meeting taking place the week of February 29th. Points of > > > discussion are likely to include: > > > > > > o May memory_order_consume dependency ordering be used in > > > unannotated code? I believe that this must be the case, > > > especially given that this is our experience base. P0190R0 > > > therefore recommends this approach. > > > > > > o If memory_order_consume dependency ordering can be used in > > > unannotated code, mu...

...nches --- git-hook/update | 26 +++++++++++++++++++++++--- 1 files changed, 23 insertions(+), 3 deletions(-) diff --git a/git-hook/update b/git-hook/update index c82015e..ed76bd2 100755 --- a/git-hook/update +++ b/git-hook/update @@ -1,6 +1,6 @@ #!/bin/sh # -# An example hook script to blocks unannotated tags from entering. +# An example hook script to block unannotated tags from entering. # Called by "git receive-pack" with arguments: refname sha1-old sha1-new # # To enable this hook, rename this file to "update". @@ -13,9 +13,15 @@ # hooks.allowdeletetag # This boolean...

...tations would be required, and how many bugs you found, when running this over LLVM and Clang? > Two months ago it was like this: > I compiled llvm and clang with the recently added -Wimplicit-fallthrough diagnostic and analyzed the results. For those who are curious: there are about 400 'unannotated fall-through' warnings in total, about 290 fall-through locations are annotated in comments, about 30 locations fall-through to an empty block (case 1: ....<no break> case 2: break;), 7 locations have assert(false) not followed by break; > From the remaining ~70 locations 6 look like...

...half hour googling, after that I set: imap_metadata = yes and mail_attribute_dict = file:%h/shared_metadata I think you cold put those lines in the 20-imap.conf example file commented; that way will be easy for us to activate. Because I changed the location of shared_metadata, all folders was unannotated . I went in folder manager in roundcube and set folder "calendar" as calendar type and so on. That worked and i have: cat shared_metadata: shared/c4268a04da44bb527c5b0000193e0904/vendor/kolab/folder-type event shared/cd5792367fc9cd5196170000193e0904/vendor/kolab/folder-type event share...

On Thu, Jul 26, 2012 at 4:24 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jul 26, 2012, at 4:07 PM, Chris Lattner <clattner at apple.com> wrote: > > > <dropping llvm-commits> > > > > On Jul 2, 2012, at 9:59 AM, Alexander Kornienko wrote: > > > >> Hi llvmdev, llvm-commits, > >> > >> There was a discussion on

On Jul 26, 2012, at 4:07 PM, Chris Lattner <clattner at apple.com> wrote: > <dropping llvm-commits> > > On Jul 2, 2012, at 9:59 AM, Alexander Kornienko wrote: > >> Hi llvmdev, llvm-commits, >> >> There was a discussion on this topic a while ago, and now I've decided to make a formal proposal and post it here. > > I missed the earlier

...il.com> wrote: >> The point isn't whether it's a good idea to discard FP precision data >> (or vectorization data, or debug data), but rather whether IR >> transformations are allowed to treat a meta-data annotated instruction >> as having the same semantics as an unannotated instruction.  If >> transformation passes which aren't metadata aware aren't allowed to >> reason about an annotated instruction, there's no point to metadata in >> the first place: we can just introduce new intrinsics/instructions, or >> change the definition of...

...open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf, 7.6). The [[clang::fallthrough]] attribute should be applied to a null statement placed in a point of execution where fall-through to the next switch label occurs, e.g.: switch (n) { case 0: ... // no break here case 1: // warning: unannotated fall-through between switch labels if (x) break; else if (y) { ... *[[clang::fallthrough]];* // annotated fall-through to case 2 } else return 13; case 2: // no warning here ... *[[clang::fallthrough]];* // annotated fall-through to case 3 case...

Hello, I'm working on a binary translator project that emits an .ll file. I'm trying to debug it in Visual Studio and would like to be able to step through and see my generated .ll file in the debugger. Does LLVM support debug information corresponding to an input .ll file? My hunch is "no, as it expects debug info to come from Clang." I assemble it using: llc -filetype=obj

2012/4/17 Hal Finkel <hfinkel at anl.gov>: > In reality, metadata might want to have merging rules and a defined API > so that metadata merging can be used by a number of passes > (vectorization will need this too). For example, merging fp-accuracy > data should choose the more-stringent bound, but not really be removed > all together. +1! The original intent of metadata was

...t; >> The point isn't whether it's a good idea to discard FP precision > >> data (or vectorization data, or debug data), but rather whether IR > >> transformations are allowed to treat a meta-data annotated > >> instruction as having the same semantics as an unannotated > >> instruction.  If transformation passes which aren't metadata aware > >> aren't allowed to reason about an annotated instruction, there's > >> no point to metadata in the first place: we can just introduce new > >> intrinsics/instructions, or chan...

..."parallel loop concept" (yet). Yes, it's "fragile" in the sense that the parallelism information is dropped too easily in some cases. E.g. inlining calls inside the loop body will at the moment make the loop a non-parallel one if the inlined function contains at least one (unannotated) memory instruction. It should be safe to do it this way around: add support for propagating/keeping the parallelism data to passes gradually instead boldly assume all passes do the safe thing. E.g. the inliner should eventually propagate the parallelism data to the memory instructions of the fun...