similar to: [LLVMdev] MC ARM ELF local common variable alignment.

Hi, Can you please file a bug and Cc me directly on it? I'll go take a look soon. Thanks -jason On Wed, Jul 20, 2011 at 9:53 AM, TDYa127 <a127a127 at gmail.com> wrote: > Hi all, > > I noticed that the static local variable(internal global in .bc) is > not aligned in ARM ELF(use MC(-filetype=obj)). > Then I found that the alignment information is lost at: >

Hi, On SPU, variables in the .bss section that are allocated with the .lcomm directive are not aligned on 16 byte boundaries. This causes misaligned loads, as the generated assembly assumes this "default" alignment. A patch to disable .lcomm in favour of '.local .comm' is attached. kalle P.s. As an example, the following function returns '3', when '5' is

A missing u64 cast causes a 32-Bit wraparound from 4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected if card has 4096 Mib per FBP. Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c

Does anybody know if there is a particular reason why MCAsmStreamer doesn't have its own .h file? https://github.com/llvm-mirror/llvm/blob/0e66a5f53c74056f95d178c86531d7d9cfb23da9/lib/MC/MCAsmStreamer.cpp#L41 It seems like it is a good idea to have this class declared as its own module ( its own .cpp and .h files). That would make it easier to inherit from it if there is a need (like in my

There is a problem with Objective-C code where a null string is placed in the wrong section. If we have this code: #include <Foundation/Foundation.h> void foo() { NSLog(@""); } The null string is defined like this: .const .lcomm LC,1,0 ## LC Causing our linker to go nuts, because it expects anonymous strings to be in the __cstring section. I came up with the attached

On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote: > There is a problem with Objective-C code where a null string is placed > in the wrong section. If we have this code: > > #include <Foundation/Foundation.h> > void foo() { > NSLog(@""); > } > > The null string is defined like this: > > .const > .lcomm LC,1,0 ## LC > > Causing our

This is what I got from gcc -S t.c .file "t.c" .globl _x .data .align 4 _x: .long _test .lcomm _test,400 On Thu, Jan 21, 2010 at 4:07 PM, Chris Lattner <clattner at apple.com> wrote: > Can someone with cygwin/mingw access tell me what .s file gcc compiles > this .c file to: > > static int test[100]; > void *x = &test; > > Thanks! > > -Chris

On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This

Hello Ben Skeggs, The patch 97e5268d57bb: "drm/nouveau/fb/gf100-: rework ram detection" from Mar 2, 2017, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c:592 gf100_ram_ctor() warn: should 'size << 20' be a 64 bit type? drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c 572 gf100_ram_ctor(const struct nvkm_ram_func

On May 7, 2010, at 12:39 AM, Nathan Jeffords wrote: > On Fri, May 7, 2010 at 12:03 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: > > > I compile these two lines in llc > > > > @tst1 = internal global [4 x i8] zeroinitializer; > > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; >

Can someone with cygwin/mingw access tell me what .s file gcc compiles this .c file to: static int test[100]; void *x = &test; Thanks! -Chris

I've run the tests from clang-tests/trunk/gcc-4_2-testsuite on a Ubuntu x86-64 Linux box with the following results: === gcc Summary === # of expected passes 29946 # of unexpected failures 9938 # of unexpected successes 29 # of expected failures 28 # of unresolved testcases 1451 # of untested testcases 273 # of unsupported tests 811 pid is 4456

Hi John, On Wed, Sep 22, 2010 at 11:32 AM, John Thompson <john.thompson.jtsoftware at gmail.com> wrote: > I've run the tests from clang-tests/trunk/gcc-4_2-testsuite on a Ubuntu > x86-64 Linux box with the following results: > >         === gcc Summary === > > # of expected passes        29946 > # of unexpected failures    9938 > # of unexpected successes    29

I compile these two lines in llc @tst1 = internal global [4 x i8] zeroinitializer; @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; @tst1 is emited via MCStreamer::EmitCommonSymbol while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, is this the

CC llvm-dev ---------- Forwarded message ---------- Hello Duncan The size of ARM binaries created by clang has increased after r236642. Would you be able to find some time to look at my findings and share your thoughts about the problem, please? r236642 prevents emitting of temp label names into object files to save memory. This is fine, the label names do not appear in the resulting binaries.

Hello. That's what I've got from ld: /usr/lib/libxenguest.a(xg_private.o): In function `unlock_pages': (.text+0x490): multiple definition of `unlock_pages' /usr/lib/libxenctrl.a(xc_private.o):(.text+0x6a0): first defined here /usr/lib/libxenguest.a(xg_private.o): In function `lock_pages': (.text+0x4d0): multiple definition of `lock_pages'

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one

Assuming you're working with an ARM target, you may also hit a problem with the alignment option on the .comm directive. Attached is a first-cut patch for this latter problem. deep On Mon, Jan 25, 2010 at 5:42 PM, Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com> wrote: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed

Getting closer... When emitting symbols, how do I set the symbol's value to the address of the current instruction? Do I need to emit a label in the current section and another that uses the former to point to the latter? If possible, a code sample would be very helpful. And probably questions for Tim, are these "section-relative" mapping symbols, as defined in 4.6.5.1 of the

Great, thanks for your help. I'll take a crack at it and contact Renato if I have questions. -Greg On Wed, Oct 10, 2012 at 1:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Cool; glad to help. > > When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. > > -Jim >