search for: __clz_tab

Hi, Here is the follow on patch for this problem. Please apply this from the top of the tree and rebuild. -------------- next part -------------- A non-text attachment was scrubbed... Name: op Type: application/octet-stream Size: 2548 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060315/eee8a766/attachment.obj> -------------- next part

...getString(Field)); } } Which comes from this: void TypeDesc::ApplyToFields(DIVisitor *Visitor) { DebugInfoDesc::ApplyToFields(Visitor); Visitor->Apply(Context); Visitor->Apply(Name); Name is empty. Here's a minimal testcase that reproduces the crash: unsigned __clz_tab[] = {0}; just invoke cc1 as given in the beginning of this email with this text as input. The problem is that llvm-debug.cpp:GetNodeName returns "" for the name of type of "__clz_tab", which is the root cause of the crash. I don't know why TYPE_NAME returns NULL, but I a...

On Wed, 15 Mar 2006, Vladimir Prus wrote: >> Please give it a try and let me know if it works any better for you! > > Here we go: Wow, you are good at finding problems! Thanks! > -fvisibility=hidden -DHIDE_EXPORTS > -c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_fixunsxfdi.o > cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h:72: void >

...842a mv s0,a0 10170: 00a7c863 blt a5,a0,10180 <foo+0x1c> 10174: 85aa mv a1,a0 10176: 0001a537 lui a0,0x1a 1017a: 6a050513 addi a0,a0,1696 # 1a6a0 <__clz_tab+0x100> 1017e: 2a69 jal 10318 <printf> 10180: 40b2 lw ra,12(sp) 10182: 8522 mv a0,s0 10184: 4422 lw s0,8(sp) 10186: 0141 addi sp,...

...;> 10170: 00a7c863 blt a5,a0,10180 <foo+0x1c> >> 10174: 85aa mv a1,a0 >> 10176: 0001a537 lui a0,0x1a >> 1017a: 6a050513 addi a0,a0,1696 # 1a6a0 >> <__clz_tab+0x100> >> 1017e: 2a69 jal 10318 <printf> >> 10180: 40b2 lw ra,12(sp) >> 10182: 8522 mv a0,s0 >> 10184: 4422 lw s0,8(sp) >> 101...

Hi, Does lld support linker relaxation that may shrink code size? As far as I see lld seems to assume that the content of input sections to be fixed other than patching up relocations, but I believe some targets may benefit the extra optimization opportunity with relaxation. Specifically, I'm currently working on adding support for RISC-V in lld, and RISC-V heavily relies on linker relaxation