search for: __builtin_object_size

Displaying 20 results from an estimated 29 matches for "__builtin_object_size".

2016 Feb 09
2
Question about __builtin_object_size
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 cor...
2016 Feb 09
2
Question about __builtin_object_size
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 objectsize functions (so far) is to insert bounds checks when a variable is used. If this quirk is causing...
2017 Jan 02
2
RFC: Allowing @llvm.objectsize to be more conservative with null.
...<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 lowered like: > > __builtin_object_size(p, 0) -> @llvm.objectsize(i8* %p, i8 2) > __builtin_object_size(p, 1) -> @llvm.objectsize(i8* %p, i8 2) > __builtin_object_size(p, 2) -> @llvm.objectsize(i8* %p, i8 3) > (__builtin_object_size(p, 3) doesn't actually get l...
2017 Jan 02
2
RFC: Allowing @llvm.objectsize to be more conservative with null.
...wrote: >> >> 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 LLVM intrinsic that clang lowers >> __builtin_object_size(p, N) to, @llvm.objectsize, only hands back 0 when >> giv...
2016 Dec 21
2
RFC: Allowing @llvm.objectsize to be more conservative with null.
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 LLVM intrinsic that clang lowers __builtin_object_size(p, N) to, @llvm.objectsize, only hands back 0 when given a null pointer. Because it's...
2016 Mar 16
4
Problem with __builtin_object_size when it depends on a condition
...---------------------------- #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 = chararray2; else cptr = chararray; return __builtin_object_size(cptr, 2); } int main() { size_t ret; ret = foo(0); printf("\n%d\n", ret); return 0; } ---------------------------------------------- If you try to compile this example with clang (trunk version) with option -fno-inline the result will be -1. Without option -fno-inline res...
2016 Mar 17
3
Problem with __builtin_object_size when it depends on a condition
...LARGER_BUF_SIZE 30 >> >> size_t foo(int flag) { >> char *cptr; >> char chararray[LARGER_BUF_SIZE]; >> char chararray2[STATIC_BUF_SIZE]; >> if(flag) >> cptr = chararray2; >> else >> cptr = chararray; >> >> return __builtin_object_size(cptr, 2); >> } >> >> int main() { >> size_t ret; >> ret = foo(0); >> printf("\n%d\n", ret); >> return 0; >> } >> ---------------------------------------------- >> If you try to compile this example with clang (trunk versi...
2015 Sep 24
2
v2.2.19 release candidate released
...or: array size is negative >> buffer_create_from_data(&buf, guid_r, GUID_128_SIZE); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ./buffer.h:23:8: note: expanded from macro 'buffer_create_from_data' >> (void)COMPILE_ERROR_IF_TRUE(__builtin_object_size((d),3) < ((s)?(s):1)); \ What happens if in src/lib/buffer.h line 23 you change the __builtin_object_size((d),3) to __builtin_object_size((d),1)? Does it work?
2013 May 09
1
[LLVMdev] How should LLVM interpreter handle llvm.objectsize.i64
...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 call __builtin_object_size explicitly in my source code. Maybe headers what I include call the built-in somewhere. How do I eliminate such built-in function call in LLVM bitcode, or what code should I add into IntrinsicLowering.cpp to handle this problem. Any suggestion or comment...
2015 Sep 24
0
v2.2.19 release candidate released
....c:106:2: error: array size is negative > buffer_create_from_data(&buf, guid_r, GUID_128_SIZE); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ./buffer.h:23:8: note: expanded from macro 'buffer_create_from_data' > (void)COMPILE_ERROR_IF_TRUE(__builtin_object_size((d),3) < ((s)?(s):1)); \ > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ./macros.h:161:15: note: expanded from macro 'COMPILE_ERROR_IF_TRUE' > (sizeof(char[1 - 2 * !!(condition)]) - 1) > ^~~~~~~~~~~~~~~~~~~~~ &...
2019 Dec 04
2
[cfe-dev] clang and -D_FORTIFY_SOURCE=1
...RCE=1 -O1 : https://godbolt.org/z/UvABWp Clang issues a call to memcpy, while gcc issues a call to __memcpy_chk. The call to __memcpy_chk performs extra runtime checks memcpy doesn't, and clang doesn't generate the extra checks inline either. This is a separate concern from the accuracy of __builtin_object_size, just a different runtime behavior. Clang could generate the call to __memcpy_chk if its declaration is available, which is the case for the glibc. On Tue, Dec 3, 2019 at 8:41 PM Eli Friedman <efriedma at quicinc.com> wrote: > Are you sure you've diagnosed the issue correctly? __bui...
2015 Sep 24
0
v2.2.19 release candidate released
...s negative >>> buffer_create_from_data(&buf, guid_r, GUID_128_SIZE); >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> ./buffer.h:23:8: note: expanded from macro 'buffer_create_from_data' >>> (void)COMPILE_ERROR_IF_TRUE(__builtin_object_size((d),3) < ((s)?(s):1)); \ > > What happens if in src/lib/buffer.h line 23 you change the __builtin_object_size((d),3) to __builtin_object_size((d),1)? Does it work? Yes, it works. Now dovecot-2.2.19.rc1 compiles fine. Thanks, Marcin P.S. Is such warnings something you care? > clang -...
2011 Feb 10
2
[LLVMdev] Preventing C backend from using gcc builtin functions
...ing 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. Then in the CBE output these are retained as gcc builtin functions. In a similar manner, llvm.objectsize.* calls are replaced with __builtin_object_size calls, another gcc builtin function. This way the resulting C code is usable as-is only on gcc-compatible compilers. Is there a way, either by passing some flags to the llvm-gcc frontend, or by specifying some other flag to llc, to prevent this from happening? Your help is as always much apprec...
2009 Oct 27
3
[LLVMdev] llvmgcc ToT broken
...e /Volumes/Sandbox/Buildbot/llvm/ build.llvm-gcc-x86_64-darwin10-selfhost/llvmCore.roots/llvmCore~obj/ src/lib/VMCore/Instructions.cpp, line 312. It seems to be compiling function uw_frame_state_for() within unwind- dw2.c; apparently the parameter types weren't a good match for a call to __builtin_object_size(). Does this look familiar to anyone? stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091027/33e4d442/attachment.html>
2015 Sep 23
8
v2.2.19 release candidate released
http://dovecot.org/releases/2.2/rc/dovecot-2.2.19.rc1.tar.gz http://dovecot.org/releases/2.2/rc/dovecot-2.2.19.rc1.tar.gz.sig A lot of changes since v2.2.18, so here's a release candidate first. If no bugs are reported, I'm planning on making the final release sometimes this week. The most interesting new features here are the imap-hibernate process, quota count backend and director/proxy
2015 Sep 23
8
v2.2.19 release candidate released
http://dovecot.org/releases/2.2/rc/dovecot-2.2.19.rc1.tar.gz http://dovecot.org/releases/2.2/rc/dovecot-2.2.19.rc1.tar.gz.sig A lot of changes since v2.2.18, so here's a release candidate first. If no bugs are reported, I'm planning on making the final release sometimes this week. The most interesting new features here are the imap-hibernate process, quota count backend and director/proxy
2019 Dec 03
5
clang and -D_FORTIFY_SOURCE=1
Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic), As a follow-up to that old thread about -D_FORTIFY_SOURCE=n http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html And, more recently, to this fedora thread where clang/llvm -D_FORTIFY_SOURCE support is claimed to be only partial: https://pagure.io/fesco/issue/2020 I dig into the glibc headers in
2011 Feb 10
0
[LLVMdev] Preventing C backend from using gcc builtin functions
...set 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 a similar manner, llvm.objectsize.* calls are replaced with > __builtin_object_size calls, another gcc builtin function. What should be used instead? > Is there a way, either by passing some flags to the llvm-gcc frontend, or by > specifying some other flag to llc, to prevent this from happening? CBE relies on many gcc extensions, so, I doubt fixing this small issue will ch...
2007 Mar 07
2
-D_FORTIFY_SOURCE (was Re: [Xapian-commits] 7903: trunk/xapian-core/)
...by "&& !defined __cplusplus"! It also doesn't activate at all unless you're using GCC >= 4.1 so if your GCC is older, it'll have no effect at all on speed or fortification. The only thing which seems to actually be activated for C++ is some stuff to do with "__builtin_object_size", which seems to allow checking of the size of buffers known at compile time. We don't make much use of static sized buffers, and we use snprintf where available, but it doesn't hurt to have extra checks if the overhead is small. I prodded glibc CVS and found the vanilla glibc versio...
2013 Feb 27
0
[LLVMdev] Question about intrinsic function llvm.objectsize
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 load from a cert...