similar to: Ignoring coverage for noreturn decls

+ cfe-dev > On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. FWIW, Daniel Dunbar and a few others have brought up the lack of a

Dear All, I am helping our test team migrate from gcov to llvmcov. They currently generate HTML reports using lcov to easily navigate where coverage is missing. However, there does not seem to be a Windows compatible solution for generating HTML reports using the llvm-cov tools. A possible solution to this problem is for llvm-cov to create html pages that include an overall coverage summary

Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > Harlan Haskins has recently submitted a patch (for review) that implements > --format=html for llvm-cov tool. Please take a look at that patch. For reference, the review thread starts here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160229/336622.html > David > > On Thu, Mar 3, 2016 at

Hi, Building the following C code I get a call instruction that has no noreturn attribute, while the function itself does have it. void foo(void **b) { __builtin_longjmp(b, 1); } define void @_Z3fooPPv(i8** %b) noreturn nounwind uwtable { entry: %0 = bitcast i8** %b to i8* tail call void @llvm.eh.sjlj.longjmp(i8* %0)

You can use CallInst::hasFnAttr(). It checks for attributes in the instruction and in the function decl. http://llvm.org/docs/doxygen/html/Instructions_8cpp_source.html#l00345 Nuno ----- Original Message ----- > Hi, > > Building the following C code I get a call instruction that has no > noreturn > attribute, while the function itself does have it. > > void foo(void **b)

Hi Kostya, On 28/11/12 14:47, Kostya Serebryany wrote: > Hi, > > Building the following C code I get a call instruction that has no noreturn > attribute, while the function itself does have it. > > void foo(void **b) { > __builtin_longjmp(b, 1); > } > > > define void @_Z3fooPPv(i8** %b) noreturn nounwind uwtable { > entry: > %0 = bitcast i8** %b to i8*

Hello, I am not sure about the semantic (if any) of returns_twice and noreturn attributes. int fork() __attribute__((returns_twice)); void join(int) __attribute__((noreturn)); int f(int n) { int t = fork(); n++; if (t != 0) join(t); return n; } Produces the following LLVM IR: ; Function Attrs: nounwind uwtable define i32 @f(i32 %n) local_unnamed_addr #0 { entry: %call = call i32

On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: > > Hello, > > I am not sure about the semantic (if any) of returns_twice and noreturn > attributes. > > int fork() __attribute__((returns_twice)); > void join(int) __attribute__((noreturn)); > > int f(int n) { > int

Counteract incorrect use of the "deprecated" attribute in ffmpeg headers. In particular, struct AVPaletteControl is deprecated, but it's used in a non-deprecated struct AVCodecContext (as found in Fedora's ffmpeg-devel-0.4.9-0.8.20070530.fc7.x86_64). Define attribute_deprecated to an empty string until broken version of ffmpeg are too obsolete to support. Use appropriate

Dear all, I don't get how llvm handles functions with __attribute__((noreturn)). It seems that LR register is backed up on the stack whilst it will never be used to return from a 'noreturn' function. I have this problem with a home-made backend but it seems that ARM flavour of clang has same behaviour. By the way, SP is also saved, I don't understand why. Is there a syntax error

hi, list, i am making a llvm compiler for shader-like programs. as we known, shader programs are short and have less function calls. i found that i have to save/restore callee-saved register(CSR) in prolog and epilog. because I can violate ABI from driver(c code) and shader, i plan to append the attribute 'noreturn' to all shader functions. in PrologEpilogInserter.cpp, you can find that

Hello, as of gcc v2.7.2.1, the noreturn attribute needs to be given *after* the prototype declaration and not before, but for gcc v3.x, things changed for this attribute again, since gcc v2.5.x did it the way, newer gcc versions prefer it... I've applied a small unified diff, fixing this stuff. THX for listening. CU Tom. (Thomas M.Ott) Germany -------------- next part -------------- ---

When I compile some code with the near-trunk clang++ I get this: ... tail call void @_Unwind_Resume_or_Rethrow(i8* %exn2) noreturn unreachable ... declare void @_Unwind_Resume_or_Rethrow(i8*) ... Same with __cxa_throw. 'noreturn' is missing on declarations. This seems to be a bug. Also can _Unwind_Resume_or_Rethrow actually return? When I run some simple exception code in JIT I

Hi, Is it somehow possible to have LLVM emit machine code for the 'unreachable' IR instruction, which would assert that it indeed never gets reached? Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140414/02108a74/attachment.html>

On 11/03/2017 07:57 PM, Yichao Yu wrote: > On Fri, Nov 3, 2017 at 8:54 PM, Alexandre Isoard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: >>> >>> Hello, >>> >>> I am not sure about the

I unfortunately haven't received any responses about this problem. We (the company I work for) are willing to discuss payment to someone who is willing to quickly contribute a fix to the RGoogleDocs/RCurl toolchain that will restore write access. Please contact me directly if you're interested. Thank you, -Harlan Harris On Tue, Jul 20, 2010 at 10:19 AM, Harlan Harris

Hi, I have made a small patchset to fix some of the GCC warnings. With these patches, I was able to compile dovecot r_1_0_rc26 with the following options: -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast Wstrict-prototypes -Wredundant-decls -Wcast-align -Wwrite-strings Wpacked -Winline -Wdisabled-optimization

Hi, I'm running wine-1.0.1, OpenBUGS 3.0.3, R 2.9.0, and R2WinBUGS on a Redhat Enterprise Linux machine. Following various peoples' suggestions... This works perfectly (yay!): wine Z:/opt/OpenBUGS/winbugs.exe Within R, however, I get this: (setup the example from ?bugs, then....) R> schools.sim <- bugs(data, inits, parameters, model.file, n.chains=3,

Hello, In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below too ugly/problematic? Feedback would be appreciated. Thanks, Dave //===- llvm/Support/VTable.h - LLVM-style

Hello, I have a minimal testcase which crashes RegisterCoalescer in my out-of-tree target. It only crashes in Debug builds of llc---not in Release builds. Also, interesting to note that the x86 backend lowers this same testcase successfully. I did a quick search of bugs.llvm.org and found no matches. This implies that the problem is in my backend and/or how my backend interacts with