similar to: [LLVMdev] Any equivalent of --allow-multiple-definitions in llvm-ld?

Before I go writing a bug report, I want to know if the behavior I am seeing is intended. Before 1.3, I was able to generate a linkonce definition in one module, and an external declaration in another module and link them together, with the result being a defined symbol with external linkage. However, with the latest head, it apparently discards the linkonce version, and my output contains

Hi Nick, I am trying to implement support for handling section groups in lld. There are two ways of figuring out section groups with ELF. a) Sections with SHF_GROUP property b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. Section Groups(SHF_GROUP) is the preferred way on ELF but .gnu.linkonce sections is

On Jun 9, 2008, at 7:13 PM, Talin wrote: > Before I go writing a bug report, I want to know if the behavior I am > seeing is intended. > > Before 1.3, I was able to generate a linkonce definition in one > module, > and an external declaration in another module and link them together, > with the result being a defined symbol with external linkage. However, > with the

On Dec 4, 2009, at 12:52 AM, Duncan Sands wrote: > Hi Bill, > >> There's a problem with your check-in for r72619 is causing "weak >> external" symbols to appear in C++ code when it shouldn't. Take >> this code for example, >> #include <stdexcept> >> void dummysymbol() { >> throw(std::runtime_error("string"));

Hi Bill, > Here's what I get with TOT compiling with -Os. The orig.ll is what I get > before r72619. Notice that orig.ll has only one function in it. Both the > one you sent and duncan.ll have more than one function. It's not the > fact that more than one function is showing up, but these functions in > particular shouldn't be there because of the implicit/explicit

OK here's a patch with the latest, including unit tests. I've also tried to make the comments clear that this is intended for the case of "generic" key types, where you are either hashing multiple data types together, or you don't know in advance what the data type will be - for cases such as strings where a tailored algorithm is available, you should use that instead of

On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: > I am trying to implement support for handling section groups in lld. > > There are two ways of figuring out section groups with ELF. > > a) Sections with SHF_GROUP property > b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. > >

BLAST! LLVM mailing list headers are still royally screwed up... My message is below... On Sun, Aug 30, 2009 at 2:20 PM, Talin<viridia at gmail.com> wrote: > Hey all, it's been a while since I have posted on this list, but I've > been continuing my work with LLVM and getting lots done :) > > One question I wanted to ask is whether anyone had any advice on how to >

On Tue, Feb 14, 2012 at 2:44 AM, Chris Lattner <clattner at apple.com> wrote: > On Feb 13, 2012, at 2:00 AM, Talin wrote: > > Just out of curiosity, why not MurmurHash3 ? This page seems to >> suggest that #2 has some flaw, and #3 is better all round: >> >> https://sites.google.com/site/murmurhash/ >> >> The main reason is because there's no

On Dec 4, 2009, at 12:40 PM, Duncan Sands wrote: > Hi Bill, > >> Here's what I get with TOT compiling with -Os. The orig.ll is what >> I get before r72619. Notice that orig.ll has only one function in >> it. Both the one you sent and duncan.ll have more than one >> function. It's not the fact that more than one function is showing >> up, but

On Mon, Feb 13, 2012 at 1:22 AM, Jay Foad <jay.foad at gmail.com> wrote: > On 13 February 2012 00:59, Talin <viridia at gmail.com> wrote: > > Here's my latest version of Hashing.h, which I propose to add to > llvm/ADT. > > Comments welcome and encouraged. > > > /// Adapted from MurmurHash2 by Austin Appleby > > Just out of curiosity, why not

On 2/7/19 4:03 AM, Joakim Tjernlund wrote: >>> >>> Hi, >>> >>> I merged your tree and added the install patch on top of it. Thank you! >>> >>> -hpa >> >> Is it worth doing another -pre immediately since upgrading gnu-efi >> took such a large leap? My thought is if someone has an issue with >> the new proposed

On Thu, 2019-02-07 at 21:49 +0000, Joakim Tjernlund via Syslinux wrote: > On Thu, 2019-02-07 at 13:14 -0800, H. Peter Anvin wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > On 2/7/19 4:03 AM, Joakim Tjernlund wrote: > > >

On Wed, 2019-02-06 at 11:34 -0800, H. Peter Anvin wrote: > On 2/6/19 9:17 AM, Joakim Tjernlund via Syslinux wrote: > > On Wed, 2019-02-06 at 16:00 +0100, Joakim Tjernlund wrote: > > > On Tue, 2019-02-05 at 14:07 -0800, H. Peter Anvin via Syslinux wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments

On 17 February 2012 08:26, Talin <viridia at gmail.com> wrote: > + // Helper class to detect if the input type is 4-byte aligned. > + template<typename T> > + struct is_4byte_aligned { > + static const bool value = (sizeof(T) & 3) == 0; > + }; I don't think this is safe, e.g. for: struct { char c[4]; } Jay.

On Fri, Feb 17, 2012 at 1:32 AM, Chris Lattner <clattner at apple.com> wrote: > On Feb 17, 2012, at 12:26 AM, Talin wrote: > > OK here's a patch with the latest, including unit tests. I've also tried > to make the comments clear that this is intended for the case of "generic" > key types, where you are either hashing multiple data types together, or > you

On Feb 13, 2012, at 2:00 AM, Talin wrote: > Just out of curiosity, why not MurmurHash3 ? This page seems to > suggest that #2 has some flaw, and #3 is better all round: > > https://sites.google.com/site/murmurhash/ > > The main reason is because there's no incremental version of 3. I think that that is a great reason. > LLVM's needs, on the other hand, are fairly

Hi, I have a question regarding the behavior of weak symbol resolution in LTO: Suppose there are weak definitions in both the source code and some native lib. In non-LTO path, we will use the version from source code. In LTO path, LLVM may discard the definition as it has "linkeonce" linkage type. So the native version will be selected by linker. Now, non-LTO and LTO build may have

On Jan 9, 2010, at 9:31 PM, Dustin Laurence wrote: > On 01/09/2010 01:12 PM, Chris Lattner wrote: > >> The equivalent of "extern int G;" is: >> >> @G = external global i32 > > Hmm. Is it really? Yes. > But this > extern int x; > > int x = 5; The equivalent of that is: @x = global i32 5 I made no claim that 'external' in

On 01/09/2010 01:12 PM, Chris Lattner wrote: > The equivalent of "extern int G;" is: > > @G = external global i32 Hmm. Is it really? This @foo = external global i32 @foo = global i32 5 define i32 @main(i32 %argc, i8 **%argv) { %fooVal = load i32* @foo ret i32 %fooVal } produces a "redefinition of global '@foo'" error. But this extern int x;