similar to: Question about __builtin_object_size

Displaying 20 results from an estimated 800 matches similar to: "Question about __builtin_object_size"

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
2016 Mar 17
3
Problem with __builtin_object_size when it depends on a condition
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:
2016 Mar 16
4
Problem with __builtin_object_size when it depends on a condition
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 =
2017 Aug 20
2
RFC: Resolving TBAA issues
On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > > The problem with the way you are trying to show this is that > > there are many ways to prove no-alias, and TBAA is one of them. > > The reason i stare at dump files and debug info is precisely to > > separate the TBAA portion from the rest.
2017 Jan 02
2
RFC: Allowing @llvm.objectsize to be more conservative with null.
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
2012 May 03
1
[nut-commits] svn commit r3554 - branches/windows_port/common
c'est quoi cette chelouzerie ? je parle de l'ajout du sizeof(DWORD)... et ce que ce serait pas un str*n*cpy ou s*n*printf la vraie solution ? Arno 2012/5/3 Frederic BOHE <fbohe-guest at alioth.debian.org>: > Author: fbohe-guest > Date: Thu May ?3 08:31:38 2012 > New Revision: 3554 > URL:
2017 Jan 02
2
RFC: Allowing @llvm.objectsize to be more conservative with null.
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
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
2017 Aug 20
3
RFC: Resolving TBAA issues
On 08/20/2017 11:22 AM, Daniel Berlin via llvm-dev wrote: > Sorry, hit send early. > > > On Sun, Aug 20, 2017 at 9:16 AM, Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>> wrote: > > > > On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at
2016 Jun 17
2
question about ARM 32 big endian
Hi everyone, I have a question about ARM 32 big endian calling convention. It's about sending small structures as function argument. For example if passing 3 chars in a structure should alignment in register (argument register for passing those chars in function) be right-adjusted ? LLVM (trunk version) is passing those chars left-adjusted in register, and trying to read them like they
2006 Sep 12
1
openssh (OpenBSD) , bsdauth and tis authsrv
nuqneH, I've tried using TIS authsrv authentication via bsd auth and found it quite limited. The most important restriction it does not log ip and fqdn of the remote peer, nor the application name, to the authentication server. It does not matter much for TIS authsrv, but since other applications do provide such information, our authsrv version uses it for extra authentication restrictions.
2013 May 09
1
[LLVMdev] How should LLVM interpreter handle llvm.objectsize.i64
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
2017 Aug 20
2
RFC: Resolving TBAA issues
On Sun, Aug 20, 2017 at 2:47 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > >>>> the type of (*x) is not compatible with the type of (*b) or, > >>>> recursively, type of b->i. Similarly, the type of (*b) is > >>>> not compatible with (*x) or, recursively, x->i. > >> ... >
2011 Feb 10
2
[LLVMdev] Preventing C backend from using gcc builtin functions
Hi all, 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. 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
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
2019 Aug 10
7
[PATCH libnbd 0/5] WIP: python: Add test for doing asynch copy.
This doesn't yet work. However it does make me more convinced than ever that we really need to sort out persistent buffer lifetimes in the library (similar to what we did for closures). Rich.
2013 Feb 27
4
[LLVMdev] Question about intrinsic function llvm.objectsize
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()
2017 Oct 02
3
[PATCH 0/2] builder: Choose better weights in the planner.
It started out as "this'll be just a simple fix ..." and turned into something a bit over-engineered in the end. Here it is anyway. Rich.
2013 Feb 26
2
[LLVMdev] Question about intrinsic function llvm.objectsize
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
2013 Feb 27
0
[LLVMdev] Question about intrinsic function llvm.objectsize
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