similar to: [LLVMdev] [RFC] Alias should not point to declarations

On Oct 30, 2013, at 12:35 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > A long time ago (before r97733) we used to model the weakref attribute > by outputting a new declaration and a weak alias to it. This was > fairly buggy and we now implement weakref directly in clang, with the > same logic an assembler uses to implement .weakref (which is what gcc >

On 30 October 2013 15:50, Chris Lattner <clattner at apple.com> wrote: > > On Oct 30, 2013, at 12:35 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> A long time ago (before r97733) we used to model the weakref attribute >> by outputting a new declaration and a weak alias to it. This was >> fairly buggy and we now implement weakref directly in

Hi, In order to find out-of-bound accesses to global objects with AddressSanitizer ( http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer) I need to create redzones to the left and to the right of every global variable. I tried the following: Before: @Extern = global [10 x i8] zeroinitializer, align 1 After: %0 = type { [32 x i8], [10 x i8], [54 x i8] } @Extern_asan_redzone =

Hi Rafael, > With all that in mind, the attached patch changes the verifier to > reject aliases to declarations and updates that language reference. MachO has an R_INDR (== "indirect") symbol flag/type that (from my understanding) exactly reflects this. The linker is supposed to record the alias and define both symbols when the referee is defined. In fact, I've been working

Hi, I wanted to see if there was a way in IR to emit a local alias such that I would get: ``` .type _ZTVSt13bad_exception, at object # @_ZTVSt13bad_exception .globl _ZTVSt13bad_exception _ZTVSt13bad_exception: *.L_ZTVSt13bad_exception:* .long 0 # 0x0 .long (_ZTISt13bad_exception.rtti_proxy-.L_ZTVSt13bad_exception)-8 .long

After discussing with Nick Lewycky in the IRC channel, here comes a less aggressive patch. We were worried that a constant pointer could alias with a GlobalValue. Also, if one pointer could be a GlobalValue and the other a GlobalAlias with the GlobalValue as aliasee. However, I was not able to produce a test where this happens wihout the getUnderlyingObject() returning the same value. It

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> Here is another change I'd like to suggest to the BasicAliasAnalysis. >> >> LLVM fails to remove the dead store in the following code: >> >> %t = type { i32 } >> >> define void @f(%t* noalias nocapture %stuff ) { >> %p = getelementptr inbounds %t* %stuff, i32 0,

I was working on https://reviews.llvm.org/D81911 to try and fix https://bugs.llvm.org/show_bug.cgi?id=46340 . Through the review process we happened upon a design limitation or perhaps a potential mis-modelling of GlobalIFunc in the IR object hierarchy, which leads to some problems in LTO flows. To summarize, as it currently stands (and in the hopes of faithfully representing the conclusions of

> * Calling getBaseObject() on a GlobalIFunc returns its resolver function. I still don't understand how it can happen looking to the code ( https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). I believe it should return nullptr (the same as if you call it from GlobalAlias that refers to GlobalIFunc). I don't have a strong opinion here because deriving

Bringing the discussion to llvmdev. For the purposed of this discussion, object files can be thought as having just a few thing we care about: data, labels and relocations. Data is what at llvm ir would be just the contents of variables or functions. Relocations are utilities to compute the data at link time when it is not possible to do so earlier. For example, to compute a pcrel relocation we

llvm[1]: Compiling Globals.cpp for Release build /home/auto-tester/projects/c16/lib/VMCore/Globals.cpp: In member function ‘virtual void llvm::GlobalValue::destroyConstant()’: /home/auto-tester/projects/c16/lib/VMCore/Globals.cpp:81: error: ‘cerr’ was not declared in this scope /home/auto-tester/projects/c16/lib/VMCore/Globals.cpp: In member function ‘const llvm::GlobalValue*

Hi, I am trying to compile a dynamic loader using LLVM. Part of the IR for this loader looks like this: @_rtld_local = hidden alias %struct.rtld_global* @_rtld_global @_rtld_global = unnamed_addr global %struct.rtld_global { ... } The purpose of _rtld_local is to allow _rtld_global to be referenced without using the GOT, as this global is accessed before the dynamic loader initialises the GOT.

Hans Wennborg wrote: > After discussing with Nick Lewycky in the IRC channel, here comes a less > aggressive patch. > > We were worried that a constant pointer could alias with a GlobalValue. > Also, if one pointer could be a GlobalValue and the other a GlobalAlias > with the GlobalValue as aliasee. > However, I was not able to produce a test where this happens wihout the

Just a heads up, I'm planning on sending patches for this soon. -- David Majnemer On Tue, Apr 1, 2014 at 2:23 PM, Rafael Espíndola <rafael.espindola at gmail.com > wrote: > > I like this proposal. Any reason to use an explicit offset rather than > > allow GEPs into aliases? > > Part of pr10367. A contant gep is more generic than whan an alias can > actually

On 30 October 2013 16:16, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Rafael, > >> With all that in mind, the attached patch changes the verifier to >> reject aliases to declarations and updates that language reference. > > MachO has an R_INDR (== "indirect") symbol flag/type that (from my > understanding) exactly reflects this. The linker is

> Yes, it is the same error referring to 4.1.2. > > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c+ > +/4.1.2/i386-redhat-linux/bits/gthr-default.h:114:1: error: weakref > declaration must have internal > linkage > __gthrw(pthread_key_delete) > > There are several such errors. Are you sure you are usin gcc44? Don't you need to run CC=gcc44 CXX=g++44

On Tue, Jan 17, 2017 at 7:24 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > I was wondering though what happens if we have an alias, which may or may > > not be weak itself, to a non-odr weak symbol that isn't prevailing. In > that > > case, do we eventually

On Wed, Jan 18, 2017 at 7:16 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > >> The rule should be that the alias to aliasee link is never broken. The > >> reason being that an alias at the file level is just another symbol with > >> the same value. > >> > >> So if foo is an alias to bar, accessing that foo will always be

Hi Sitvanit, On 12/07/12 22:18, Sitvanit Ruah wrote: > I ran "configure -help " and it says > > usage: configure [OPTION]..... [VAR=VALUE] > > So I assume configure CC=... is the right syntax. Isn't it? while you might think so, try it the other way round. Also, by doing make VERBOSE=1 you can see which compiler is really being used. Ciao, Duncan. > >

I ran "configure -help " and it says usage: configure [OPTION]..... [VAR=VALUE] So I assume configure CC=... is the right syntax. Isn't it? Regard, Sitvanit From: Konstantin Tokarev <annulen at yandex.ru> To: Sitvanit Ruah/Haifa/IBM at IBMIL, Cc: llvmdev-bounces at cs.uiuc.edu, llvmdev at cs.uiuc.edu, Duncan Sands <baldrick at free.fr> Date: