similar to: GlobalVariable I inserted gets removed by LTO

Hi Tim, The global merge pass puts the GVs into a sturcture to guarantee their address are contiguous. It works for static GVs but for global hidden GVs, this will cause name resoltion fail during linking .o into .so Any thoughs? Thanks, Weiming > Hi Weiming, > > On 12 March 2014 17:43, Weiming Zhao <weimingz at codeaurora.org> wrote: >> Clang will emit 1 GOT entry for

On Mon, Jul 27, 2009 at 1:13 PM, Dan Gohman<gohman at apple.com> wrote: > > On Jul 27, 2009, at 10:10 AM, Devang Patel wrote: > > >> In LLVM IR metadata is used to attach auxiliary information with >> various IR constructs. Currently metadata information is represented >> using MDNode and MDString. The metadata can refer to LLVM values but >> these

On Jul 27, 2009, at 3:05 PM, Devang Patel wrote: > On Mon, Jul 27, 2009 at 1:13 PM, Dan Gohman<gohman at apple.com> wrote: > >> >> >> On Jul 27, 2009, at 10:10 AM, Devang Patel wrote: >> >> >> >> >> >>> In LLVM IR metadata is used to attach auxiliary information with >>> >>> various IR constructs. Currently

Hi Karthik, Thank you very much, you made me much more relaxed. Below is getfattr output for a file from all the bricks: root at gv2 ~ # getfattr -d -e hex -m . /data/glusterfs/testset/306/30677af808ad578916f54783904e6342.pack getfattr: Removing leading '/' from absolute path names # file: data/glusterfs/testset/306/30677af808ad578916f54783904e6342.pack

Hi Karthik, Thank you for your reply. The heal is still undergoing, as the /var/log/glusterfs/glustershd.log keeps growing, and there's a lot of pending entries in the heal info. The gluster version is 3.10.9 and 3.10.10 (the version update in progress). It doesn't have info summary [yet?], and the heal info is way too long to attach here. (It takes more than 20 minutes just to collect

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr

Hi David, On Thu, Jul 9, 2009 at 10:26 AM, David Greene<dag at cray.com> wrote: > On Thursday 09 July 2009 10:01, John Criswell wrote: >> Dear All, >> >> To add to this, what you want to do is find the appropriate debug stop >> point intrinsic and then use it to look up the information for that >> instruction. > > Ick.  So line number information is

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

Hi, Is anyone here using smb:// URLs to access "Windows" shares? I've been doing this for a while with common file systems at work, and it used to work just fine. Then I while back, I started getting issues; I will now just keep getting asked for a password when I try to access something through smb://. I thought at first that this meant there had been some kind of change

> On Mar 11, 2016, at 12:16 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 11 March 2016 at 14:58, John McCall <rjmccall at apple.com> wrote: >>> On Mar 11, 2016, at 11:26 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> Now, there are a number of things about linkage that are kindof orthogonal, >>>> and it

On Thu, Aug 24, 2017 at 6:30 PM, Justin Bogner <mail at justinbogner.com> wrote: > Peter Collingbourne <peter at pcc.me.uk> writes: > > On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> > wrote: > > > >> > >> > >> On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > >> wrote:

Sorry I am late to the thread. I've been meaning to find the time to respond properly. 1. Yes, the default behavior is to keep GV and function in the same memory buffer. The reason is the JIT can be used in a client and server environment. This makes it possible without doing expensive relocation on the fly. In fact, the currently implementation doesn't allow the client to do

On Oct 14, 2008, at 2:32 PM, Nuno Lopes wrote: > [resending since the previous copy was apparently dropped by the > mailing > list] > >>> Today I found a nice bug in the JIT global variable emitter. >>> The problem may lead to an assert() failure when doing the >>> following: >>> 1) compile some function >>> 2) emit a global variable

Hi, When I’m compiling a code with –fvisibility=hidden –fPIC for ARM, I find that LLVM generates less optimized code than GCC. For example: test.cpp: void init(void *); int g0[100]; int g1[100]; int g2[100]; void foo() { init(&g0); init(&g1); init(&g2); } Clang will emit 1 GOT entry for each GV and 2 instructions to get the address: ldr

Hey, Did the heal completed and you still have some entries pending heal? If yes then can you provide the following informations to debug the issue. 1. Which version of gluster you are running 2. gluster volume heal <volname> info summary or gluster volume heal <volname> info 3. getfattr -d -e hex -m . <filepath-on-brick> output of any one of the which is pending heal from all

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

Hi folks, I'm troubled moving an arbiter brick to another server because of I/O load issues. My setup is as follows: # gluster volume info Volume Name: myvol Type: Distributed-Replicate Volume ID: 43ba517a-ac09-461e-99da-a197759a7dc8 Status: Started Snapshot Count: 0 Number of Bricks: 3 x (2 + 1) = 9 Transport-type: tcp Bricks: Brick1: gv0:/data/glusterfs Brick2: gv1:/data/glusterfs Brick3:

I am getting a timeout on running totem .... searching led me to think its gvs related.... Error creating proxy: Error calling StartServiceByName for org.gtk.vfs.GoaVolumeMonitor: Timeout was reached (g-io-error-quark, 24) Then totem does start - but with like a 30 second delay. I ran this command and it says its inactive systemctl --user status gvfs-mtp-volume-monitor.service ?

On Jul 27, 2009, at 10:10 AM, Devang Patel wrote: > In LLVM IR metadata is used to attach auxiliary information with > various IR constructs. Currently metadata information is represented > using MDNode and MDString. The metadata can refer to LLVM values but > these references are not counted as regular "uses" of these values > because metadata is maintained 'on the

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module