search for: _odr

...linkonce globals are allowed to be discarded. > > Why would linkonce be used to implement inline functions if it's not safe to inline linkonce functions? I was wrong - linkonce is an exception to the general rule that a "weak" linkage type prevents inlining unless of the "_odr" form. Ciao, Duncan.

...uncan Sands wrote: > Hi Dustin, > >> define linkonce fastcc i32 @foo(i32 %arg) alwaysinline > > linkonce implies that the function body may change at link time. Thus it would > be wrong to inline it, since the code being inlined would not be the final code. > Use linkonce_odr to tell the compiler that the function body can be replaced > only by an equivalent function body. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://li...

I think that all makes sense. You're just adding the missing non-ODR conterpart of 'external' linkage. I could imagine having "external / external_odr" linkage for example. That said, do you think we should take the opportunity to split out a bit for interposability so that we can kill off the *_odr linkage variants? Today's non-ODR weak functions would look more like this: define weak interposable void @foo() { ret void } We could p...

...hat it would really simplify things if > the check was done as such. Do you have any idea exactly how much of the > things that we want to check are not keyed on symbols? If most things are > keyed on symbols, for the things we are not we can just emit extra symbols > prefixed by __clang_odr_check_ or whatever. > Since the current implementation only works with records there is basically zero overlap right now between ODR names and symbols. I suppose that I could estimate the amount of function overlap in a hypothetical implementation that computes ODR hashes of functions by compar...

...ngs if >>> the check was done as such. Do you have any idea exactly how much of the >>> things that we want to check are not keyed on symbols? If most things are >>> keyed on symbols, for the things we are not we can just emit extra symbols >>> prefixed by __clang_odr_check_ or whatever. >>> >> >> Since the current implementation only works with records there is >> basically zero overlap right now between ODR names and symbols. I suppose >> that I could estimate the amount of function overlap in a hypothetical >> implementa...

...check was done as such. Do you have any idea exactly how much of the >>>>> things that we want to check are not keyed on symbols? If most things are >>>>> keyed on symbols, for the things we are not we can just emit extra symbols >>>>> prefixed by __clang_odr_check_ or whatever. >>>>> >>>> >>>> Since the current implementation only works with records there is >>>> basically zero overlap right now between ODR names and symbols. I suppose >>>> that I could estimate the amount of function overl...

...Do you have any idea exactly how much of the >>>>>>> things that we want to check are not keyed on symbols? If most things are >>>>>>> keyed on symbols, for the things we are not we can just emit extra symbols >>>>>>> prefixed by __clang_odr_check_ or whatever. >>>>>>> >>>>>> >>>>>> Since the current implementation only works with records there is >>>>>> basically zero overlap right now between ODR names and symbols. I suppose >>>>>> that I cou...

...t 9:15 AM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org > wrote: > > I think that all makes sense. You're just adding the missing > > non-ODR > > conterpart of 'external' linkage. I could imagine having "external > > / > > external_odr" linkage for example. > > > That said, do you think we should take the opportunity to split out > > a > > bit for interposability so that we can kill off the *_odr linkage > > variants? Today's non-ODR weak functions would look more like this: > > > d...

...ctly how much of the >>>>>>>>> things that we want to check are not keyed on symbols? If most things are >>>>>>>>> keyed on symbols, for the things we are not we can just emit extra symbols >>>>>>>>> prefixed by __clang_odr_check_ or whatever. >>>>>>>>> >>>>>>>> >>>>>>>> Since the current implementation only works with records there is >>>>>>>> basically zero overlap right now between ODR names and symbols. I suppose &gt...

...t;>>>>>>>> of the things that we want to check are not keyed on symbols? If most >>>>>>>>>>> things are keyed on symbols, for the things we are not we can just emit >>>>>>>>>>> extra symbols prefixed by __clang_odr_check_ or whatever. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Since the current implementation only works with records there is >>>>>>>>>> basically zero overlap right now between ODR...

...;>> how much of the things that we want to check are not keyed on symbols? If >>>>>>>>>>>>> most things are keyed on symbols, for the things we are not we can just >>>>>>>>>>>>> emit extra symbols prefixed by __clang_odr_check_ or whatever. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Since the current implementation only works with records there >>>>>>>>>>>> is basically zer...

...;>> how much of the things that we want to check are not keyed on symbols? If >>>>>>>>>>>>> most things are keyed on symbols, for the things we are not we can just >>>>>>>>>>>>> emit extra symbols prefixed by __clang_odr_check_ or whatever. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Since the current implementation only works with records there >>>>>>>>>>>> is basically zer...

...ch of the things that we want to check are not keyed on symbols? If >>>>>>>>>>>>>>> most things are keyed on symbols, for the things we are not we can just >>>>>>>>>>>>>>> emit extra symbols prefixed by __clang_odr_check_ or whatever. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since the current implementation only works with records >>>>>>>>>>>&gt...

...that we want to check are not keyed on symbols? If >>>>>>>>>>>>>>>>> most things are keyed on symbols, for the things we are not we can just >>>>>>>>>>>>>>>>> emit extra symbols prefixed by __clang_odr_check_ or whatever. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since the current implementation only works with records >>>>>&gt...

...about on IRC, when we have a non-prevailing weak/linkonce symbol f() that has an alias point to it, we need to: 1) Rename and internalize f() 2) Create a new external decl f() 3) RAUW existing references (other than from the aliases) with the new local created in 1) I think if it is however a weak_odr/linkonce_odr we can simplify the process since all copies will be the same. We can make f() available_externally (to enable inlining), and simply convert references to aliases of f() into direct references to f() and drop the aliases - does that sound right? Another tricky thing is if the weak sy...

Hi all, I'd like to propose an ODR checker feature for Clang and LLD. The feature would be similar to gold's --detect-odr-violations feature, but better: we can rely on integration with clang to avoid relying on debug info and to perform more precise matching. The basic idea is that we use clang's ability to create ODR hashes for declarations. ODR hashes are computed using all

Hi everyone, Clang/LLVM's support for ELF interposition is in a confusing state, and I propose making a few (hopefully simple) adjustments in order to bring our model into a self-consistent state. The problem: On ELF systems, global symbols can be interposed. This means, for example, that calls to global functions in some (shared) library defined in that same library might end up being

----- Original Message ----- > From: "James Y Knight" <jyknight at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Monday, February 29, 2016 9:31:24 AM > Subject: Re: [llvm-dev] Possible soundness issue with