search for: lcomm

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: lib/CodeGen/AsmPrinter/AsmPrinter.cpp:316 if (MAI->hasLCOMMDirective()) { // .lcomm _foo, 42 OutStreamer.EmitLocalCommonSymbol(GVSym, Size); return; } MCStreamer::EmitLocalCommonSymbol have no parameter about alignment. Is this issue will cause some problem? The original c code: ===========test-lcomm.c========= #include <stdio....

...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: > lib/CodeGen/AsmPrinter/AsmPrinter.cpp:316 > if (MAI->hasLCOMMDirective()) { > // .lcomm _foo, 42 > OutStreamer.EmitLocalCommonSymbol(GVSym, Size); > return; > } > > MCStreamer::EmitLocalCommonSymbol have no parameter about alignment. > > Is this issue will cause some problem? > > > > The original c code: &...

...os; 578 const u32 rsvd_head = ( 256 * 1024); /* vga memory */ 579 const u32 rsvd_tail = (1024 * 1024); /* vbios etc */ 580 enum nvkm_ram_type type = nvkm_fb_bios_memtype(bios); 581 u32 fbps = nvkm_rd32(device, 0x022438); 582 u64 total = 0, lcomm = ~0, lower, ubase, usize; ^^^^^^^^^^^^^ It's a u64. 583 int ret, fbp, ltcs, ltcn = 0; 584 585 nvkm_debug(subdev, "%d FBP(s)\n", fbps); 586 for (fbp = 0; fbp < fbps; fbp++) { 587 u32 size = func->probe...

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',...

...644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c @@ -589,7 +589,7 @@ gf100_ram_ctor(const struct nvkm_ram_func *func, struct nvkm_fb *fb, nvkm_debug(subdev, "FBP %d: %4d MiB, %d LTC(s)\n", fbp, size, ltcs); lcomm = min(lcomm, (u64)(size / ltcs) << 20); - total += size << 20; + total += (u64) size << 20; ltcn += ltcs; } else { nvkm_debug(subdev, "FBP %d: disabled\n", fbp); -- 2.7.4

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

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 patch, which places the string in the .cstring section. My GCC-fu isn't great. Could someone review this to see if I broke anything? Thanks! -bw -----...

...t; 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 patch, which > places the string in the .cstring section. > > My GCC-fu isn't great. Could someone review this to see if I broke...

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

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 > ______...

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

...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 patch, which >> places the string in the .cstring section. >> >> My GCC-fu isn't great. Could someo...

...tr); bool ParseDirectiveELFType(); // ELF specific ".type" - bool ParseDirectiveDarwinSymbolDesc(); // Darwin specific ".desc" - bool ParseDirectiveDarwinLsym(); // Darwin specific ".lsym" - - bool ParseDirectiveComm(bool IsLocal); // ".comm" and ".lcomm" - bool ParseDirectiveDarwinZerofill(); // Darwin specific ".zerofill" - bool ParseDirectiveDarwinTBSS(); // Darwin specific ".tbss" - - // Darwin specific ".subsections_via_symbols" - bool ParseDirectiveDarwinSubsectionsViaSymbols(); - // Darwin specific .du...

...er::EmitCommonSymbol, > > > > is this the expected behavior or should I fix it? > > This is expected behavior. tst1 should be emitted with something like: > > .local _tst1 > .comm _tst1, ... > > based on the exact syntax of your target. If your target supports .lcomm, you can also enable that. > > -Chris > > This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm lan...

I just got this error message from the GNU assembler: Error: alignment too large: 15 assumed Which made me laugh at first. The corresponding input line was: .align 16 Apparently what's going on here is that ".align 16" is ambiguous: on some architectures it means ".balign 16", and on some it means ".p2align 16", which would mean ".balign 65536" if

...verbose) flag. I have a 6 mb log file from this run if needed. ~/gcc-4_2-testsuite$ find . -print | wc 36392 36392 1687901 Some output from the first few failed tests: Testing gcc.apple/5490617.c doing compile pid is 17502 -17502 output is status 0 FAIL: gcc.apple/5490617.c scan-assembler .lcomm __my_endbss Testing gcc.apple/4104248.c doing compile pid is 17445 -17445 close result is 17445 exp8 0 1 output is ilp3217400.c:2: error: array size is negative status 1 Testing gcc.apple/4641942.c doing compile pid is 17481 -17481 output is status 0 FAIL: gcc.apple/4641942.c (test for warning...

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

...if needed. > > ~/gcc-4_2-testsuite$ find . -print | wc >   36392   36392 1687901 > > Some output from the first few failed tests: > > Testing gcc.apple/5490617.c > doing compile > pid is 17502 -17502 > output is  status 0 > FAIL: gcc.apple/5490617.c scan-assembler .lcomm __my_endbss > > Testing gcc.apple/4104248.c > doing compile > pid is 17445 -17445 > close result is 17445 exp8 0 1 > output is ilp3217400.c:2: error: array size is negative >  status 1 > > Testing gcc.apple/4641942.c > doing compile > pid is 17481 -17481 > output...

...messages: gzip.4.s:2007: Error: value of 326712 too large for field of 2 bytes at 6994 ... The line 2007 looks like: ... ld 6, block_start at l(6) ... Where the symbol block_start is defined at the end of gzip.s as ... .section .bss,"aw", at nobits ... .lcomm block_start,8 # 'block_start' ... Is there something wrong with my cross-compiler or is the llc-generated code bad? Thanks, Andi

When the .bc file contains an array as the following: @.str = private global [7 x i8] zeroinitializer "llc -march=x86" generates the following x86 assembly lines: .data .lcomm L_.str,7 And trying to compile it with clang generates an error: "fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x3". Is that fixable? Thanks! Alon ________________________________ This message is confidential and intended only for the addressee. If you ha...