similar to: Is pointer tagging defined behavior?

On Sat, Mar 26, 2016 at 2:58 PM, Russell Wallace via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Dynamic languages commonly use an implementation technique where you take > a pointer to an object (aligned on eight bytes so the lower three bits are > zero), cast to intptr_t, change the lower three bits to a tag value > indicating the type of the object, then later test the

> On Jan 14, 2016, at 4:49 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Jan 14, 2016 at 12:56 PM, John McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > C 6.3.2.3p7 (N1548) says: > A pointer to an object type may be converted to a pointer to a > different object type. If the resulting pointer is not

I've finally managed to extract from Kaleidoscope one particular thing that it seems to me should be working and isn't. Given the global declaration extern "C" void foo() {} within the same program I have RTDyldMemoryManager::getSymbolAddressInProcess("foo") And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? -------------- next part

Are the Kaleidoscope examples supposed to work on Windows? e.g. C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp when I try to compile this with clang it gives compile time error messages, and when I try with Microsoft C++ it generates an executable that runs but crashes when I type in an expression; I get similar results with a few of the other versions. I can give more detailed feedback if

C 6.3.2.3p7 (N1548) says: A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned) for the referenced type, the behavior is undefined. C++ [expr.reinterpret.cast]p7 (N4527) defines pointer conversions in terms of conversions from void*: An object pointer can be explicitly converted to an object pointer of a

(Sorry for the duplicate mail, Richard, I accidentally sent a copy only to you before.) On Thu, Jan 14, 2016 at 10:26 PM, Richard Smith via cfe-dev < cfe-dev at lists.llvm.org> wrote: > [1]: That's not completely true, as it's possible to create an object > that is underaligned for its type: > > struct __attribute__((packed)) A { > char k; > struct B { int n;

I’m not entirely opposed to solution #3. As I said, my concern is that there are cases it would miss. For instance, if I had some code like this: char *get_ptr(char *base, intptr_t offset) { return base + offset; } char *convert_to_ptr(intptr_t ptr_val) { return get_ptr((char*)0, ptr_val); } There the idiom would only appear after inlining, so the front end couldn’t handle it. The

I have a pointer to a function that I need to invoke without going through llvm::Module::getOrInsertFunction. This example does not work: static int add(int x, int y); llvm::Value *one, *two; llvm::Constant* addfn = llvm::ConstantInt::get(JB->getIntPtrTy(DataLayout), (intptr_t)add); llvm::Type* args[] = { Int32Ty, Int32Ty }; llvm::FunctionType* ftype = llvm::FunctionType::get(Int32Ty,

Hi everyone, I've got a problem that I would like some input on. The problem basically boils down to a program that I am compiling, whose source I don't control, doing something like this: p = (char*)0 + n where 'n' is an intptr_t-sized value that the program knows is actually a valid address for a pointer. clang translates this as %p = getelementptr inbounds i8, i8*

On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de> wrote: vector.size() returns a size_t, which on 64-bit platforms can represent types values larger than those that can fit into an int64_t. So to turn your argument around, since it's theoretically possible to have a vector with more items than an int64_t can represent, isn't it already worth it to use

Hello everbody, doing a #find(:first,an_id) with Rails 1.1.0 I expected that find returns the record which id mathches the given parameter an_id or nil if it couldn''t be found. This behaviour is documented on api.rubyonrails.org. But the find returns the first available object and not nil if an_id is not in the db. Is the doc on rubyonrails.org out of sync? Greetings, -- Daniel

On Wed, Jul 1, 2015 at 12:22 PM, Russell Wallace <russell.wallace at gmail.com> wrote: > I am arguing in favor of a point, and I understand you disagree with it, > but I don't think I'm dismissing any use cases except a very small > performance increment. > I'm sure Google has numbers about how much electricity/server cost they save for X% performance improvement.

> glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else? I originally saw this in a benchmark (which it may be possible to get changed) and only afterward found the glibc idiom. The most recent glibc code is a bit more complicated than I represented below. If you look up obstack.h you can see what’s there now.

On Jun 17, 2010, at 1:34 PM, Eugene Toder wrote: >> Do you have a reference to the standard that makes it undefined? > > I'm second this question. I tried to find anything banning calculating > address of one field from address of another in the standard some time > ago, but could not find it. In the currect C++0x FCD, 5.7/5: "When an expression that has integral

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

Hi, I'm not sure what I'm doing wrong here. With the single source file attached to this email, I tried the following commands: llvmgcc -o timeLLVMfft timeLLVMfft.c -lm llc -o timeLLVMfft.s timeLLVMfft.bc /opt/SUNWspro/bin/cc -xarch=v9 -o timeLLVMfft.sparc timeLLVMfft.s I got the errors at the bottom of this email in response to the last command. On the other hand, gcc v2.95.3 had

Yes. We currently build LLVM 3.4.2 on our OpenVMS Itanium box with an older EDG/Intel C++03 compiler to create legacy cross-compilers to our OpenVMS x86 box (well, VirtualBox). We do have a few tweaks to the relocations to access static data always through the GOT (including CodeGen's static data). Our linker sees references to code (which might be in 64-bit space) and creates trampolines

Hi John, On 15 Jan 2016, at 08:14, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The question at hand is whether we should require the user to write this: > misaligned_A_B *p = &a.b; > instead of, say: > A::B *p = &a.b; > int x = *(misaligned_int*) &p->n; > because we want to reserve the right to invoke undefined behavior and

I need to track down all pointers anywhere in a module that could be pointing to functions (because some of the optimizations I want to do, require either identifying every use of a function, or conservatively identifying when such cannot be done). A starting point is to look at all the global variables: for (auto &G : M.globals()) for (auto &V : G.operands()) if (auto F =

David, As you suggested, I try to compile the following test code: *include "llvm/IR/Instruction.h"#include "stdint.h"extern void callback(intptr_t);void foo(){ llvm::Instruction* i; intptr_t zzzz=static_cast<intptr_t>(i); callback(zzzz);}* but got this compilation error: * 'intptr_t' (aka 'long') is not allowed intptr_t