similar to: [LLVMdev] Preventing C backend from using gcc builtin functions

> Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend > and the C backend I see it converting regular (non-checking) memcpy and > memset calls to __memset_chk and __memcpy_chk already at the IR stage. Most probably these are changed due to defines in the system headers, so, compiler cannot do anything about this. You can hack on your system headers though. > In

Hi George, On Mon, Jan 2, 2017 at 10:41 AM, George Burgess IV <george.burgess.iv at gmail.com> wrote: > Thanks for the comments! > >> Have you considered changing our existing behavior to match GCC's >> builtin_object_size instead of adding a new parameter > > Yup! My issue with turning `i1 %min` into `i8 %flags` is that > __builtin_object_size would get

tl;dr: We'd like to add a bit to @llvm.objectsize to make it optionally be conservative when it's handed a null pointer. Happy Wednesday! We're trying to fix PR23277, which is a bug about how clang+LLVM treat __builtin_object_size when it's given a null pointer. For compatibility with GCC, clang would like to be able to hand back a conservative result (e.g. (size_t)-1), but the

Hi George, Have you considered changing our existing behavior to match GCC's builtin_object_size instead of adding a new parameter? That may be simpler overall. There's also a clear upgrade strategy -- fold every old style call to "<min> ? 0 : 1". You probably already know this, but GCC folds builtin_object_size(0, 0) to -1 and builtin_object_size(0, 2) to 0. We'll

Hi! This is an artifact of how LLVM works. Essentially, LLVM detects that `var` is unused and deletes it before it tries to lower the `llvm.objectsize` (which is what clang lowers `__builtin_object_size` to) call to a constant. While this isn't ideal, I don't think it realistically a problem, because `var` must be otherwise unused for this behavior to occur, and the whole purpose of

Optimizer doesn't know how to calculate the object size when it finds condition that cannot be eliminated. There is example: ----------------------------------------------- #include<stdlib.h> #define STATIC_BUF_SIZE 10 #define LARGER_BUF_SIZE 30 size_t foo(int flag) { char *cptr; char chararray[LARGER_BUF_SIZE]; char chararray2[STATIC_BUF_SIZE]; if(flag) cptr =

I made a mistake here, I get zero same as you. I want to fix it to get correct value. On 16.03.2016. 19:28, Duncan P. N. Exon Smith wrote: >> On 2016-Mar-16, at 09:39, Strahinja Petrovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Optimizer doesn't know how to calculate the object size when it finds condition that cannot be eliminated. There is example:

Hello LLVMer, I use dragonegg to generate LLVM bitcode. Then I use LLVM interpreter to execute what I get from compilation. However an error occurred and the error message is: "LLVM ERROR: Code generator does not support intrinsic function 'llvm.objectsize.i64'!." As far as I know, objectsize intrinsic is equivalent to gcc built-in function __builtin_object_size. But I don't

Hi Duncan, >> #include<stdio.h> >> #include<string.h> >> >> int main(int argc, char** argv){ >> >> char a[8] = "aaaaaaa"; >> char b[8] = "bbbbbbb"; >> >> char *c = (char*) malloc(sizeof(char)*(strlen(a)+strlen(b)+1)); >> memcpy(c, a, strlen(a)); >> memcpy(c + strlen(a), b, strlen(b) + 1); >>

Hi Pablo, I can reproduce this with the supplied IR. It is related to the use of __memcpy_chk. As far as I can see it is a bug in lli or the LLVM code generators. Can you please open a bugreport, attaching the LLVM IR. Ciao, Duncan. On 23/01/12 17:00, Pablo Barrio wrote: > Hi Duncan, >>> #include<stdio.h> >>> #include<string.h> >>> >>> int

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

Hi, Nuno and Arnold: Thank you all for the input. Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. A clique is statically or dynamically allocated type-free stretch of memory. A "clique" 1) is maximal in the sense that a clique dose not have any enclosing data structure that can completely cover or, partially

On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Nuno and Arnold: > > Thank you all for the input. > > Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. > A clique is statically or dynamically allocated type-free stretch of memory. A "clique" > 1) is maximal in the sense

Hi, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

> we lower llvm.objectsize later than we should Is there a well-accepted best (or even just better) place to lower objectsize? I ask because I sorta fear that these kinds of problems will become more pronounced as llvm.is.constant, which is also lowered in CGP, gains popularity. (To be clear, I think it totally makes sense to lower is.constant and objectsize in the same place. I'm just

Hi, I have question about __builtin_object_size behaviour. LLVM for __builtin_object_size function doesn't calculate correct value when pointer is used only in __builtin_object_size function call, and never after that. For this case LLVM as result generates 0 or -1 depends of second argument of __builtin_object_size function. Is this correct behaviour or it should work as gcc (gcc

This is a new build failure as of today. Does this look familiar to anyone? -bw llvm[2]: Compiling CommonProfiling.ll to CommonProfiling.bc for Debug build (bytecode) Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter

Hi all, Is there any way to make the C backend not omit long longs for i64 values, on a 32 bit machine? I'm thinking of either some frontend or some backend flag... any ideas? Thanks in advance! Harel Cain -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110925/dac008f1/attachment.html>

My mistake. I needed to update llvm-gcc as well. Sorry for the noise. -bw On Dec 23, 2009, at 3:22 PM, Bill Wendling wrote: > This is a new build failure as of today. Does this look familiar to anyone? > > -bw > > llvm[2]: Compiling CommonProfiling.ll to CommonProfiling.bc for Debug build (bytecode) > Intrinsic parameter #1 is wrong! > i64 (i8*, i32)* @llvm.objectsize.i64