similar to: [LLVMdev] RFC: New Linkage Type linker_private_weak

On Jun 30, 2010, at 1:36 PM, Bill Wendling wrote: > This patch introduces a the new "linker_private_weak" linkage type. > > Why a new linkage type? The idea behind the "linker" linkage types is that they are used by the linker and then discarded. I.e., the symbols won't show up in the final linked image. In that regard, all "linker" linkage types are

On Jun 30, 2010, at 9:52 PM, Chris Lattner wrote: > On Jun 30, 2010, at 1:36 PM, Bill Wendling wrote: > >> I implemented the new linkage to have its own prefix from linker_private. As it currently stands, the symbol's prefix ("l") is the same for "linker_private" and "linker_private_weak". If this will always be the case, then I can remove the code

On Fri, Dec 19, 2014 at 12:56 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > However, I think this would set a bad precedent. There's nowhere else > (that I know of) where we accept two versions of assembly. The > LLParser is relatively easy to work with because it doesn't have that > kind of historical baggage. I can think of two precedents:

---------- Forwarded message ---------- From: charles quarra <charllsnotieneningunputocorreo at gmail.com> Date: 2012/12/13 Subject: error while linking modules with exception handling demo code To: llvmdev at cs.uiuc.edu Hi, I am building a module X with an arithmetic function foo, a module Y with an arithmetic function foo2 that invokes foo. For the invocation be a proper one (being

Hi, I'm trying to understand better how linker_private (and friends) work. From what I can understand from the manual (http://llvm.org/docs/LangRef.html#linkage_linker_private), it seems that a linker_private function cannot be removed by the optimizers. Only the linker can discard the symbol. However, I tested with 'opt -O1' and a function with *no users* is removed. Same

everyone-- The OCaml bindings need help again. diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800 @@ -42,13 +42,18 @@ | External | Available_externally | Link_once + | Link_once_odr | Weak +

Hi Duncan, >> #include<stdio.h> >> #include<string.h> >> >> int main(int argc, char** argv){ >> >> char a[8] = "aaaaaaa"; >> char b[8] = "bbbbbbb"; >> >> char *c = (char*) malloc(sizeof(char)*(strlen(a)+strlen(b)+1)); >> memcpy(c, a, strlen(a)); >> memcpy(c + strlen(a), b, strlen(b) + 1); >>

Hi Pablo, I can reproduce this with the supplied IR. It is related to the use of __memcpy_chk. As far as I can see it is a bug in lli or the LLVM code generators. Can you please open a bugreport, attaching the LLVM IR. Ciao, Duncan. On 23/01/12 17:00, Pablo Barrio wrote: > Hi Duncan, >>> #include<stdio.h> >>> #include<string.h> >>> >>> int

Dear all, First of all, Merry Christmas! :) While testing a File I/O sample program, I've encountered a link failure due to missing implementation of "\01__isoc99_fscanf" function. I think this function should be named "__isoc99_fscanf" instead. Please see the program code and LLVM IR generated by DragonEgg and clang below. It shows that clang generates

Hi Pablo, in fact this is coming from the "ssp" attribute on main, which turns on LLVM's stack protection logic. I have no idea what that does exactly, but it seems to be causing the problem. On ubuntu systems it is enabled by default. You can turn it off by passing -fno-stack-protector to dragonegg. However please still open a bugreport since stack protection is supposed to work.

On Dec 27, 2009, at 11:41 AM, james woodyatt wrote: > everyone-- > > The OCaml bindings need help again. Please attach this as a .patch file and I'd be happy to apply it for you, -Chris > > diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml > --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800 > +++

Hi Pablo, > I came across something that seems to be a bug in the dragonegg option that > emits LLVM IR. ¿Can anybody reproduce the error, or see what's wrong? I can't reproduce this on x86-64 linux with latest LLVM+dragonegg+gcc-4.6. ¿Should I > post it somewhere else in case it's really a bug? Thanks ahead! > > With this simple program: > * > #include

Hi all, I came across something that seems to be a bug in the dragonegg option that emits LLVM IR. ¿Can anybody reproduce the error, or see what's wrong? ¿Should I post it somewhere else in case it's really a bug? Thanks ahead! With this simple program: * #include <stdio.h> #include <string.h> int main(int argc, char** argv){ char a[8] = "aaaaaaa";

>> The days of the old .ll parser are long gone, but is it too late to >> change? In case it is not, the attached patches implement just that >> :-) > I'm afraid you need to provide syntax autoupgrade until 4.0 Why, we moved to doing autoupgrade via bitcode quiet some time ago. There were quiet a few format changes to the .ll in the process. Cheers, Rafael

Hi Meador, this buildbot started failing last night and I think it was probably you! http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-test/builds/887 Here's a testcase. You can reproduce with "opt -instcombine". (The problem is that the code isn't expecting printf to return void). Ciao, Duncan. @.cst = linker_private unnamed_addr constant [8 x i8]

Hi, I had a problem with LLVM not emitting local variable info, even though I had calls to llvm.dbg.define. After some tracking I found that the llvm.dbg.declare (and probably value too) have to have a !dbg !nr after them to get emitted at all. maybe someone can adjust http://llvm.org/docs/SourceLevelDebugging.html#format_common_declare that the two llvm.dbg. functions need a !dbg line info

On 8 January 2013 17:01, Dmitri Gribenko <gribozavr at gmail.com> wrote: > r171853 for this one. Build not finished yet. > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4312 Thanks!! > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > > Looks like a better regex can fix this. > I think both of them are just bad FileChecks... This is

Eric Christopher <echristo at gmail.com> writes: > I'm not a huge fan of this because then you get to decide on a default > for all the ports, but I can understand if people want to move this > way to reduce uncertainty. FWIW, since it's one of the three targets Jim mentioned, -march=z10 is the obvious default for SystemZ. On the other hand, I think it's good to run

I think I understand the concepts, but I sure would appreciate a specific example, and I appreciate the offer. To make your life harder, could you start with what I should do given that I have not created a branch for the first patch? I just have the six files staged. I have GitHub Desktop installed, if that makes any of the steps easier. Thanks again, and no rush! At 8/10/2020 10:07 AM,

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,